# Table of Contents - [Overview | Kubernetes](#overview-kubernetes) - [Instalasi Add-ons | Kubernetes](#instalasi-add-ons-kubernetes) - [安装扩展（Addon） | Kubernetes](#-addon-kubernetes) - [使用 kubeconfig 文件组织集群访问 | Kubernetes](#-kubeconfig-kubernetes) - [Kubernetes | Kubernetes](#kubernetes-kubernetes) - [アドオンのインストール | Kubernetes](#-kubernetes) - [kubeconfigファイルを使用してクラスターアクセスを組織する | Kubernetes](#kubeconfig-kubernetes) - [애드온 설치 | Kubernetes](#-kubernetes) - [kubeconfig 파일을 사용하여 클러스터 접근 구성하기 | Kubernetes](#kubeconfig-kubernetes) - [Configurazione | Kubernetes](#configurazione-kubernetes) - [Instalando Complementos | Kubernetes](#instalando-complementos-kubernetes) - [Organizando o acesso ao cluster usando arquivos kubeconfig | Kubernetes](#organizando-o-acesso-ao-cluster-usando-arquivos-kubeconfig-kubernetes) - [Architettura di Kubernetes | Kubernetes](#architettura-di-kubernetes-kubernetes) - [Containers | Kubernetes](#containers-kubernetes) - [Documentazione di Kubernetes | Kubernetes](#documentazione-di-kubernetes-kubernetes) - [Tutorials | Kubernetes](#tutorials-kubernetes) - [Manage Cluster Daemons | Kubernetes](#manage-cluster-daemons-kubernetes) - [नीतियाँ | Kubernetes](#-kubernetes) - [Other Tools | Kubernetes](#other-tools-kubernetes) - [उत्पादन वातावरण | Kubernetes](#-kubernetes) - [शुरू करना | Kubernetes](#-kubernetes) - [Networking | Kubernetes](#networking-kubernetes) - [Concetti | Kubernetes](#concetti-kubernetes) - [Przechowywanie danych | Kubernetes](#przechowywanie-danych-kubernetes) - [Kubernetes Documentation | Kubernetes](#kubernetes-documentation-kubernetes) - [कुबेरनेट्स प्रलेखन | Kubernetes](#-kubernetes) - [Kubernetes Dokumentation | Kubernetes](#kubernetes-dokumentation-kubernetes) - [उत्तम प्रथाएं | Kubernetes](#-kubernetes) - [Administrasi Klaster | Kubernetes](#administrasi-klaster-kubernetes) - [Konfiguracja | Kubernetes](#konfiguracja-kubernetes) - [Amministrazione del Cluster | Kubernetes](#amministrazione-del-cluster-kubernetes) - [Kubernetes — Dokumentacja | Kubernetes](#kubernetes-dokumentacja-kubernetes) - [TLS | Kubernetes](#tls-kubernetes) - [Kubectl Reference Docs](#kubectl-reference-docs) - [Polityki | Kubernetes](#polityki-kubernetes) - [कुबेरनेटेस डॉक्स में योगदान दे | Kubernetes](#-kubernetes) - [Styl dokumentacji | Kubernetes](#styl-dokumentacji-kubernetes) - [Documentazione | Kubernetes](#documentazione-kubernetes) - [शेडुलिंग | Kubernetes](#-kubernetes) - [Współtworzenie nowych treści | Kubernetes](#wsp-tworzenie-nowych-tre-ci-kubernetes) - [उपकरण स्थापित करें | Kubernetes](#-kubernetes) - [404 Page not found | Kubernetes](#404-page-not-found-kubernetes) - [Kontenery | Kubernetes](#kontenery-kubernetes) - [Aktualizacja materiałów źródłowych | Kubernetes](#aktualizacja-materia-w-r-d-owych-kubernetes) - [अन्य उपकरण | Kubernetes](#-kubernetes) - [Pojęcia | Kubernetes](#poj-cia-kubernetes) - [Event Rate Limit Configuration (v1alpha1) | Kubernetes](#event-rate-limit-configuration-v1alpha1-kubernetes) - [IPv4/IPv6 双协议栈 | Kubernetes](#ipv4-ipv6-kubernetes) - [生产环境 | Kubernetes](#-kubernetes) - [Kubernetes 问题和安全 | Kubernetes](#kubernetes-kubernetes) - [부트스트랩 토큰을 사용한 인증 | Kubernetes](#-kubernetes) - [Kubernetes 安全和信息披露 | Kubernetes](#kubernetes-kubernetes) - [Kubelet CredentialProvider (v1) | Kubernetes](#kubelet-credentialprovider-v1-kubernetes) - [Установка дополнений | Kubernetes](#-kubernetes) - [Kubernetes Secret 良好实践 | Kubernetes](#kubernetes-secret-kubernetes) - [CSI 卷克隆 | Kubernetes](#csi-kubernetes) - [外部 API | Kubernetes](#-api-kubernetes) - [Storage | Kubernetes](#storage-kubernetes) - [Linux 节点的交换（Swap）行为 | Kubernetes](#linux-swap-kubernetes) - [由 kubelet 填充的节点标签 | Kubernetes](#-kubelet-kubernetes) - [Ikhtisar | Kubernetes](#ikhtisar-kubernetes) - [Memberlakukan Standar Keamanan Pod | Kubernetes](#memberlakukan-standar-keamanan-pod-kubernetes) - [调试集群 | Kubernetes](#-kubernetes) - [运行于多可用区环境 | Kubernetes](#-kubernetes) - [Официальный CVE-фид | Kubernetes](#-cve-kubernetes) - [Utilizando Autorização ABAC | Kubernetes](#utilizando-autoriza-o-abac-kubernetes) - [kube-apiserver Audit 配置（v1） | Kubernetes](#kube-apiserver-audit-v1-kubernetes) - [কুবারনেটিসে অবদান | Kubernetes](#-kubernetes) - [Unterstützte Versionen der Kubernetes-Dokumentation | Kubernetes](#unterst-tzte-versionen-der-kubernetes-dokumentation-kubernetes) - [kubelet 所使用的本地文件和路径 | Kubernetes](#kubelet-kubernetes) - [PKI証明書とその要件 | Kubernetes](#pki-kubernetes) - [组件工具 | Kubernetes](#-kubernetes) - [工作负载 | Kubernetes](#-kubernetes) - [Windows 存储 | Kubernetes](#windows-kubernetes) - [工作负载管理 | Kubernetes](#-kubernetes) - [Visão Geral de Autorização | Kubernetes](#vis-o-geral-de-autoriza-o-kubernetes) - [Services, Load Balancing, dan Jaringan | Kubernetes](#services-load-balancing-dan-jaringan-kubernetes) - [서비스가 지원하는 프로토콜 | Kubernetes](#-kubernetes) - [Connecting Applications with Services | Kubernetes](#connecting-applications-with-services-kubernetes) - [VolumeSnapshotClass | Kubernetes](#volumesnapshotclass-kubernetes) - [进程 ID 约束与预留 | Kubernetes](#-id-kubernetes) - [Keamanan | Kubernetes](#keamanan-kubernetes) - [Addons Installieren | Kubernetes](#addons-installieren-kubernetes) - [Supervisión del Estado del Volumen | Kubernetes](#supervisi-n-del-estado-del-volumen-kubernetes) - [Berpartisipasi dalam SIG Docs | Kubernetes](#berpartisipasi-dalam-sig-docs-kubernetes) - [客户端身份认证（Client Authentication）(v1beta1) | Kubernetes](#-client-authentication-v1beta1-kubernetes) - [kubelet systemd 看门狗 | Kubernetes](#kubelet-systemd-kubernetes) - [Pod 安全性准入 | Kubernetes](#pod-kubernetes) - [Pods | Kubernetes](#pods-kubernetes) - [Arsitektur Kubernetes | Kubernetes](#arsitektur-kubernetes-kubernetes) - [Resourcen-Verwaltung für Pods und Container | Kubernetes](#resourcen-verwaltung-f-r-pods-und-container-kubernetes) - [Windows 节点的安全性 | Kubernetes](#windows-kubernetes) - [Acceder al clúster y las aplicaciones | Kubernetes](#acceder-al-cl-ster-y-las-aplicaciones-kubernetes) - [Pertimbangan untuk klaster besar | Kubernetes](#pertimbangan-untuk-klaster-besar-kubernetes) - [Image Policy API (v1alpha1) | Kubernetes](#image-policy-api-v1alpha1-kubernetes) - [容器 | Kubernetes](#-kubernetes) - [노드 레퍼런스 정보 | Kubernetes](#-kubernetes) - [Imagens | Kubernetes](#imagens-kubernetes) - [네트워킹 레퍼런스 | Kubernetes](#-kubernetes) - [Persistent Volume | Kubernetes](#persistent-volume-kubernetes) - [Kubernetes 自定义指标 (v1beta2) | Kubernetes](#kubernetes-v1beta2-kubernetes) - [自动扩缩工作负载 | Kubernetes](#-kubernetes) - [Comunicação entre Nós e a Camada de Gerenciamento | Kubernetes](#comunica-o-entre-n-s-e-a-camada-de-gerenciamento-kubernetes) - [Tài liệu tham khảo | Kubernetes](#t-i-li-u-tham-kh-o-kubernetes) - [Podセキュリティ標準の強制 | Kubernetes](#pod-kubernetes) - [Instalación de Complementos (AddOns) | Kubernetes](#instalaci-n-de-complementos-addons-kubernetes) - [提出内容改进建议 | Kubernetes](#-kubernetes) - [容器环境 | Kubernetes](#-kubernetes) - [Service 与 Pod 的 DNS | Kubernetes](#service-pod-dns-kubernetes) - [NetworkPolicy | Kubernetes](#networkpolicy-kubernetes) - [Ingress 控制器 | Kubernetes](#ingress-kubernetes) - [安装工具 | Kubernetes](#-kubernetes) - [Kubernetes z-pages | Kubernetes](#kubernetes-z-pages-kubernetes) - [kubelet 配置 (v1alpha1) | Kubernetes](#kubelet-v1alpha1-kubernetes) - [Überblick | Kubernetes](#-berblick-kubernetes) - [Kubernetes Architektur | Kubernetes](#kubernetes-architektur-kubernetes) - [Workloads | Kubernetes](#workloads-kubernetes) - [混合版本代理 | Kubernetes](#-kubernetes) - [端口和协议 | Kubernetes](#-kubernetes) - [Runtime Container | Kubernetes](#runtime-container-kubernetes) - [KYAML 参考 | Kubernetes](#kyaml-kubernetes) - [云原生安全和 Kubernetes | Kubernetes](#-kubernetes-kubernetes) - [大規模クラスターの構築 | Kubernetes](#-kubernetes) - [Über cgroup v2 | Kubernetes](#-ber-cgroup-v2-kubernetes) - [Pod 安全策略 | Kubernetes](#pod-kubernetes) - [Ferramentas de Configuração | Kubernetes](#ferramentas-de-configura-o-kubernetes) - [网络策略 | Kubernetes](#-kubernetes) - [Speicher | Kubernetes](#speicher-kubernetes) - [Ingress | Kubernetes](#ingress-kubernetes) - [ノードのセットアップの検証 | Kubernetes](#-kubernetes) - [Сборщик мусора | Kubernetes](#-kubernetes) - [ওভারভিউ | Kubernetes](#-kubernetes) - [容器运行时 | Kubernetes](#-kubernetes) - [ネットワーキングのリファレンス | Kubernetes](#-kubernetes) - [콘텐츠 개선 제안하기 | Kubernetes](#-kubernetes) - [Coleta de Lixo | Kubernetes](#coleta-de-lixo-kubernetes) - [存储 | Kubernetes](#-kubernetes) - [动态卷制备 | Kubernetes](#-kubernetes) - [Unknown](#unknown) - [Turnkey 云解决方案 | Kubernetes](#turnkey-kubernetes) - [使用部署工具安装 Kubernetes | Kubernetes](#-kubernetes-kubernetes) - [配置 | Kubernetes](#-kubernetes) - [Pengklonaan Volume CSI | Kubernetes](#pengklonaan-volume-csi-kubernetes) - [Service | Kubernetes](#service-kubernetes) - [Alokasi ClusterIP pada servis (Service ClusterIP allocation) | Kubernetes](#alokasi-clusterip-pada-servis-service-clusterip-allocation-kubernetes) - [Visão Geral da Segurança Cloud Native | Kubernetes](#vis-o-geral-da-seguran-a-cloud-native-kubernetes) - [参与 SIG Docs | Kubernetes](#-sig-docs-kubernetes) - [Kubernetes 指标 (v1beta1) | Kubernetes](#kubernetes-v1beta1-kubernetes) - [官方 CVE 订阅源 | Kubernetes](#-cve-kubernetes) - [プロダクション環境 | Kubernetes](#-kubernetes) - [Persiapan | Kubernetes](#persiapan-kubernetes) - [Secrets | Kubernetes](#secrets-kubernetes) - [Ingress | Kubernetes](#ingress-kubernetes) - [Versi Dokumentasi yang Tersedia | Kubernetes](#versi-dokumentasi-yang-tersedia-kubernetes) - [도커심 제거 및 CRI 호환 런타임 사용에 대한 기사 | Kubernetes](#-cri-kubernetes) - [存活、就绪和启动探针 | Kubernetes](#-kubernetes) - [KubeletチェックポイントAPI | Kubernetes](#kubelet-api-kubernetes) - [Best practices | Kubernetes](#best-practices-kubernetes) - [Service 所用的协议 | Kubernetes](#service-kubernetes) - [IPv4/IPv6 dual-stack | Kubernetes](#ipv4-ipv6-dual-stack-kubernetes) - [Problèmes et alertes de sécurité de Kubernetes | Kubernetes](#probl-mes-et-alertes-de-s-curit-de-kubernetes-kubernetes) - [Kontainer Environment | Kubernetes](#kontainer-environment-kubernetes) - [DNS untuk Service dan Pod | Kubernetes](#dns-untuk-service-dan-pod-kubernetes) - [Überwachung, Protokollierung und Fehlerbehebung | Kubernetes](#-berwachung-protokollierung-und-fehlerbehebung-kubernetes) - [Visão Geral | Kubernetes](#vis-o-geral-kubernetes) - [卷 | Kubernetes](#-kubernetes) - [Referencia | Kubernetes](#referencia-kubernetes) - [Formación en línea | Kubernetes](#formaci-n-en-l-nea-kubernetes) - [Kubernetes Vulnerability Announcements - CVE Feed](#kubernetes-vulnerability-announcements-cve-feed) - [外部 API | Kubernetes](#-api-kubernetes) - [Gateway API | Kubernetes](#gateway-api-kubernetes) - [服务、负载均衡和联网 | Kubernetes](#-kubernetes) - [Dienste, Lastverteilung und Netzwerkfunktionen | Kubernetes](#dienste-lastverteilung-und-netzwerkfunktionen-kubernetes) - [调试集群 | Kubernetes](#-kubernetes) - [Notes | Kubernetes](#notes-kubernetes) - [Kubernetes 问题和安全 | Kubernetes](#kubernetes-kubernetes) - [Berkontribusi ke Dokumentasi Kubernetes | Kubernetes](#berkontribusi-ke-dokumentasi-kubernetes-kubernetes) - [টাস্ক | Kubernetes](#-kubernetes) - [Image | Kubernetes](#image-kubernetes) - [Aplicaciones Stateless | Kubernetes](#aplicaciones-stateless-kubernetes) - [কুবারনেটিসে অবদান | Kubernetes](#-kubernetes) - [Container | Kubernetes](#container-kubernetes) - [Огляд | Kubernetes](#-kubernetes) - [Configurar pods y contenedores | Kubernetes](#configurar-pods-y-contenedores-kubernetes) - [Проблемы и безопасность Kubernetes | Kubernetes](#-kubernetes-kubernetes) - [Extender la API de Kubernetes | Kubernetes](#extender-la-api-de-kubernetes-kubernetes) - [Speicher | Kubernetes](#speicher-kubernetes) - [Inyectar datos en las aplicaciones | Kubernetes](#inyectar-datos-en-las-aplicaciones-kubernetes) - [네트워킹 레퍼런스 | Kubernetes](#-kubernetes) - [Administrar un clúster | Kubernetes](#administrar-un-cl-ster-kubernetes) - [Herramientas de configuración | Kubernetes](#herramientas-de-configuraci-n-kubernetes) - [ターンキークラウドソリューション | Kubernetes](#-kubernetes) - [স্টোরেজ | Kubernetes](#-kubernetes) - [ネットワーキングのリファレンス | Kubernetes](#-kubernetes) - [সার্ভিস, লোড ব্যালেন্সিং এবং নেটওয়ার্কিং | Kubernetes](#-kubernetes) - [最佳实践 | Kubernetes](#-kubernetes) - [Расширения Kubernetes | Kubernetes](#-kubernetes-kubernetes) - [Setup | Kubernetes](#setup-kubernetes) - [Services | Kubernetes](#services-kubernetes) - [Gestionar y ejecutar aplicaciones | Kubernetes](#gestionar-y-ejecutar-aplicaciones-kubernetes) - [Praktek-praktek Terbaik | Kubernetes](#praktek-praktek-terbaik-kubernetes) - [Tổng quan | Kubernetes](#t-ng-quan-kubernetes) - [Среда обучения | Kubernetes](#-kubernetes) - [Monitoreo, Logging y Depuración | Kubernetes](#monitoreo-logging-y-depuraci-n-kubernetes) - [Políticas | Kubernetes](#pol-ticas-kubernetes) - [클러스터 아키텍처 | Kubernetes](#-kubernetes) - [Contribuir a la documentación de Kubernetes | Kubernetes](#contribuir-a-la-documentaci-n-de-kubernetes-kubernetes) - [Kontainer | Kubernetes](#kontainer-kubernetes) - [Kubernetes Configuration Good Practices | Kubernetes](#kubernetes-configuration-good-practices-kubernetes) - [Administration d'un cluster | Kubernetes](#administration-d-un-cluster-kubernetes) - [Настройка | Kubernetes](#-kubernetes) - [কুবারনেটিসে উইন্ডোজ | Kubernetes](#-kubernetes) - [节点参考信息 | Kubernetes](#-kubernetes) - [কনফিগারেশন | Kubernetes](#-kubernetes) - [API 접근 제어 | Kubernetes](#api-kubernetes) - [SIG Docsへの参加 | Kubernetes](#sig-docs-kubernetes) - [Contêineres | Kubernetes](#cont-ineres-kubernetes) - [Arquitectura de Kubernetes | Kubernetes](#arquitectura-de-kubernetes-kubernetes) - [쿠버네티스 이슈와 보안 | Kubernetes](#-kubernetes) - [ベストプラクティス | Kubernetes](#-kubernetes) - [Seguridad | Kubernetes](#seguridad-kubernetes) - [শিডিউলিং, প্রিএম্পশন এবং ইভিকশন (Scheduling, Preemption and Eviction) | Kubernetes](#-scheduling-preemption-and-eviction-kubernetes) - [TLS | Kubernetes](#tls-kubernetes) - [নীতিমালা | Kubernetes](#-kubernetes) - [쿠버네티스 기초 학습 | Kubernetes](#-kubernetes) - [セットアップツールのリファレンス | Kubernetes](#-kubernetes) - [노드 레퍼런스 정보 | Kubernetes](#-kubernetes) - [設定 | Kubernetes](#-kubernetes) - [セキュリティ | Kubernetes](#-kubernetes) --- # Overview | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/concepts/overview/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/concepts/overview/) . Overview ======== * 1: [Cos'è Kubernetes?](https://kubernetes.io/it/docs/concepts/overview/_print/#pg-45bdca6129cf540121623e903c18ba46) * 2: [I componenti di Kubernetes](https://kubernetes.io/it/docs/concepts/overview/_print/#pg-13b0f1dbe89228e3d76d2ac231e245f1) * 3: [Le API di Kubernetes](https://kubernetes.io/it/docs/concepts/overview/_print/#pg-0c745f42e623d2b70a53bc0e6db73d95) 1 - Cos'è Kubernetes? ===================== Kubernetes è una piattaforma portatile, estensibile e open-source per la gestione di carichi di lavoro e servizi containerizzati, in grado di facilitare sia la configurazione dichiarativa che l'automazione. La piattaforma vanta un grande ecosistema in rapida crescita. Servizi, supporto e strumenti sono ampiamente disponibili nel mondo Kubernetes . Questa pagina è una panoramica generale su Kubernetes. Kubernetes è una piattaforma portatile, estensibile e open-source per la gestione di carichi di lavoro e servizi containerizzati, in grado di facilitare sia la configurazione dichiarativa che l'automazione. La piattaforma vanta un grande ecosistema in rapida crescita. Servizi, supporto e strumenti sono ampiamente disponibili nel mondo Kubernetes . Il nome Kubernetes deriva dal greco, significa timoniere o pilota. Google ha reso open-source il progetto Kubernetes nel 2014. Kubernetes unisce [oltre quindici anni di esperienza di Google](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/) nella gestione di carichi di lavoro di produzione su scala mondiale con le migliori idee e pratiche della comunità. Facciamo un piccolo salto indietro ---------------------------------- Diamo un'occhiata alla ragione per cui Kubernetes è così utile facendo un piccolo salto indietro nel tempo. ![Deployment evolution](https://kubernetes.io/images/docs/Container_Evolution.svg) **L'era del deployment tradizionale:** All'inizio, le organizzazioni eseguivano applicazioni su server fisici. Non c'era modo di definire i limiti delle risorse per le applicazioni in un server fisico e questo ha causato non pochi problemi di allocazione delle risorse. Ad esempio, se più applicazioni vengono eseguite sullo stesso server fisico, si possono verificare casi in cui un'applicazione assorbe la maggior parte delle risorse e, di conseguenza, le altre applicazioni non hanno le prestazioni attese. Una soluzione per questo sarebbe di eseguire ogni applicazione su un server fisico diverso. Ma questa non è una soluzione ideale, dal momento che le risorse vengono sottoutilizzate, inoltre, questa pratica risulta essere costosa per le organizzazioni, le quali devono mantenere numerosi server fisici. **L'era del deployment virtualizzato:** Come soluzione venne introdotta la virtualizzazione. Essa consente di eseguire più macchine virtuali (VM) su una singola CPU fisica. La virtualizzazione consente di isolare le applicazioni in più macchine virtuali e fornisce un livello di sicurezza superiore, dal momento che le informazioni di un'applicazione non sono liberamente accessibili da un'altra applicazione. La virtualizzazione consente un migliore utilizzo delle risorse riducendo i costi per l'hardware, permette una migliore scalabilità, dato che un'applicazione può essere aggiunta o aggiornata facilmente, e ha molti altri vantaggi. Ogni VM è una macchina completa che esegue tutti i componenti, compreso il proprio sistema operativo, sopra all'hardware virtualizzato. **L'era del deployment in container:** I container sono simili alle macchine virtuali, ma presentano un modello di isolamento più leggero, condividendo il sistema operativo (OS) tra le applicazioni. Pertanto, i container sono considerati più leggeri. Analogamente a una macchina virtuale, un container dispone di una segregazione di filesystem, CPU, memoria, PID e altro ancora. Poiché sono disaccoppiati dall'infrastruttura sottostante, risultano portabili tra differenti cloud e diverse distribuzioni. I container sono diventati popolari dal momento che offrono molteplici vantaggi, ad esempio: * Creazione e distribuzione di applicazioni in modalità Agile: maggiore facilità ed efficienza nella creazione di immagini container rispetto all'uso di immagini VM. * Adozione di pratiche per lo sviluppo/test/rilascio continuativo: consente la frequente creazione e la distribuzione di container image affidabili, dando la possibilità di fare rollback rapidi e semplici (grazie all'immutabilità dell'immagine stessa). * Separazione delle fasi di Dev e Ops: le container image vengono prodotte al momento della compilazione dell'applicativo piuttosto che nel momento del rilascio, permettendo così di disaccoppiare le applicazioni dall'infrastruttura sottostante. * L'osservabilità non riguarda solo le informazioni e le metriche del sistema operativo, ma anche lo stato di salute e altri segnali dalle applicazioni. * Coerenza di ambiente tra sviluppo, test e produzione: i container funzionano allo stesso modo su un computer portatile come nel cloud. * Portabilità tra cloud e sistemi operativi differenti: lo stesso container funziona su Ubuntu, RHEL, CoreOS, on-premise, nei più grandi cloud pubblici e da qualsiasi altra parte. * Gestione incentrata sulle applicazioni: Aumenta il livello di astrazione dall'esecuzione di un sistema operativo su hardware virtualizzato all'esecuzione di un'applicazione su un sistema operativo utilizzando risorse logiche. * Microservizi liberamente combinabili, distribuiti, ad alta scalabilità: le applicazioni sono suddivise in pezzi più piccoli e indipendenti che possono essere distribuite e gestite dinamicamente - niente stack monolitici che girano su una singola grande macchina. * Isolamento delle risorse: le prestazioni delle applicazioni sono prevedibili. * Utilizzo delle risorse: alta efficienza e densità. Perché necessito di Kubernetes e cosa posso farci ------------------------------------------------- I container sono un buon modo per distribuire ed eseguire le tue applicazioni. In un ambiente di produzione, è necessario gestire i container che eseguono le applicazioni e garantire che non si verifichino interruzioni dei servizi. Per esempio, se un container si interrompe, è necessario avviare un nuovo container. Non sarebbe più facile se questo comportamento fosse gestito direttamente da un sistema? È proprio qui che Kubernetes viene in soccorso! Kubernetes ti fornisce un framework per far funzionare i sistemi distribuiti in modo resiliente. Kubernetes si occupa della scalabilità, failover, distribuzione delle tue applicazioni. Per esempio, Kubernetes può facilmente gestire i rilasci con modalità Canary deployment. Kubernetes ti fornisce: * **Scoperta dei servizi e bilanciamento del carico** Kubernetes può esporre un container usando un nome DNS o il suo indirizzo IP. Se il traffico verso un container è alto, Kubernetes è in grado di distribuire il traffico su più container in modo che il servizio rimanga stabile. * **Orchestrazione dello storage** Kubernetes ti permette di montare automaticamente un sistema di archiviazione di vostra scelta, come per esempio storage locale, dischi forniti da cloud pubblici, e altro ancora. * **Rollout e rollback automatizzati** Puoi utilizzare Kubernetes per descrivere lo stato desiderato per i propri container, e Kubernetes si occuperà di cambiare lo stato attuale per raggiungere quello desiderato ad una velocità controllata. Per esempio, puoi automatizzare Kubernetes per creare nuovi container per il tuo servizio, rimuovere i container esistenti e adattare le loro risorse a quelle richieste dal nuovo container. * **Ottimizzazione dei carichi** Fornisci a Kubernetes un cluster di nodi per eseguire i container. Puoi istruire Kubernetes su quanta CPU e memoria (RAM) ha bisogno ogni singolo container. Kubernetes allocherà i container sui nodi per massimizzare l'uso delle risorse a disposizione. * **Self-healing** Kubernetes riavvia i container che si bloccano, sostituisce container, termina i container che non rispondono agli health checks, e evita di far arrivare traffico ai container che non sono ancora pronti per rispondere correttamente. * **Gestione di informazioni sensibili e della configurazione** Kubernetes consente di memorizzare e gestire informazioni sensibili, come le password, i token OAuth e le chiavi SSH. Puoi distribuire e aggiornare le informazioni sensibili e la configurazione dell'applicazione senza dover ricostruire le immagini dei container e senza svelare le informazioni sensibili nella configurazione del tuo sistema. Cosa non è Kubernetes --------------------- Kubernetes non è un sistema PaaS (Platform as a Service) tradizionale e completo. Dal momento che Kubernetes opera a livello di container piuttosto che che a livello hardware, esso fornisce alcune caratteristiche generalmente disponibili nelle offerte PaaS, come la distribuzione, il ridimensionamento, il bilanciamento del carico, la registrazione e il monitoraggio. Tuttavia, Kubernetes non è monolitico, e queste soluzioni predefinite sono opzionali ed estensibili. Kubernetes fornisce gli elementi base per la costruzione di piattaforme di sviluppo, ma conserva le scelte dell'utente e la flessibilità dove è importante. Kubernetes: * Non limita i tipi di applicazioni supportate. Kubernetes mira a supportare una grande varietà di carichi di lavoro, compresi i carichi di lavoro stateless, stateful e elaborazione di dati. Se un'applicazione può essere eseguita in un container, dovrebbe funzionare alla grande anche su Kubernetes. * Non compila il codice sorgente e non crea i container. I flussi di Continuous Integration, Delivery, and Deployment (CI/CD) sono determinati dalla cultura e dalle preferenze dell'organizzazione e dai requisiti tecnici. * Non fornisce servizi a livello applicativo, come middleware (per esempio, bus di messaggi), framework di elaborazione dati (per esempio, Spark), database (per esempio, mysql), cache, né sistemi di storage distribuito (per esempio, Ceph) come servizi integrati. Tali componenti possono essere eseguiti su Kubernetes, e/o possono essere richiamati da applicazioni che girano su Kubernetes attraverso meccanismi come l'[Open Service Broker](https://openservicebrokerapi.org/) . * Non impone soluzioni di logging, monitoraggio o di gestione degli alert. Fornisce alcune integrazioni come dimostrazione, e meccanismi per raccogliere ed esportare le metriche. * Non fornisce né rende obbligatorio un linguaggio/sistema di configurazione (per esempio, Jsonnet). Fornisce un'API dichiarativa che può essere richiamata da qualsiasi sistema. * Non fornisce né adotta alcun sistema di gestione completa della macchina, configurazione, manutenzione, gestione o sistemi di self healing. * Inoltre, Kubernetes non è un semplice sistema di orchestrazione. Infatti, questo sistema elimina la necessità di orchestrazione. La definizione tecnica di orchestrazione è l'esecuzione di un flusso di lavoro definito: prima si fa A, poi B, poi C. Al contrario, Kubernetes è composto da un insieme di processi di controllo indipendenti e componibili che guidano costantemente lo stato attuale verso lo stato desiderato. Non dovrebbe importare come si passa dalla A alla C. Anche il controllo centralizzato non è richiesto. Questo si traduce in un sistema più facile da usare, più potente, robusto, resiliente ed estensibile. Voci correlate -------------- * Dai un'occhiata alla pagina [i componenti di Kubernetes](https://kubernetes.io/it/docs/concepts/overview/components/) * Sai già [Come Iniziare](https://kubernetes.io/docs/setup/) ? 2 - I componenti di Kubernetes ============================== Un cluster di Kubernetes è costituito da un insieme di componenti che sono, come minimo, un Control Plane e uno o più sistemi di elaborazione, detti nodi. Facendo il deployment di Kubernetes, ottieni un cluster. Un cluster Kubernetes è un'insieme di macchine, chiamate nodi, che eseguono container gestiti da Kubernetes. Un cluster ha almeno un Worker Node. Il/I Worker Node ospitano i Pod che eseguono i workload dell'utente. Il/I Control Plane Node gestiscono i Worker Node e tutto quanto accade all'interno del cluster. Per garantire la high-availability e la possibilità di failover del cluster, vengono utilizzati più Control Plane Node. Questo documento descrive i diversi componenti che sono necessari per avere un cluster Kubernetes completo e funzionante. Questo è un diagramma di un cluster Kubernetes con tutti i componenti e le loro relazioni. ![I componenti di Kubernetes](https://kubernetes.io/images/docs/components-of-kubernetes.png) Componenti della Control Plane ------------------------------ I componenti del Control Plane sono responsabili di tutte le decisioni globali sul cluster (ad esempio, lo scheduling) oltre che a rilevare e rispondere agli eventi del cluster (ad esempio, l'avvio di un nuovo [pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") quando il valore `replicas` di un deployment non è soddisfatto). I componenti della Control Plane possono essere eseguiti su qualsiasi nodo del cluster stesso. Solitamente, per semplicità, gli script di installazione tendono a eseguire tutti i componenti della Control Plane sulla stessa macchina, separando la Control Plane dai workload dell'utente. Vedi [creare un cluster in High-Availability](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) per un esempio di un'installazione multi-master. ### kube-apiserver L'API server è un componente di Kubernetes [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") che espone le Kubernetes API. L'API server è il front end del control plane di Kubernetes. La principale implementazione di un server Kubernetes API è [kube-apiserver](https://kubernetes.io/docs/reference/generated/kube-apiserver/) . kube-apiserver è progettato per scalare orizzontalmente, cioè scala aumentando il numero di istanze. Puoi eseguire multiple istanze di kube-apiserver e bilanciare il traffico tra queste istanze. ### etcd È un database key-value ridondato, che è usato da Kubernetes per salvare tutte le informazioni del cluster. Se il tuo cluster utilizza etcd per salvare le informazioni, assicurati di avere una strategia di [backup](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) per questi dati. Puoi trovare informazioni dettagliate su etcd sulla [documentazione](https://etcd.io/docs/) ufficiale. ### kube-scheduler Componente della Control Plane che controlla i pod appena creati che non hanno un nodo assegnato, e dopo averlo identificato glielo assegna. I fattori presi in considerazioni nell'individuare un nodo a cui assegnare l'esecuzione di un Pod includono la richiesta di risorse del Pod stesso e degli altri workload presenti nel sistema, i vincoli delle hardware/software/policy, le indicazioni di affinity e di anti-affinity, requisiti relativi alla disponibilità di dati/Volumes, le interferenze tra diversi workload e le scadenze. ### kube-controller-manager Componente della Control Plane che gestisce [controllers](https://kubernetes.io/it/docs/concepts/architecture/controller/ "Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato.") . Da un punto di vista logico, ogni [controller](https://kubernetes.io/it/docs/concepts/architecture/controller/ "Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato.") è un processo separato, ma per ridurre la complessità, tutti i principali controller di Kubernetes vengono raggruppati in un unico container ed eseguiti in un singolo processo. Alcuni esempi di controller gestiti dal kube-controller-manager sono: * Node Controller: Responsabile del monitoraggio dei nodi del cluster, e.g. della gestione delle azioni da eseguire quando un nodo diventa non disponibile. * Replication Controller: Responsabile per il mantenimento del corretto numero di Pod per ogni ReplicaSet presente nel sistema * Endpoints Controller: Popola gli oggetti Endpoints (cioè, mette in relazioni i Pods con i Services). * Service Account & Token Controllers: Creano gli account di default e i token di accesso alle API per i nuovi namespaces. ### cloud-controller-manager Un componente della [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") di Kubernetes che aggiunge logiche di controllo specifiche per il cloud. Il cloud-controller-manager ti permette di collegare il tuo cluster con le API del cloud provider e separa le componenti che interagiscono con la piattaforma cloud dai componenti che interagiscono solamente col cluster. Il cloud-controller-manager esegue dei controller specifici del tuo cloud provider. Se hai una installazione Kubernetes on premises, o un ambiente di laboratorio nel tuo PC, il cluster non ha un cloud-controller-manager. Come nel kube-controller-manager, il cloud-controller-manager combina diversi control loop logicamente indipendenti in un singolo binario che puoi eseguire come un singolo processo. Tu puoi scalare orizzontalmente (eseguire più di una copia) per migliorare la responsività o per migliorare la tolleranza ai fallimenti. I seguenti controller hanno dipendenze verso implementazioni di specifici cloud provider: * Node Controller: Per controllare se sul cloud provider i nodi che hanno smesso di rispondere sono stati cancellati * Route Controller: Per configurare le network route nella sottostante infrastruttura cloud * Service Controller: Per creare, aggiornare ed eliminare i load balancer del cloud provider Componenti dei Nodi ------------------- I componenti del nodo vengono eseguiti su ogni nodo, mantenendo i pod in esecuzione e fornendo l'ambiente di runtime Kubernetes. ### kubelet Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod. La kubelet riceve un set di PodSpecs che vengono forniti attraverso vari meccanismi, e si assicura che i container descritti in questi PodSpecs funzionino correttamente e siano sani. La kubelet non gestisce i container che non sono stati creati da Kubernetes. ### kube-proxy [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) è un proxy eseguito su ogni nodo del cluster, responsabile della gestione dei Kubernetes [Service](https://kubernetes.io/it/docs/concepts/services-networking/service/ "A way to expose an application running on a set of Pods as a network service.") . I kube-proxy mantengono le regole di networking sui nodi. Queste regole permettono la comunicazione verso gli altri nodi del cluster o l'esterno. Il kube-proxy usa le librerie del sistema operativo quando possible; in caso contrario il kube-proxy gestisce il traffico direttamente. ### Container Runtime Il container runtime è il software che è responsabile per l'esecuzione dei container. Kubernetes supporta diversi container runtimes: [Docker](http://www.docker.com/) , [containerd](https://containerd.io/) , [cri-o](https://cri-o.io/) , [rktlet](https://github.com/kubernetes-incubator/rktlet) e tutte le implementazioni di [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Addons ------ Gli Addons usano le risorse Kubernetes ([DaemonSet](https://kubernetes.io/it/docs/concepts/workloads/controllers/daemonset "Assicura che una copia di un Pod è attiva su tutti nodi di un cluster.") , [Deployment](https://kubernetes.io/it/docs/concepts/workloads/controllers/deployment/ "Gestisce una applicazione replicata nel tuo cluster.") , etc) per implementare funzionalità di cluster. Dal momento che gli addons forniscono funzionalità a livello di cluster, le risorse che necessitano di un namespace, vengono collocate nel namespace `kube-system`. Alcuni addons sono descritti di seguito; mentre per una più estesa lista di addons, per favore vedere [Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) . ### DNS Mentre gli altri addons non sono strettamente richiesti, tutti i cluster Kubernetes dovrebbero essere muniti di un [DNS del cluster](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) , dal momento che molte applicazioni lo necessitano. Il DNS del cluster è un server DNS aggiuntivo rispetto ad altri server DNS presenti nella rete, e si occupa specificatamente dei record DNS per i servizi Kubernetes. I container eseguiti da Kubernetes automaticamente usano questo server per la risoluzione DNS. ### Interfaccia web (Dashboard) La [Dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) è una interfaccia web per i cluster Kubernetes. Permette agli utenti di gestire e fare troubleshooting delle applicazioni che girano nel cluster, e del cluster stesso. ### Monitoraggio dei Container Il [Monitoraggio dei Container](https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/) salva serie temporali di metriche generiche dei container in un database centrale e fornisce una interfaccia in cui navigare i dati stessi. ### Log a livello di Cluster Un [log a livello di cluster](https://kubernetes.io/docs/concepts/cluster-administration/logging/) è responsabile per il salvataggio dei log dei container in un log centralizzato la cui interfaccia permette di cercare e navigare nei log. Voci correlate -------------- * Scopri i concetti relativi ai [Nodi](https://kubernetes.io/docs/concepts/architecture/nodes/) * Scopri i concetti relativi ai [Controller](https://kubernetes.io/it/docs/concepts/architecture/controller/) * Scopri i concetti relativi al [kube-scheduler](https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/) * Leggi la [documentazione](https://etcd.io/docs/) ufficiale di etcd 3 - Le API di Kubernetes ======================== Le API di Kubernetes ti permettono di interrogare e manipolare lo stato degli oggetti in Kubernetes. Il cuore del Control Plane di Kubernetes è l'API server e le API HTTP che esso espone. Ogni entità o componente che si interfaccia con il cluster (gli utenti, le singole parti del tuo cluster, i componenti esterni), comunica attraverso l'API server. Le convenzioni generali seguite dalle API sono descritte in [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) . Gli _endpoints_ delle API, la lista delle risorse esposte ed i relativi esempi sono descritti in [API Reference](https://kubernetes.io/docs/reference) . L'accesso alle API da remoto è discusso in [Controllare l'accesso alle API](https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/) . Le API di Kubernetes servono anche come riferimento per lo schema dichiarativo della configurazione del sistema stesso. Il comando [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) può essere usato per creare, aggiornare, cancellare ed ottenere le istanze delle risorse esposte attraverso le API. Kubernetes assicura la persistenza del suo stato (al momento in [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/) ) usando la rappresentazione delle risorse implementata dalle API. Kubernetes stesso è diviso in differenti componenti, i quali interagiscono tra loro attraverso le stesse API. Evoluzione delle API -------------------- In base alla nostra esperienza, ogni sistema di successo ha bisogno di evolvere ovvero deve estendersi aggiungendo funzionalità o modificare le esistenti per adattarle a nuovi casi d'uso. Le API di Kubernetes sono quindi destinate a cambiare e ad estendersi. In generale, ci si deve aspettare che nuove risorse vengano aggiunte di frequente cosi come nuovi campi possano altresì essere aggiunti a risorse esistenti. L'eliminazione di risorse o di campi devono seguire la [politica di deprecazione delle API](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) . In cosa consiste una modifica compatibile e come modificare le API è descritto dal [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md) . Definizioni OpenAPI e Swagger ----------------------------- La documentazione completa e dettagliata delle API è fornita attraverso la specifica [OpenAPI](https://www.openapis.org/) . Dalla versione 1.10 di Kubernetes, l'API server di Kubernetes espone le specifiche OpenAPI attraverso il seguente _endpoint_ `/openapi/v2`. Attraverso i seguenti _headers_ HTTP è possibile richiedere un formato specifico: | Header | Possibili Valori | | --- | --- | | Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (il content-type di default è `application/json` per `*/*` ovvero questo header può anche essere omesso) | | Accept-Encoding | `gzip` (questo header è facoltativo) | Prima della versione 1.14, gli _endpoints_ che includono il formato del nome all'interno del segmento (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) espongo le specifiche OpenAPI in formati differenti. Questi _endpoints_ sono deprecati, e saranno rimossi dalla versione 1.14 di Kubernetes. **Esempi per ottenere le specifiche OpenAPI**: | Prima della 1.10 | Dalla versione 1.10 di Kubernetes | | --- | --- | | GET /swagger.json | GET /openapi/v2 **Accept**: application/json | | GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: [application/com.github.proto-openapi.spec.v2@v1.0](mailto:application/com.github.proto-openapi.spec.v2@v1.0)
+protobuf | | GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: [application/com.github.proto-openapi.spec.v2@v1.0](mailto:application/com.github.proto-openapi.spec.v2@v1.0)
+protobuf **Accept-Encoding**: gzip | Kubernetes implementa per le sue API anche una serializzazione alternativa basata sul formato Protobuf che è stato pensato principalmente per la comunicazione intra-cluster, documentato nella seguente [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) , e i files IDL per ciascun schema si trovano nei _Go packages_ che definisco i tipi delle API. Prima della versione 1.14, l'_apiserver_ di Kubernetes espone anche un'_endpoint_, `/swaggerapi`, che può essere usato per ottenere le documentazione per le API di Kubernetes secondo le specifiche [Swagger v1.2](http://swagger.io/) . Questo _endpoint_ è deprecato, ed è stato rimosso nella versione 1.14 di Kubernetes. Versionamento delle API ----------------------- Per facilitare l'eliminazione di campi specifici o la modifica della rappresentazione di una data risorsa, Kubernetes supporta molteplici versioni della stessa API disponibili attraverso differenti indirizzi, come ad esempio `/api/v1` oppure `/apis/extensions/v1beta1`. Abbiamo deciso di versionare a livello di API piuttosto che a livello di risorsa o di campo per assicurare che una data API rappresenti una chiara, consistente vista delle risorse di sistema e dei sui comportamenti, e per abilitare un controllo degli accessi sia per le API in via di decommissionamento che per quelle sperimentali. Si noti che il versionamento delle API ed il versionamento del Software sono indirettamente collegati. La [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) descrive la relazione tra le versioni delle API ed le versioni del Software. Differenti versioni delle API implicano differenti livelli di stabilità e supporto. I criteri per ciascuno livello sono descritti in dettaglio nella [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions) . Queste modifiche sono qui ricapitolate: * Livello alpha: * Il nome di versione contiene `alpha` (e.g. `v1alpha1`). * Potrebbe contenere dei _bug_. Abilitare questa funzionalità potrebbe esporre al rischio di _bugs_. Disabilitata di default. * Il supporto di questa funzionalità potrebbe essere rimosso in ogni momento senza previa notifica. * Questa API potrebbe cambiare in modo incompatibile in rilasci futuri del Software e senza previa notifica. * Se ne raccomandata l'utilizzo solo in _clusters_ di test creati per un breve periodo di vita, a causa di potenziali _bugs_ e delle mancanza di un supporto di lungo periodo. * Livello beta: * Il nome di versione contiene `beta` (e.g. `v2beta3`). * Il codice è propriamente testato. Abilitare la funzionalità è considerato sicuro. Abilitata di default. * Il supporto per la funzionalità nel suo complesso non sarà rimosso, tuttavia potrebbe subire delle modifiche. * Lo schema e/o la semantica delle risorse potrebbe cambiare in modo incompatibile in successivi rilasci beta o stabili. Nel caso questo dovesse verificarsi, verrano fornite istruzioni per la migrazione alla versione successiva. Questo potrebbe richiedere la cancellazione, modifica, e la ri-creazione degli oggetti supportati da questa API. Questo processo di modifica potrebbe richiedere delle valutazioni. La modifica potrebbe richiedere un periodo di non disponibilità dell'applicazione che utilizza questa funzionalità. * Raccomandata solo per applicazioni non critiche per la vostra impresa a causa dei potenziali cambiamenti incompatibili in rilasci successivi. Se avete più _clusters_ che possono essere aggiornati separatamente, potreste essere in grado di gestire meglio questa limitazione. * **Per favore utilizzate le nostre versioni beta e forniteci riscontri relativamente ad esse! Una volta promosse a stabili, potrebbe non essere semplice apportare cambiamenti successivi.** * Livello stabile: * Il nome di versione è `vX` dove `X` è un intero. * Le funzionalità relative alle versioni stabili continueranno ad essere presenti per parecchie versioni successive. API groups ---------- Per facilitare l'estendibilità delle API di Kubernetes, sono stati implementati gli [_API groups_](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) . L'_API group_ è specificato nel percorso REST ed anche nel campo `apiVersion` di un oggetto serializzato. Al momento ci sono diversi _API groups_ in uso: 1. Il gruppo _core_, spesso referenziato come il _legacy group_, è disponibile al percorso REST `/api/v1` ed utilizza `apiVersion: v1`. 2. I gruppi basati su un nome specifico sono disponibili attraverso il percorso REST `/apis/$GROUP_NAME/$VERSION`, ed usano `apiVersion: $GROUP_NAME/$VERSION` (e.g. `apiVersion: batch/v1`). La lista completa degli _API groups_ supportati e' descritta nel documento [Kubernetes API reference](https://kubernetes.io/docs/reference/) . Vi sono due modi per supportati per estendere le API attraverso le [_custom resources_](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) : 1. [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) è pensato per utenti con esigenze CRUD basilari. 2. Utenti che necessitano di un nuovo completo set di API che utilizzi appieno la semantica di Kubernetes possono implementare il loro _apiserver_ ed utilizzare l'[_aggregator_](https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) per fornire ai propri utilizzatori la stessa esperienza a cui sono abituati con le API incluse nativamente in Kubernetes. Abilitare o disabilitare gli _API groups_ ----------------------------------------- Alcune risorse ed _API groups_ sono abilitati di default. Questi posso essere abilitati o disabilitati attraverso il settaggio/flag `--runtime-config` applicato sull'_apiserver_. `--runtime-config` accetta valori separati da virgola. Per esempio: per disabilitare `batch/v1`, usa la seguente configurazione `--runtime-config=batch/v1=false`, per abilitare `batch/v2alpha1`, utilizzate `--runtime-config=batch/v2alpha1`. Il _flag_ accetta set di coppie _chiave/valore_ separati da virgola che descrivono la configurazione a _runtime_ dell'_apiserver_. #### Nota: Abilitare o disabilitare risorse o gruppi richiede il riavvio dell'_apiserver_ e del _controller-manager_ affinché le modifiche specificate attraverso il flag `--runtime-config` abbiano effetto. Abilitare specifiche risorse nel gruppo extensions/v1beta1 ---------------------------------------------------------- DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies e ReplicaSets presenti nel gruppo di API `extensions/v1beta1` sono disabilitate di default. Per esempio: per abilitare deployments and daemonsets, utilizza la seguente configurazione `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. #### Nota: Abilitare/disabilitare una singola risorsa è supportato solo per il gruppo di API `extensions/v1beta1` per ragioni storiche. --- # Instalasi Add-ons | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Installing Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) Instalasi Add-ons ================= _Add-ons_ berfungsi untuk menambah serta memperluas fungsionalitas dari Kubernetes. Laman ini akan menjabarkan beberapa _add-ons_ yang tersedia serta tautan instruksi bagaimana cara instalasi masing-masing _add-ons_. _Add-ons_ pada setiap bagian akan diurutkan secara alfabet - pengurutan ini tidak dilakukan berdasarkan status preferensi atau keunggulan. Jaringan dan _Policy_ Jaringan ------------------------------ * [ACI](https://www.github.com/noironetworks/aci-containers) menyediakan integrasi jaringan kontainer dan keamanan jaringan dengan Cisco ACI. * [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) merupakan penyedia jaringan L3 yang aman dan _policy_ jaringan. * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) menggabungkan Flannel dan Calico, menyediakan jaringan serta _policy_ jaringan. * [Cilium](https://github.com/cilium/cilium) merupakan _plugin_ jaringan L3 dan _policy_ jaringan yang dapat menjalankan _policy_ HTTP/API/L7 secara transparan. Mendukung mode _routing_ maupun _overlay/encapsulation_. * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam _plugin_ CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus. * [Contiv](https://contivpp.io/) menyediakan jaringan yang dapat dikonfigurasi (_native_ L3 menggunakan BGP, _overlay_ menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta _policy framework_ yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](https://github.com/contiv) . Laman [instalasi](https://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk klaster dengan kubeadm maupun non-kubeadm. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) , yang berbasis dari [Tungsten Fabric](https://tungsten.io/) , merupakan sebuah proyek _open source_ yang menyediakan virtualisasi jaringan _multi-cloud_ serta platform manajemen _policy_. Contrail dan Tungsten Fabric terintegrasi dengan sistem orkestrasi lainnya seperti Kubernetes, OpenShift, OpenStack dan Mesos, serta menyediakan mode isolasi untuk mesin virtual (VM), kontainer/pod dan _bare metal_. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) merupakan penyedia jaringan _overlay_ yang dapat digunakan pada Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) merupakan solusi jaringan yang mendukung multipel jaringan pada Kubernetes. * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) merupakan sebuah multi _plugin_ agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua _plugin_ CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada _workload_ Kubernetes. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti _Pivotal Container Service_ (PKS) dan OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan _policy-based_ jaringan antara Kubernetes Pods dan non-Kubernetes _environment_ dengan _monitoring_ visibilitas dan keamanan. * [Romana](http://romana.io/) merupakan solusi jaringan _Layer_ 3 untuk jaringan pod yang juga mendukung [_NetworkPolicy_ API](https://kubernetes.io/id/docs/concepts/services-networking/network-policies/) . Instalasi Kubeadm _add-on_ ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize) . * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta _policy_ jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal. _Service Discovery_ ------------------- * [CoreDNS](https://coredns.io/) merupakan server DNS yang fleksibel, mudah diperluas yang dapat [diinstal](https://github.com/coredns/helm) sebagai _in-cluster_ DNS untuk pod. Visualisasi & Kontrol --------------------- * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) merupakan antarmuka web dasbor untuk Kubernetes. _Add-ons_ Terdeprekasi ---------------------- Ada beberapa _add-on_ lain yang didokumentasikan pada direktori deprekasi [_cluster/addons_](https://git.k8s.io/kubernetes/cluster/addons) . _Add-on_ lain yang dipelihara dan dikelola dengan baik dapat ditulis di sini. Ditunggu PR-nya! Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified February 17, 2025 at 12:52 AM PST: [\[id\] Fixed link for core dns helm charts (197ed17c77)](https://github.com/kubernetes/website/commit/197ed17c77a550a61010b7170b474d194c01237d) --- # 安装扩展（Addon） | Kubernetes **此文档中的信息可能已过时** 此文档的更新日期比原文晚，因此其中的信息可能已过时。如果能阅读英文，请查看英文版本以获取最新信息： [Installing Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) 安装扩展（Addon） =========== **说明：** 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) ，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读[内容指南](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) 。 Add-on 扩展了 Kubernetes 的功能。 本文列举了一些可用的 add-on 以及到它们各自安装说明的链接。该列表并不试图详尽无遗。 联网和网络策略 ------- * [ACI](https://www.github.com/noironetworks/aci-containers) 通过 Cisco ACI 提供集成的容器网络和安全网络。 * [Antrea](https://antrea.io/) 在第 3/4 层执行操作，为 Kubernetes 提供网络连接和安全服务。Antrea 利用 Open vSwitch 作为网络的数据面。 Antrea 是一个[沙箱级的 CNCF 项目](https://www.cncf.io/projects/antrea/) 。 * [Calico](https://www.tigera.io/project-calico/) 是一个联网和网络策略供应商。 Calico 支持一套灵活的网络选项，因此你可以根据自己的情况选择最有效的选项，包括非覆盖和覆盖网络，带或不带 BGP。 Calico 使用相同的引擎为主机、Pod 和（如果使用 Istio 和 Envoy）应用程序在服务网格层执行网络策略。 * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) 结合 Flannel 和 Calico，提供联网和网络策略。 * [Cilium](https://github.com/cilium/cilium) 是一种网络、可观察性和安全解决方案，具有基于 eBPF 的数据平面。 Cilium 提供了简单的 3 层扁平网络， 能够以原生路由（routing）和覆盖/封装（overlay/encapsulation）模式跨越多个集群， 并且可以使用与网络寻址分离的基于身份的安全模型在 L3 至 L7 上实施网络策略。 Cilium 可以作为 kube-proxy 的替代品；它还提供额外的、可选的可观察性和安全功能。 Cilium 是一个[毕业级别的 CNCF 项目](https://www.cncf.io/projects/cilium/) 。 * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) 使 Kubernetes 无缝连接到 Calico、Canal、Flannel 或 Weave 等其中一种 CNI 插件。 CNI-Genie 是一个[沙箱级的 CNCF 项目](https://www.cncf.io/projects/cni-genie/) 。 * [Contiv](https://contivpp.io/) 为各种用例和丰富的策略框架提供可配置的网络 （带 BGP 的原生 L3、带 vxlan 的覆盖、标准 L2 和 Cisco-SDN/ACI）。 Contiv 项目完全[开源](https://github.com/contiv) 。 其[安装程序](https://github.com/contiv/install) 提供了基于 kubeadm 和非 kubeadm 的安装选项。 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) 基于 [Tungsten Fabric](https://tungsten.io/) ，是一个开源的多云网络虚拟化和策略管理平台。 Contrail 和 Tungsten Fabric 与业务流程系统（例如 Kubernetes、OpenShift、OpenStack 和 Mesos）集成在一起， 为虚拟机、容器或 Pod 以及裸机工作负载提供了隔离模式。 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) 是一个可以用于 Kubernetes 的 overlay 网络提供者。 * [Gateway API](https://kubernetes.io/zh-cn/docs/concepts/services-networking/gateway/) 是一个由 [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) 社区管理的开源项目， 为服务网络建模提供一种富有表达力、可扩展和面向角色的 API。 * [Knitter](https://github.com/ZTE/Knitter/) 是在一个 Kubernetes Pod 中支持多个网络接口的插件。 * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) 是一个多插件， 可在 Kubernetes 中提供多种网络支持，以支持所有 CNI 插件（例如 Calico、Cilium、Contiv、Flannel）， 而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) 是一个 Kubernetes 网络驱动， 基于 [OVN（Open Virtual Network）](https://github.com/ovn-org/ovn/) 实现，是从 Open vSwitch (OVS) 项目衍生出来的虚拟网络实现。OVN-Kubernetes 为 Kubernetes 提供基于覆盖网络的网络实现， 包括一个基于 OVS 实现的负载均衡器和网络策略。 * [Nodus](https://github.com/akraino-edge-stack/icn-nodus) 是一个基于 OVN 的 CNI 控制器插件， 提供基于云原生的服务功能链 (SFC)。 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 容器插件（NCP） 提供了 VMware NSX-T 与容器协调器（例如 Kubernetes）之间的集成，以及 NSX-T 与基于容器的 CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) 是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。 * [Romana](https://github.com/romana) 是一个 Pod 网络的第三层解决方案，并支持 [NetworkPolicy](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) API。 * [Spiderpool](https://github.com/spidernet-io/spiderpool) 为 Kubernetes 提供了下层网络和 RDMA 高速网络解决方案，兼容裸金属、虚拟机和公有云等运行环境。 * [Terway](https://github.com/AliyunContainerService/terway/) 是一套基于阿里云 VPC 和 ECS 网络产品的 CNI 插件，能够在阿里云环境中提供原生的 VPC 网络和网络策略支持。 * [Weave Net](https://github.com/rajch/weave#using-weave-on-kubernetes) 提供在网络分组两端参与工作的联网和网络策略，并且不需要额外的数据库。 服务发现 ---- * [CoreDNS](https://coredns.io/) 是一种灵活的，可扩展的 DNS 服务器，可以 [安装](https://github.com/coredns/helm) 为集群内的 Pod 提供 DNS 服务。 可视化管理 ----- * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 Web 控制台界面。 * [Headlamp](https://headlamp.dev/) 是一个**可扩展的 Kubernetes 用户界面（UI）**， 既可以**以集群内方式部署**，也可以**作为桌面应用程序使用**。 基础设施 ---- * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes 运行虚拟机的 add-on。通常运行在裸机集群上。 * [节点问题检测器](https://github.com/kubernetes/node-problem-detector) 在 Linux 节点上运行， 并将系统问题报告为[事件](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/cluster-resources/event-v1/) 或[节点状况](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/#condition) 。 插桩 -- * [kube-state-metrics](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/kube-state-metrics) 遗留 Add-on --------- 还有一些其它 add-on 归档在已废弃的 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 路径中。 维护完善的 add-on 应该被链接到这里。欢迎提出 PR！ 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 January 13, 2026 at 9:26 AM PST: [\[zh-cn\] sync addons networking (9d93ad8005)](https://github.com/kubernetes/website/commit/9d93ad800542c244f49cd6e086f763534757aece) 本页面中的条目引用了第三方产品或项目，这些产品（项目）提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品（项目）负责。请参阅[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) 了解更多细节。 在提交更改建议，向本页添加新的第三方链接之前，你应该先阅读[内容指南。](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) --- # 使用 kubeconfig 文件组织集群访问 | Kubernetes 使用 kubeconfig 文件组织集群访问 ====================== 使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。 `kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。 #### 说明： 用于配置集群访问的文件称为 **kubeconfig 文件**。 这是引用到配置文件的通用方法，并不意味着有一个名为 `kubeconfig` 的文件。 #### 警告： 请务必仅使用来源可靠的 kubeconfig 文件。使用特制的 kubeconfig 文件可能会导致恶意代码执行或文件暴露。 如果必须使用不受信任的 kubeconfig 文件，请首先像检查 Shell 脚本一样仔细检查此文件。 默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。 你可以通过设置 `KUBECONFIG` 环境变量或者设置 [`--kubeconfig`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl/) 参数来指定其他 kubeconfig 文件。 有关创建和指定 kubeconfig 文件的分步说明， 请参阅[配置对多集群的访问](https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters) 。 支持多集群、用户和身份认证机制 --------------- 假设你有多个集群，并且你的用户和组件以多种方式进行身份认证。比如： * 正在运行的 kubelet 可能使用证书在进行认证。 * 用户可能通过令牌进行认证。 * 管理员可能拥有多个证书集合提供给各用户。 使用 kubeconfig 文件，你可以组织集群、用户和命名空间。你还可以定义上下文，以便在集群和命名空间之间快速轻松地切换。 上下文（Context） ------------ 通过 kubeconfig 文件中的 _context_ 元素，使用简便的名称来对访问参数进行分组。 每个 context 都有三个参数：cluster、namespace 和 user。 默认情况下，`kubectl` 命令行工具使用 **当前上下文** 中的参数与集群进行通信。 选择当前上下文： kubectl config use-context KUBECONFIG 环境变量 --------------- `KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。 对于 Linux 和 Mac，此列表以英文冒号分隔。对于 Windows，此列表以英文分号分隔。 `KUBECONFIG` 环境变量不是必需的。 如果 `KUBECONFIG` 环境变量不存在，`kubectl` 将使用默认的 kubeconfig 文件：`$HOME/.kube/config`。 如果 `KUBECONFIG` 环境变量存在，`kubectl` 将使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。 合并 kubeconfig 文件 ---------------- 要查看配置，输入以下命令： kubectl config view 如前所述，输出可能来自单个 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。 以下是 `kubectl` 在合并 kubeconfig 文件时使用的规则。 1. 如果设置了 `--kubeconfig` 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。 否则，如果设置了 `KUBECONFIG` 环境变量，将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件： * 忽略空文件名。 * 对于内容无法反序列化的文件，产生错误信息。 * 第一个设置特定值或者映射键的文件将生效。 * 永远不会更改值或者映射键。示例：保留第一个文件的上下文以设置 `current-context`。 示例：如果两个文件都指定了 `red-user`，则仅使用第一个文件的 `red-user` 中的值。 即使第二个文件在 `red-user` 下有非冲突条目，也要丢弃它们。 有关设置 `KUBECONFIG` 环境变量的示例， 请参阅[设置 KUBECONFIG 环境变量](https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable) 。 否则，使用默认的 kubeconfig 文件（`$HOME/.kube/config`），不进行合并。 2. 根据此链中的第一个匹配确定要使用的上下文。 1. 如果存在上下文，则使用 `--context` 命令行参数。 2. 使用合并的 kubeconfig 文件中的 `current-context`。 这种场景下允许空上下文。 3. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户， 这将运行两次：一次用于用户，一次用于集群。 1. 如果存在用户或集群，则使用命令行参数：`--user` 或者 `--cluster`。 2. 如果上下文非空，则从上下文中获取用户或集群。 这种场景下用户和集群可以为空。 4. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。 基于此链构建每个集群信息；第一个匹配项会被采用： 1. 如果存在集群信息，则使用命令行参数：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`。 2. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用这些属性。 3. 如果没有 server 配置，则配置无效。 5. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但对于每个用户只允许使用一种身份认证技术： 1. 如果存在用户信息，则使用命令行参数：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`。 2. 使用合并的 kubeconfig 文件中的 `user` 字段。 3. 如果存在两种冲突技术，则配置无效。 6. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。 文件引用 ---- kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。 命令行上的文件引用是相对于当前工作目录的。 在 `$HOME/.kube/config` 中，相对路径按相对路径存储，而绝对路径按绝对路径存储。 代理 -- 你可以在 `kubeconfig` 文件中，为每个集群配置 `proxy-url` 来让 `kubectl` 使用代理，例如： apiVersion: v1 kind: Config clusters: - cluster: proxy-url: http://proxy.example.org:3128 server: https://k8s.example.org/k8s/clusters/c-xxyyzz name: development users: - name: developer contexts: - context: name: development 接下来 --- * [配置对多集群的访问](https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#config) 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 March 07, 2023 at 6:06 PM PST: [\[zh\] sync organize-cluster-access-kubeconfig.md (bccd515e3e)](https://github.com/kubernetes/website/commit/bccd515e3ea8ecc79a06cb7ae71204085225baca) --- # Kubernetes | Kubernetes O Kubernetes é uma engine de orquestração de contêineres Open Source utilizado para automatizar a implantação, dimensionamento e gerenciamento de aplicativos em contêiner. O projeto é hospedado por the Cloud Native Computing Foundation ([CNCF](https://www.cncf.io/about) ). Entenda o básico ---------------- Aprenda sobre o Kubernetes e seus conceitos fundamentais. * [Visão Geral](https://kubernetes.io/pt-br/docs/concepts/overview/) * [Componentes do Kubernetes](https://kubernetes.io/pt-br/docs/concepts/overview/components/) * [Entendendo os objetos do Kubernetes](https://kubernetes.io/pt-br/docs/concepts/overview/working-with-objects/kubernetes-objects/) Aprenda Conceitos Experimente o Kubernetes ------------------------ Siga os tutoriais para aprender a implantar aplicativos no Kubernetes. * [Olá, Minikube!](https://kubernetes.io/pt-br/docs/tutorials/hello-minikube/) Veja os Tutoriais Configurar um cluster --------------------- Obtenha um Kubernetes em execução com base em seus recursos e necessidades. * [Ambiente de aprendizagem](https://kubernetes.io/pt-br/docs/setup/#ambiente-de-aprendizagem) * [Ambiente de produção](https://kubernetes.io/pt-br/docs/setup/#ambiente-de-produ%c3%a7%c3%a3o) * [Instalar a ferramenta de configuração kubeadm](https://kubernetes.io/pt-br/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) Configurando um Kubernetes Aprenda a usar o Kubernetes --------------------------- Procure tarefas comuns e como realizá-las usando uma pequena seqüência de etapas. * [Referência Rápida do kubectl](https://kubernetes.io/pt-br/docs/reference/kubectl/quick-reference/) * [Instale o kubectl](https://kubernetes.io/pt-br/docs/tasks/tools/#kubectl) * [Configure o acesso a clusters](https://kubernetes.io/pt-br/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [Use o Painel Web do Kubernetes](https://kubernetes.io/pt-br/docs/tasks/access-application-cluster/web-ui-dashboard/) * [Configurando um Pod Para Usar um ConfigMap](https://kubernetes.io/pt-br/docs/tasks/configure-pod-container/configure-pod-configmap/) * [Obtendo ajuda](https://kubernetes.io/pt-br/docs/tasks/debug/) Visualizar tarefas Procurar informações de referência ---------------------------------- Navegue pela terminologia, pela sintaxe da linha de comando, pelos tipos de recursos da API e pela documentação da ferramenta de configuração. * [Glossário](https://kubernetes.io/pt-br/docs/reference/glossary/) * [Ferramenta de linha de comando kubectl](https://kubernetes.io/pt-br/docs/reference/kubectl/) * [kubectl Cheat Sheet](https://kubernetes.io/pt-br/docs/reference/kubectl/cheatsheet/) * [Kubeadm](https://kubernetes.io/pt-br/docs/reference/setup-tools/kubeadm/) Visualizar referência Contribua para a documentação ----------------------------- Qualquer um pode contribuir, quer você seja novo no projeto ou esteja há um bom tempo. Contribua para a Documentação Download Kubernetes ------------------- Se você estiver instalando o Kubernetes ou atualizando para a versão mais recente, consulte as notas de versão atuais. Sobre a documentação -------------------- Este site contém documentação para a versão atual e as 4 versões anteriores do Kubernetes. * [Versões Suportadas da Documentação](https://kubernetes.io/pt-br/docs/home/supported-doc-versions/) --- # アドオンのインストール | Kubernetes **このページに記載されている情報は古い可能性があります** このページの更新日は英語版よりも古いため、記載されている情報が古い可能性があります。最新の情報をご覧になりたい方は英語版のページをご覧ください: [Installing Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) アドオンのインストール =========== **備考:** このセクションでは、Kubernetesが必要とする機能を提供するサードパーティープロジェクトにリンクしています。これらのプロジェクトはアルファベット順に記載されていて、Kubernetesプロジェクトの作者は責任を持ちません。このリストにプロジェクトを追加するには、変更を提出する前に[content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) をお読みください。[詳細はこちら。](https://kubernetes.io/ja/docs/concepts/cluster-administration/addons/#third-party-content-disclaimer) アドオンはKubernetesの機能を拡張するものです。 このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。 この一覧は、すべてを網羅するものではありません。 ネットワークとネットワークポリシー ----------------- * [ACI](https://www.github.com/noironetworks/aci-containers) は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。 * [Antrea](https://antrea.io/) は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。 Antreaは[SandboxレベルのCNCFプロジェクト](https://www.cncf.io/projects/antrea/) です。 * [Calico](https://www.tigera.io/project-calico/) は、ネットワーキングおよびネットワークポリシーのプロバイダーです。 Calicoは柔軟なネットワーキングオプションをサポートしており、BGPの有無を含む非オーバーレイネットワークやオーバーレイネットワークなど、状況に応じて最も効率的なオプションを選択できます。 Calicoは、ホスト、Pod、および(IstioとEnvoyを使用している場合)サービスメッシュレイヤーのアプリケーションに対して、同じエンジンを使用してネットワークポリシーを適用します。 * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) はFlannelとCalicoをあわせたもので、ネットワークとネットワークポリシーを提供します。 * [Cilium](https://github.com/cilium/cilium) は、eBPFベースのデータプレーンを備えたネットワーク、可観測性、およびセキュリティのソリューションです。 Ciliumは、ネイティブなルーティングまたはoverlay/encapsulationモードのいずれかを用いて複数のクラスターにまたがることができる、シンプルでフラットなL3ネットワークを提供します。 また、ネットワークのアドレス指定から切り離されたアイデンティティベースのセキュリティモデルを使用して、L3からL7のネットワークポリシーを適用することができます。 Ciliumはkube-proxyの代替として機能し、オプトインにて可観測性およびセキュリティ機能も追加で提供しています。 Ciliumは[GraduatedレベルのCNCFプロジェクト](https://www.cncf.io/projects/cilium/) です。 * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) は、KubernetesをCalico、Canal、Flannel、Weaveなど選択したCNIプラグインをシームレスに接続できるようにするプラグインです。 CNI-Genieは[SandboxレベルのCNCFプロジェクト](https://www.cncf.io/projects/cni-genie/) です。 * [Contiv](https://contivpp.io/) は、さまざまなユースケースと豊富なポリシーフレームワーク向けに設定可能なネットワーク(BGPを使用したネイティブのL3、vxlanを使用したオーバーレイ、古典的なL2、Cisco-SDN/ACI)を提供します。 Contivプロジェクトは完全に[オープンソース](https://github.com/contiv) です。 [インストーラー](https://github.com/contiv/install) はkubeadmとkubeadm以外の両方をベースとしたインストールオプションがあります。 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) は、[Tungsten Fabric](https://tungsten.io/) をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。 ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。 * [Gateway API](https://kubernetes.io/ja/docs/concepts/services-networking/gateway/) は、[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) コミュニティによって管理されているオープンソースプロジェクトで、サービスネットワーキングをモデル化するための表現力豊かで拡張可能、かつロール指向のAPIを提供します。 * [Knitter](https://github.com/ZTE/Knitter/) は、1つのKubernetes Podで複数のネットワークインターフェースをサポートするためのプラグインです。 * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのマルチプラグインです。 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/) をベースとする、Kubernetesのためのネットワークプロバイダーです。 OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。 * [Nodus](https://github.com/akraino-edge-stack/icn-nodus) は、OVNベースのCNIコントローラープラグインで、クラウドネイティブベースのService function chaining(SFC)を提供します。 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。 また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。 * [Romana](https://github.com/romana) は、[NetworkPolicy](https://kubernetes.io/ja/docs/concepts/services-networking/network-policies/) APIもサポートするPodネットワーク向けのL3のネットワークソリューションです。 * [Spiderpool](https://github.com/spidernet-io/spiderpool) は、Kubernetes向けのアンダーレイおよびRDMAネットワークソリューションです。 Spiderpoolは、ベアメタル、仮想マシン、パブリッククラウド環境でサポートされています。 * [Terway](https://github.com/AliyunContainerService/terway/) は、AlibabaCloudのVPCおよびECSネットワーク製品をベースとしたCNIプラグインの一式です。 AlibabaCloud環境でネイティブVPCネットワーキングとネットワークポリシーを提供します。 * [Weave Net](https://github.com/rajch/weave#using-weave-on-kubernetes) は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。 サービスディスカバリ ---------- * [CoreDNS](https://coredns.io/) は、フレキシブルで拡張可能なDNSサーバーです。 Pod向けのクラスター内DNSとして[インストール](https://github.com/coredns/helm) できます。 可視化と制御 ------ * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) はKubernetes向けのダッシュボードを提供するウェブインターフェースです。 * [Headlamp](https://headlamp.dev/) は、拡張可能なKubernetesのUIです。 クラスター内にデプロイすることや、デスクトップアプリケーションとして使用することができます。 インフラストラクチャ ---------- * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) は仮想マシンをKubernetes上で実行するためのアドオンです。 通常、ベアメタルのクラスターで実行します。 * [node problem detector](https://github.com/kubernetes/node-problem-detector) はLinuxノード上で動作し、システムの問題を[Event](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/) または[ノードのCondition](https://kubernetes.io/ja/docs/concepts/architecture/nodes/#condition) として報告します。 計測 -- * [kube-state-metrics](https://kubernetes.io/ja/docs/concepts/cluster-administration/kube-state-metrics/) レガシーなアドオン --------- いくつかのアドオンは、廃止された[cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) ディレクトリに掲載されています。 よくメンテナンスされたアドオンはここにリンクしてください。 PRを歓迎しています。 フィードバック ------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最終更新 February 09, 2026 at 12:47 AM PST: [\[ja\] Update content/ja/docs/concepts/cluster-administration/addons.md (#53946) (4385f8eed9)](https://github.com/kubernetes/website/commit/4385f8eed90fe6016ec370f7d8d1fe0e5e6af6a7) このページの項目は、Kubernetesが必要とする機能を提供するサードパーティー製品またはプロジェクトです。Kubernetesプロジェクトの作者は、それらのサードパーティー製品またはプロジェクトに責任を負いません。詳しくは、[CNCFウェブサイトのガイドライン](https://github.com/cncf/foundation/blob/master/website-guidelines.md) をご覧ください。第三者のリンクを追加するような変更を提案する前に、[コンテンツガイド](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) を読むべきです。 --- # kubeconfigファイルを使用してクラスターアクセスを組織する | Kubernetes kubeconfigファイルを使用してクラスターアクセスを組織する ================================= kubeconfigを使用すると、クラスターに、ユーザー、名前空間、認証の仕組みに関する情報を組織できます。`kubectl`コマンドラインツールはkubeconfigファイルを使用してクラスターを選択するために必要な情報を見つけ、クラスターのAPIサーバーと通信します。 #### 備考: クラスターへのアクセスを設定するために使われるファイルは_kubeconfigファイル_と呼ばれます。これは設定ファイルを指すために使われる一般的な方法です。`kubeconfig`という名前を持つファイルが存在するという意味ではありません。 #### 警告: 信頼できるソースからのkubeconfigファイルのみを使用してください。特別に細工されたkubeconfigファイルを使用すると、悪意のあるコードの実行やファイルの公開につながる可能性があります。 信頼できないkubeconfigファイルを使用しなければならない場合は、シェルスクリプトを使用するのと同じように、まず最初に慎重に検査してください。 デフォルトでは、`kubectl`は`$HOME/.kube`ディレクトリ内にある`config`という名前のファイルを探します。`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl/) フラグで指定することで、別のkubeconfigファイルを指定することもできます。 kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](https://kubernetes.io/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters) を参照してください。 複数のクラスター、ユーザ、認証の仕組みのサポート ------------------------ 複数のクラスターを持っていて、ユーザーやコンポーネントがさまざまな方法で認証を行う次のような状況を考えてみます。 * 実行中のkubeletが証明書を使用して認証を行う可能性がある。 * ユーザーがトークンを使用して認証を行う可能性がある。 * 管理者が個別のユーザに提供する複数の証明書を持っている可能性がある。 kubeconfigファイルを使用すると、クラスター、ユーザー、名前空間を組織化することができます。また、contextを定義することで、複数のクラスターや名前空間を素早く簡単に切り替えられます。 Context ------- kubeconfigファイルの_context_要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメーター、cluster、namespace、userを持ちます。デフォルトでは、`kubectl`コマンドラインツールはクラスターとの通信に_current context_のパラメーターを使用します。 current contextを選択するには、以下のコマンドを使用します。 kubectl config use-context KUBECONFIG環境変数 -------------- `KUBECONFIG`環境変数には、kubeconfigファイルのリストを指定できます。LinuxとMacでは、リストはコロン区切りです。Windowsでは、セミコロン区切りです。`KUBECONFIG`環境変数は必須ではありません。`KUBECONFIG`環境変数が存在しない場合は、`kubectl`はデフォルトのkubeconfigファイルである`$HOME/.kube/config`を使用します。 `KUBECONFIG`環境変数が存在する場合は、`kubectl`は`KUBECONFIG`環境変数にリストされているファイルをマージした結果を有効な設定として使用します。 kubeconfigファイルのマージ ------------------ 設定ファイルを確認するには、以下のコマンドを実行します。 kubectl config view 上で説明したように、出力は1つのkubeconfigファイルから作られる場合も、複数のkubeconfigファイルをマージした結果となる場合もあります。 `kubectl`がkubeconfigファイルをマージするときに使用するルールを以下に示します。 1. もし`--kubeconfig`フラグが設定されていた場合、指定したファイルだけが使用されます。マージは行いません。このフラグに指定できるのは1つのファイルだけです。 そうでない場合、`KUBECONFIG`環境変数が設定されていた場合には、それをマージするべきファイルのリストとして使用します。`KUBECONFIG`環境変数にリストされたファイルのマージは、次のようなルールに従って行われます。 * 空のファイルを無視する。 * デシリアライズできない内容のファイルに対してエラーを出す。 * 特定の値やmapのキーを設定する最初のファイルが勝つ。 * 値やmapのキーは決して変更しない。 例: 最初のファイルが指定した`current-context`を保持する。 例: 2つのファイルが`red-user`を指定した場合、1つ目のファイルの`red-user`だけを使用する。もし2つ目のファイルの`red-user`以下に競合しないエントリーがあったとしても、それらは破棄する。 `KUBECONFIG`環境変数を設定する例については、[KUBECONFIG環境変数を設定する](https://kubernetes.io/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable) を参照してください。 それ以外の場合は、デフォルトのkubeconfigファイル`$HOME/.kube/config`をマージせずに使用します。 2. 以下のチェーンで最初に見つかったものをもとにして、使用するcontextを決定する。 1. `--context`コマンドラインフラグが存在すれば、それを使用する。 2. マージしたkubeconrfigファイルから`current-context`を使用する。 この時点では、空のcontextも許容されます。 3. クラスターとユーザーを決定する。この時点では、contextである場合もそうでない場合もあります。以下のチェーンで最初に見つかったものをもとにして、クラスターとユーザーを決定します。この手順はユーザーとクラスターについてそれぞれ1回ずつ、合わせて2回実行されます。 1. もし存在すれば、コマンドラインフラグ`--user`または`--cluster`を使用する。 2. もしcontextが空でなければ、contextからユーザーまたはクラスターを取得する。 この時点では、ユーザーとクラスターは空である可能性があります。 4. 使用する実際のクラスター情報を決定する。この時点では、クラスター情報は存在しない可能性があります。以下のチェーンで最初に見つかったものをもとにして、クラスター情報の各パーツをそれぞれを構築します。 1. もし存在すれば、`--server`、`--certificate-authority`、`--insecure-skip-tls-verify`コマンドラインフラグを使用する。 2. もしマージしたkubeconfigファイルにクラスター情報の属性が存在すれば、それを使用する。 3. もしサーバーの場所が存在しなければ、マージは失敗する。 5. 使用する実際のユーザー情報を決定する。クラスター情報の場合と同じルールを使用して、ユーザー情報を構築します。ただし、ユーザーごとに許可される認証方法は1つだけです。 1. もし存在すれば、`--client-certificate`、`--client-key`、`--username`、`--password`、`--token`コマンドラインフラグを使用する。 2. マージしたkubeconfigファイルの`user`フィールドを使用する。 3. もし2つの競合する方法が存在する場合、マージは失敗する。 6. もし何らかの情報がまだ不足していれば、デフォルトの値を使用し、認証情報については場合によってはプロンプトを表示する。 ファイルリファレンス ---------- kubeconfigファイル内のファイルとパスのリファレンスは、kubeconfigファイルの位置からの相対パスで指定します。コマンドライン上のファイルのリファレンスは、現在のワーキングディレクトリからの相対パスです。`$HOME/.kube/config`内では、相対パスは相対のまま、絶対パスは絶対のまま保存されます。 プロキシ ---- kubeconfigファイルで`proxy-url`を使用すると、以下のようにクラスターごとにプロキシを使用するように`kubectl`を設定することができます。 apiVersion: v1 kind: Config clusters: - cluster: proxy-url: http://proxy.example.org:3128 server: https://k8s.example.org/k8s/clusters/c-xxyyzz name: development users: - name: developer contexts: - context: name: development 次の項目 ---- * [複数のクラスターへのアクセスを設定する](https://kubernetes.io/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#config) フィードバック ------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最終更新 February 06, 2024 at 4:27 PM PST: [\[ja\] fix term "proxy" variations (adada78799)](https://github.com/kubernetes/website/commit/adada78799d09303426a8761fc05d2b43d55f98a) --- # 애드온 설치 | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Installing Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) 애드온 설치 ====== **참고:** 이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 [CNCF 웹사이트 가이드라인](https://github.com/cncf/foundation/blob/master/website-guidelines.md) 에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 [콘텐츠 가이드](https://kubernetes.io/contribute/style/content-guide/#third-party-content) 를 읽어본다. 애드온은 쿠버네티스의 기능을 확장한다. 이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다. 이 목차에서 전체를 다루지는 않는다. 네트워킹과 네트워크 폴리시 -------------- * [ACI](https://www.github.com/noironetworks/aci-containers) 는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다. * [Antrea](https://antrea.io/) 는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다. * [Calico](https://docs.projectcalico.org/latest/introduction/) 는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다. * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) 은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다. * [Cilium](https://github.com/cilium/cilium) 은 네트워킹, 관측 용의성(Observability), 보안 특징을 지닌 eBPF 기반 데이터 플레인을 갖춘 솔루션입니다. Cilium은 기본 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 여러 클러스터를 포괄할 수 있는 단순한 플랫(flat) Layer 3 네트워크를 제공합니다. 또한, Cilium은 (네트워크 주소 지정 방식에서 분리된) 신원 기반 보안 모델(identity-based security model)을 사용하여 L3-L7에서 네트워크 정책을 시행할 수 있습니다. Cilium은 kube-proxy를 대체하는 역할을 할 수 있습니다. 또한 부가적으로, 옵트인(opt-in) 형태로 관측 용의성(Observability) 및 보안 기능을 제공합니다. * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) 를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다. * [Contiv](https://contivpp.io/) 는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv) 이다. [인스톨러](https://github.com/contiv/install) 는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) 은 [Tungsten Fabric](https://tungsten.io/) 을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) 은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/) 는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) 는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) 는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/) 을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다. * [Nodus](https://github.com/akraino-edge-stack/icn-nodus) 는 클라우드 네이티브 기반 서비스 기능 체인(SFC)을 제공하는 OVN 기반 CNI 컨트롤러 플러그인이다. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) 는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다. * [Romana](https://github.com/romana) 는 [네트워크폴리시 API](https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/) 도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. * [Weave Net](https://github.com/rajch/weave#using-weave-on-kubernetes) 은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다. 서비스 검색 ------ * [CoreDNS](https://coredns.io/) 는 유연하고 확장 가능한 DNS 서버로, 파드를 위한 클러스터 내 DNS로 [설치](https://github.com/coredns/helm) 할 수 있다. 시각화 & 제어 -------- * [대시보드](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 는 쿠버네티스를 위한 대시보드 웹 인터페이스이다. 인프라스트럭처 ------- * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다. * [node problem detector](https://github.com/kubernetes/node-problem-detector) 는 리눅스 노드에서 실행되며, 시스템 이슈를 [이벤트](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/) 또는 [노드 컨디션](https://kubernetes.io/ko/docs/concepts/architecture/nodes/#condition) 형태로 보고한다. 레거시 애드온 ------- 더 이상 사용되지 않는 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 디렉터리에 다른 여러 애드온이 문서화되어 있다. 잘 관리된 것들이 여기에 연결되어 있어야 한다. PR을 환영한다! 피드백 --- 이 페이지가 도움이 되었나요? 네 아니요 피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 원한다면 GitHub 리포지터리에 이슈를 열어서 [문제 리포트](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 또는 [개선 제안이 가능합니다.](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 최종 수정 February 11, 2025 at 12:10 AM PST: [\[ko\] Fixed link for core dns helm charts (e24debf813)](https://github.com/kubernetes/website/commit/e24debf813c4fc953e89199e79917cba1eb86b39) 이 페이지는 쿠버네티스가 필요로 하는 기능을 제공하는 써드파티 프로젝트 또는 제품에 대해 언급하고 있습니다. 쿠버네티스 프로젝트 저자들은 이러한 써드파티 프로젝트 또는 제품에 대해 책임지지 않습니다. [CNCF 웹사이트 가이드라인](https://github.com/cncf/foundation/blob/master/website-guidelines.md) 에서 더 자세한 내용을 확인합니다. 다른 써드파티 링크를 추가하는 변경을 제안하기 전에, [컨텐츠 가이드](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) 를 확인해야 합니다. --- # kubeconfig 파일을 사용하여 클러스터 접근 구성하기 | Kubernetes kubeconfig 파일을 사용하여 클러스터 접근 구성하기 ================================ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스 및 인증 메커니즘에 대한 정보를 관리하자. `kubectl` 커맨드라인 툴은 kubeconfig 파일을 사용하여 클러스터의 선택과 클러스터의 API 서버와의 통신에 필요한 정보를 찾는다. #### 참고: 클러스터에 대한 접근을 구성하는 데 사용되는 파일을 _kubeconfig 파일_ 이라 한다. 이는 구성 파일을 참조하는 일반적인 방법을 의미한다. `kubeconfig`라는 이름의 파일이 있다는 의미는 아니다. #### 경고: 신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다. 신뢰할 수 없는 kubeconfig 파일을 사용해야 하는 경우 셸 스크립트를 사용하는 경우처럼 먼저 신중하게 검사한다. 기본적으로 `kubectl`은 `$HOME/.kube` 디렉터리에서 `config`라는 이름의 파일을 찾는다. `KUBECONFIG` 환경 변수를 설정하거나 [`--kubeconfig`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl/) 플래그를 지정해서 다른 kubeconfig 파일을 사용할 수 있다. kubeconfig 파일을 생성하고 지정하는 단계별 지시사항은 [다중 클러스터로 접근 구성하기](https://kubernetes.io/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 를 참조한다. 다중 클러스터, 사용자와 인증 메커니즘 지원 ------------------------ 여러 클러스터가 있고, 사용자와 구성 요소가 다양한 방식으로 인증한다고 가정하자. 예를 들면 다음과 같다. * 실행 중인 kubelet은 인증서를 이용하여 인증할 수 있다. * 사용자는 토큰으로 인증할 수 있다. * 관리자는 개별 사용자에게 제공하는 인증서 집합을 가지고 있다. kubeconfig 파일을 사용하면 클러스터와 사용자와 네임스페이스를 구성할 수 있다. 또한 컨텍스트를 정의하여 빠르고 쉽게 클러스터와 네임스페이스 간에 전환할 수 있다. 컨텍스트 ---- kubeconfig에서 _컨텍스트_ 요소는 편리한 이름으로 접속 매개 변수를 묶는데 사용한다. 각 컨텍스트는 클러스터, 네임스페이스와 사용자라는 세 가지 매개 변수를 가진다. 기본적으로 `kubectl` 커맨드라인 툴은 _현재 컨텍스트_ 의 매개 변수를 사용하여 클러스터와 통신한다. 현재 컨택스트를 선택하려면 다음을 실행한다. kubectl config use-context KUBECONFIG 환경 변수 ---------------- `KUBECONFIG` 환경 변수는 kubeconfig 파일 목록을 보유한다. 리눅스 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다. 윈도우는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다. `KUBECONFIG` 환경 변수가 없으면, `kubectl`은 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다. `KUBECONFIG` 환경 변수가 존재하면, `kubectl`은 `KUBECONFIG` 환경 변수에 나열된 파일을 병합한 결과 형태의 효과적 구성을 이용한다. kubeconfig 파일 병합 ---------------- 구성을 보려면, 다음 커맨드를 입력한다. kubectl config view 앞서 설명한 것처럼, 이 출력 내용은 단일 kubeconfig 파일이나 여러 kubeconfig 파일을 병합한 결과 일 수 있다. 다음은 kubeconfig 파일을 병합할 때에 `kubectl`에서 사용하는 규칙이다. 1. `--kubeconfig` 플래그를 설정했으면, 지정한 파일만 사용한다. 병합하지 않는다. 이 플래그는 오직 한 개 인스턴스만 허용한다. 그렇지 않고, `KUBECONFIG` 환경 변수를 설정하였다면 병합해야 하는 파일의 목록으로 사용한다. `KUBECONFIG` 환경 변수의 나열된 파일은 다음 규칙에 따라 병합한다. * 빈 파일명은 무시한다. * 역 직렬화 불가한 파일 내용에 대해서 오류를 일으킨다. * 특정 값이나 맵 키를 설정한 첫 번째 파일을 우선한다. * 값이나 맵 키를 변경하지 않는다. 예: `현재 컨텍스트`를 설정할 첫 번째 파일의 컨택스트를 유지한다. 예: 두 파일이 `red-user`를 지정했다면, 첫 번째 파일의 `red-user` 값만을 사용한다. 두 번째 파일의 `red-user` 하위에 충돌하지 않는 항목이 있어도 버린다. `KUBECONFIG` 환경 변수 설정의 예로, [KUBECONFIG 환경 변수 설정](https://kubernetes.io/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#kubeconfig-%ED%99%98%EA%B2%BD-%EB%B3%80%EC%88%98-%EC%84%A4%EC%A0%95) 를 참조한다. 그렇지 않다면, 병합하지 않고 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다. 2. 이 체인에서 첫 번째를 기반으로 사용할 컨텍스트를 결정한다. 1. 커맨드라인 플래그의 `--context`를 사용한다. 2. 병합된 kubeconfig 파일에서 `current-context`를 사용한다. 이 시점에서는 빈 컨텍스트도 허용한다. 3. 클러스터와 사용자를 결정한다. 이 시점에서는 컨텍스트가 있을 수도 있고 없을 수도 있다. 사용자에 대해 한 번, 클러스터에 대해 한 번 총 두 번에 걸친 이 체인에서 첫 번째 것을 기반으로 클러스터와 사용자를 결정한다. 1. 커맨드라인 플래그가 존재하면, `--user` 또는 `--cluster`를 사용한다. 2. 컨텍스트가 비어있지 않다면, 컨텍스트에서 사용자 또는 클러스터를 가져온다. 이 시점에서는 사용자와 클러스터는 비워둘 수 있다. 4. 사용할 실제 클러스터 정보를 결정한다. 이 시점에서 클러스터 정보가 있을 수 있고 없을 수도 있다. 이 체인을 기반으로 클러스터 정보를 구축한다. 첫 번째 것을 사용한다. 1. 커맨드라인 플래그가 존재하면, `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`를 사용한다. 2. 병합된 kubeconfig 파일에서 클러스터 정보 속성이 있다면 사용한다. 3. 서버 위치가 없다면 실패한다. 5. 사용할 실제 사용자 정보를 결정한다. 사용자 당 하나의 인증 기법만 허용하는 것을 제외하고는 클러스터 정보와 동일한 규칙을 사용하여 사용자 정보를 작성한다. 1. 커맨드라인 플래그가 존재하면, `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`을 사용한다. 2. 병합된 kubeconfig 파일에서 `user` 필드를 사용한다. 3. 충돌하는 두 가지 기법이 있다면 실패한다. 6. 여전히 누락된 정보는 기본 값을 사용하고 인증 정보를 묻는 메시지가 표시될 수 있다. 파일 참조 ----- kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치와 관련 있다. 커맨드라인 상에 파일 참조는 현재 디렉터리를 기준으로 한다. `$HOME/.kube/config`에서 상대 경로는 상대적으로, 절대 경로는 절대적으로 저장한다. 프록시 --- 다음과 같이 kubeconfig 파일에서 `proxy-url`를 사용하여 `kubectl`이 각 클러스터마다 프록시를 거치도록 설정할 수 있다. apiVersion: v1 kind: Config clusters: - cluster: proxy-url: http://proxy.example.org:3128 server: https://k8s.example.org/k8s/clusters/c-xxyyzz name: development users: - name: developer contexts: - context: name: development 다음 내용 ----- * [다중 클러스터 접근 구성하기](https://kubernetes.io/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#config) 피드백 --- 이 페이지가 도움이 되었나요? 네 아니요 피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 원한다면 GitHub 리포지터리에 이슈를 열어서 [문제 리포트](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 또는 [개선 제안이 가능합니다.](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 최종 수정 July 20, 2022 at 1:05 AM PST: [Update outdated files dev-1.24-ko.2 (M11-M20) (4d92fef330)](https://github.com/kubernetes/website/commit/4d92fef330099bc888cdd0a8b22ab41dc5d7e614) --- # Configurazione | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/concepts/configuration/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/concepts/configuration/) . Configurazione ============== Risorse che fornisce Kubernetes per configurare i Pods. * 1: [ConfigMaps](https://kubernetes.io/it/docs/concepts/configuration/_print/#pg-6b5ccadd699df0904e8e9917c5450c4b) 1 - ConfigMaps ============== La ConfigMap è un oggetto API usato per memorizzare dati non riservati in coppie chiave-valore. I [Pods](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") possono utilizzare le ConfigMaps come variabili d'ambiente, argomenti da riga di comando, o come files di configurazione all'interno di un [Volume](https://kubernetes.io/it/docs/concepts/storage/volumes/ "Una cartella contenente dati, accessibile dai containers all'interno del pod.") . La ConfigMap ti permette di disaccoppiare le configurazioni specifiche per ambiente dalle [immagini del container](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-image "Istanza archiviata di un cointainer che contiene un insieme di software e librerie necessarie per eseguire l'applicazione.") , cosicchè le tue applicazioni siano facilmente portabili. #### Attenzione: La ConfigMap non fornisce riservatezza o cifratura dei dati. Se i dati che vuoi salvare sono confidenziali, usa un [Secret](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-secret "Contiene informazioni sensibili, come passwords, token OAuth, e chiavi ssh.") piuttosto che una ConfigMap, o usa uno strumento di terze parti per tenere privati i tuoi dati. Utilizzo -------- Usa una ConfigMap per tenere separati i dati di configurazione dal codice applicativo. Per esempio, immagina che stai sviluppando un'applicazione che puoi eseguire sul tuo computer (per lo sviluppo) e sul cloud (per gestire il traffico reale). Puoi scrivere il codice puntando a una variabile d'ambiente chiamata `DATABASE_HOST`. Localmente, puoi settare quella variabile a `localhost`. Nel cloud, la puoi settare referenziando il [Service](https://kubernetes.io/it/docs/concepts/services-networking/service/ "A way to expose an application running on a set of Pods as a network service.") di Kubernetes che espone la componente del database sul tuo cluster. Ciò ti permette di andare a recuperare l'immagine del container eseguita nel cloud e fare il debug dello stesso codice localmente se necessario. La ConfigMap non è pensata per sostenere una gran mole di dati. I dati memorizzati su una ConfigMap non possono superare 1 MiB. Se hai bisogno di memorizzare delle configurazioni che superano questo limite, puoi considerare di montare un volume oppure usare un database o un file service separato. Oggetto ConfigMap ----------------- La ConfigMap è un [oggetto](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/) API che ti permette di salvare configurazioni per poi poter essere riutilizzate da altri oggetti. A differenza di molti oggetti di Kubernetes che hanno una `spec`, la ConfigMap ha i campi `data` e `binaryData`. Questi campi accettano le coppie chiave-valore come valori. Entrambi i campi `data` e `binaryData` sono opzionali. Il campo `data` è pensato per contenere le stringhe UTF-8 mentre il campo `binaryData` è pensato per contenere dati binari come le stringhe codificate in base64. Il nome di una ConfigMap deve essere un nome valido per un sottodominio DNS. Ogni chiave sotto il campo `data` o `binaryData` deve consistere di caratteri alfanumerici, `-`, `_` o `.`. Le chiavi salvate sotto `data` non devono coincidere con le chiavi nel campo `binaryData`. Partendo dalla versione 1.19, puoi aggiungere il campo `immutable` alla definizione di ConfigMap per creare una [ConfigMap immutabile](https://kubernetes.io/it/docs/concepts/configuration/_print/#configmap-immutable) . ConfigMaps e Pods ----------------- Puoi scrivere una `spec` del Pod che si riferisce a una ConfigMap e configurare il o i containers in quel Pod sulla base dei dati presenti nella ConfigMap. Il Pod e la ConfigMap devono essere nello stesso Namespace. #### Nota: La `spec` di un [Pod statico](https://kubernetes.io/it/docs/tasks/configure-pod-container/static-pod/ "A pod managed directly by the kubelet daemon on a specific node.") non può riferirsi a una ConfigMap o ad altri oggetti API. Questo è un esempio di una ConfigMap che ha alcune chiavi con valori semplici, e altre chiavi dove il valore ha il formato di un frammento di configurazione. apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: # chiavi simili a proprietà; ogni chiave mappa un valore semplice player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # chiavi simili a files game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true Ci sono quattro modi differenti con cui puoi usare una ConfigMap per configurare un container all'interno di un Pod: 1. Argomento da riga di comando come entrypoint di un container 2. Variabile d'ambiente di un container 3. Aggiungere un file in un volume di sola lettura, per fare in modo che l'applicazione lo legga 4. Scrivere il codice da eseguire all'interno del Pod che utilizza l'API di Kubernetes per leggere la ConfigMap Questi metodologie differenti permettono di utilizzare diversi metodi per modellare i dati che saranno consumati. Per i primi tre metodi, il [kubelet](https://kubernetes.io/it/docs/reference/generated/kubelet "Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.") utilizza i dati della ConfigMap quando lancia il container (o più) in un Pod. Per il quarto metodo dovrai scrivere il codice per leggere la ConfigMap e i suoi dati. Comunque, poiché stai utilizzando l'API di Kubernetes direttamente, la tua applicazione può sottoscriversi per ottenere aggiornamenti ogniqualvolta la ConfigMap cambia, e reagire quando ciò accade. Accedendo direttamente all'API di Kubernetes, questa tecnica ti permette anche di accedere a una ConfigMap in namespace differenti. Ecco un esempio di Pod che usa i valori da `game-demo` per configurare il container: apiVersion: v1 kind: Pod metadata: name: configmap-demo-pod spec: containers: - name: demo image: alpine command: ["sleep", "3600"] env: # Definire la variabile d'ambiente - name: PLAYER_INITIAL_LIVES # Notare che il case qui è differente # dal nome della key nella ConfigMap. valueFrom: configMapKeyRef: name: game-demo # La ConfigMap da cui proviene il valore. key: player_initial_lives # La chiave da recuperare. - name: UI_PROPERTIES_FILE_NAME valueFrom: configMapKeyRef: name: game-demo key: ui_properties_file_name volumeMounts: - name: config mountPath: "/config" readOnly: true volumes: # Settare i volumi al livello del Pod, in seguito montarli nei containers all'interno del Pod - name: config configMap: # Fornire il nome della ConfigMap che vuoi montare. name: game-demo # Una lista di chiavi dalla ConfigMap per essere creata come file items: - key: "game.properties" path: "game.properties" - key: "user-interface.properties" path: "user-interface.properties" Una ConfigMap non differenzia tra le proprietà di una singola linea e un file con più linee e valori. L'importante è il modo in cui i Pods e gli altri oggetti consumano questi valori. Per questo esempio, definire un volume e montarlo all'interno del container `demo` come `/config` crea due files, `/config/game.properties` e `/config/user-interface.properties`, sebbene ci siano quattro chiavi nella ConfigMap. Ciò avviene perché la definizione del Pod specifica una lista di `items` nella sezione dei `volumes`. Se ometti del tutto la lista degli `items`, ogni chiave nella ConfigMap diventerà un file con lo stesso nome della chiave, e otterrai 4 files. Usare le ConfigMaps ------------------- Le ConfigMaps possono essere montate come volumi. Le ConfigMaps possono anche essere utilizzate da altre parti del sistema, senza essere direttamente esposte al Pod. Per esempio, le ConfigMaps possono contenere l'informazione che altre parti del sistema utilizzeranno per la loro configurazione. La maniera più comune per usare le ConfigMaps è di configurare i containers che sono in esecuzione in un Pod nello stesso namespace. Puoi anche utilizzare una ConfigMap separatamente. Per esempio, potresti incontrare [addons](https://kubernetes.io/it/docs/concepts/cluster-administration/addons/ "Resources that extend the functionality of Kubernetes.") o [operators](https://kubernetes.io/it/docs/concepts/extend-kubernetes/operator/ "A specialized controller used to manage a custom resource") che adattano il loro comportamento in base a una ConfigMap. ### Usare le ConfigMaps come files in un Pod Per utilizzare una ConfigMap in un volume all'interno di un Pod: 1. Creare una ConfigMap o usarne una che già esiste. Più Pods possono utilizzare la stessa ConfigMap. 2. Modificare la definizione del Pod per aggiungere un volume sotto `.spec.volumes[]`. Nominare il volume in qualsiasi modo, e avere un campo `.spec.volumes[].configMap.name` configurato per referenziare il tuo oggetto ConfigMap. 3. Aggiungere un `.spec.containers[].volumeMounts[]` a ogni container che necessiti di una ConfigMap. Nello specifico `.spec.containers[].volumeMounts[].readOnly = true` e `.spec.containers[].volumeMounts[].mountPath` in una cartella inutilizzata dove vorresti che apparisse la ConfigMap. 4. Modificare l'immagine o il comando utilizzato così che il programma cerchi i files in quella cartella. Ogni chiave nella sezione `data` della ConfigMap si converte in un file sotto `mountPath`. Questo è un esempio di un Pod che monta una ConfigMap in un volume: apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true volumes: - name: foo configMap: name: myconfigmap Ogni ConfigMap che desideri utilizzare deve essere referenziata in `.spec.volumes`. Se c'è più di un container nel Pod, allora ogni container necessita del suo blocco `volumeMounts`, ma solamente un `.spec.volumes` è necessario ConfigMap. #### Le ConfigMaps montate sono aggiornate automaticamente Quando una ConfigMap è utilizzata in un volume ed è aggiornata, anche le chiavi vengono aggiornate. Il kubelet controlla se la ConfigMap montata è aggiornata ad ogni periodo di sincronizzazione. Ad ogni modo, il kubelet usa la sua cache locale per ottenere il valore attuale della ConfigMap. Il tipo di cache è configurabile usando il campo `ConfigMapAndSecretChangeDetectionStrategy` nel [KubeletConfiguration struct](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/) . Una ConfigMap può essere propagata per vista (default), ttl-based, o redirigendo tutte le richieste direttamente all'API server. Come risultato, il ritardo totale dal momento in cui la ConfigMap è aggiornata al momento in cui nuove chiavi sono propagate al Pod può essere tanto lungo quanto il periodo della sincronizzazione del kubelet + il ritardo della propagazione della cache, dove il ritardo della propagazione della cache dipende dal tipo di cache scelta (è uguale rispettivamente al ritardo della propagazione, ttl della cache, o zero). Le ConfigMaps consumate come variabili d'ambiente non sono aggiornate automaticamente e necessitano di un riavvio del pod. #### Nota: Un container utilizzando una ConfigMap come un [subPath](https://kubernetes.io/docs/concepts/storage/volumes#using-subpath) volume mount non riceverà gli aggiornamenti della ConfigMap. ConfigMaps Immutabili --------------------- FEATURE STATE: `Kubernetes v1.21 [stable]` La funzionalità di Kubernetes _Immutable Secrets and ConfigMaps_ fornisce un'opzione per configurare Secrets individuali e ConfigMaps come immutabili. Per clusters che usano le ConfigMaps come estensione (almeno decine o centinaia di ConfigMap uniche montate nel Pod), prevenire i cambiamenti nei loro dati ha i seguenti vantaggi: * protezione da aggiornamenti accidentali (o non voluti) che potrebbero causare l'interruzione di applicazioni * miglioramento della performance del tuo cluster riducendo significativamente il carico sul kube-apiserver, chiudendo l'ascolto sulle ConfigMaps che sono segnate come immutabili. Questa funzionalità è controllata dal `ImmutableEphemeralVolumes` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) . Puoi creare una ConfigMap immutabile settando il campo `immutable` a `true`. Per esempio: apiVersion: v1 kind: ConfigMap metadata: ... data: ... immutable: true Una volta che una ConfigMap è segnata come immutabile, _non_ è possibile invertire questo cambiamento né cambiare il contenuto del campo `data` o `binaryData` field. Puoi solamente cancellare e ricreare la ConfigMap. Poiché i Pods hanno un puntamento verso la ConfigMap eliminata, è raccomandato di ricreare quei Pods. Voci correlate -------------- * Leggi in merito [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) . * Leggi [Configura un Pod per utilizzare una ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) . * Leggi in merito [Modificare una ConfigMap (o qualsiasi altro oggetto di Kubernetes)](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) * Leggi [The Twelve-Factor App](https://12factor.net/) per comprendere il motivo di separare il codice dalla configurazione. --- # Instalando Complementos | Kubernetes **Este documento pode estar desatualizado** Este documento possui uma data de atualização mais antiga que o documento original. Portanto, este conteúdo pode estar desatualizado. Se você lê inglês, veja a versão em inglês para acessar a versão mais atualizada: [Installing Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) Instalando Complementos ======================= **Nota:** Esta seção contém links para projetos de terceiros que fornecem a funcionalidade exigida pelo Kubernetes. Os autores do projeto Kubernetes não são responsáveis por esses projetos. Esta página obedece as [diretrizes de conteúdo do site CNCF](https://github.com/cncf/foundation/blob/master/website-guidelines.md) , listando os itens em ordem alfabética. Para adicionar um projeto a esta lista, leia o [guia de conteúdo](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) antes de enviar sua alteração. Complementos estendem as funcionalidades do Kubernetes. Esta página lista alguns dos complementos disponíveis e links com suas respectivas instruções de instalação. Rede e Política de Rede ----------------------- * [ACI](https://www.github.com/noironetworks/aci-containers) fornece rede integrada de contêineres e segurança de rede com a Cisco ACI. * [Antrea](https://antrea.io/) opera nas camadas 3 e 4 do modelo de rede OSI para fornecer serviços de rede e de segurança para o Kubernetes, aproveitando o Open vSwitch como camada de dados de rede. * [Calico](https://docs.projectcalico.org/latest/introduction/) é um provedor de serviços de rede e de políticas de rede. Este complemento suporta um conjunto flexível de opções de rede, de modo a permitir a escolha da opção mais eficiente para um dado caso de uso, incluindo redes _overlay_ (sobrepostas) e não-_overlay_, com ou sem o uso do protocolo BGP. Calico usa o mesmo mecanismo para aplicar políticas de rede a hosts, pods, e aplicações na camada de _service mesh_ (quando Istio e Envoy estão instalados). * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) une Flannel e Calico, fornecendo rede e política de rede. * [Cilium](https://github.com/cilium/cilium) é um plug-in de rede de camada 3 e de políticas de rede que pode aplicar políticas HTTP/API/camada 7 de forma transparente. Tanto o modo de roteamento quanto o de sobreposição/encapsulamento são suportados. Este plug-in também consegue operar no topo de outros plug-ins CNI. * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) permite que o Kubernetes se conecte facilmente a uma variedade de plug-ins CNI, como Calico, Canal, Flannel, Romana ou Weave. * [Contiv](https://contivpp.io/) oferece serviços de rede configuráveis para diferentes casos de uso (camada 3 nativa usando BGP, _overlay_ (sobreposição) usando vxlan, camada 2 clássica e Cisco-SDN/ACI) e também um _framework_ rico de políticas de rede. O projeto Contiv é totalmente [open source](http://github.com/contiv) . O [instalador](http://github.com/contiv/install) fornece opções de instalação com ou sem kubeadm. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) é uma plataforma open source baseada no [Tungsten Fabric](https://tungsten.io/) que oferece virtualização de rede multi-nuvem e gerenciamento de políticas de rede. O Contrail e o Tungsten Fabric são integrados a sistemas de orquestração de contêineres, como Kubernetes, OpenShift, OpenStack e Mesos, e fornecem modos de isolamento para cargas de trabalho executando em máquinas virtuais, contêineres/pods e servidores físicos. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) é um provedor de redes _overlay_ (sobrepostas) que pode ser usado com o Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) é um plug-in para suporte de múltiplas interfaces de rede em Pods do Kubernetes. * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) é um plugin para suporte a várias interfaces de rede em Pods no Kubernetes. Este plug-in pode agir como um "meta-plug-in", ou um plug-in CNI que se comunica com múltiplos outros plug-ins CNI (por exemplo, Calico, Cilium, Contiv, Flannel), além das cargas de trabalho baseadas em SRIOV, DPDK, OVS-DPDK e VPP no Kubernetes. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) fornece integração entre o VMware NSX-T e sistemas de orquestração de contêineres como o Kubernetes. Além disso, oferece também integração entre o NSX-T e as plataformas CaaS/PaaS baseadas em contêiner, como o Pivotal Container Service (PKS) e o OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) é uma plataforma de rede definida por software que fornece serviços de rede baseados em políticas entre os Pods do Kubernetes e os ambientes não-Kubernetes, com visibilidade e monitoramento de segurança. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) é um provedor de rede para o Kubernetes baseado no [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/) , uma implementação de redes virtuais que surgiu através do projeto Open vSwitch (OVS). O OVN-Kubernetes fornece uma implementação de rede baseada em _overlay_ (sobreposição) para o Kubernetes, incluindo uma implementação baseada em OVS para serviços de balanceamento de carga e políticas de rede. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) é um plug-in controlador CNI baseado no OVN (Open Virtual Network) que fornece serviços de rede _cloud native_, como _Service Function Chaining_ (SFC), redes _overlay_ (sobrepostas) OVN múltiplas, criação dinâmica de subredes, criação dinâmica de redes virtuais, provedor de rede VLAN e provedor de rede direto, e é plugável a outros plug-ins multi-rede. Ideal para cargas de trabalho que utilizam computação de borda _cloud native_ em redes multi-cluster. * [Romana](https://github.com/romana/romana) é uma solução de rede de camada 3 para redes de pods que também suporta a [API NetworkPolicy](https://kubernetes.io/pt-br/docs/concepts/services-networking/network-policies/) . Detalhes da instalação do complemento Kubeadm disponíveis [aqui](https://github.com/romana/romana/tree/master/containerize) . * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornece rede e política de rede, funciona em ambos os lados de uma partição de rede e não requer um banco de dados externo. Descoberta de Serviço --------------------- * [CoreDNS](https://coredns.io/) é um servidor DNS flexível e extensível que pode ser [instalado](https://github.com/coredns/helm) como o serviço de DNS dentro do cluster para ser utilizado por pods. Visualização & Controle ----------------------- * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) é uma interface web para gestão do Kubernetes. Infraestrutura -------------- * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) é um complemento para executar máquinas virtuais no Kubernetes. É geralmente executado em clusters em máquina física. Complementos Legados -------------------- Existem vários outros complementos documentados no diretório [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) que não são mais utilizados. Projetos bem mantidos devem ser listados aqui. PRs são bem-vindos! Comentários ----------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Última modificação February 12, 2025 at 12:10 AM PST: [\[pt\] Fixed link for core dns helm charts (9bf945a4c6)](https://github.com/kubernetes/website/commit/9bf945a4c6fd8a07c12edc835e4b01112cc61fe3) Itens nesta página referem-se a produtos ou projetos de terceiros que fornecem a funcionalidade requerida pelo Kubernetes. Os autores do projeto Kubernetes não são responsáveis por estes produtos ou projetos de terceiros. Veja as [diretrizes de conteúdo do site CNCF](https://github.com/cncf/foundation/blob/master/website-guidelines.md) para mais detalhes. Você deve ler o [guia de conteúdo](https://kubernetes.io/pt-br/docs/contribute/style/content-guide/#third-party-content) antes de propor alterações que incluam links extras de terceiros. --- # Organizando o acesso ao cluster usando arquivos kubeconfig | Kubernetes Organizando o acesso ao cluster usando arquivos kubeconfig ========================================================== Utilize arquivos kubeconfig para organizar informações sobre clusters, usuários, namespaces e mecanismos de autenticação. A ferramenta de linha de comando `kubectl` faz uso dos arquivos kubeconfig para encontrar as informações necessárias para escolher e se comunicar com o serviço de API de um cluster. #### Nota: Um arquivo que é utilizado para configurar o acesso aos clusters é chamado de _kubeconfig_. Esta á uma forma genérica de referenciamento para um arquivo de configuração desta natureza. Isso não significa que existe um arquivo com o nome `kubeconfig`. Por padrão, o `kubectl` procura por um arquivo de nome `config` no diretório `$HOME/.kube` Você pode especificar outros arquivos kubeconfig através da variável de ambiente `KUBECONFIG` ou adicionando a opção [`--kubeconfig`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl/) . Para maiores detalhes na criação e especificação de um kubeconfig, veja o passo a passo em [Configurar Acesso para Múltiplos Clusters](https://kubernetes.io/pt-br/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) . Suportando múltiplos clusters, usuários e mecanismos de autenticação -------------------------------------------------------------------- Imagine que você possua inúmeros clusters, e seus usuários e componentes se autenticam de várias formas. Por exemplo: * Um kubelet ativo pode se autenticar utilizando certificados * Um usuário pode se autenticar através de tokens * Administradores podem possuir conjuntos de certificados os quais provém acesso aos usuários de forma individual. Através de arquivos kubeconfig, você pode organizar os seus clusters, usuários, e namespaces. Você também pode definir contextos para uma fácil troca entre clusters e namespaces. Contexto -------- Um elemento de _contexto_ em um kubeconfig é utilizado para agrupar parâmetros de acesso em um nome conveniente. Cada contexto possui três parâmetros: cluster, namespace, e usuário. Por padrão, a ferramenta de linha de comando `kubectl` utiliza os parâmetros do _contexto atual_ para se comunicar com o cluster. Para escolher o contexto atual: kubectl config use-context A variável de ambiente KUBECONFIG --------------------------------- A variável de ambiente `KUBECONFIG` possui uma lista dos arquivos kubeconfig. Para Linux e Mac, esta lista é delimitada por vírgula. No Windows, a lista é delimitada por ponto e vírgula. A variável de ambiente `KUBECONFIG` não é um requisito obrigatório - caso ela não exista o `kubectl` utilizará o arquivo kubeconfig padrão localizado no caminho `$HOME/.kube/config`. Se a variável de ambiente `KUBECONFIG` existir, o `kubectl` utilizará uma configuração que é o resultado da combinação dos arquivos listados na variável de ambiente `KUBECONFIG`. Combinando arquivos kubeconfig ------------------------------ Para inspecionar a sua configuração atual, execute o seguinte comando: kubectl config view Como descrito anteriormente, a saída poderá ser resultado de um único arquivo kubeconfig, ou poderá ser o resultado da junção de vários arquivos kubeconfig. Aqui estão as regras que o `kubectl` utiliza quando realiza a combinação de arquivos kubeconfig: 1. Se o argumento `--kubeconfig` está definido, apenas o arquivo especificado será utilizado. Apenas uma instância desta flag é permitida. Caso contrário, se a variável de ambiente `KUBECONFIG` estiver definida, esta deverá ser utilizada como uma lista de arquivos a serem combinados, seguindo o fluxo a seguir: * Ignorar arquivos vazios. * Produzir erros para aquivos cujo conteúdo não for possível desserializar. * O primeiro arquivo que definir um valor ou mapear uma chave determinada, será o escolhido. * Nunca modificar um valor ou mapear uma chave. Exemplo: Preservar o contexto do primeiro arquivo que definir `current-context`. Exemplo: Se dois arquivos especificarem um `red-user`, use apenas os valores do primeiro `red-user`. Mesmo se um segundo arquivo possuir entradas não conflitantes sobre a mesma entrada `red-user`, estas deverão ser descartadas. Para um exemplo de definição da variável de ambiente `KUBECONFIG` veja [Definido a variável de ambiente KUBECONFIG](https://kubernetes.io/pt-br/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable) . Caso contrário, utilize o arquivo kubeconfig padrão encontrado no diretório `$HOME/.kube/config`, sem qualquer tipo de combinação. 2. Determine o contexto a ser utilizado baseado no primeiro padrão encontrado, nesta ordem: 1. Usar o conteúdo da flag `--context` caso ela existir. 2. Usar o `current-context` a partir da combinação dos arquivos kubeconfig. Um contexto vazio é permitido neste momento. 3. Determinar o cluster e o usuário. Neste ponto, poderá ou não existir um contexto. Determinar o cluster e o usuário no primeiro padrão encontrado de acordo com a ordem à seguir. Este procedimento deverá executado duas vezes: uma para definir o usuário a outra para definir o cluster. 1. Utilizar a flag caso ela existir: `--user` ou `--cluster`. 2. Se o contexto não estiver vazio, utilizar o cluster ou usuário deste contexto. O usuário e o cluster poderão estar vazios neste ponto. 4. Determinar as informações do cluster atual a serem utilizadas. Neste ponto, poderá ou não existir informações de um cluster. Construir cada peça de informação do cluster baseado nas opções à seguir; a primeira ocorrência encontrada será a opção vencedora: 1. Usar as flags de linha de comando caso existirem: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`. 2. Se algum atributo do cluster existir a partir da combinação de kubeconfigs, estes deverão ser utilizados. 3. Se não existir informação de localização do servidor falhar. 5. Determinar a informação atual de usuário a ser utilizada. Construir a informação de usuário utilizando as mesmas regras utilizadas para o caso de informações de cluster, exceto para a regra de técnica de autenticação que deverá ser única por usuário: 1. Usar as flags, caso existirem: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`. 2. Usar os campos `user` resultado da combinação de arquivos kubeconfig. 3. Se existirem duas técnicas conflitantes, falhar. 6. Para qualquer informação que ainda estiver ausente, utilizar os valores padrão e potencialmente solicitar informações de autenticação a partir do prompt de comando. Referências de arquivos ----------------------- Arquivos e caminhos referenciados em um arquivo kubeconfig são relativos à localização do arquivo kubeconfig. Referências de arquivos na linha de comando são relativas ao diretório de trabalho vigente. No arquivo `$HOME/.kube/config`, caminhos relativos são armazenados de forma relativa, e caminhos absolutos são armazenados de forma absoluta. Próximos passos --------------- * [Configurar Acesso para Multiplos Clusters](https://kubernetes.io/pt-br/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#config) Comentários ----------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Última modificação November 24, 2025 at 9:32 AM PST: [Fixed wording accesso. (ab2a84e909)](https://github.com/kubernetes/website/commit/ab2a84e909332edf982e7c2488c3ba1f9fdc956b) --- # Architettura di Kubernetes | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/concepts/architecture/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/concepts/architecture/) . Architettura di Kubernetes ========================== * 1: [Comunicazione Control Plane - Nodo](https://kubernetes.io/it/docs/concepts/architecture/_print/#pg-c0251def6da29b30afebfb04549f1703) * 2: [Concetti alla base del Cloud Controller Manager](https://kubernetes.io/it/docs/concepts/architecture/_print/#pg-bc804b02614d67025b4c788f1ca87fbc) * 3: [Controller](https://kubernetes.io/it/docs/concepts/architecture/_print/#pg-ca8819042a505291540e831283da66df) 1 - Comunicazione Control Plane - Nodo ====================================== Questo documento cataloga le connessioni tra il piano di controllo (_control-plane_), in realtà l'apiserver, e il cluster Kubernetes. L'intento è di consentire agli utenti di personalizzare la loro installazione per rafforzare la configurazione di rete affinché il cluster possa essere eseguito su una rete pubblica (o su IP completamente pubblici resi disponibili da un fornitore di servizi cloud). Dal Nodo al control-plane ------------------------- Kubernetes adotta un pattern per le API di tipo _"hub-and-spoke"_. Tutte le chiamate delle API eseguite sui vari nodi sono effettuate verso l'apiserver (nessuno degli altri componenti principali è progettato per esporre servizi remoti). L'apiserver è configurato per l'ascolto di connessioni remote su una porta HTTPS protetta (443) con una o più forme di [autenticazioni client](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) abilitate. Si dovrebbero abilitare una o più forme di [autorizzazioni](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) , in particolare nel caso in cui siano ammesse [richieste anonime](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests) o [_token_ legati ad un account di servizio (_service account_)](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) . Il certificato pubblico (_public root certificate_) relativo al cluster corrente deve essere fornito ai vari nodi di modo che questi possano connettersi in modo sicuro all'apiserver insieme alle credenziali valide per uno specifico _client_. Ad esempio, nella configurazione predefinita di un cluster [GKE](https://cloud.google.com/kubernetes-engine?hl=it) , le credenziali del client fornite al kubelet hanno la forma di un certificato client. Si veda [inizializzazione TLS del kubelet TLS](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) per la fornitura automatica dei certificati client al _kubelet_. I Pod che desiderano connettersi all'apiserver possono farlo in modo sicuro sfruttando un account di servizio in modo che Kubernetes inserisca automaticamente il certificato pubblico di radice e un token valido al portatore (_bearer token_) all'interno Pod quando questo viene istanziato. In tutti i namespace è configurato un _Service_ con nome `kubernetes` con un indirizzo IP virtuale che viene reindirizzato (tramite _kube-proxy_) all'endpoint HTTPS dell'apiserver. Anche i componenti del piano d controllo comunicano con l'apiserver del cluster su di una porta sicura esposta da quest'ultimo. Di conseguenza, la modalità operativa predefinita per le connessioni dai nodi e dai Pod in esecuzione sui nodi verso il _control-plane_ è protetta da un'impostazione predefinita e può essere eseguita su reti non sicure e/o pubbliche. Dal control-plane al nodo ------------------------- Esistono due percorsi di comunicazione principali dal _control-plane_ (apiserver) verso i nodi. Il primo è dall'apiserver verso il processo _kubelet_ in esecuzione su ogni nodo nel cluster. Il secondo è dall'apiserver a ciascun nodo, Pod, o servizio attraverso la funzionalità proxy dell'apiserver. ### Dall'apiserver al _kubelet_ Le connessioni dall'apiserver al _kubelet_ vengono utilizzate per: * Prendere i log relativi ai vari Pod. * Collegarsi (attraverso kubectl) ai Pod in esecuzione. * Fornire la funzionalità di _port-forwarding_ per i _kubelet_. Queste connessioni terminano all'endpoint HTTPS del _kubelet_. Di default, l'apiserver non verifica il certificato servito dal _kubelet_, il che rende la connessione soggetta ad attacchi _man-in-the-middle_, e tale da essere considerato **non sicuro (unsafe)** se eseguito su reti non protette e/o pubbliche. Per verificare questa connessione, si utilizzi il parametro `--kubelet-certificate-authority` al fine di fornire all'apiserver un insieme di certificati radice da utilizzare per verificare il il certificato servito dal _kubelet_. Se questo non è possibile, si usi un [tunnel SSH](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) tra l'apiserver e il _kubelet_, se richiesto, per evitare il collegamento su una rete non protetta o pubblica. In fine, l'[autenticazione e/o l'autorizzazione del kubelet](https://kubernetes.io/docs/admin/kubelet-authentication-authorization/) dovrebbe essere abilitate per proteggere le API esposte dal _kubelet_. ### Dall'apiserver ai nodi, Pod, e servizi Le connessioni dall'apiserver verso un nodo, Pod o servizio avvengono in modalità predefinita su semplice connessione HTTP e quindi non sono né autenticate né criptata. Queste connessioni possono essere eseguite su una connessione HTTPS sicura mediante il prefisso `https:` al nodo, Pod o nome del servizio nell'URL dell'API, ma non valideranno il certificato fornito dall'endpoint HTTPS né forniranno le credenziali del client così anche se la connessione verrà criptata, non fornirà alcuna garanzia di integrità. **Non è attualmente sicuro** eseguire queste connessioni su reti non protette e/o pubbliche. ### I tunnel SSH Kubernetes supporta i _tunnel_ SSH per proteggere la comunicazione tra il _control-plane_ e i nodi. In questa configurazione, l'apiserver inizializza un tunnel SSH con ciascun nodo del cluster (collegandosi al server SSH in ascolto sulla porta 22) e fa passare tutto il traffico verso il _kubelet_, il nodo, il Pod, o il servizio attraverso questo tunnel. Questo tunnel assicura che il traffico non sia esposto al di fuori della rete su cui sono in esecuzioni i vari nodi. I tunnel SSH sono al momento deprecati ovvero non dovrebbero essere utilizzati a meno che ci siano delle esigenze particolari. Il servizio `Konnectivity` è pensato per rimpiazzare questo canale di comunicazione. ### Il servizio _Konnectivity_ FEATURE STATE: `Kubernetes v1.18 [beta]` Come rimpiazzo dei tunnel SSH, il servizio _Konnectivity_ fornisce un proxy a livello TCP per la comunicazione tra il _control-plane_ e il cluster. Il servizio _Konnectivity_ consiste in due parti: il _Konnectivity_ server e gli agenti _Konnectivity_, in esecuzione rispettivamente sul _control-plane_ e sui vari nodi. Gli agenti _Konnectivity_ inizializzano le connessioni verso il server _Konnectivity_ e mantengono le connessioni di rete. Una volta abilitato il servizio _Konnectivity_, tutto il traffico tra il _control-plane_ e i nodi passa attraverso queste connessioni. Si può fare riferimento al [tutorial per il servizio _Konnectivity_](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) per configurare il servizio _Konnectivity_ all'interno del cluster 2 - Concetti alla base del Cloud Controller Manager =================================================== Il concetto di CCM (cloud controller manager), da non confondere con il binario, è stato originariamente creato per consentire di sviluppare Kubernetes indipendentemente dall'implementazione dello specifico cloud provider. Il cloud controller manager viene eseguito insieme ad altri componenti principali come il Kubernetes controller manager, il server API e lo scheduler. Può anche essere avviato come addon di Kubernetes, nel qual caso viene eseguito su Kubernetes. Il design del cloud controller manager è basato su un meccanismo di plug-in che consente ai nuovi provider cloud di integrarsi facilmente con Kubernetes creando un plug-in. Sono in atto programmi per l'aggiunta di nuovi provider di cloud su Kubernetes e per la migrazione dei provider che usano il vecchio metodo a questo nuovo metodo. Questo documento discute i concetti alla base del cloud controller manager e fornisce dettagli sulle funzioni associate. Ecco l'architettura di un cluster Kubernetes senza il gestore del controller cloud: ![Pre CCM Kube Arch](https://kubernetes.io/images/docs/pre-ccm-arch.png) Architettura ------------ Nel diagramma precedente, Kubernetes e il provider cloud sono integrati attraverso diversi componenti: * Kubelet * Kubernetes controller manager * Kubernetes API server Il CCM consolida tutta la logica dipendente dal cloud presente nei tre componenti precedenti, per creare un singolo punto di integrazione con il cloud. La nuova architettura con il CCM si presenta così: ![CCM Kube Arch](https://kubernetes.io/images/docs/post-ccm-arch.png) Componenti del CCM ------------------ Il CCM divide alcune funzionalità del Kubernetes controller manager (KCM) e le esegue in un differente processo. In particolare, toglie dal KCM le integrazioni con il cloud specifico. Il KCM ha i seguenti controller che dipendono dal cloud specifico: * Node controller * Volume controller * Route controller * Service controller Nella versione 1.9, il CCM esegue i seguenti controller dall'elenco precedente: * Node controller * Route controller * Service controller #### Nota: È stato deliberatamente deciso di non spostare il Volume controller nel CCM. Data la complessità del Volume controller e gli sforzi già fatti per astrarre le logiche specifiche dei singoli fornitori, è stato deciso che il Volume controller non verrà spostato nel CCM. Il piano originale per supportare i volumi utilizzando il CCM era di utilizzare [Flex](https://kubernetes.io/docs/concepts/storage/volumes/#flexVolume) per supportare volumi collegabili. Tuttavia, una implementazione parallela, nota come [CSI](https://kubernetes.io/docs/concepts/storage/volumes/#csi) è stata designata per sostituire Flex. Considerando queste evoluzioni, abbiamo deciso di adottare un approccio intermedio finché il CSI non è pronto. Funzioni del CCM ---------------- Il CCM eredita le sue funzioni da componenti di Kubernetes che dipendono da uno specifico provider di cloud. Questa sezione è strutturata sulla base di tali componenti. ### 1\. Kubernetes controller manager La maggior parte delle funzioni del CCM deriva dal KCM. Come menzionato nella sezione precedente, CCM esegue i seguenti cicli di controllo: * Node controller * Route controller * Service controller #### Node controller Il Node controller è responsabile per l'inizializzazione di un nodo ottenendo informazioni sui nodi in esecuzione nel cluster dal provider cloud. Il controller del nodo esegue le seguenti funzioni: 1. Inizializzare un nodo con le label zone/region specifiche per il cloud in uso. 2. Inizializzare un nodo con le specifiche, ad esempio, tipo e dimensione specifiche del cloud in uso. 3. Ottenere gli indirizzi di rete del nodo e l'hostname. 4. Nel caso in cui un nodo non risponda, controlla il cloud per vedere se il nodo è stato cancellato dal cloud. Se il nodo è stato eliminato dal cloud, elimina l'oggetto Nodo di Kubernetes. #### Route controller Il Route controller è responsabile della configurazione delle route nel cloud in modo che i container su nodi differenti del cluster Kubernetes possano comunicare tra loro. Il Route controller è utilizzabile solo dai cluster su Google Compute Engine. #### Service Controller Il Service Controller rimane in ascolto per eventi di creazione, aggiornamento ed eliminazione di servizi. In base allo stato attuale dei servizi in Kubernetes, configura i bilanciatori di carico forniti dal cloud (come gli ELB, i Google LB, o gli Oracle Cloud Infrastructure LB) per riflettere lo stato dei servizi in Kubernetes. Inoltre, assicura che i back-end dei bilanciatori di carico forniti dal cloud siano aggiornati. ### 2\. Kubelet Il Node Controller contiene l'implementazione dipendente dal cloud della kubelet. Prima dell'introduzione del CCM, la kubelet era responsabile dell'inizializzazione di un nodo con dettagli dipendenti dallo specifico cloud come gli indirizzi IP, le label region/zone e le informazioni sul tipo di istanza. L'introduzione del CCM ha spostato questa operazione di inizializzazione dalla kubelet al CCM. In questo nuovo modello, la kubelet inizializza un nodo senza informazioni specifiche del cloud. Tuttavia, aggiunge un blocco al nodo appena creato che rende il nodo non selezionabile per eseguire container finché il CCM non inizializza il nodo con le informazioni specifiche del cloud. Il CCM rimuove quindi questo blocco. Sistema a plug-in ----------------- Il cloud controller manager utilizza le interfacce di Go per consentire l'implementazione di implementazioni di qualsiasi cloud. In particolare, utilizza l'interfaccia CloudProvider definita [qui](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62) . L'implementazione dei quattro controller generici evidenziati sopra, alcune strutture, l'interfaccia cloudprovider condivisa rimarranno nel core di Kubernetes. Le implementazioni specifiche per i vari cloud saranno costruite al di fuori del core e implementeranno le interfacce definite nel core. Per ulteriori informazioni sullo sviluppo di plug-in, consultare [Developing Cloud Controller Manager](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/) . Autorizzazione -------------- Questa sezione dettaglia l'accesso richiesto dal CCM sui vari API objects per eseguire le sue operazioni. ### Node controller Il Node controller funziona solo con oggetti di tipo Node. Richiede l'accesso completo per ottenere, elencare, creare, aggiornare, applicare patch, guardare ed eliminare oggetti di tipo Node. v1/Node: * Get * List * Create * Update * Patch * Watch * Delete ### Route controller Il Route controller ascolta la creazione dell'oggetto Node e configura le rotte in modo appropriato. Richiede l'accesso in lettura agli oggetti di tipo Node. v1/Node: * Get ### Service controller Il Service controller resta in ascolto per eventi di creazione, aggiornamento ed eliminazione di oggetti di tipo Servizi, e configura gli endpoint per tali Servizi in modo appropriato. Per accedere ai Servizi, è necessario il permesso per list e watch. Per aggiornare i Servizi, sono necessari i permessi patch e update. Per impostare gli endpoint per i Servizi, richiede i permessi create, list, get, watch, e update. v1/Service: * List * Get * Watch * Patch * Update ### Others L'implementazione del core di CCM richiede l'accesso per creare eventi e, per garantire operazioni sicure, richiede l'accesso per creare ServiceAccounts. v1/Event: * Create * Patch * Update v1/ServiceAccount: * Create L'RBAC ClusterRole per il CCM ha il seguente aspetto: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cloud-controller-manager rules: - apiGroups: - "" resources: - events verbs: - create - patch - update - apiGroups: - "" resources: - nodes verbs: - '*' - apiGroups: - "" resources: - nodes/status verbs: - patch - apiGroups: - "" resources: - services verbs: - list - patch - update - watch - apiGroups: - "" resources: - serviceaccounts verbs: - create - apiGroups: - "" resources: - persistentvolumes verbs: - get - list - update - watch - apiGroups: - "" resources: - endpoints verbs: - create - get - list - watch - update Vendor Implementations ---------------------- I seguenti fornitori di cloud hanno una implementazione di CCM: * [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) * [AWS](https://github.com/kubernetes/cloud-provider-aws) * [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) * [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) * [GCP](https://github.com/kubernetes/cloud-provider-gcp) * [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) * [Linode](https://github.com/linode/linode-cloud-controller-manager) * [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) * [Oracle](https://github.com/oracle/oci-cloud-controller-manager) * [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) Cluster Administration ---------------------- Le istruzioni complete per la configurazione e l'esecuzione del CCM sono fornite [qui](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) . 3 - Controller ============== Nella robotica e nell'automazione, un _circuito di controllo_ (_control loop_) è un un'iterazione senza soluzione di continuità che regola lo stato di un sistema. Ecco un esempio di un circuito di controllo: il termostato di una stanza. Quando viene impostata la temperatura, si definisce attraverso il termostato lo _stato desiderato_. L'attuale temperatura nella stanza è invece lo _stato corrente_. Il termostato agisce per portare lo stato corrente il più vicino possibile allo stato desiderato accendendo e spegnendo le apparecchiature. In Kubernetes, i _controller_ sono circuiti di controllo che osservano lo stato del [cluster](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-cluster "Un'insieme di macchine, chiamate nodi, che eseguono container gestiti da Kubernetes. Un cluster ha almeno un Worker Node.") , e apportano o richiedono modifiche quando necessario. Ogni _controller_ prova a portare lo stato corrente del cluster verso lo stato desiderato. Il modello del controller ------------------------- Un _controller_ monitora almeno una tipo di risorsa registrata in Kubernetes. Questi [oggetti](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) hanno una proprietà chiamata _spec_ (specifica) che rappresenta lo stato desiderato. Il o i _controller_ per quella risorsa sono responsabili di mantenere lo stato corrente il più simile possibile rispetto allo stato desiderato. Il _controller_ potrebbe eseguire l'azione relativa alla risorsa in questione da sé; più comunemente, in Kubernetes, un _controller_ invia messaggi all'[API server](https://kubernetes.io/it/docs/concepts/architecture/#kube-apiserver "Componente della Control plane che serve le Kubernetes API.") che a sua volta li rende disponibili ad altri componenti nel cluster. Di seguito troverete esempi per questo scenario. ### Controllo attraverso l'API server Il [Job](https://kubernetes.io/it/docs/concepts/workloads/controllers/jobs-run-to-completion "Uno o più lavori (task) che vengono eseguiti fino al loro completamento.") _controller_ è un esempio di un _controller_ nativo in Kubernetes. I _controller_ nativi gestiscono lo stato interagendo con l'API server presente nel cluster. Il Job è una risorsa di Kubernetes che lancia uno o più [Pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") per eseguire un lavoro (task) e poi fermarsi. (Una volta che è stato [schedulato](https://kubernetes.io/docs/concepts/scheduling-eviction/) , un oggetto _Pod_ diventa parte dello stato desisderato di un dato _kubelet_). Quando il Job _controller_ vede un nuovo lavoro da svolgere si assicura che, da qualche parte nel cluster, i _kubelet_ anche sparsi su più nodi eseguano il numero corretto di _Pod_ necessari per eseguire il lavoro richiesto. Il Job _controller_ non esegue direttamente alcun _Pod_ o _container_ bensì chiede all'API server di creare o rimuovere i _Pod_. Altri componenti appartenenti al [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") reagiscono in base alle nuove informazioni (ci sono nuovi _Pod_ da creare e gestire) e cooperano al completamento del job. Dopo che un nuovo Job è stato creato, lo stato desiderato per quel Job è il suo completamento. Il Job _controller_ fa sì che lo stato corrente per quel Job sia il più vicino possibile allo stato desiderato: creare _Pod_ che eseguano il lavoro che deve essere effettuato attraverso il Job, così che il Job sia prossimo al completamento. I _controller_ aggiornano anche gli oggetti che hanno configurato. Ad esempio: una volta che il lavoro relativo ad un dato Job è stato completato, il Job _controller_ aggiorna l'oggetto Job segnandolo come `Finished`. (Questo è simile allo scenario del termostato che spegne un certo led per indicare che ora la stanza ha raggiungo la temperatura impostata) ### Controllo diretto A differenza del Job, alcuni _controller_ devono eseguire delle modifiche a parti esterne al cluster. Per esempio, se viene usato un circuito di controllo per assicurare che ci sia un numero sufficiente di [Nodi](https://kubernetes.io/it/docs/concepts/architecture/nodes/ "Un node è una macchina worker in Kubernetes.") nel cluster, allora il _controller_ ha bisogno che qualcosa al di fuori del cluster configuri i nuovi _Nodi_ quando sarà necessario. I _controller_ che interagiscono con un sistema esterno trovano il loro stato desiderato attraverso l'API server, quindi comunicano direttamente con un sistema esterno per portare il loro stato corrente più in linea possibile con lo stato desiderato (In realtà c'è un _controller_ che scala orizzontalmente i nodi nel cluster. Vedi [Cluster autoscaling](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) ). Stato desiderato versus corrente -------------------------------- Kubernetes ha una visione _cloud-native_ dei sistemi, ed è in grado di gestire continue modifiche. Il cluster viene modificato continuamente durante la sua attività ed il _circuito di controllo_ è in grado di risolvere automaticamente i possibili guasti. Fino a che i _controller_ del cluster sono in funzione ed in grado di apportare le dovute modifiche, non è rilevante che lo stato complessivo del cluster sia o meno stabile. Progettazione ------------- Come cardine della sua progettazione, Kubernetes usa vari _controller_ ognuno dei quali è responsabile per un particolare aspetto dello stato del cluster. Più comunemente, un dato _circuito di controllo_ (_controller_) usa un tipo di risorsa per il suo stato desiderato, ed utilizza anche risorse di altro tipo per raggiungere questo stato desiderato. Per esempio il Job _controller_ tiene traccia degli oggetti di tipo _Job_ (per scoprire nuove attività da eseguire) e degli oggetti di tipo _Pod_ (questi ultimi usati per eseguire i _Job_, e quindi per controllare quando il loro lavoro è terminato). In questo caso, qualcos'altro crea i _Job_, mentre il _Job_ _controller_ crea i _Pod_. È utile avere semplici _controller_ piuttosto che un unico, monolitico, _circuito di controllo_. I _controller_ possono guastarsi, quindi Kubernetes è stato disegnato per gestire questa eventualità. #### Nota: Ci possono essere diversi _controller_ che creato o aggiornano lo stesso tipo di oggetti. Dietro le quinte, i _controller_ di Kubernetes si preoccupano esclusivamente delle risorse (di altro tipo) collegate alla risorsa primaria da essi controllata. Per esempio, si possono avere _Deployment_ e _Job_; entrambe creano _Pod_. Il Job _controller_ non distrugge i _Pod_ creati da un _Deployment_, perché ci sono informazioni (_[labels](https://kubernetes.io/it/docs/concepts/overview/working-with-objects/labels "Tags di oggetti con attributi identificativi che sono significativi e pertinenti per gli utenti.") _) che vengono usate dal _controller_ per distinguere i _Pod_. I modi per eseguire i _controller_ ---------------------------------- Kubernetes annovera un insieme di _controller_ nativi che sono in esecuzione all'interno del [kube-controller-manager](https://kubernetes.io/it/docs/reference/command-line-tools-reference/kube-controller-manager/ "Componente della Control Plane che gestisce i controller.") . Questi _controller_ nativi forniscono importanti funzionalità di base. Il Deployment _controller_ ed il Job _controller_ sono esempi di _controller_ che vengono forniti direttamente da Kubernetes stesso (ovvero _controller_ "nativi"). Kubernetes consente di eseguire un _piano di controllo_(_control plane_) resiliente, di modo che se un dei _controller_ nativi dovesse fallire, un'altra parte del piano di controllo si occuperà di eseguire quel lavoro. Al fine di estendere Kubernetes, si possono avere _controller_ in esecuzione al di fuori del piano di controllo. Oppure, se si desidera, è possibile scriversi un nuovo _controller_. È possibile eseguire il proprio controller come una serie di _Pod_, oppure esternamente rispetto a Kubernetes. Quale sia la soluzione migliore, dipende dalla responsabilità di un dato controller. Voci correlate -------------- * Leggi in merito [Kubernetes control plane](https://kubernetes.io/it/docs/concepts/#kubernetes-control-plane) * Scopri alcune delle basi degli [oggetti di Kubernetes](https://kubernetes.io/it/docs/concepts/#kubernetes-objects) * Per saperne di più riguardo alle [API di Kubernetes](https://kubernetes.io/it/docs/concepts/overview/kubernetes-api/) * Se vuoi creare un tuo _controller_, guarda [i modelli per l'estensibilità](https://kubernetes.io/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Estendere Kubernetes. --- # Containers | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/concepts/containers/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/concepts/containers/) . Containers ========== La tecnologia per distribuire un'applicazione insieme con le dipendenze necessarie per la sua esecuzione. * 1: [Immagini](https://kubernetes.io/it/docs/concepts/containers/_print/#pg-16042b4652ad19e565c7263824029a43) * 2: [Container Environment](https://kubernetes.io/it/docs/concepts/containers/_print/#pg-643212488f778acf04bebed65ba34441) * 3: [Container Lifecycle Hooks](https://kubernetes.io/it/docs/concepts/containers/_print/#pg-e6941d969d81540208a3e78bc56f43bc) Ogni _container_ che viene eseguito è riproducibile; la pratica di includere le dipendenze all'interno di ciascuno _container_ permette di ottenere sempre lo stesso risultato ad ogni esecuzione del medesimo _container_. I _Container_ permettono di disaccoppiare le applicazioni dall'infrastruttura del host su cui vengono eseguite. Questo approccio rende più facile il _deployment_ su cloud o sitemi operativi differenti tra loro. Immagine di container --------------------- L'[immagine di un container](https://kubernetes.io/it/docs/concepts/containers/images/) e' un pacchetto software che contiene tutto ciò che serve per eseguire un'applicazione: il codice sorgente e ciascun _runtime_ necessario, librerie applicative e di sistema, e le impostazioni predefinite per ogni configurazione necessaria. Un _container_ è immutabile per definizione: non è possibile modificare il codice di un _container_ in esecuzione. Se si ha un'applicazione containerizzata e la si vuole modificare, si deve costruire un nuovo _container_ che includa il cambiamento desiderato, e quindi ricreare il _container_ partendo dalla nuova immagine aggiornata. Container runtimes ------------------ Il container runtime è il software che è responsabile per l'esecuzione dei container. Kubernetes supporta diversi container runtimes: [Docker](http://www.docker.com/) , [containerd](https://containerd.io/) , [cri-o](https://cri-o.io/) , [rktlet](https://github.com/kubernetes-incubator/rktlet) e tutte le implementazioni di [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Voci correlate -------------- * Leggi in merito [immagine di container](https://kubernetes.io/it/docs/concepts/containers/images/) * Leggi in merito [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) 1 - Immagini ============ L'immagine di un container rappresenta dati binari che incapsulano un'applicazione e tutte le sue dipendenze software. Le immagini sono costituite da pacchetti software eseguibili che possono essere avviati in modalità standalone e su cui si possono fare ipotesi ben precise circa l'ambiente in cui vengono eseguiti. Tipicamente viene creata un'immagine di un'applicazione ed effettuato il _push_ su un registry (un repository pubblico di immagini) prima di poterne fare riferimento esplicito in un [Pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") Questa pagina va a delineare nello specifico il concetto di immagine di un container. I nomi delle immagini --------------------- Alle immagini dei container vengono normalmente attribuiti nomi come `pause`, `example/mycontainer`, o `kube-apiserver`. Le immagini possono anche contenere l'hostname del registry in cui le immagini sono pubblicate; ad esempio: `registro.fittizio.esempio/nomeimmagine`, ed è possibile che sia incluso nel nome anche il numero della porta; ad esempio: `registro.fittizio.esempio:10443/nomeimmagine`. Se non si specifica l'hostname di un registry, Kubernetes assume che ci si riferisca al registry pubblico di Docker. Dopo la parte relativa al nome dell'immagine si può aggiungere un _tag_ (come comunemente avviene per comandi come `docker` e `podman`). I tag permettono l'identificazione di differenti versioni della stessa serie di immagini. I tag delle immagini sono composti da lettere minuscole e maiuscole, numeri, underscore (`_`), punti (`.`), e trattini (`-`). Esistono regole aggiuntive relative a dove i caratteri separatori (`_`, `-`, and `.`) possano essere inseriti nel tag di un'immagine. Se non si specifica un tag, Kubernetes assume il tag `latest` che va a definire l'immagine disponibile più recente. #### Attenzione: Evitate di utilizzare il tag `latest` quando si rilasciano dei container in produzione, in quanto risulta difficile tracciare quale versione dell'immagine sia stata avviata e persino più difficile effettuare un rollback ad una versione precente. Invece, meglio specificare un tag specifico come ad esempio `v1.42.0`. Aggiornamento delle immagini ---------------------------- Quando un [Deployment](https://kubernetes.io/it/docs/concepts/workloads/controllers/deployment/ "Gestisce una applicazione replicata nel tuo cluster.") , [StatefulSet](https://kubernetes.io/it/docs/concepts/workloads/controllers/statefulset/ "Gestisce deployment e la scalabilità di un gruppo di Pod, con storage e identificativi persistenti per ogni Pod.") , Pod, o qualsiasi altro oggetto che includa un Pod template viene creato per la prima volta, la policy di default per il pull di tutti i container nel Pod è impostata su `IfNotPresent` (se non presente) se non specificato diversamente. Questa policy permette al [kubelet](https://kubernetes.io/it/docs/reference/generated/kubelet "Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.") di evitare di fare il pull di un'immagine se questa è già presente. Se necessario, si può forzare il pull in ogni occasione in uno dei seguenti modi: * impostando `imagePullPolicy` (specifica per il pull delle immagini) del container su `Always` (sempre). * omettendo `imagePullPolicy` ed usando il tag `:latest` (più recente) per l'immagine da utilizzare; Kubernetes imposterà la policy su `Always` (sempre). * omettendo `imagePullPolicy` ed il tag per l'immagine da utilizzare. * abilitando l'admission controller [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) . #### Nota: Il valore dell'impostazione `imagePullPolicy` del container è sempre presente quando l'oggetto viene creato per la prima volta e non viene aggiornato se il tag dell'immagine dovesse cambiare successivamente. Ad esempio, creando un Deployment con un'immagine il cui tag _non_ è `:latest`, e successivamente aggiornando il tag di quell'immagine a `:latest`, il campo `imagePullPolicy` _non_ cambierà su `Always`. È necessario modificare manualmente la policy di pull di ogni oggetto dopo la sua creazione. Quando `imagePullPolicy` è definito senza un valore specifico, esso è impostato su `Always`. Multi-architecture support nelle immagini ----------------------------------------- Oltre a fornire immagini binarie, un _container registry_ può fornire un [indice delle immagini disponibili per un container](https://github.com/opencontainers/image-spec/blob/master/image-index.md) . L'indice di un'immagine può puntare a più [file manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md) ciascuno per una versione specifica dell'architettura di un container. L'idea è che si può avere un unico nome per una stessa immagine (ad esempio: `pause`, `example/mycontainer`, `kube-apiserver`) e permettere a diversi sistemi di recuperare l'immagine binaria corretta a seconda dell'architettura della macchina che la sta utilizzando. Kubernetes stesso tipicamente nomina le immagini dei container tramite il suffisso `-$(ARCH)`. Per la garantire la retrocompatibilità è meglio generare le vecchie immagini con dei suffissi. L'idea è quella di generare, ad esempio, l'immagine `pause` con un manifest che include tutte le architetture supportate, affiancata, ad esempio, da `pause-amd64` che è retrocompatibile per le vecchie configurazioni o per quei file YAML in cui sono specificate le immagini con i suffissi. Utilizzare un private registry ------------------------------ I private registry possono richiedere l'utilizzo di chiavi per accedere alle immagini in essi contenute. Le credenziali possono essere fornite in molti modi: * configurando i nodi in modo tale da autenticarsi al private registry * tutti i pod possono acquisire informazioni da qualsiasi private registry configurato * è necessario che l'amministratore del cluster configuri i nodi in tal senso * tramite pre-pulled images (immagini pre-caricate sui nodi) * tutti i pod possono accedere alle immagini salvate sulla cache del nodo a cui si riferiscono * è necessario effettuare l'accesso come root di sistema su ogni nodo per inserire questa impostazione * specificando _ImagePullSecrets_ su un determinato pod * solo i pod che forniscono le proprie chiavi hanno la possibilità di accedere al private registry * tramite estensioni locali o specifiche di un _Vendor_ * se si sta utilizzando una configurazione personalizzata del nodo oppure se manualmente, o tramite il _cloud provider_, si implementa un meccanismo di autenticazione del nodo presso il _container registry_. Di seguito la spiegazione dettagliata di queste opzioni. ### Configurazione dei nodi per l'autenticazione ad un private registry Se si sta utilizzando Docker sui nodi, si può configurare il _Docker container runtime_ per autenticare il nodo presso un private container registry. Questo è un approccio possibile se si ha il controllo sulle configurazioni del nodo. #### Nota: Kubernetes di default supporta solo le sezioni `auths` e `HttpHeaders` nelle configurazioni relative a Docker. Eventuali _helper_ per le credenziali di Docker (`credHelpers` o `credsStore`) non sono supportati. Docker salva le chiavi per i registri privati in `$HOME/.dockercfg` oppure nel file `$HOME/.docker/config.json`. Inserendo lo stesso file nella lista seguente, kubelet lo utilizzerà per recuperare le credenziali quando deve fare il _pull_ delle immagini. * `{--root-dir:-/var/lib/kubelet}/config.json` * `{cwd of kubelet}/config.json` * `${HOME}/.docker/config.json` * `/.docker/config.json` * `{--root-dir:-/var/lib/kubelet}/.dockercfg` * `{cwd of kubelet}/.dockercfg` * `${HOME}/.dockercfg` * `/.dockercfg` #### Nota: Potrebbe essere necessario impostare `HOME=/root` esplicitamente come variabile d'ambiente del processo _kubelet_. Di seguito i passi consigliati per configurare l'utilizzo di un private registry da parte dei nodi del _cluster_. In questo esempio, eseguire i seguenti comandi sul proprio desktop/laptop: 1. Esegui `docker login [server]` per ogni _set_ di credenziali che vuoi utilizzare. Questo comando aggiornerà `$HOME/.docker/config.json` sul tuo PC. 2. Controlla il file `$HOME/.docker/config.json` in un editor di testo per assicurarti che contenga le credenziali che tu voglia utilizzare. 3. Recupera la lista dei tuoi nodi; ad esempio: * se vuoi utilizzare i nomi: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` * se vuoi recuperare gli indirizzi IP: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 4. Copia il tuo file locale `.docker/config.json` in uno dei path sopra riportati nella lista di ricerca. * ad esempio, per testare il tutto: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` #### Nota: Per i cluster di produzione, utilizza un configuration management tool per poter applicare le impostazioni su tutti i nodi laddove necessario. Puoi fare una verifica creando un Pod che faccia uso di un'immagine privata; ad esempio: kubectl apply -f - < --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL Se possiedi il file delle credenziali per Docker, anziché utilizzare il comando quì sopra puoi importare il file di credenziali come un Kubernetes [Secrets](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-secret "Contiene informazioni sensibili, come passwords, token OAuth, e chiavi ssh.") . [Creare un Secret a partire da credenziali Docker](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) fornisce la spiegazione dettagliata su come fare. Ciò è particolarmente utile se si utilizzano più _container registry_ privati, in quanto il comando `kubectl create secret docker-registry` genera un Secret che funziona con un solo private registry. #### Nota: I Pod possono fare riferimento ai Secret per il pull delle immagini soltanto nel proprio _namespace_, quindi questo procedimento deve essere svolto per ogni _namespace_. #### Fare riferimento ad imagePullSecrets in un Pod È possibile creare pod che referenzino quel Secret aggiungendo la sezione `imagePullSecrets` alla definizione del Pod. Ad esempio: cat < pod.yaml apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey EOF cat <> ./kustomization.yaml resources: - pod.yaml EOF Questo deve esser fatto per ogni Pod che utilizzi un private registry. Comunque, le impostazioni relative a questo campo possono essere automatizzate inserendo la sezione _imagePullSecrets_ nella definizione della risorsa [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) . Visitare la pagina [Aggiungere ImagePullSecrets ad un Service Account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) per istruzioni più dettagliate. Puoi utilizzarlo in congiunzione al file `.docker/config.json` configurato per ogni nodo. In questo caso, si applicherà un _merge_ delle credenziali. Casi d'uso ---------- Ci sono varie soluzioni per configurare i private registry. Di seguito, alcuni casi d'uso comuni e le soluzioni suggerite. 1. Cluster in cui sono utilizzate soltanto immagini non proprietarie (ovvero _open-source_). In questo caso non sussiste il bisogno di nascondere le immagini. * Utilizza immagini pubbliche da Docker hub. * Nessuna configurazione richiesta. * Alcuni _cloud provider_ mettono in _cache_ o effettuano il _mirror_ di immagini pubbliche, il che migliora la disponibilità delle immagini e ne riduce il tempo di _pull_. 2. Cluster con container avviati a partire da immagini proprietarie che dovrebbero essere nascoste a chi è esterno all'organizzazione, ma visibili a tutti gli utenti abilitati nel cluster. * Utilizza un private [Docker registry](https://docs.docker.com/registry/) . * Esso può essere ospitato da [Docker Hub](https://hub.docker.com/signup) , o da qualche altra piattaforma. * Configura manualmente il file .docker/config.json su ogni nodo come descritto sopra. * Oppure, avvia un private registry dietro il tuo firewall con accesso in lettura libero. * Non è necessaria alcuna configurazione di Kubernetes. * Utilizza un servizio di _container registry_ che controlli l'accesso alle immagini * Esso funzionerà meglio con una configurazione del cluster basata su _autoscaling_ che con una configurazione manuale del nodo. * Oppure, su un cluster dove la modifica delle configurazioni del nodo non è conveniente, utilizza `imagePullSecrets`. 3. Cluster con immagini proprietarie, alcune delle quali richiedono un controllo sugli accessi. * Assicurati che l'_admission controller_ [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod potenzialmente possono avere accesso a tutte le immagini. * Sposta i dati sensibili un un _Secret_, invece di inserirli in un'immagine. 4. Un cluster multi-tenant dove ogni tenant necessiti di un private registry. * Assicurati che l'_admission controller_ [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod di tutti i tenant potrebbero potenzialmente avere accesso a tutte le immagini. * Avvia un private registry che richieda un'autorizzazione all'accesso. * Genera delle credenziali di registry per ogni tenant, inseriscile in dei _Secret_, e popola i _Secret_ per ogni _namespace_ relativo ad ognuno dei tenant. * Il singolo tenant aggiunge così quel _Secret_ all'impostazione _imagePullSecrets_ di ogni _namespace_. Se si ha la necessità di accedere a più registri, si può generare un _Secret_ per ognuno di essi. Kubelet farà il _merge_ di ogni `imagePullSecrets` in un singolo file virtuale `.docker/config.json`. Voci correlate -------------- * Leggi [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 2 - Container Environment ========================= Questa pagina descrive le risorse disponibili nei Container eseguiti in Kubernetes. Container environment --------------------- Quando si esegue un Container in Kubernetes, le seguenti risorse sono rese disponibili: * Un filesystem, composto dal file system dell'[image](https://kubernetes.io/it/docs/concepts/containers/images/) e da uno o più [volumes](https://kubernetes.io/docs/concepts/storage/volumes/) . * Una serie di informazioni sul Container stesso. * Una serie di informazioni sugli oggetti nel cluster. ### Informazioni sul Container L' _hostname_ di un Container è il nome del Pod all'interno del quale è eseguito il Container. È consultabile tramite il comando `hostname` o tramite la funzione [`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) disponibile in libc. Il nome del Pod e il namespace possono essere resi disponibili come environment variables attraverso l'uso delle [downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) . Gli utenti possono aggiungere altre environment variables nella definizione del Pod; anche queste saranno disponibili nel Container come tutte le altre environment variables definite staticamente nella Docker image. ### Informazioni sul cluster Al momento della creazione del Container è generata una serie di environment variables con la lista di servizi in esecuzione nel cluster. Queste environment variables rispettano la sintassi dei Docker links. Per un servizio chiamato _foo_ che è in esecuzione in un Container di nome _bar_, le seguenti variabili sono generate: FOO_SERVICE_HOST= FOO_SERVICE_PORT= I servizi hanno un indirizzo IP dedicato e sono disponibili nei Container anche via DNS se il [DNS addon](http://releases.k8s.io/master/cluster/addons/dns/) è installato nel cluster. Voci correlate -------------- * Approfondisci [Container lifecycle hooks](https://kubernetes.io/it/docs/concepts/containers/container-lifecycle-hooks/) . * Esegui un tutorial su come [definire degli handlers per i Container lifecycle events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . 3 - Container Lifecycle Hooks ============================= Questa pagina descrive come i Container gestiti con kubelet possono utilizzare il lifecycle hook framework dei Container per l'esecuzione di codice eseguito in corrispondenza di alcuni eventi durante il loro ciclo di vita. Overview -------- Analogamente a molti framework di linguaggi di programmazione che hanno degli hooks legati al ciclo di vita dei componenti, come ad esempio Angular, Kubernetes fornisce ai Container degli hook legati al loro ciclo di vita dei Container. Gli hook consentono ai Container di essere consapevoli degli eventi durante il loro ciclo di gestione ed eseguire del codice implementato in un handler quando il corrispondente hook viene eseguito. Container hooks --------------- Esistono due tipi di hook che vengono esposti ai Container: `PostStart` Questo hook viene eseguito successivamente alla creazione del container. Tuttavia, non vi è garanzia che questo hook venga eseguito prima dell'ENTRYPOINT del container. Non vengono passati parametri all'handler. `PreStop` Questo hook viene eseguito prima della terminazione di un container a causa di una richiesta API o di un evento di gestione, come ad esempio un fallimento delle sonde di liveness/startup, preemption, risorse contese e altro. Una chiamata all'hook di `PreStop` fallisce se il container è in stato terminated o completed e l'hook deve finire prima che possa essere inviato il segnale di TERM per fermare il container. Il conto alla rovescia per la terminazione del Pod (grace period) inizia prima dell'esecuzione dell'hook `PreStop`, quindi indipendentemente dall'esito dell'handler, il container terminerà entro il grace period impostato. Non vengono passati parametri all'handler. Una descrizione più dettagliata riguardante al processo di terminazione dei Pod può essere trovata in [Terminazione dei Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) . ### Implementazione degli hook handler I Container possono accedere a un hook implementando e registrando un handler per tale hook. Ci sono due tipi di handler che possono essere implementati per i Container: * Exec - Esegue un comando specifico, tipo `pre-stop.sh`, all'interno dei cgroup e namespace del Container. Le risorse consumate dal comando vengono contate sul Container. * HTTP - Esegue una richiesta HTTP verso un endpoint specifico del Container. ### Esecuzione dell'hook handler Quando viene richiamato l'hook legato al lifecycle del Container, il sistema di gestione di Kubernetes esegue l'handler secondo l'azione dell'hook, `httpGet` e `tcpSocket` vengono eseguiti dal processo kubelet, mentre `exec` è eseguito nel Container. Le chiamate agli handler degli hook sono sincrone rispetto al contesto del Pod che contiene il Container. Questo significa che per un hook `PostStart`, l'ENTRYPOINT e l'hook si attivano in modo asincrono. Tuttavia, se l'hook impiega troppo tempo per essere eseguito o si blocca, il container non può raggiungere lo stato di `running`. Gli hook di `PreStop` non vengono eseguiti in modo asincrono dall'evento di stop del container; l'hook deve completare la sua esecuzione prima che l'evento TERM possa essere inviato. Se un hook di `PreStop` si blocca durante la sua esecuzione, la fase del Pod rimarrà `Terminating` finchè il Pod non sarà rimosso forzatamente dopo la scadenza del suo `terminationGracePeriodSeconds`. Questo grace period si applica al tempo totale necessario per effettuare sia l'esecuzione dell'hook di `PreStop` che per l'arresto normale del container. Se, per esempio, il `terminationGracePeriodSeconds` è di 60, e l'hook impiega 55 secondi per essere completato, e il container impiega 10 secondi per fermarsi normalmente dopo aver ricevuto il segnale, allora il container verrà terminato prima di poter completare il suo arresto, poiché `terminationGracePeriodSeconds` è inferiore al tempo totale (55+10) necessario perché queste due cose accadano. Se un hook `PostStart` o `PreStop` fallisce, allora il container viene terminato. Gli utenti dovrebbero mantenere i loro handler degli hook i più leggeri possibili. Ci sono casi, tuttavia, in cui i comandi di lunga durata hanno senso, come il salvataggio dello stato del container prima della sua fine. ### Garanzia della chiamata dell'hook La chiamata degli hook avviene _almeno una volta_, il che significa che un hook può essere chiamato più volte da un dato evento, come per `PostStart` o `PreStop`. Sta all'implementazione dell'hook gestire correttamente questo aspetto. Generalmente, vengono effettuate singole chiamate agli hook. Se, per esempio, la destinazione di hook HTTP non è momentaneamente in grado di ricevere traffico, non c'è alcun tentativo di re invio. In alcuni rari casi, tuttavia, può verificarsi una doppia chiamata. Per esempio, se un kubelet si riavvia nel mentre dell'invio di un hook, questo potrebbe essere chiamato per una seconda volta dopo che il kubelet è tornato in funzione. ### Debugging Hook handlers I log di un handler di hook non sono esposti negli eventi del Pod. Se un handler fallisce per qualche ragione, trasmette un evento. Per il `PostStart`, questo è l'evento di `FailedPostStartHook`, e per il `PreStop`, questo è l'evento di `FailedPreStopHook`. Puoi vedere questi eventi eseguendo `kubectl describe pod `. Ecco alcuni esempi di output di eventi dall'esecuzione di questo comando: Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook Voci correlate -------------- * Approfondisci [Container environment](https://kubernetes.io/it/docs/concepts/containers/container-environment/) . * Esegui un tutorial su come [definire degli handlers per i Container lifecycle events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . --- # Documentazione di Kubernetes | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/home/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/home/) . Documentazione di Kubernetes ============================ * 1: [Versioni supportate della documentazione di Kubernetes](https://kubernetes.io/it/docs/home/_print/#pg-92dfff0ca612d0bff40171aa9df6c4ae) 1 - Versioni supportate della documentazione di Kubernetes ========================================================== Questo sito contiene la documentazione della versione attuale di Kubernetes e delle quattro versioni precedenti di Kubernetes. --- # Tutorials | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/tutorials/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/tutorials/) . Tutorials ========= * 1: [Hello Minikube](https://kubernetes.io/it/docs/tutorials/_print/#pg-5e3051fff9e84735871d9fb5e7b93f33) Questa sezione della documentazione di Kubernetes contiene i tutorials. Un tutorial mostra come raggiungere un obiettivo più complesso di un singolo [task](https://kubernetes.io/docs/tasks/) . Solitamente un tutorial ha diverse sezioni, ognuna delle quali consiste in una sequenza di più task. Prima di procedere con vari tutorial, raccomandiamo di aggiungere il [Glossario](https://kubernetes.io/it/docs/reference/glossary/) ai tuoi bookmark per riferimenti successivi. Per cominciare -------------- * [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) è un approfondito tutorial che aiuta a capire cosa è Kubernetes e che permette di testare in modo interattivo alcune semplici funzionalità di Kubernetes. * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) * [Hello Minikube](https://kubernetes.io/it/docs/tutorials/hello-minikube/) Configurazione -------------- * [Configurare Redis utilizzando una ConfigMap](https://kubernetes.io/docs/tutorials/configuration/configure-redis-using-configmap/) Stateless Applications ---------------------- * [Esporre un External IP Address per permettere l'accesso alle applicazioni nel Cluster](https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address/) * [Esempio: Rilasciare l'applicazione PHP Guestbook con Redis](https://kubernetes.io/docs/tutorials/stateless-application/guestbook/) Stateful Applications --------------------- * [StatefulSet Basics](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/) * [Esempio: WordPress e MySQL con i PersistentVolumes](https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) * [Esempio: Rilasciare Cassandra con i StatefulSets](https://kubernetes.io/docs/tutorials/stateful-application/cassandra/) * [Eseguire ZooKeeper, un sistema distribuito CP](https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/) Clusters -------- * [AppArmor](https://kubernetes.io/docs/tutorials/clusters/apparmor/) * [Seccomp](https://kubernetes.io/docs/tutorials/clusters/seccomp/) Servizi ------- * [Utilizzare Source IP](https://kubernetes.io/docs/tutorials/services/source-ip/) Voci correlate -------------- Se sei interessato a scrivere un tutorial, vedi [Utilizzare i Page Templates](https://kubernetes.io/docs/home/contribute/page-templates/) per informazioni su come creare una tutorial page e sul tutorial template. 1 - Hello Minikube ================== Questo tutorial mostra come eseguire una semplice applicazione in Kubernetes utilizzando [Minikube](https://kubernetes.io/docs/setup/learning-environment/minikube) e Katacoda. Katacoda permette di operare su un'installazione di Kubernetes dal tuo browser. #### Nota: Come alternativa, è possibile eseguire questo tutorial [installando minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) localmente. Obbiettivi ---------- * Rilasciare una semplice applicazione su Minikube. * Eseguire l'applicazione. * Visualizzare i log dell'applicazione. Prima di cominciare ------------------- Questo tutorial fornisce una container image che utilizza NGINX per risponde a tutte le richieste con un echo che visualizza i dati della richiesta stessa. Crea un Minikube cluster ------------------------ 1. Click **Launch Terminal** #### Nota: Se hai installato Minikube localmente, esegui `minikube start`. 2. Apri la console di Kubernetes nel browser: minikube dashboard 3. Katacoda environment only: In alto alla finestra del terminale, fai click segno più, e a seguire click su **Select port to view on Host 1**. 4. Katacoda environment only: Inserisci `30000`, a seguire click su **Display Port**. Crea un Deployment ------------------ Un Kubernetes [_Pod_](https://kubernetes.io/docs/concepts/workloads/pods/pod/) è un gruppo di uno o più Containers, che sono uniti tra loro dal punto di vista amministrativo e che condividono lo stesso network. Il Pod in questo tutorial ha un solo Container. Un Kubernetes [_Deployment_](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) monitora lo stato del Pod ed eventualmente provvedere a farlo ripartire nel caso questo termini. L'uso dei Deployments è la modalità raccomandata per gestire la creazione e lo scaling dei Pods. 1. Usa il comando `kubectl create` per creare un Deployment che gestisce un singolo Pod. Il Pod eseguirà un Container basato sulla Docker image specificata. kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080 2. Visualizza il Deployment: kubectl get deployments L'output del comando è simile a: NAME READY UP-TO-DATE AVAILABLE AGE hello-node 1/1 1 1 1m 3. Visualizza il Pod creato dal Deployment: kubectl get pods L'output del comando è simile a: NAME READY STATUS RESTARTS AGE hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m 4. Visualizza gli eventi del cluster Kubernetes: kubectl get events 5. Visualizza la configurazione di `kubectl`: kubectl config view #### Nota: Per maggiori informazioni sui comandi di `kubectl`, vedi [kubectl overview](https://kubernetes.io/docs/user-guide/kubectl-overview/) . Crea un Service --------------- Con le impostazioni di default, un Pod è accessibile solamente dagli indirizzi IP interni al Kubernetes cluster. Per far si che il Container `hello-node` sia accessibile dall'esterno del Kubernetes virtual network, è necessario esporre il Pod utilizzando un Kubernetes [_Service_](https://kubernetes.io/docs/concepts/services-networking/service/) . 1. Esponi il Pod su internet untilizzando il comando `kubectl expose`: kubectl expose deployment hello-node --type=LoadBalancer --port=8080 Il flag `--type=LoadBalancer` indica la volontà di esporre il Service all'esterno del Kubernetes cluster. 2. Visualizza il Servizio appena creato: kubectl get services L'output del comando è simile a: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s kubernetes ClusterIP 10.96.0.1 443/TCP 23m Nei cloud providers che supportano i servizi di tipo load balancers, viene fornito un indirizzo IP pubblico per permettere l'acesso al Service. Su Minikube, il service type `LoadBalancer` rende il Service accessibile attraverso il comando `minikube service`. 3. Esegui il comando: minikube service hello-node 4. Katacoda environment only: Fai click segno più, e a seguire click su **Select port to view on Host 1**. 5. Katacoda environment only: Fai attenzione al numero di 5 cifre visualizzato a fianco di `8080` nell'output del comando. Questo port number è generato casualmente e può essere diverso nel tuo caso. Inserisci il tuo port number nella textbox, e a seguire fai click su Display Port. Nell'esempio precedente, avresti scritto `30369`. Questo apre un finestra nel browser dove l'applicazione visuallizza l'echo delle richieste ricevute. Attiva gli addons ----------------- Minikube include un set [addons](https://kubernetes.io/it/docs/concepts/cluster-administration/addons/ "Resources that extend the functionality of Kubernetes.") che possono essere attivati, disattivati o eseguti nel ambiente Kubernetes locale. 1. Elenca gli addons disponibili: minikube addons list L'output del comando è simile a: addon-manager: enabled dashboard: enabled default-storageclass: enabled efk: disabled freshpod: disabled gvisor: disabled helm-tiller: disabled ingress: disabled ingress-dns: disabled logviewer: disabled metrics-server: disabled nvidia-driver-installer: disabled nvidia-gpu-device-plugin: disabled registry: disabled registry-creds: disabled storage-provisioner: enabled storage-provisioner-gluster: disabled 2. Attiva un addon, per esempio, `metrics-server`: minikube addons enable metrics-server L'output del comando è simile a: metrics-server was successfully enabled 3. Visualizza i Pods ed i Service creati in precedenza: kubectl get pod,svc -n kube-system L'output del comando è simile a: NAME READY STATUS RESTARTS AGE pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m pod/metrics-server-67fb648c5 1/1 Running 0 26s pod/etcd-minikube 1/1 Running 0 34m pod/influxdb-grafana-b29w8 2/2 Running 0 26s pod/kube-addon-manager-minikube 1/1 Running 0 34m pod/kube-apiserver-minikube 1/1 Running 0 34m pod/kube-controller-manager-minikube 1/1 Running 0 34m pod/kube-proxy-rnlps 1/1 Running 0 34m pod/kube-scheduler-minikube 1/1 Running 0 34m pod/storage-provisioner 1/1 Running 0 34m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s 4. Disabilita `metrics-server`: minikube addons disable metrics-server L'output del comando è simile a: metrics-server was successfully disabled Clean up -------- Adesso puoi procedere a fare clean up delle risorse che hai creato nel tuo cluster: kubectl delete service hello-node kubectl delete deployment hello-node Eventualmente, puoi stoppare la Minikube virtual machine (VM): minikube stop Eventualmente, puoi cancellare la Minikube VM: minikube delete Voci correlate -------------- * Approfondisci la tua conoscenza dei [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) . * Approfondisci la tua conoscenza di [Rilasciare applicazioni](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/) . * Approfondisci la tua conoscenza dei [Services](https://kubernetes.io/docs/concepts/services-networking/service/) . --- # Manage Cluster Daemons | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/docs/tasks/manage-daemon/_print/#) . [Return to the regular view of this page](https://kubernetes.io/docs/tasks/manage-daemon/) . Manage Cluster Daemons ====================== Perform common tasks for managing a DaemonSet, such as performing a rolling update. * 1: [Building a Basic DaemonSet](https://kubernetes.io/docs/tasks/manage-daemon/_print/#pg-4c10d304f68febdf95ee7ab4b6b77a96) * 2: [Perform a Rolling Update on a DaemonSet](https://kubernetes.io/docs/tasks/manage-daemon/_print/#pg-bcfd795e4b59420f7db275a0482af37c) * 3: [Perform a Rollback on a DaemonSet](https://kubernetes.io/docs/tasks/manage-daemon/_print/#pg-f1bf7e426f482a85e1a417d1fd9ea7b7) * 4: [Running Pods on Only Some Nodes](https://kubernetes.io/docs/tasks/manage-daemon/_print/#pg-9f4e3502e32b35c9804dd5a30b65b4cc) 1 - Building a Basic DaemonSet ============================== This page demonstrates how to build a basic [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset "Ensures a copy of a Pod is running across a set of nodes in a cluster.") that runs a Pod on every node in a Kubernetes cluster. It covers a simple use case of mounting a file from the host, logging its contents using an [init container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) , and utilizing a pause container. Before you begin ---------------- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) or you can use one of these Kubernetes playgrounds: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) A Kubernetes cluster with at least two nodes (one control plane node and one worker node) to demonstrate the behavior of DaemonSets. Define the DaemonSet -------------------- In this task, a basic DaemonSet is created which ensures that the copy of a Pod is scheduled on every node. The Pod will use an init container to read and log the contents of `/etc/machine-id` from the host, while the main container will be a `pause` container, which keeps the Pod running. [`application/basic-daemonset.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/basic-daemonset.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy application/basic-daemonset.yaml to clipboard") apiVersion: apps/v1 kind: DaemonSet metadata: name: example-daemonset spec: selector: matchLabels: app.kubernetes.io/name: example template: metadata: labels: app.kubernetes.io/name: example spec: containers: - name: pause image: registry.k8s.io/pause initContainers: - name: log-machine-id image: busybox:1.37 command: ['sh', '-c', 'cat /etc/machine-id > /var/log/machine-id.log'] volumeMounts: - name: machine-id mountPath: /etc/machine-id readOnly: true - name: log-dir mountPath: /var/log volumes: - name: machine-id hostPath: path: /etc/machine-id type: File - name: log-dir hostPath: path: /var/log 1. Create a DaemonSet based on the (YAML) manifest: kubectl apply -f https://k8s.io/examples/application/basic-daemonset.yaml 2. Once applied, you can verify that the DaemonSet is running a Pod on every node in the cluster: kubectl get pods -o wide The output will list one Pod per node, similar to: NAME READY STATUS RESTARTS AGE IP NODE example-daemonset-xxxxx 1/1 Running 0 5m x.x.x.x node-1 example-daemonset-yyyyy 1/1 Running 0 5m x.x.x.x node-2 3. You can inspect the contents of the logged `/etc/machine-id` file by checking the log directory mounted from the host: kubectl exec -- cat /var/log/machine-id.log Where `` is the name of one of your Pods. Cleaning up ----------- To delete the DaemonSet, run this command: kubectl delete --cascade=foreground --ignore-not-found --now daemonsets/example-daemonset This simple DaemonSet example introduces key components like init containers and host path volumes, which can be expanded upon for more advanced use cases. For more details refer to [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) . What's next ----------- * See [Performing a rolling update on a DaemonSet](https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/) * See [Creating a DaemonSet to adopt existing DaemonSet pods](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) 2 - Perform a Rolling Update on a DaemonSet =========================================== This page shows how to perform a rolling update on a DaemonSet. Before you begin ---------------- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) or you can use one of these Kubernetes playgrounds: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) DaemonSet Update Strategy ------------------------- DaemonSet has two update strategy types: * `OnDelete`: With `OnDelete` update strategy, after you update a DaemonSet template, new DaemonSet pods will _only_ be created when you manually delete old DaemonSet pods. This is the same behavior of DaemonSet in Kubernetes version 1.5 or before. * `RollingUpdate`: This is the default update strategy. With `RollingUpdate` update strategy, after you update a DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods will be created automatically, in a controlled fashion. At most one pod of the DaemonSet will be running on each node during the whole update process. Performing a Rolling Update --------------------------- To enable the rolling update feature of a DaemonSet, you must set its `.spec.updateStrategy.type` to `RollingUpdate`. You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (default to 1), [`.spec.minReadySeconds`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (default to 0) and [`.spec.updateStrategy.rollingUpdate.maxSurge`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (defaults to 0) as well. ### Creating a DaemonSet with `RollingUpdate` update strategy This YAML file specifies a DaemonSet with an update strategy as 'RollingUpdate' [`controllers/fluentd-daemonset.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/controllers/fluentd-daemonset.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy controllers/fluentd-daemonset.yaml to clipboard") apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd-elasticsearch namespace: kube-system labels: k8s-app: fluentd-logging spec: selector: matchLabels: name: fluentd-elasticsearch updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 template: metadata: labels: name: fluentd-elasticsearch spec: tolerations: # these tolerations are to have the daemonset runnable on control plane nodes # remove them if your control plane nodes should not run pods - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule - key: node-role.kubernetes.io/master operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1 volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers After verifying the update strategy of the DaemonSet manifest, create the DaemonSet: kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to update the DaemonSet with `kubectl apply`. kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml ### Checking DaemonSet `RollingUpdate` update strategy Check the update strategy of your DaemonSet, and make sure it's set to `RollingUpdate`: kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system If you haven't created the DaemonSet in the system, check your DaemonSet manifest with the following command instead: kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' The output from both commands should be: RollingUpdate If the output isn't `RollingUpdate`, go back and modify the DaemonSet object or manifest accordingly. ### Updating a DaemonSet template Any updates to a `RollingUpdate` DaemonSet `.spec.template` will trigger a rolling update. Let's update the DaemonSet by applying a new YAML file. This can be done with several different `kubectl` commands. [`controllers/fluentd-daemonset-update.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/controllers/fluentd-daemonset-update.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy controllers/fluentd-daemonset-update.yaml to clipboard") apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd-elasticsearch namespace: kube-system labels: k8s-app: fluentd-logging spec: selector: matchLabels: name: fluentd-elasticsearch updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 template: metadata: labels: name: fluentd-elasticsearch spec: tolerations: # these tolerations are to have the daemonset runnable on control plane nodes # remove them if your control plane nodes should not run pods - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule - key: node-role.kubernetes.io/master operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers #### Declarative commands If you update DaemonSets using [configuration files](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/) , use `kubectl apply`: kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset-update.yaml #### Imperative commands If you update DaemonSets using [imperative commands](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/) , use `kubectl edit` : kubectl edit ds/fluentd-elasticsearch -n kube-system ##### Updating only the container image If you only need to update the container image in the DaemonSet template, i.e. `.spec.template.spec.containers[*].image`, use `kubectl set image`: kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system ### Watching the rolling update status Finally, watch the rollout status of the latest DaemonSet rolling update: kubectl rollout status ds/fluentd-elasticsearch -n kube-system When the rollout is complete, the output is similar to this: daemonset "fluentd-elasticsearch" successfully rolled out Troubleshooting --------------- ### DaemonSet rolling update is stuck Sometimes, a DaemonSet rolling update may be stuck. Here are some possible causes: #### Some nodes run out of resources The rollout is stuck because new DaemonSet pods can't be scheduled on at least one node. This is possible when the node is [running out of resources](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/) . When this happens, find the nodes that don't have the DaemonSet pods scheduled on by comparing the output of `kubectl get nodes` and the output of: kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system Once you've found those nodes, delete some non-DaemonSet pods from the node to make room for new DaemonSet pods. #### Note: This will cause service disruption when deleted pods are not controlled by any controllers or pods are not replicated. This does not respect [PodDisruptionBudget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) either. #### Broken rollout If the recent DaemonSet template update is broken, for example, the container is crash looping, or the container image doesn't exist (often due to a typo), DaemonSet rollout won't progress. To fix this, update the DaemonSet template again. New rollout won't be blocked by previous unhealthy rollouts. #### Clock skew If `.spec.minReadySeconds` is specified in the DaemonSet, clock skew between master and nodes will make DaemonSet unable to detect the right rollout progress. Clean up -------- Delete DaemonSet from a namespace : kubectl delete ds fluentd-elasticsearch -n kube-system What's next ----------- * See [Performing a rollback on a DaemonSet](https://kubernetes.io/docs/tasks/manage-daemon/rollback-daemon-set/) * See [Creating a DaemonSet to adopt existing DaemonSet pods](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) 3 - Perform a Rollback on a DaemonSet ===================================== This page shows how to perform a rollback on a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset "Ensures a copy of a Pod is running across a set of nodes in a cluster.") . Before you begin ---------------- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) or you can use one of these Kubernetes playgrounds: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) Your Kubernetes server must be at or later than version 1.7. To check the version, enter `kubectl version`. You should already know how to [perform a rolling update on a DaemonSet](https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/) . Performing a rollback on a DaemonSet ------------------------------------ ### Step 1: Find the DaemonSet revision you want to roll back to You can skip this step if you only want to roll back to the last revision. List all revisions of a DaemonSet: kubectl rollout history daemonset This returns a list of DaemonSet revisions: daemonsets "" REVISION CHANGE-CAUSE 1 ... 2 ... ... * Change cause is copied from DaemonSet annotation `kubernetes.io/change-cause` to its revisions upon creation. You may specify `--record=true` in `kubectl` to record the command executed in the change cause annotation. To see the details of a specific revision: kubectl rollout history daemonset --revision=1 This returns the details of that revision: daemonsets "" with revision #1 Pod Template: Labels: foo=bar Containers: app: Image: ... Port: ... Environment: ... Mounts: ... Volumes: ... ### Step 2: Roll back to a specific revision # Specify the revision number you get from Step 1 in --to-revision kubectl rollout undo daemonset --to-revision= If it succeeds, the command returns: daemonset "" rolled back #### Note: If `--to-revision` flag is not specified, kubectl picks the most recent revision. ### Step 3: Watch the progress of the DaemonSet rollback `kubectl rollout undo daemonset` tells the server to start rolling back the DaemonSet. The real rollback is done asynchronously inside the cluster [control plane](https://kubernetes.io/docs/reference/glossary/?all=true#term-control-plane "The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.") . To watch the progress of the rollback: kubectl rollout status ds/ When the rollback is complete, the output is similar to: daemonset "" successfully rolled out Understanding DaemonSet revisions --------------------------------- In the previous `kubectl rollout history` step, you got a list of DaemonSet revisions. Each revision is stored in a resource named ControllerRevision. To see what is stored in each revision, find the DaemonSet revision raw resources: kubectl get controllerrevision -l = This returns a list of ControllerRevisions: NAME CONTROLLER REVISION AGE - DaemonSet/ 1 1h - DaemonSet/ 2 1h Each ControllerRevision stores the annotations and template of a DaemonSet revision. `kubectl rollout undo` takes a specific ControllerRevision and replaces DaemonSet template with the template stored in the ControllerRevision. `kubectl rollout undo` is equivalent to updating DaemonSet template to a previous revision through other commands, such as `kubectl edit` or `kubectl apply`. #### Note: DaemonSet revisions only roll forward. That is to say, after a rollback completes, the revision number (`.revision` field) of the ControllerRevision being rolled back to will advance. For example, if you have revision 1 and 2 in the system, and roll back from revision 2 to revision 1, the ControllerRevision with `.revision: 1` will become `.revision: 3`. Troubleshooting --------------- * See [troubleshooting DaemonSet rolling update](https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting) . 4 - Running Pods on Only Some Nodes =================================== This page demonstrates how can you run [Pods](https://kubernetes.io/docs/concepts/workloads/pods/ "A Pod represents a set of running containers in your cluster.") on only some [Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/ "A node is a worker machine in Kubernetes.") as part of a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset "Ensures a copy of a Pod is running across a set of nodes in a cluster.") Before you begin ---------------- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) or you can use one of these Kubernetes playgrounds: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) Running Pods on only some Nodes ------------------------------- Imagine that you want to run a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset "Ensures a copy of a Pod is running across a set of nodes in a cluster.") , but you only need to run those daemon pods on nodes that have local solid state (SSD) storage. For example, the Pod might provide cache service to the node, and the cache is only useful when low-latency local storage is available. ### Step 1: Add labels to your nodes Add the label `ssd=true` to the nodes which have SSDs. kubectl label nodes example-node-1 example-node-2 ssd=true ### Step 2: Create the manifest Let's create a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset "Ensures a copy of a Pod is running across a set of nodes in a cluster.") which will provision the daemon pods on the SSD labeled [nodes](https://kubernetes.io/docs/concepts/architecture/nodes/ "A node is a worker machine in Kubernetes.") only. Next, use a `nodeSelector` to ensure that the DaemonSet only runs Pods on nodes with the `ssd` label set to `"true"`. [`controllers/daemonset-label-selector.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/controllers/daemonset-label-selector.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy controllers/daemonset-label-selector.yaml to clipboard") apiVersion: apps/v1 kind: DaemonSet metadata: name: ssd-driver labels: app: nginx spec: selector: matchLabels: app: ssd-driver-pod template: metadata: labels: app: ssd-driver-pod spec: nodeSelector: ssd: "true" containers: - name: example-container image: example-image ### Step 3: Create the DaemonSet Create the DaemonSet from the manifest by using `kubectl create` or `kubectl apply` Let's label another node as `ssd=true`. kubectl label nodes example-node-3 ssd=true Labelling the node automatically triggers the control plane (specifically, the DaemonSet controller) to run a new daemon pod on that node. kubectl get pods -o wide The output is similar to: NAME READY STATUS RESTARTS AGE IP NODE 1/1 Running 0 13s ..... example-node-1 1/1 Running 0 13s ..... example-node-2 1/1 Running 0 5s ..... example-node-3 --- # नीतियाँ | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/concepts/policy/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/concepts/policy/) . नीतियाँ ======= नीतियों के साथ सुरक्षा और सर्वोत्तम प्रथाओं को प्रबंधित करें। Kubernetes नीतियाँ वे कॉन्फ़िगरेशन होती हैं जो अन्य कॉन्फ़िगरेशन या रनटाइम व्यवहारों को प्रबंधित करती हैं। Kubernetes विभिन्न प्रकार की नीतियाँ प्रदान करता है, जो नीचे दी गई हैं: API ऑब्जेक्ट्स का उपयोग करके नीतियाँ लागू करें ---------------------------------------------- कुछ API ऑब्जेक्ट्स नीतियों के रूप में कार्य करते हैं। यहाँ कुछ उदाहरण दिए गए हैं: * [NetworkPolicies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) का उपयोग किसी वर्कलोड के लिए इनग्रेस और एग्रेस ट्रैफिक को प्रतिबंधित करने के लिए किया जा सकता है। * [LimitRanges](https://kubernetes.io/docs/concepts/policy/limit-range/) विभिन्न ऑब्जेक्ट प्रकारों के बीच संसाधन आवंटन सीमाओं का प्रबंधन करते हैं। * [ResourceQuotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) किसी [नेमस्पेस](https://kubernetes.io/hi/docs/concepts/overview/working-with-objects/namespaces "An abstraction used by Kubernetes to support isolation of groups of resources within a single cluster.") के लिए संसाधन खपत को सीमित करती हैं। Admission Controllers का उपयोग करके नीतियाँ लागू करें ----------------------------------------------------- एक [admission controller](https://kubernetes.io/hi/docs/reference/access-authn-authz/admission-controllers/ "कोड का एक भाग जो ऑब्जेक्ट के स्थायी रूप से संग्रहीत होने से पहले कुबेरनेट्स API सर्वर को भेजे गए अनुरोधों को इंटरसेप्ट करता है।") API सर्वर में चलता है और API अनुरोधों को सत्यापित या बदल सकता है। कुछ admission controllers नीतियों को लागू करने के लिए कार्य करते हैं। उदाहरण के लिए, [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller प्रत्येक नए Pod में इमेज पुल नीति को `Always` पर सेट करने के लिए सक्षम करता है। Kubernetes के पास कई अंतर्निहित admission controllers हैं जिन्हें API सर्वर `--enable-admission-plugins` फ्लैग के माध्यम से कॉन्फ़िगर किया जा सकता है। Admission controllers के बारे में विस्तृत जानकारी, उपलब्ध admission controllers की पूरी सूची के साथ, एक समर्पित अनुभाग में प्रलेखित है: * [Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) ValidatingAdmissionPolicy का उपयोग करके नीतियाँ लागू करें --------------------------------------------------------- Validating admission policies, API सर्वर में कॉन्फ़िगर करने योग्य सत्यापन जांचों को लागू करने की अनुमति देती हैं, जो Common Expression Language (CEL) का उपयोग करती हैं। उदाहरण के लिए, एक `ValidatingAdmissionPolicy` का उपयोग `latest` इमेज टैग के उपयोग को अस्वीकृत करने के लिए किया जा सकता है। एक `ValidatingAdmissionPolicy` एक API अनुरोध पर कार्य करता है और गैर-अनुपालन कॉन्फ़िगरेशनों के बारे में उपयोगकर्ताओं को ब्लॉक, ऑडिट, और चेतावनी देने के लिए उपयोग किया जा सकता है। `ValidatingAdmissionPolicy` API के बारे में विवरण, उदाहरणों सहित, एक समर्पित अनुभाग में प्रलेखित है: * [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) Dynamic admission control का उपयोग करके नीतियाँ लागू करें --------------------------------------------------------- Dynamic admission controllers (या admission webhooks) API सर्वर के बाहर एक अलग एप्लिकेशन के रूप में चलते हैं जो API अनुरोधों के सत्यापन या संशोधन के लिए वेबहुक अनुरोधों को प्राप्त करने के लिए पंजीकृत होते हैं। Dynamic admission controllers का उपयोग API अनुरोधों पर नीतियाँ लागू करने और अन्य नीति-आधारित वर्कफ़्लोज़ को ट्रिगर करने के लिए किया जा सकता है। एक dynamic admission controller ऐसी जटिल जांच कर सकता है, जिसमें अन्य क्लस्टर संसाधनों और बाहरी डेटा की पुनर्प्राप्ति की आवश्यकता होती है। उदाहरण के लिए, एक इमेज सत्यापन जांच OCI रजिस्ट्रियों से डेटा प्राप्त करके कंटेनर इमेज हस्ताक्षर और प्रमाणपत्रों को मान्य करने के लिए उपयोग की जा सकती है। Dynamic admission control के बारे में विवरण एक समर्पित अनुभाग में प्रलेखित है: * [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) ### Implementations **टिप्पणी:** यह खंड अन्य पक्ष परियोजनाओं से जुड़ा है जो कुबेरनेट्स द्वारा आवश्यक कार्यक्षमता प्रदान करते हैं। कुबेरनेट्स परियोजना के लेखक इन परियोजनाओं के लिए जिम्मेदार नहीं हैं। यह पृष्ठ [CNCF वेबसाइट दिशानिर्देश](https://github.com/cncf/foundation/blob/master/website-guidelines.md) का अनुसरण करते हुए परियोजनाओं को वर्णानुक्रम में सूचीबद्ध करता है। इस सूची में कोई नई परियोजना जोड़ने से पहले यह [विषय मार्गदर्शक](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) पृष्ट पढ़के ही परिवर्तन करें। Dynamic admission controllers जो फ्लेक्सिबल नीति इंजन के रूप में कार्य करते हैं, उन्हें कुबेरनेट्स इकोसिस्टम में विकसित किया जा रहा है, जैसे की: * [Kubewarden](https://github.com/kubewarden) * [Kyverno](https://kyverno.io/) * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) * [Polaris](https://polaris.docs.fairwinds.com/admission-controller/) Kubelet कॉन्फ़िगरेशनों का उपयोग करके नीतियाँ लागू करें ------------------------------------------------------ Kubernetes प्रत्येक वर्कर नोड पर Kubelet को कॉन्फ़िगर करने की अनुमति देता है। कुछ Kubelet कॉन्फ़िगरेशन नीतियों के रूप में कार्य करते हैं: * [Process ID limits and reservations](https://kubernetes.io/docs/concepts/policy/pid-limiting/) का उपयोग आवंटन योग्य PIDs को सीमित और आरक्षित करने के लिए किया जाता है। * [Node Resource Managers](https://kubernetes.io/docs/concepts/policy/node-resource-managers/) उच्च-प्रदर्शन और विलंब-संवेदनशील वर्कलोड्स के लिए कंप्यूट, मेमोरी, और डिवाइस संसाधनों का प्रबंधन कर सकते हैं। --- # Other Tools | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/docs/reference/tools/_print/#) . [Return to the regular view of this page](https://kubernetes.io/docs/reference/tools/) . Other Tools =========== Kubernetes contains several tools to help you work with the Kubernetes system. crictl ------ [`crictl`](https://github.com/kubernetes-sigs/cri-tools) is a command-line interface for inspecting and debugging [CRI](https://kubernetes.io/docs/concepts/architecture/cri "Protocol for communication between the kubelet and the local container runtime.") \-compatible container runtimes. Dashboard --------- [`Dashboard`](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) , the web-based user interface of Kubernetes, allows you to deploy containerized applications to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself. Headlamp -------- [Headlamp](https://headlamp.dev/) is an extensible Kubernetes graphical user interface, and is an optional Kubernetes cluster component. Headlamp is part of the Kubernetes project. Headlamp provides: * A modern, user-friendly graphical interface for cluster management and troubleshooting * Support for both in-cluster deployment and desktop application modes * Extensibility through a plugin system * RBAC-based controls that adapt to user permissions Helm ---- 🛇 This item links to a third party project or product that is not part of Kubernetes itself. [More information](https://kubernetes.io/docs/reference/tools/_print/#third-party-content-disclaimer) [Helm](https://helm.sh/) is a tool for managing packages of pre-configured Kubernetes resources. These packages are known as _Helm charts_. Use Helm to: * Find and use popular software packaged as Kubernetes charts * Share your own applications as Kubernetes charts * Create reproducible builds of your Kubernetes applications * Intelligently manage your Kubernetes manifest files * Manage releases of Helm packages Kompose ------- [`Kompose`](https://github.com/kubernetes/kompose) is a tool to help Docker Compose users move to Kubernetes. Use Kompose to: * Translate a Docker Compose file into Kubernetes objects * Go from local Docker development to managing your application via Kubernetes * Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/) Kui --- [`Kui`](https://github.com/kubernetes-sigs/kui) is a GUI tool that takes your normal `kubectl` command line requests and responds with graphics. Instead of ASCII tables, Kui provides a GUI rendering with tables that you can sort. Kui lets you: * Directly click on long, auto-generated resource names instead of copying and pasting * Type in `kubectl` commands and see them execute, even sometimes faster than `kubectl` itself * Query a [Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/ "A finite or batch task that runs to completion.") and see its execution rendered as a waterfall diagram * Click through resources in your cluster using a tabbed UI Minikube -------- [`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that runs a single-node Kubernetes cluster locally on your workstation for development and testing purposes. --- # उत्पादन वातावरण | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/setup/production-environment/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/setup/production-environment/) . उत्पादन वातावरण =============== एक उत्पादन-गुणवत्ता वाला कुबेरनेट्स क्लस्टर बनाएं * 1: [कंटेनर रनटाइम](https://kubernetes.io/hi/docs/setup/production-environment/_print/#pg-a77d3feb6e6d9978f32fa14622642e9a) * 2: [Turnkey Cloud Solutions](https://kubernetes.io/hi/docs/setup/production-environment/_print/#pg-d2f55eefe7222b7c637875af9c3ec199) * 3: [परिनियोजन टूल के साथ कुबेरनेट्स स्थापित करे](https://kubernetes.io/hi/docs/setup/production-environment/_print/#pg-00e1646f68aeb89f9722cf6f6cfcad94) * 4: [कुबेरनेट्स में Windows](https://kubernetes.io/hi/docs/setup/production-environment/_print/#pg-acce7e24090fea04715a7a516ba3e69b) उत्पादन-गुणवत्ता वाले कुबेरनेट्स क्लस्टर के लिए योजना और तैयारी की आवश्यकता होती है। यदि आपका कुबेरनेट्स क्लस्टर महत्वपूर्ण कार्यभार चलाने के लिए है, तो इसे लचीला होने के लिए कॉन्फ़िगर किया जाना चाहिए। यह पेज उन चरणों के बारे में बताता है जो आप उत्पादन के लिए तैयार क्लस्टर सेटअप करने के लिए, या उत्पादन के उपयोग के लिए मौजूदा क्लस्टर को अपग्रेड करने के लिए उठा सकते हैं। यदि आप पहले से ही उत्पादन सेटअप से परिचित हैं और लिंक चाहते हैं, तो [आगे जाएं](https://kubernetes.io/hi/docs/setup/production-environment/_print/#what-s-next) । उत्पादन विचार ------------- आमतौर पर, उत्पादन कुबेरनेट्स क्लस्टर वातावरण में व्यक्तिगत सीखने, विकास या परीक्षण वातावरण कुबेरनेट्स की तुलना में अधिक आवश्यकताएं होती हैं। एक उत्पादन वातावरण की आवश्यकता ये हो सकती है, जैसे: कई उपयोगकर्ताओं द्वारा सुरक्षित पहुंच, लगातार उपलब्धता, और बदलती मांगों के लिए संसाधनों को अनुकूलित करना। जैसा कि आप तय करते हैं कि आप अपने उत्पादन कुबेरनेट्स वातावरण को कहाँ रखना चाहते हैं (परिसर या क्लाउड में) और प्रबंधन की मात्रा जिसे आप दूसरों को देना या सौंपना चाहते हैं, विचार करें कि कुबेरनेट्स क्लस्टर के लिए आपकी आवश्यकताएं निम्नलिखित मुद्दों से कैसे प्रभावित होती हैं: * _उपलब्धता_: सिंगल-मशीन कुबेरनेट्स [सीखने का माहौल](https://kubernetes.io/hi/docs/setup/#learning-environment) में विफलता का एक बिंदु है। अत्यधिक उपलब्ध क्लस्टर बनाने का अर्थ है: * कण्ट्रोल प्लेन को वर्कर नोड्स से अलग करना। * कई नोड्स पर कण्ट्रोल प्लेन घटकों की प्रतिकृति। * क्लस्टर के लिए संतुलन यातायात लोड करें[API server](https://kubernetes.io/hi/docs/concepts/overview/components/#kube-apiserver "एक कंट्रोल प्लेन घटक जो कुबेरनेट्स API की सेवाएं प्रदान करता है।।") . * पर्याप्त वर्कर नोड्स उपलब्ध होना, या जल्दी से उपलब्ध होने में सक्षम होना, क्योंकि बदलते वर्कलोड इसे वारंट करते हैं। * _स्केल_: यदि आप उम्मीद करते हैं कि आपके उत्पादन कुबेरनेट्स पर्यावरण को मांग की एक स्थिर मात्रा प्राप्त होगी, तो आप उस क्षमता के लिए सेटअप करने में सक्षम हो सकते हैं जिसकी आपको आवश्यकता है और किया जा सकता है। हालाँकि, यदि आप समय के साथ मांग बढ़ने की उम्मीद करते हैं या मौसम या विशेष घटनाओं जैसी चीजों के आधार पर अचानक से बदलते हैं, तो आपको योजना बनाने की आवश्यकता है कि कण्ट्रोल प्लेन और वर्कर नोड्स के लिए अधिक अनुरोधों से बढ़े दबाव को कैसे दूर किया जाए या अप्रयुक्त संसाधनों को कम करने के लिए स्केल किया जाए। * _सुरक्षा और एक्सेस मैनेजमेंट_: आपके अपने कुबेरनेट्स लर्निंग क्लस्टर पर पूर्ण व्यवस्थापकीय विशेषाधिकार हैं। लेकिन महत्वपूर्ण कार्यभार के साथ साझा क्लस्टर, और एक या दो से अधिक उपयोगकर्ता, को क्लस्टर संसाधनों तक कौन और क्या एक्सेस कर सकता है, इसके लिए अधिक परिष्कृत दृष्टिकोण की आवश्यकता होती है। आप यह सुनिश्चित करने के लिए ([भूमिका-आधारित एक्सेस कण्ट्रोल](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) ) और अन्य सुरक्षा तंत्रों का उपयोग कर सकते हैं कि उपयोगकर्ता और कार्यभार उन संसाधनों तक पहुँच प्राप्त कर सकते हैं जिनकी उन्हें आवश्यकता है, साथ ही में कार्यभार और क्लस्टर को साथ में सुरक्षित रख सके। आप [नीतियों](https://kubernetes.io/hi/docs/concepts/policy/) और [कंटेनर संसाधन](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) को प्रबंधित करके उन संसाधनों की सीमा निर्धारित कर सकते हैं जिन तक उपयोगकर्ता और कार्यभार पहुंच सकते हैं। कुबेरनेट्स उत्पादन वातावरण को स्वयं बनाने से पहले, इस कार्य में से कुछ या सभी को सौंपने पर विचार करें [टर्नकी क्लाउड सॉल्यूशंस](https://kubernetes.io/hi/docs/setup/production-environment/turnkey-solutions/) प्रदाता या अन्य [कुबेरनेट्स पार्टनर्स](https://kubernetes.io/partners/) विकल्पों में शामिल हैं: * _सर्वरलेस_: किसी क्लस्टर को प्रबंधित किए बिना केवल तृतीय-पक्ष उपकरण पर कार्यभार चलाएं। आपसे सीपीयू उपयोग, मेमोरी और डिस्क अनुरोध जैसी चीज़ों के लिए शुल्क लिया जाएगा। * _व्यवस्थित कण्ट्रोल प्लेन_: प्रदाता को क्लस्टर के कण्ट्रोल प्लेन के पैमाने और उपलब्धता का प्रबंधन करने दें, साथ ही पैच और अपग्रेड को भी संभालें। * _व्यवस्थित वर्कर नोड्स_: अपनी आवश्यकताओं को पूरा करने के लिए नोड्स के पूल को कॉन्फ़िगर करें, फिर प्रदाता सुनिश्चित करता है कि वे नोड उपलब्ध हैं और जरूरत पड़ने पर अपग्रेड को लागू करने के लिए तैयार हैं। * _एकीकरण_: ऐसे प्रदाता हैं जो कुबेरनेट्स को अन्य सेवाओं के साथ एकीकृत करते हैं जिनकी आपको आवश्यकता हो सकती है, जैसे भंडारण, कंटेनर रजिस्ट्रियां, प्रमाणीकरण तरीके, और विकास उपकरण। चाहे आप कुबेरनेट्स क्लस्टर का निर्माण स्वयं करें या भागीदारों के साथ काम करें, अपनी आवश्यकताओं का मूल्यांकन करने के लिए निम्नलिखित अनुभागों की समीक्षा करें क्योंकि वे आपके क्लस्टर से संबंधित हैं _कण्ट्रोल प्लेन_, _वर्कर नोड्स_, _यूज़र एक्सेस_, और _वर्कलोड रिसोर्सस_. उत्पादन क्लस्टर सेटअप --------------------- उत्पादन-गुणवत्ता वाले कुबेरनेट्स क्लस्टर में, कण्ट्रोल प्लेन क्लस्टर को उन सेवाओं से प्रबंधित करता है जिन्हें विभिन्न तरीकों से कई कंप्यूटरों में फैलाया जा सकता है। हालाँकि, प्रत्येक वर्कर नोड एक एकल इकाई का प्रतिनिधित्व करता है जिसे कुबेरनेट्स पॉड चलाने के लिए कॉन्फ़िगर किया गया है। ### उत्पादन कण्ट्रोल प्लेन सबसे सरल कुबेरनेट्स क्लस्टर में एक ही मशीन पर चलने वाले संपूर्ण कण्ट्रोल प्लेन और वर्कर नोड सेवाएं होती हैं। आप वर्कर नोड्स को जोड़कर उस वातावरण को विकसित कर सकते हैं, जैसा कि [कुबेरनेट्स कंपोनेंट्स](https://kubernetes.io/docs/concepts/overview/components/) के डायग्राम में दर्शाया गया है। यदि क्लस्टर थोड़े समय के लिए उपलब्ध होने के लिए है, या अगर कुछ गंभीर रूप से गलत हो जाता है, तो इसे छोड़ दिया जा सकता है, यह आपकी आवश्यकताओं को पूरा कर सकता है। यदि आपको अधिक स्थायी, अत्यधिक उपलब्ध क्लस्टर की आवश्यकता है, तो आपको कण्ट्रोल प्लेन को विस्तारित करने के तरीकों पर विचार करना चाहिए। डिजाइन के अनुसार, एक मशीन पर चलने वाली एक-मशीन कण्ट्रोल प्लेन सेवाएं अत्यधिक उपलब्ध नहीं हैं। यदि क्लस्टर को चालू रखना और यह सुनिश्चित करना कि कुछ गलत होने पर इसकी मरम्मत की जा सकती है, महत्वपूर्ण है, तो इन चरणों पर विचार करें: * _डिप्लॉयमेंट टूल्स चुनें_: आप kubeadm, kops, और kubespray जैसे टूल का उपयोग करके एक कण्ट्रोल प्लेन को तैनात कर सकते हैं। उनमें से प्रत्येक डिप्लॉयमेंट विधियों का उपयोग करके उत्पादन-गुणवत्ता डिप्लॉयमेंट के लिए युक्तियों को जानने के लिए [डिप्लॉयमेंट टूल्स के साथ कुबेरनेट्स स्थापित करना](https://kubernetes.io/hi/docs/setup/production-environment/tools/) देखें। आपके डिप्लॉयमेंट के साथ उपयोग करने के लिए विभिन्न [कंटेनर रनटाइम](https://kubernetes.io/hi/docs/setup/production-environment/container-runtimes/) उपलब्ध हैं। * _सर्टिफ़िकेट प्रबंधित करे_: कण्ट्रोल प्लेन सेवाओं के बीच सुरक्षित संचार सर्टिफ़िकेटस का उपयोग करके कार्यान्वित किया जाता है। डिप्लॉयमेंट के दौरान सर्टिफ़िकेट स्वचालित रूप से उत्पन्न होते हैं या आप अपने स्वयं के सर्टिफ़िकेट अथॉरिटी का उपयोग करके उन्हें उत्पन्न कर सकते हैं। विवरण के लिए [PKI सर्टिफ़िकेटस और आवश्यकताएं](https://kubernetes.io/docs/setup/best-practices/certificates/) देखें। * _एपिसर्वर के लिए लोड बैलेंसर कॉन्फ़िगर करें_: विभिन्न नोड्स पर चल रहे एपिसर्वर सर्विस इंस्टेंस के लिए बाहरी एपीआई अनुरोधों को वितरित करने के लिए लोड बैलेंसर को कॉन्फ़िगर करें। विवरण के लिए [एक बाहरी लोड बैलेंसर बनाना](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) देखें। * _अलग और बैकअप etcd सेवा_: अतिरिक्त सुरक्षा और उपलब्धता के लिए etcd सेवाएं या तो अन्य कंट्रोल प्लेन सेवाओं के समान मशीनों पर चल सकती हैं या अलग मशीनों पर चल सकती हैं। क्योंकि etcd क्लस्टर कॉन्फ़िगरेशन डेटा संग्रहीत करता है, etcd डेटाबेस का बैकअप नियमित रूप से किया जाना चाहिए ताकि यह सुनिश्चित हो सके कि यदि आवश्यक हो तो आप उस डेटाबेस की मरम्मत कर सकते हैं। etcd को कॉन्फ़िगर करने और उपयोग करने के विवरण के लिए [etcd अक्सर पूछे जाने वाले प्रश्न](https://etcd.io/docs/v3.5/faq/) देखें। विवरण के लिए [कुबेरनेट्स के लिए ऑपरेटिंग etcd क्लस्टर](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) और [क्यूबएडीएम के साथ एक उच्च उपलब्धता etcd क्लस्टर स्थापित करें](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) देखें। * _मल्टीपल कण्ट्रोल प्लेन सिस्टम बनाएं_: उच्च उपलब्धता के लिए, कण्ट्रोल प्लेन एक मशीन तक सीमित नहीं होना चाहिए। यदि कण्ट्रोल प्लेन सेवाएं एक init सेवा (जैसे systemd) द्वारा चलाई जाती हैं, तो प्रत्येक सेवा को कम से कम तीन मशीनों पर चलना चाहिए। हालाँकि, कुबेरनेट्स में पॉड्स के रूप में कण्ट्रोल प्लेन सेवाएं चलाना सुनिश्चित करता है कि आपके द्वारा अनुरोधित सेवाओं की प्रतिकृति संख्या हमेशा उपलब्ध रहेगी। अनुसूचक फॉल्ट सहने वाला होना चाहिए, लेकिन अत्यधिक उपलब्ध नहीं होना चाहिए। कुबेरनेट्स सेवाओं के नेता चुनाव करने के लिए कुछ डिप्लॉयमेंट उपकरण [राफ्ट](https://raft.github.io/) सर्वसम्मति एल्गोरिथ्म की स्थापना करते हैं। यदि प्राथमिक चला जाता है, तो दूसरी सेवा स्वयं को चुनती है और कार्यभार संभालती है। * _कई क्षेत्रों में विस्तार करना_: यदि अपने क्लस्टर को हर समय उपलब्ध रखना महत्वपूर्ण है, तो एक ऐसा क्लस्टर बनाने पर विचार करें, जो कई डेटा केंद्रों पर चलता हो, जिसे क्लाउड वातावरण में ज़ोन के रूप में संदर्भित किया जाता है। ज़ोन(zone) के समूहों को रीजन(region) कहा जाता है। एक ही क्षेत्र में कई क्षेत्रों में एक क्लस्टर फैलाकर, यह इस संभावना में सुधार कर सकता है कि एक क्षेत्र अनुपलब्ध होने पर भी आपका क्लस्टर कार्य करना जारी रखेगा। विवरण के लिए [एक से अधिक ज़ोन मे चलाना](https://kubernetes.io/docs/setup/best-practices/multiple-zones/) देखें। * _चल रही सुविधाओं का प्रबंधन_: यदि आप अपने क्लस्टर को समय के साथ रखने की योजना बनाते हैं, तो इसके स्वास्थ्य और सुरक्षा को बनाए रखने के लिए आपको कुछ कार्य करने होंगे। उदाहरण के लिए, यदि आपने क्यूबएडीएम के साथ स्थापित किया है, तो आपको [सर्टिफिकेट प्रबंधन](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) और [क्यूबएडीएम क्लस्टर्स को अपग्रेड करने](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) में मदद करने के लिए निर्देश दिए गए हैं, कुबेरनेट्स प्रशासनिक कार्यों की लंबी सूची के लिए [क्लस्टर का एडमिनिस्टर](https://kubernetes.io/docs/tasks/administer-cluster/) देखें। जब आप कण्ट्रोल प्लेन सेवाएं चलाते हैं, तो उपलब्ध विकल्पों के बारे में जानने के लिए, [kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) , [क्यूब-कंट्रोलर-मैनेजर](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) , देखें। और [क्यूब-शेड्यूलर](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) कॉम्पोनेन्ट पेज। अत्यधिक उपलब्ध कंट्रोल प्लेन उदाहरणों के लिए [अत्यधिक उपलब्ध टोपोलॉजी के लिए विकल्प](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/) , [kubeadm के साथ अत्यधिक उपलब्ध क्लस्टर बनाना](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) , और [कुबेरनेट्स के लिए ऑपरेटिंग etcd क्लस्टर](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) । etcd बैकअप योजना बनाने के बारे में जानकारी के लिए [etcd क्लस्टर का बैकअप लेना](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) देखें। ### उत्पादन वर्कर नोड्स उत्पादन-गुणवत्ता वाले कार्यभार को लचीला होने की आवश्यकता है और वे जिस चीज पर भरोसा करते हैं वह लचीला होना चाहिए (जैसे कि CoreDNS)। चाहे आप अपने स्वयं के कंट्रोल प्लेन का प्रबंधन करें या क्लाउड प्रदाता आपके लिए इसे करें, आपको अभी भी यह विचार करने की आवश्यकता है कि आप अपने वर्कर नोड्स को कैसे प्रबंधित करना चाहते हैं (इसे बस _नोड्स_ के रूप में भी संदर्भित किया गया है)। * _नोड्स कॉन्फ़िगर करें_: नोड्स भौतिक या आभासी मशीन हो सकते हैं। यदि आप अपने स्वयं के नोड्स बनाना और प्रबंधित करना चाहते हैं, तो आप एक समर्थित ऑपरेटिंग सिस्टम स्थापित कर सकते हैं, फिर उपयुक्त जोड़ और चला सकते हैं [नोड सेवाएं](https://kubernetes.io/docs/concepts/overview/components/#node-components) । विचार करना: * जब आप उपयुक्त मेमोरी, सीपीयू, और डिस्क स्पीड और स्टोरेज क्षमता उपलब्ध कराकर नोड्स सेट करते हैं तो आपके वर्कलोड की मांग। * क्या जेनेरिक कंप्यूटर सिस्टम करेंगे या आपके पास ऐसे वर्कलोड हैं जिन्हें GPU प्रोसेसर, Windows नोड्स या VM आइसोलेशन की आवश्यकता है। * _वैलिदेट(Validate) नोड_: यह सुनिश्चित करने के तरीके के बारे में जानकारी के लिए [वैलिद(Valid) नोड सेटअप](https://kubernetes.io/docs/setup/best-practices/node-conformance/) देखें कि एक नोड कुबेरनेट्स क्लस्टर में शामिल होने के लिए आवश्यकताओं को पूरा करता है। * _क्लस्टर में नोड जोड़ें_: यदि आप अपने स्वयं के क्लस्टर का प्रबंधन कर रहे हैं, तो आप अपनी स्वयं की मशीनें स्थापित करके और या तो उन्हें मैन्युअल रूप से जोड़कर या क्लस्टर के एपिसर्वर में खुद को पंजीकृत करवाकर नोड्स जोड़ सकते हैं। इन तरीकों से नोड्स जोड़ने के लिए कुबेरनेट्स को कैसे सेट करें, इस बारे में जानकारी के लिए [नोड्स](https://kubernetes.io/docs/concepts/architecture/nodes/) अनुभाग देखें। * _क्लस्टर में Windows नोड्स जोड़ें_: कुबेरनेट्स Windows वर्कर नोड्स के लिए समर्थन प्रदान करता है, जिससे आप Windows कंटेनरों में लागू वर्कलोड को चला सकते हैं। विवरण के लिए [कुबेरनेट्स में Windows](https://kubernetes.io/hi/docs/setup/production-environment/windows/) देखें। * _स्केल नोड्स_: आपके क्लस्टर को अंततः जिस क्षमता की आवश्यकता होगी, उसके विस्तार के लिए एक योजना बनाएं। आपको चलाने के लिए आवश्यक पॉड्स और कंटेनरों की संख्या के आधार पर, यह निर्धारित करने में सहायता के लिए [बड़े समूहों के लिए विचार](https://kubernetes.io/docs/setup/best-practices/cluster-large/) देखें कि आपको कितने नोड्स की आवश्यकता है। यदि आप स्वयं नोड्स का प्रबंधन कर रहे हैं, तो इसका अर्थ यह हो सकता है कि आप अपने स्वयं के भौतिक उपकरण खरीदना और स्थापित करना चाहते हैं। * _ऑटोस्केल नोड्स_: अधिकांश क्लाउड प्रदाता अस्वस्थ नोड्स को बदलने के लिए [क्लस्टर ऑटोस्केलर](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) का समर्थन करते हैं या मांग के अनुसार नोड्स की संख्या को बढ़ाते और घटाते हैं। विभिन्न क्लाउड प्रदाताओं द्वारा इसे कैसे कार्यान्वित किया जाता है, इसके लिए [अक्सर पूछे जाने वाले प्रश्न](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) ऑटोस्केलर कैसे काम करता है और [डिप्लॉयमेंट](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) देखें। ऑन-प्रिमाइसेस के लिए, कुछ वर्चुअलाइजेशन प्लेटफॉर्म हैं जिन्हें मांग के आधार पर नए नोड्स को स्पिन करने के लिए स्क्रिप्ट किया जा सकता है। * _नोड स्वास्थ्य जांच सेट करें_: महत्वपूर्ण कार्यभार के लिए, आप यह सुनिश्चित करना चाहते हैं कि उन नोड्स पर चलने वाले नोड और पॉड स्वस्थ हैं। [नोड समस्या डिटेक्टर](https://kubernetes.io/docs/tasks/debug-application-cluster/monitor-node-health/) डेमॉन का उपयोग करके, आप सुनिश्चित कर सकते हैं कि आपके नोड स्वस्थ हैं। उत्पादन उपयोगकर्ता प्रबंधन -------------------------- उत्पादन में, आप उस मॉडल से आगे बढ़ रहे हैं जहां आप या लोगों का एक छोटा समूह क्लस्टर तक पहुंच रहा है जहां संभावित रूप से दर्जनों या सैकड़ों लोग हो सकते हैं। सीखने के माहौल या प्लेटफ़ॉर्म प्रोटोटाइप में, आप जो कुछ भी करते हैं उसके लिए आपके पास एक ही प्रशासनिक खाता हो सकता है। उत्पादन में, आप विभिन्न नेमस्पेस्सों तक पहुंच के विभिन्न स्तरों वाले अधिक खाते चाहते हैं। उत्पादन-गुणवत्ता वाले क्लस्टर को लेने का अर्थ है यह तय करना कि आप कैसे हैं अन्य उपयोगकर्ताओं द्वारा चुनिंदा रूप से पहुंच की अनुमति देना चाहते हैं। विशेष रूप से, आपको उन लोगों की पहचान को सत्यापित करने के लिए रणनीतियों का चयन करने की आवश्यकता है जो आपके क्लस्टर (प्रमाणीकरण) तक पहुंचने का प्रयास करते हैं और यह तय करते हैं कि क्या उनके पास वह करने की अनुमति है जो वे पूछ रहे हैं (प्राधिकरण): * _प्रमाणीकरण_: apiserver क्लाइंट का उपयोग करके उपयोगकर्ताओं को प्रमाणित कर सकता है प्रमाण पत्र, वाहक टोकन, एक प्रमाणीकरण प्रॉक्सी, या HTTP मूल प्रमाणीकरण। आप चुन सकते हैं कि आप किन प्रमाणीकरण विधियों का उपयोग करना चाहते हैं। प्लगइन्स का उपयोग करके, apiserver आपके संगठन की मौजूदा प्रमाणीकरण विधियों, जैसे LDAP या Kerberos का लाभ उठा सकता है। कुबेरनेट्स उपयोगकर्ताओं को प्रमाणित करने के इन विभिन्न तरीकों के विवरण के लिए [प्रमाणीकरण](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) देखो। * _प्राधिकरण_: जब आप अपने नियमित उपयोगकर्ताओं को अधिकृत करने के लिए निकलते हैं, तो आप शायद आरबीएसी और एबीएसी प्राधिकरण के बीच चयन करेंगे। उपयोगकर्ता खातों को अधिकृत करने के लिए विभिन्न तरीकों की समीक्षा करने के लिए [प्राधिकरण अवलोकन](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) देखें (साथ ही आपके क्लस्टर में सेवा खाते तक पहुंच): * _भूमिका-आधारित अभिगम नियंत्रण_ ([RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) ): प्रमाणित उपयोगकर्ताओं को अनुमतियों के विशिष्ट सेट की अनुमति देकर आप अपने क्लस्टर तक पहुँच प्रदान कर सकते हैं। अनुमतियाँ एक विशिष्ट नेमस्पेस्स (भूमिका) या संपूर्ण क्लस्टर (ClusterRole) के लिए असाइन की जा सकती हैं। फिर रोलबाइंडिंग और क्लस्टररोलबाइंडिंग का उपयोग करके, उन अनुमतियों को विशेष उपयोगकर्ताओं से जोड़ा जा सकता है। * _विशेषता-आधारित अभिगम नियंत्रण_ ([ABAC](https://kubernetes.io/docs/reference/access-authn-authz/abac/) ): आपको क्लस्टर में संसाधन विशेषताओं के आधार पर नीतियां बनाने देता है और उन विशेषताओं के आधार पर पहुंच की अनुमति देगा या अस्वीकार करेगा। नीति फ़ाइल की प्रत्येक पंक्ति विषय (उपयोगकर्ता या समूह), संसाधन संपत्ति, गैर-संसाधन संपत्ति (/ संस्करण या / एपिस), और केवल पढ़ने के लिए संस्करण गुणों (एपीआई संस्करण और प्रकार) और विशिष्ट गुणों के मानचित्र की पहचान करती है। विवरण के लिए देखें [उदाहरण](https://kubernetes.io/docs/reference/access-authn-authz/abac/#examples) । जब कोई आपके उत्पादन कुबेरनेट्स क्लस्टर पर प्रमाणीकरण और प्राधिकरण सेटअप कर रहा हो, तो यहां कुछ बातों पर विचार करना चाहिए: * _प्राधिकरण मोड सेट करें_: जब कुबेरनेट्स एपीआई सर्वर ([kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) ) शुरू होता है, समर्थित प्रमाणीकरण मोड को _\--authorization-mode_ फ़्लैग का उपयोग करके सेट किया जाना चाहिए। उदाहरण के लिए, _kube-adminserver.yaml_ फ़ाइल में वह फ़्लैग (_/etc/kubernetes/manifests_ में) नोड, आरबीएसी पर सेट किया जा सकता है। यह प्रमाणित अनुरोधों के लिए नोड और आरबीएसी प्राधिकरण की अनुमति देगा। * _उपयोगकर्ता प्रमाणपत्र और रोल बाइंडिंग (RBAC) बनाएं_: यदि आप आरबीएसी प्राधिकरण का उपयोग कर रहे हैं, तो उपयोगकर्ता एक सर्टिफिकेट साइनिंग रिक्वेस्ट (सीएसआर) बना सकते हैं जिस पर क्लस्टर सीए द्वारा हस्ताक्षर किए जा सकते हैं। फिर आप प्रत्येक उपयोगकर्ता के लिए रोल्स और क्लस्टररोल्स को बाध्य कर सकते हैं। विवरण के लिए [प्रमाणपत्र पर हस्ताक्षर करने के अनुरोध](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/) देखें। * _ऐसी नीतियां बनाएं जो विशेषताओं को जोड़ती हैं (ABAC)_: यदि आप एबीएसी प्राधिकरण का उपयोग कर रहे हैं, तो आप चुनिंदा उपयोगकर्ताओं या समूहों को विशेष संसाधनों (जैसे पॉड), नेमस्पेस, या एपीग्रुप तक पहुंचने के लिए अधिकृत करने के लिए नीतियां बनाने के लिए विशेषताओं के संयोजन असाइन कर सकते हैं। अधिक जानकारी के लिए देखें [उदाहरण](https://kubernetes.io/docs/reference/access-authn-authz/abac/#examples) । * _प्रवेश नियंत्रकों पर विचार करें_: एपीआई सर्वर के माध्यम से आने वाले अनुरोधों के लिए प्राधिकरण के अतिरिक्त रूपों में शामिल हैं [वेबहुक टोकन प्रमाणीकरण](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) । वेबहुक और अन्य विशेष प्राधिकरण प्रकारों को एपीआई सर्वर में [प्रवेश नियंत्रक](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) जोड़कर सक्षम करने की आवश्यकता है। कार्यभार संसाधनों पर सीमा निर्धारित करें ---------------------------------------- उत्पादन कार्यभार की मांग कुबेरनेट्स नियंत्रण विमान के अंदर और बाहर दोनों जगह दबाव पैदा कर सकती है। अपने क्लस्टर के वर्कलोड की जरूरतों के लिए सेट अप करते समय इन मदों पर विचार करें: * _नेमस्पेस्स की सीमा निर्धारित करें_: मेमोरी और सीपीयू जैसी चीजों पर प्रति नेमस्पेस कोटा सेट करें। विवरण के लिए [मेमोरी, सीपीयू और एपीआई संसाधन प्रबंधित करें](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/) देखें। आप इनहेरिट करने की सीमा के लिए [हिरार्चीकैल नेमस्पेस्स](https://kubernetes.io/blog/2020/08/14/introducing-hierarchical-namespaces/) भी सेट कर सकते हैं। * _DNS मांग के लिए तैयार करें_: यदि आप वर्कलोड के बड़े पैमाने पर बढ़ने की उम्मीद करते हैं, तो आपकी DNS सेवा भी बड़े पैमाने पर तैयार होनी चाहिए। [क्लस्टर में DNS सेवा को ऑटोस्केल करना](https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) देखें। * _अतिरिक्त सेवा खाते बनाएं_: उपयोगकर्ता खाते यह निर्धारित करते हैं कि उपयोगकर्ता क्लस्टर पर क्या कर सकते हैं, जबकि एक सेवा खाता किसी विशेष नेमस्पेस्स के भीतर पॉड एक्सेस को परिभाषित करता है। डिफ़ॉल्ट रूप से, एक पॉड अपने नेमस्पेस्स से डिफ़ॉल्ट सेवा खाता लेता है। नया सेवा खाता बनाने के बारे में जानकारी के लिए [सेवा खातों का प्रबंधन](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/) देखें। उदाहरण के लिए, आप शायद यह करना चाहें: * ऐसे रहस्य जोड़ें जिनका उपयोग पॉड किसी विशेष कंटेनर रजिस्ट्री से इमेज खींचने के लिए कर सकता है। उदाहरण के लिए [पॉड्स के लिए सेवा खाते कॉन्फ़िगर करें](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) देखें। * किसी सेवा खाते में RBAC अनुमतियाँ असाइन करें। विवरण के लिए [सेवा खाता अनुमतियां](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions) देखें। आगे क्या है ----------- * तय करें कि आप अपना खुद का उत्पादन कुबेरनेट्स बनाना चाहते हैं या उपलब्ध [टर्नकी क्लाउड सॉल्यूशंस](https://kubernetes.io/hi/docs/setup/production-environment/turnkey-solutions/) से एक प्राप्त करना चाहते हैं या [कुबेरनेट्स पार्टनर्स](https://kubernetes.io/partners/) । * यदि आप अपना स्वयं का क्लस्टर बनाना चुनते हैं, तो योजना बनाएं कि आप [प्रमाणपत्र](https://kubernetes.io/docs/setup/best-practices/certificates/) को कैसे संभालना चाहते हैं और [etcd](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) जैसी सुविधाओं के लिए उच्च उपलब्धता सेट करें। और [एपीआई सर्वर](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/) । * [kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/) , [kops](https://kubernetes.io/docs/setup/production-environment/tools/kops/) या [kubespray](https://kubernetes.io/docs/setup/production-environment/tools/kubespray/) डिप्लॉयमेंट विधियों में से चुनें। * अपना निर्धारित करके उपयोगकर्ता प्रबंधन को कॉन्फ़िगर करें [प्रमाणीकरण](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) और [प्राधिकरण](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) विधियां। * सेटअप करके एप्लिकेशन वर्कलोड की तैयारी करें [संसाधन सीमाएं](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/) , [DNS ऑटोस्केलिंग](https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) और [सेवा खाते](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/) । 1 - कंटेनर रनटाइम ================= आपको क्लस्टर में प्रत्येक नोड में एक [कंटेनर रनटाइम](https://kubernetes.io/hi/docs/setup/production-environment/container-runtimes "The container runtime is the software that is responsible for running containers.") इंस्टॉल करना होगा ताकि पॉड वहां चल सकें। यह पृष्ठ बताता है कि क्या शामिल है और नोड्स की स्थापना के लिए संबंधित कार्यों का वर्णन करता है। कुबेरनेट्स 1.35 के लिए आवश्यक है कि आप एक रनटाइम का उपयोग करें जो [कंटेनर रनटाइम इंटरफ़ेस](https://kubernetes.io/hi/docs/concepts/overview/components/#container-runtime "क्यूबलेट के साथ एकीकृत करने के लिए कंटेनर रनटाइम के लिए एक API") (CRI) के अनुरूप है। अधिक जानकारी के लिए [CRI version support](https://kubernetes.io/hi/docs/setup/production-environment/_print/#cri-versions) देखें। यह पृष्ठ Linux पर कुबेरनेट्स के साथ कई सामान्य कंटेनर रनटाइम का उपयोग करने के विवरण सूचीबद्ध करता है: * [containerd](https://kubernetes.io/hi/docs/setup/production-environment/_print/#containerd) * [CRI-O](https://kubernetes.io/hi/docs/setup/production-environment/_print/#cri-o) * [Docker Engine](https://kubernetes.io/hi/docs/setup/production-environment/_print/#docker) * [Mirantis Container Runtime](https://kubernetes.io/hi/docs/setup/production-environment/_print/#mcr) #### टिप्पणी: अन्य ऑपरेटिंग सिस्टम के लिए, अपने प्लेटफ़ॉर्म के अनुसार विशिष्ट प्रलेखन देखें। Cgroup ड्राइवर -------------- प्रक्रियाओं के लिए आवंटित संसाधनों को सीमित करने के लिए कंट्रोल ग्रुप का उपयोग किया जाता है। जब Linux वातावरण के लिए init सिस्टम, [systemd](https://www.freedesktop.org/wiki/Software/systemd/) को चुना जाता है, तब init प्रक्रिया रुट(root) control group (`cgroup`) उत्पन्न करती है और उपभोग करती है तथा cgroup मैनेजर की तरह काम करता है। Systemd और cgroups एकीकृत हैं और प्रत्येक systemd यूनिट को एक cgroup आवंटित होता है। अपने कन्टैनर रनटाइम और kubelet को `cgroupfs` प्रयोग करने के लिए कॉन्फ़िगर करना संभव है। systemd के साथ `cgroupfs` प्रयोग करने के कारण दो अलग cgroup मैनेजर होंगे। एक एकल cgroup प्रबंधक इस दृष्टिकोण को सरल बनाता है कि कौन से संसाधन आवंटित किए जा रहे हैं और डिफ़ॉल्ट रूप से उपलब्ध और उपयोग में आने वाले संसाधनों के बारे में अधिक सुसंगत दृश्य होगा। जब एक सिस्टम पर दो cgroup मैनेजर होते हैं, तो आपको उन रिसोर्सेज के दो व्यू मिलते हैं। क्षेत्र में, लोगों ने ऐसे मामलों की सूचना दी है जहां नोड्स जो kubelet और डॉकर के लिए `cgroupfs` का उपयोग करने के लिए कॉन्फ़िगर किए गए हैं, लेकिन बाकी प्रक्रियाओं के लिए `systemd` संसाधन दबाव के कारण अस्थिर हो जाते हैं। सेटिंग्स को इस तरह बदलना कि आपका कंटेनर रनटाइम और kubelet `systemd` का उपयोग करें क्योंकि cgroup ड्राइवर सिस्टम को स्थिर करता है। डॉकर के लिए इसे कॉन्फ़िगर करने के लिए, `native.cgroupdriver=systemd` सेट करें। #### सावधान: क्लस्टर में शामिल होने वाले नोड के cgroup ड्राइवर को बदलना एक संवेदनशील ऑपरेशन है। यदि kubelet ने एक सीग्रुप ड्राइवर के सिमेंटिक्स (semantics) का उपयोग करके पॉड्स बनाए हैं, तो कंटेनर रनटाइम को दूसरे सीग्रुप ड्राइवर में बदलने से मौजूदा पॉड्स के पॉड सैंडबॉक्स को फिर से बनाते समय त्रुटियां हो सकती हैं। kubelet को पुनरारंभ करने से ऐसी त्रुटियों का समाधान नहीं हो सकता है। यदि आपके पास स्वचालन है जो इसे व्यवहार्य बनाता है, तो अद्यतन किए गए कॉन्फ़िगरेशन का उपयोग करके नोड को दूसरे के साथ बदलें, या स्वचालन का उपयोग करके इसे पुनर्स्थापित करें। Cgroup v2 --------- Cgroup v2, cgroup Linux API का अगला संस्करण है। Cgroup v1 से अलग, प्रत्येक कंट्रोलर के लिए एक अलग अनुक्रम के बजाय एक पदानुक्रम है। नया संस्करण cgroup v1 पर कई सुधार प्रदान करता है, इनमें से कुछ सुधार हैं: * API का उपयोग करने का स्पष्ट और आसान तरीका * कंटेनरों के लिए सुरक्षित उप-वृक्ष प्रतिनिधिमंडल * प्रेशर स्टॉल की जानकारी जैसी नई सुविधाएँ भले ही कर्नेल हाइब्रिड कॉन्फ़िगरेशन का समर्थन करता हो, जहां कुछ नियंत्रक cgroup v1 द्वारा प्रबंधित किए जाते हैं और कुछ अन्य cgroup v2 द्वारा, Kubernetes सभी नियंत्रकों को प्रबंधित करने के लिए केवल उसी cgroup संस्करण का समर्थन करता है। यदि सिस्टमड (Systemd) डिफ़ॉल्ट रूप से cgroup v2 का उपयोग नहीं करता है, तो आप कर्नेल कमांड लाइन में `systemd.unified_cgroup_hierarchy=1` जोड़कर सिस्टम को इसका उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं। # यह उदाहरण एक Linux OS के लिए है जो DNF पैकेज मैनेजर का उपयोग करता है # आपका सिस्टम कमांड लाइन सेट करने के लिए एक अलग विधि का उपयोग कर सकता है # लिनक्स कर्नेल का उपयोग करता है। sudo dnf install -y grubby && \ sudo grubby \ --update-kernel=ALL \ --args="systemd.unified_cgroup_hierarchy=1" यदि आप कर्नेल के लिए कमांड लाइन बदलते हैं, तो आपको अपने से पहले नोड को रिबूट करना होगा परिवर्तन प्रभावी होता है। Cgroup v2 में स्विच करते समय उपयोगकर्ता अनुभव में कोई उल्लेखनीय अंतर नहीं होना चाहिए, जब तक कि उपयोगकर्ता सीग्रुप फाइल सिस्टम को सीधे नोड पर या कंटेनरों के भीतर से एक्सेस कर रहे हैं। इसका उपयोग करने के लिए, Cgroup v2 को CRI रनटाइम द्वारा भी सपोर्टेड (supported) होना चाहिए। ### Kubeadm प्रबंधित क्लस्टर में `systemd` ड्राइवर में माइग्रेट करना यदि आप मौजूदा kubeadm प्रबंधित क्लस्टर में `systemd` cgroup ड्राइवर में माइग्रेट करना चाहते हैं, तो [माइग्रेशन गाइड](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/) का पालन करें। CRI संस्करण समर्थन ------------------ आपके कंटेनर रनटाइम को कंटेनर रनटाइम इंटरफ़ेस के कम से कम v1alpha2 का समर्थन करना चाहिए। कुबेरनेट्स 1.35 डिफ़ॉल्ट रूप से CRI API के v1 का उपयोग करता है। यदि कंटेनर रनटाइम v1 API का समर्थन नहीं करता है, तो क्यूबलेट वापस आ जाता है इसके बजाय (बहिष्कृत) v1alpha2 API का उपयोग करना। कंटेनर रनटाइम ------------- **टिप्पणी:** यह खंड अन्य पक्ष परियोजनाओं से जुड़ा है जो कुबेरनेट्स द्वारा आवश्यक कार्यक्षमता प्रदान करते हैं। कुबेरनेट्स परियोजना के लेखक इन परियोजनाओं के लिए जिम्मेदार नहीं हैं। यह पृष्ठ [CNCF वेबसाइट दिशानिर्देश](https://github.com/cncf/foundation/blob/master/website-guidelines.md) का अनुसरण करते हुए परियोजनाओं को वर्णानुक्रम में सूचीबद्ध करता है। इस सूची में कोई नई परियोजना जोड़ने से पहले यह [विषय मार्गदर्शक](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) पृष्ट पढ़के ही परिवर्तन करें। ### कंटेनरडी यह खंड कंटेनरडी को CRI रनटाइम के रूप में उपयोग करने के लिए आवश्यक कदम है। अपने सिस्टम पर containerd इंस्टॉल करने के लिए निम्नलिखित कमांड का उपयोग करें: पूर्वापेक्षाएँ इंस्टॉल और कॉन्फ़िगर करें: cat < 443/TCP 17d The default Service, in this case, uses the ClusterIP 10.96.0.1, that has the corresponding IPAddress object. kubectl get ipaddress 10.96.0.1 NAME PARENTREF 10.96.0.1 services/default/kubernetes The ServiceCIDRs are protected with [finalizers](https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/ "A namespaced key that tells Kubernetes to wait until specific conditions are met before it fully deletes an object marked for deletion.") , to avoid leaving Service ClusterIPs orphans; the finalizer is only removed if there is another subnet that contains the existing IPAddresses or there are no IPAddresses belonging to the subnet. Extend the number of available IPs for Services ----------------------------------------------- There are cases that users will need to increase the number addresses available to Services, previously, increasing the Service range was a disruptive operation that could also cause data loss. With this new feature users only need to add a new ServiceCIDR to increase the number of available addresses. ### Adding a new ServiceCIDR On a cluster with a 10.96.0.0/28 range for Services, there is only 2^(32-28) - 2 = 14 IP addresses available. The `kubernetes.default` Service is always created; for this example, that leaves you with only 13 possible Services. for i in $(seq 1 13); do kubectl create service clusterip "test-$i" --tcp 80 -o json | jq -r .spec.clusterIP; done 10.96.0.11 10.96.0.5 10.96.0.12 10.96.0.13 10.96.0.14 10.96.0.2 10.96.0.3 10.96.0.4 10.96.0.6 10.96.0.7 10.96.0.8 10.96.0.9 error: failed to create ClusterIP service: Internal error occurred: failed to allocate a serviceIP: range is full You can increase the number of IP addresses available for Services, by creating a new ServiceCIDR that extends or adds new IP address ranges. cat 80/TCP 5s Validate that the Service gets cluster IPs from the IPv4 and IPv6 address blocks using `kubectl describe`. You may then validate access to the service via the IPs and ports. kubectl describe svc -l app.kubernetes.io/name=MyApp Name: my-service Namespace: default Labels: app.kubernetes.io/name=MyApp Annotations: Selector: app.kubernetes.io/name=MyApp Type: ClusterIP IP Family Policy: PreferDualStack IP Families: IPv4,IPv6 IP: 10.0.216.242 IPs: 10.0.216.242,2001:db8:fd00::af55 Port: 80/TCP TargetPort: 9376/TCP Endpoints: Session Affinity: None Events: ### Create a dual-stack load balanced Service If the cloud provider supports the provisioning of IPv6 enabled external load balancers, create the following Service with `PreferDualStack` in `.spec.ipFamilyPolicy`, `IPv6` as the first element of the `.spec.ipFamilies` array and the `type` field set to `LoadBalancer`. [`service/networking/dual-stack-prefer-ipv6-lb-svc.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/dual-stack-prefer-ipv6-lb-svc.yaml to clipboard") apiVersion: v1 kind: Service metadata: name: my-service labels: app.kubernetes.io/name: MyApp spec: ipFamilyPolicy: PreferDualStack ipFamilies: - IPv6 type: LoadBalancer selector: app.kubernetes.io/name: MyApp ports: - protocol: TCP port: 80 Check the Service: kubectl get svc -l app.kubernetes.io/name=MyApp Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer 2001:db8:fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s --- # Concetti | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/concepts/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/concepts/) . Concetti ======== * 1: [Overview](https://kubernetes.io/it/docs/concepts/_print/#pg-0554ac387412eaf4e6e89b2f847dacde) * 1.1: [Cos'è Kubernetes?](https://kubernetes.io/it/docs/concepts/_print/#pg-45bdca6129cf540121623e903c18ba46) * 1.2: [I componenti di Kubernetes](https://kubernetes.io/it/docs/concepts/_print/#pg-13b0f1dbe89228e3d76d2ac231e245f1) * 1.3: [Le API di Kubernetes](https://kubernetes.io/it/docs/concepts/_print/#pg-0c745f42e623d2b70a53bc0e6db73d95) * 2: [Architettura di Kubernetes](https://kubernetes.io/it/docs/concepts/_print/#pg-2bf36ccd6b3dbeafecf87c39761b07c7) * 2.1: [Comunicazione Control Plane - Nodo](https://kubernetes.io/it/docs/concepts/_print/#pg-c0251def6da29b30afebfb04549f1703) * 2.2: [Concetti alla base del Cloud Controller Manager](https://kubernetes.io/it/docs/concepts/_print/#pg-bc804b02614d67025b4c788f1ca87fbc) * 2.3: [Controller](https://kubernetes.io/it/docs/concepts/_print/#pg-ca8819042a505291540e831283da66df) * 3: [Containers](https://kubernetes.io/it/docs/concepts/_print/#pg-a5f7383c83ab9eb9cd0e3c4c020b3ae6) * 3.1: [Immagini](https://kubernetes.io/it/docs/concepts/_print/#pg-16042b4652ad19e565c7263824029a43) * 3.2: [Container Environment](https://kubernetes.io/it/docs/concepts/_print/#pg-643212488f778acf04bebed65ba34441) * 3.3: [Container Lifecycle Hooks](https://kubernetes.io/it/docs/concepts/_print/#pg-e6941d969d81540208a3e78bc56f43bc) * 4: [Configurazione](https://kubernetes.io/it/docs/concepts/_print/#pg-275bea454e1cf4c5adeca4058b5af988) * 4.1: [ConfigMaps](https://kubernetes.io/it/docs/concepts/_print/#pg-6b5ccadd699df0904e8e9917c5450c4b) * 5: [Amministrazione del Cluster](https://kubernetes.io/it/docs/concepts/_print/#pg-285a3785fd3d20f437c28d87ca4dadca) * 5.1: [Proxy in Kubernetes](https://kubernetes.io/it/docs/concepts/_print/#pg-08e94e6a480e0d6b2de72d84a1b97617) * 6: [Esempio di modello di concetto](https://kubernetes.io/it/docs/concepts/_print/#pg-4c31edff4063c7b31c556b3eb1405c65) La sezione Concetti ti aiuta a conoscere le parti del sistema Kubernetes e le astrazioni utilizzate da Kubernetes per rappresentare il tuo cluster e ti aiuta ad ottenere una comprensione più profonda di come funziona Kubernetes. Overview -------- Per lavorare con Kubernetes, usi _gli oggetti API Kubernetes_ per descrivere lo _stato desiderato del tuo cluster_: quali applicazioni o altri carichi di lavoro vuoi eseguire, quali immagini del contenitore usano, numero di repliche, quali risorse di rete e disco vuoi rendere disponibile e altro ancora. Puoi impostare lo stato desiderato creando oggetti usando l'API di Kubernetes, in genere tramite l'interfaccia della riga di comando, `kubectl`. Puoi anche utilizzare direttamente l'API di Kubernetes per interagire con il cluster e impostare o modificare lo stato desiderato. Una volta impostato lo stato desiderato, il _Kubernetes Control Plane_ funziona per fare in modo che lo stato corrente del cluster corrisponda allo stato desiderato. Per fare ciò, Kubernetes esegue automaticamente una serie di attività, come l'avvio o il riavvio dei contenitori, il ridimensionamento del numero di repliche di una determinata applicazione e altro ancora. Il piano di controllo di Kubernetes è costituito da una raccolta di processi in esecuzione sul cluster: * Il **Kubernetes Master** è una raccolta di tre processi che vengono eseguiti su un singolo nodo nel cluster, che è designato come nodo principale. Questi processi sono: [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver/) , [kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager/) e [kube-scheduler](https://kubernetes.io/docs/admin/kube-scheduler/) . * Ogni singolo nodo non principale nel cluster esegue due processi:   \* **[kubelet](https://kubernetes.io/docs/admin/kubelet/) **, che comunica con il master di Kubernetes.   \* **[kube-proxy](https://kubernetes.io/docs/admin/kube-proxy/) **, un proxy di rete che riflette i servizi di rete di Kubernetes su ciascun nodo. Kubernetes Objects ------------------ kubernetes contiene una serie di astrazioni che rappresentano lo stato del tuo sistema: applicazioni e carichi di lavoro distribuiti in container, le loro risorse di rete e disco associate e altre informazioni su ciò che sta facendo il tuo cluster. Queste astrazioni sono rappresentate da oggetti nell'API di Kubernetes; guarda la [Panoramica degli oggetti di Kubernetes](https://kubernetes.io/docs/concepts/abstractions/overview/) per maggiori dettagli. Gli oggetti di base di Kubernetes includono: * [Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) * [Service](https://kubernetes.io/docs/concepts/services-networking/service/) * [Volume](https://kubernetes.io/docs/concepts/storage/volumes/) * [Namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) 209/5000 Inoltre, Kubernetes contiene una serie di astrazioni di livello superiore denominate Controllori. I controller si basano sugli oggetti di base e forniscono funzionalità aggiuntive e funzionalità di convenienza. Loro includono: * [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) * [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) * [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) * [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) * [Job](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) Kubernetes Control Plane ------------------------ Le varie parti del Piano di controllo di Kubernetes, come i master Kubernetes e i processi di Kubelet, regolano il modo in cui Kubernetes comunica con il cluster. Il Piano di controllo mantiene un registro di tutti gli oggetti Kubernetes nel sistema e esegue cicli di controllo continui per gestire lo stato di tali oggetti. In qualsiasi momento, i loop di controllo di Control Plane risponderanno ai cambiamenti nel cluster e lavoreranno per fare in modo che lo stato effettivo di tutti gli oggetti nel sistema corrisponda allo stato desiderato che hai fornito. Ad esempio, quando si utilizza l'API di Kubernetes per creare un oggetto di distribuzione, si fornisce un nuovo stato desiderato per il sistema. Il piano di controllo di Kubernetes registra la creazione dell'oggetto e svolge le tue istruzioni avviando le applicazioni richieste e pianificandole sui nodi del cluster, in modo che lo stato effettivo del cluster corrisponda allo stato desiderato. ### Kubernetes Master Il master Kubernetes è responsabile della gestione dello stato desiderato per il tuo cluster. Quando interagisci con Kubernetes, ad esempio utilizzando l'interfaccia della riga di comando `kubectl`, stai comunicando con il master di Kubernetes del cluster. > Il "master" si riferisce a una raccolta di processi che gestiscono lo stato del cluster. In genere questi processi vengono eseguiti tutti su un singolo nodo nel cluster e questo nodo viene anche definito master. Il master può anche essere replicato per disponibilità e ridondanza. ### Kubernetes Nodes I nodi di un cluster sono le macchine (VM, server fisici, ecc.) che eseguono i flussi di lavoro delle applicazioni e del cloud. Il master Kubernetes controlla ciascun nodo; raramente interagirai direttamente con i nodi. #### Object Metadata * [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) Voci correlate -------------- Se vuoi scrivere una pagina concettuale, vedi [Uso dei modelli di pagina](https://kubernetes.io/docs/home/contribute/page-templates/) per informazioni sul tipo di pagina di concetto e il modello di concetto. 1 - Overview ============ 1.1 - Cos'è Kubernetes? ======================= Kubernetes è una piattaforma portatile, estensibile e open-source per la gestione di carichi di lavoro e servizi containerizzati, in grado di facilitare sia la configurazione dichiarativa che l'automazione. La piattaforma vanta un grande ecosistema in rapida crescita. Servizi, supporto e strumenti sono ampiamente disponibili nel mondo Kubernetes . Questa pagina è una panoramica generale su Kubernetes. Kubernetes è una piattaforma portatile, estensibile e open-source per la gestione di carichi di lavoro e servizi containerizzati, in grado di facilitare sia la configurazione dichiarativa che l'automazione. La piattaforma vanta un grande ecosistema in rapida crescita. Servizi, supporto e strumenti sono ampiamente disponibili nel mondo Kubernetes . Il nome Kubernetes deriva dal greco, significa timoniere o pilota. Google ha reso open-source il progetto Kubernetes nel 2014. Kubernetes unisce [oltre quindici anni di esperienza di Google](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/) nella gestione di carichi di lavoro di produzione su scala mondiale con le migliori idee e pratiche della comunità. Facciamo un piccolo salto indietro ---------------------------------- Diamo un'occhiata alla ragione per cui Kubernetes è così utile facendo un piccolo salto indietro nel tempo. ![Deployment evolution](https://kubernetes.io/images/docs/Container_Evolution.svg) **L'era del deployment tradizionale:** All'inizio, le organizzazioni eseguivano applicazioni su server fisici. Non c'era modo di definire i limiti delle risorse per le applicazioni in un server fisico e questo ha causato non pochi problemi di allocazione delle risorse. Ad esempio, se più applicazioni vengono eseguite sullo stesso server fisico, si possono verificare casi in cui un'applicazione assorbe la maggior parte delle risorse e, di conseguenza, le altre applicazioni non hanno le prestazioni attese. Una soluzione per questo sarebbe di eseguire ogni applicazione su un server fisico diverso. Ma questa non è una soluzione ideale, dal momento che le risorse vengono sottoutilizzate, inoltre, questa pratica risulta essere costosa per le organizzazioni, le quali devono mantenere numerosi server fisici. **L'era del deployment virtualizzato:** Come soluzione venne introdotta la virtualizzazione. Essa consente di eseguire più macchine virtuali (VM) su una singola CPU fisica. La virtualizzazione consente di isolare le applicazioni in più macchine virtuali e fornisce un livello di sicurezza superiore, dal momento che le informazioni di un'applicazione non sono liberamente accessibili da un'altra applicazione. La virtualizzazione consente un migliore utilizzo delle risorse riducendo i costi per l'hardware, permette una migliore scalabilità, dato che un'applicazione può essere aggiunta o aggiornata facilmente, e ha molti altri vantaggi. Ogni VM è una macchina completa che esegue tutti i componenti, compreso il proprio sistema operativo, sopra all'hardware virtualizzato. **L'era del deployment in container:** I container sono simili alle macchine virtuali, ma presentano un modello di isolamento più leggero, condividendo il sistema operativo (OS) tra le applicazioni. Pertanto, i container sono considerati più leggeri. Analogamente a una macchina virtuale, un container dispone di una segregazione di filesystem, CPU, memoria, PID e altro ancora. Poiché sono disaccoppiati dall'infrastruttura sottostante, risultano portabili tra differenti cloud e diverse distribuzioni. I container sono diventati popolari dal momento che offrono molteplici vantaggi, ad esempio: * Creazione e distribuzione di applicazioni in modalità Agile: maggiore facilità ed efficienza nella creazione di immagini container rispetto all'uso di immagini VM. * Adozione di pratiche per lo sviluppo/test/rilascio continuativo: consente la frequente creazione e la distribuzione di container image affidabili, dando la possibilità di fare rollback rapidi e semplici (grazie all'immutabilità dell'immagine stessa). * Separazione delle fasi di Dev e Ops: le container image vengono prodotte al momento della compilazione dell'applicativo piuttosto che nel momento del rilascio, permettendo così di disaccoppiare le applicazioni dall'infrastruttura sottostante. * L'osservabilità non riguarda solo le informazioni e le metriche del sistema operativo, ma anche lo stato di salute e altri segnali dalle applicazioni. * Coerenza di ambiente tra sviluppo, test e produzione: i container funzionano allo stesso modo su un computer portatile come nel cloud. * Portabilità tra cloud e sistemi operativi differenti: lo stesso container funziona su Ubuntu, RHEL, CoreOS, on-premise, nei più grandi cloud pubblici e da qualsiasi altra parte. * Gestione incentrata sulle applicazioni: Aumenta il livello di astrazione dall'esecuzione di un sistema operativo su hardware virtualizzato all'esecuzione di un'applicazione su un sistema operativo utilizzando risorse logiche. * Microservizi liberamente combinabili, distribuiti, ad alta scalabilità: le applicazioni sono suddivise in pezzi più piccoli e indipendenti che possono essere distribuite e gestite dinamicamente - niente stack monolitici che girano su una singola grande macchina. * Isolamento delle risorse: le prestazioni delle applicazioni sono prevedibili. * Utilizzo delle risorse: alta efficienza e densità. Perché necessito di Kubernetes e cosa posso farci ------------------------------------------------- I container sono un buon modo per distribuire ed eseguire le tue applicazioni. In un ambiente di produzione, è necessario gestire i container che eseguono le applicazioni e garantire che non si verifichino interruzioni dei servizi. Per esempio, se un container si interrompe, è necessario avviare un nuovo container. Non sarebbe più facile se questo comportamento fosse gestito direttamente da un sistema? È proprio qui che Kubernetes viene in soccorso! Kubernetes ti fornisce un framework per far funzionare i sistemi distribuiti in modo resiliente. Kubernetes si occupa della scalabilità, failover, distribuzione delle tue applicazioni. Per esempio, Kubernetes può facilmente gestire i rilasci con modalità Canary deployment. Kubernetes ti fornisce: * **Scoperta dei servizi e bilanciamento del carico** Kubernetes può esporre un container usando un nome DNS o il suo indirizzo IP. Se il traffico verso un container è alto, Kubernetes è in grado di distribuire il traffico su più container in modo che il servizio rimanga stabile. * **Orchestrazione dello storage** Kubernetes ti permette di montare automaticamente un sistema di archiviazione di vostra scelta, come per esempio storage locale, dischi forniti da cloud pubblici, e altro ancora. * **Rollout e rollback automatizzati** Puoi utilizzare Kubernetes per descrivere lo stato desiderato per i propri container, e Kubernetes si occuperà di cambiare lo stato attuale per raggiungere quello desiderato ad una velocità controllata. Per esempio, puoi automatizzare Kubernetes per creare nuovi container per il tuo servizio, rimuovere i container esistenti e adattare le loro risorse a quelle richieste dal nuovo container. * **Ottimizzazione dei carichi** Fornisci a Kubernetes un cluster di nodi per eseguire i container. Puoi istruire Kubernetes su quanta CPU e memoria (RAM) ha bisogno ogni singolo container. Kubernetes allocherà i container sui nodi per massimizzare l'uso delle risorse a disposizione. * **Self-healing** Kubernetes riavvia i container che si bloccano, sostituisce container, termina i container che non rispondono agli health checks, e evita di far arrivare traffico ai container che non sono ancora pronti per rispondere correttamente. * **Gestione di informazioni sensibili e della configurazione** Kubernetes consente di memorizzare e gestire informazioni sensibili, come le password, i token OAuth e le chiavi SSH. Puoi distribuire e aggiornare le informazioni sensibili e la configurazione dell'applicazione senza dover ricostruire le immagini dei container e senza svelare le informazioni sensibili nella configurazione del tuo sistema. Cosa non è Kubernetes --------------------- Kubernetes non è un sistema PaaS (Platform as a Service) tradizionale e completo. Dal momento che Kubernetes opera a livello di container piuttosto che che a livello hardware, esso fornisce alcune caratteristiche generalmente disponibili nelle offerte PaaS, come la distribuzione, il ridimensionamento, il bilanciamento del carico, la registrazione e il monitoraggio. Tuttavia, Kubernetes non è monolitico, e queste soluzioni predefinite sono opzionali ed estensibili. Kubernetes fornisce gli elementi base per la costruzione di piattaforme di sviluppo, ma conserva le scelte dell'utente e la flessibilità dove è importante. Kubernetes: * Non limita i tipi di applicazioni supportate. Kubernetes mira a supportare una grande varietà di carichi di lavoro, compresi i carichi di lavoro stateless, stateful e elaborazione di dati. Se un'applicazione può essere eseguita in un container, dovrebbe funzionare alla grande anche su Kubernetes. * Non compila il codice sorgente e non crea i container. I flussi di Continuous Integration, Delivery, and Deployment (CI/CD) sono determinati dalla cultura e dalle preferenze dell'organizzazione e dai requisiti tecnici. * Non fornisce servizi a livello applicativo, come middleware (per esempio, bus di messaggi), framework di elaborazione dati (per esempio, Spark), database (per esempio, mysql), cache, né sistemi di storage distribuito (per esempio, Ceph) come servizi integrati. Tali componenti possono essere eseguiti su Kubernetes, e/o possono essere richiamati da applicazioni che girano su Kubernetes attraverso meccanismi come l'[Open Service Broker](https://openservicebrokerapi.org/) . * Non impone soluzioni di logging, monitoraggio o di gestione degli alert. Fornisce alcune integrazioni come dimostrazione, e meccanismi per raccogliere ed esportare le metriche. * Non fornisce né rende obbligatorio un linguaggio/sistema di configurazione (per esempio, Jsonnet). Fornisce un'API dichiarativa che può essere richiamata da qualsiasi sistema. * Non fornisce né adotta alcun sistema di gestione completa della macchina, configurazione, manutenzione, gestione o sistemi di self healing. * Inoltre, Kubernetes non è un semplice sistema di orchestrazione. Infatti, questo sistema elimina la necessità di orchestrazione. La definizione tecnica di orchestrazione è l'esecuzione di un flusso di lavoro definito: prima si fa A, poi B, poi C. Al contrario, Kubernetes è composto da un insieme di processi di controllo indipendenti e componibili che guidano costantemente lo stato attuale verso lo stato desiderato. Non dovrebbe importare come si passa dalla A alla C. Anche il controllo centralizzato non è richiesto. Questo si traduce in un sistema più facile da usare, più potente, robusto, resiliente ed estensibile. Voci correlate -------------- * Dai un'occhiata alla pagina [i componenti di Kubernetes](https://kubernetes.io/it/docs/concepts/overview/components/) * Sai già [Come Iniziare](https://kubernetes.io/docs/setup/) ? 1.2 - I componenti di Kubernetes ================================ Un cluster di Kubernetes è costituito da un insieme di componenti che sono, come minimo, un Control Plane e uno o più sistemi di elaborazione, detti nodi. Facendo il deployment di Kubernetes, ottieni un cluster. Un cluster Kubernetes è un'insieme di macchine, chiamate nodi, che eseguono container gestiti da Kubernetes. Un cluster ha almeno un Worker Node. Il/I Worker Node ospitano i Pod che eseguono i workload dell'utente. Il/I Control Plane Node gestiscono i Worker Node e tutto quanto accade all'interno del cluster. Per garantire la high-availability e la possibilità di failover del cluster, vengono utilizzati più Control Plane Node. Questo documento descrive i diversi componenti che sono necessari per avere un cluster Kubernetes completo e funzionante. Questo è un diagramma di un cluster Kubernetes con tutti i componenti e le loro relazioni. ![I componenti di Kubernetes](https://kubernetes.io/images/docs/components-of-kubernetes.png) Componenti della Control Plane ------------------------------ I componenti del Control Plane sono responsabili di tutte le decisioni globali sul cluster (ad esempio, lo scheduling) oltre che a rilevare e rispondere agli eventi del cluster (ad esempio, l'avvio di un nuovo [pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") quando il valore `replicas` di un deployment non è soddisfatto). I componenti della Control Plane possono essere eseguiti su qualsiasi nodo del cluster stesso. Solitamente, per semplicità, gli script di installazione tendono a eseguire tutti i componenti della Control Plane sulla stessa macchina, separando la Control Plane dai workload dell'utente. Vedi [creare un cluster in High-Availability](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) per un esempio di un'installazione multi-master. ### kube-apiserver L'API server è un componente di Kubernetes [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") che espone le Kubernetes API. L'API server è il front end del control plane di Kubernetes. La principale implementazione di un server Kubernetes API è [kube-apiserver](https://kubernetes.io/docs/reference/generated/kube-apiserver/) . kube-apiserver è progettato per scalare orizzontalmente, cioè scala aumentando il numero di istanze. Puoi eseguire multiple istanze di kube-apiserver e bilanciare il traffico tra queste istanze. ### etcd È un database key-value ridondato, che è usato da Kubernetes per salvare tutte le informazioni del cluster. Se il tuo cluster utilizza etcd per salvare le informazioni, assicurati di avere una strategia di [backup](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) per questi dati. Puoi trovare informazioni dettagliate su etcd sulla [documentazione](https://etcd.io/docs/) ufficiale. ### kube-scheduler Componente della Control Plane che controlla i pod appena creati che non hanno un nodo assegnato, e dopo averlo identificato glielo assegna. I fattori presi in considerazioni nell'individuare un nodo a cui assegnare l'esecuzione di un Pod includono la richiesta di risorse del Pod stesso e degli altri workload presenti nel sistema, i vincoli delle hardware/software/policy, le indicazioni di affinity e di anti-affinity, requisiti relativi alla disponibilità di dati/Volumes, le interferenze tra diversi workload e le scadenze. ### kube-controller-manager Componente della Control Plane che gestisce [controllers](https://kubernetes.io/it/docs/concepts/architecture/controller/ "Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato.") . Da un punto di vista logico, ogni [controller](https://kubernetes.io/it/docs/concepts/architecture/controller/ "Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato.") è un processo separato, ma per ridurre la complessità, tutti i principali controller di Kubernetes vengono raggruppati in un unico container ed eseguiti in un singolo processo. Alcuni esempi di controller gestiti dal kube-controller-manager sono: * Node Controller: Responsabile del monitoraggio dei nodi del cluster, e.g. della gestione delle azioni da eseguire quando un nodo diventa non disponibile. * Replication Controller: Responsabile per il mantenimento del corretto numero di Pod per ogni ReplicaSet presente nel sistema * Endpoints Controller: Popola gli oggetti Endpoints (cioè, mette in relazioni i Pods con i Services). * Service Account & Token Controllers: Creano gli account di default e i token di accesso alle API per i nuovi namespaces. ### cloud-controller-manager Un componente della [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") di Kubernetes che aggiunge logiche di controllo specifiche per il cloud. Il cloud-controller-manager ti permette di collegare il tuo cluster con le API del cloud provider e separa le componenti che interagiscono con la piattaforma cloud dai componenti che interagiscono solamente col cluster. Il cloud-controller-manager esegue dei controller specifici del tuo cloud provider. Se hai una installazione Kubernetes on premises, o un ambiente di laboratorio nel tuo PC, il cluster non ha un cloud-controller-manager. Come nel kube-controller-manager, il cloud-controller-manager combina diversi control loop logicamente indipendenti in un singolo binario che puoi eseguire come un singolo processo. Tu puoi scalare orizzontalmente (eseguire più di una copia) per migliorare la responsività o per migliorare la tolleranza ai fallimenti. I seguenti controller hanno dipendenze verso implementazioni di specifici cloud provider: * Node Controller: Per controllare se sul cloud provider i nodi che hanno smesso di rispondere sono stati cancellati * Route Controller: Per configurare le network route nella sottostante infrastruttura cloud * Service Controller: Per creare, aggiornare ed eliminare i load balancer del cloud provider Componenti dei Nodi ------------------- I componenti del nodo vengono eseguiti su ogni nodo, mantenendo i pod in esecuzione e fornendo l'ambiente di runtime Kubernetes. ### kubelet Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod. La kubelet riceve un set di PodSpecs che vengono forniti attraverso vari meccanismi, e si assicura che i container descritti in questi PodSpecs funzionino correttamente e siano sani. La kubelet non gestisce i container che non sono stati creati da Kubernetes. ### kube-proxy [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) è un proxy eseguito su ogni nodo del cluster, responsabile della gestione dei Kubernetes [Service](https://kubernetes.io/it/docs/concepts/services-networking/service/ "A way to expose an application running on a set of Pods as a network service.") . I kube-proxy mantengono le regole di networking sui nodi. Queste regole permettono la comunicazione verso gli altri nodi del cluster o l'esterno. Il kube-proxy usa le librerie del sistema operativo quando possible; in caso contrario il kube-proxy gestisce il traffico direttamente. ### Container Runtime Il container runtime è il software che è responsabile per l'esecuzione dei container. Kubernetes supporta diversi container runtimes: [Docker](http://www.docker.com/) , [containerd](https://containerd.io/) , [cri-o](https://cri-o.io/) , [rktlet](https://github.com/kubernetes-incubator/rktlet) e tutte le implementazioni di [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Addons ------ Gli Addons usano le risorse Kubernetes ([DaemonSet](https://kubernetes.io/it/docs/concepts/workloads/controllers/daemonset "Assicura che una copia di un Pod è attiva su tutti nodi di un cluster.") , [Deployment](https://kubernetes.io/it/docs/concepts/workloads/controllers/deployment/ "Gestisce una applicazione replicata nel tuo cluster.") , etc) per implementare funzionalità di cluster. Dal momento che gli addons forniscono funzionalità a livello di cluster, le risorse che necessitano di un namespace, vengono collocate nel namespace `kube-system`. Alcuni addons sono descritti di seguito; mentre per una più estesa lista di addons, per favore vedere [Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) . ### DNS Mentre gli altri addons non sono strettamente richiesti, tutti i cluster Kubernetes dovrebbero essere muniti di un [DNS del cluster](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) , dal momento che molte applicazioni lo necessitano. Il DNS del cluster è un server DNS aggiuntivo rispetto ad altri server DNS presenti nella rete, e si occupa specificatamente dei record DNS per i servizi Kubernetes. I container eseguiti da Kubernetes automaticamente usano questo server per la risoluzione DNS. ### Interfaccia web (Dashboard) La [Dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) è una interfaccia web per i cluster Kubernetes. Permette agli utenti di gestire e fare troubleshooting delle applicazioni che girano nel cluster, e del cluster stesso. ### Monitoraggio dei Container Il [Monitoraggio dei Container](https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/) salva serie temporali di metriche generiche dei container in un database centrale e fornisce una interfaccia in cui navigare i dati stessi. ### Log a livello di Cluster Un [log a livello di cluster](https://kubernetes.io/docs/concepts/cluster-administration/logging/) è responsabile per il salvataggio dei log dei container in un log centralizzato la cui interfaccia permette di cercare e navigare nei log. Voci correlate -------------- * Scopri i concetti relativi ai [Nodi](https://kubernetes.io/docs/concepts/architecture/nodes/) * Scopri i concetti relativi ai [Controller](https://kubernetes.io/it/docs/concepts/architecture/controller/) * Scopri i concetti relativi al [kube-scheduler](https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/) * Leggi la [documentazione](https://etcd.io/docs/) ufficiale di etcd 1.3 - Le API di Kubernetes ========================== Le API di Kubernetes ti permettono di interrogare e manipolare lo stato degli oggetti in Kubernetes. Il cuore del Control Plane di Kubernetes è l'API server e le API HTTP che esso espone. Ogni entità o componente che si interfaccia con il cluster (gli utenti, le singole parti del tuo cluster, i componenti esterni), comunica attraverso l'API server. Le convenzioni generali seguite dalle API sono descritte in [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) . Gli _endpoints_ delle API, la lista delle risorse esposte ed i relativi esempi sono descritti in [API Reference](https://kubernetes.io/docs/reference) . L'accesso alle API da remoto è discusso in [Controllare l'accesso alle API](https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/) . Le API di Kubernetes servono anche come riferimento per lo schema dichiarativo della configurazione del sistema stesso. Il comando [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) può essere usato per creare, aggiornare, cancellare ed ottenere le istanze delle risorse esposte attraverso le API. Kubernetes assicura la persistenza del suo stato (al momento in [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/) ) usando la rappresentazione delle risorse implementata dalle API. Kubernetes stesso è diviso in differenti componenti, i quali interagiscono tra loro attraverso le stesse API. Evoluzione delle API -------------------- In base alla nostra esperienza, ogni sistema di successo ha bisogno di evolvere ovvero deve estendersi aggiungendo funzionalità o modificare le esistenti per adattarle a nuovi casi d'uso. Le API di Kubernetes sono quindi destinate a cambiare e ad estendersi. In generale, ci si deve aspettare che nuove risorse vengano aggiunte di frequente cosi come nuovi campi possano altresì essere aggiunti a risorse esistenti. L'eliminazione di risorse o di campi devono seguire la [politica di deprecazione delle API](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) . In cosa consiste una modifica compatibile e come modificare le API è descritto dal [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md) . Definizioni OpenAPI e Swagger ----------------------------- La documentazione completa e dettagliata delle API è fornita attraverso la specifica [OpenAPI](https://www.openapis.org/) . Dalla versione 1.10 di Kubernetes, l'API server di Kubernetes espone le specifiche OpenAPI attraverso il seguente _endpoint_ `/openapi/v2`. Attraverso i seguenti _headers_ HTTP è possibile richiedere un formato specifico: | Header | Possibili Valori | | --- | --- | | Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (il content-type di default è `application/json` per `*/*` ovvero questo header può anche essere omesso) | | Accept-Encoding | `gzip` (questo header è facoltativo) | Prima della versione 1.14, gli _endpoints_ che includono il formato del nome all'interno del segmento (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) espongo le specifiche OpenAPI in formati differenti. Questi _endpoints_ sono deprecati, e saranno rimossi dalla versione 1.14 di Kubernetes. **Esempi per ottenere le specifiche OpenAPI**: | Prima della 1.10 | Dalla versione 1.10 di Kubernetes | | --- | --- | | GET /swagger.json | GET /openapi/v2 **Accept**: application/json | | GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: [application/com.github.proto-openapi.spec.v2@v1.0](mailto:application/com.github.proto-openapi.spec.v2@v1.0)
+protobuf | | GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: [application/com.github.proto-openapi.spec.v2@v1.0](mailto:application/com.github.proto-openapi.spec.v2@v1.0)
+protobuf **Accept-Encoding**: gzip | Kubernetes implementa per le sue API anche una serializzazione alternativa basata sul formato Protobuf che è stato pensato principalmente per la comunicazione intra-cluster, documentato nella seguente [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) , e i files IDL per ciascun schema si trovano nei _Go packages_ che definisco i tipi delle API. Prima della versione 1.14, l'_apiserver_ di Kubernetes espone anche un'_endpoint_, `/swaggerapi`, che può essere usato per ottenere le documentazione per le API di Kubernetes secondo le specifiche [Swagger v1.2](http://swagger.io/) . Questo _endpoint_ è deprecato, ed è stato rimosso nella versione 1.14 di Kubernetes. Versionamento delle API ----------------------- Per facilitare l'eliminazione di campi specifici o la modifica della rappresentazione di una data risorsa, Kubernetes supporta molteplici versioni della stessa API disponibili attraverso differenti indirizzi, come ad esempio `/api/v1` oppure `/apis/extensions/v1beta1`. Abbiamo deciso di versionare a livello di API piuttosto che a livello di risorsa o di campo per assicurare che una data API rappresenti una chiara, consistente vista delle risorse di sistema e dei sui comportamenti, e per abilitare un controllo degli accessi sia per le API in via di decommissionamento che per quelle sperimentali. Si noti che il versionamento delle API ed il versionamento del Software sono indirettamente collegati. La [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) descrive la relazione tra le versioni delle API ed le versioni del Software. Differenti versioni delle API implicano differenti livelli di stabilità e supporto. I criteri per ciascuno livello sono descritti in dettaglio nella [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions) . Queste modifiche sono qui ricapitolate: * Livello alpha: * Il nome di versione contiene `alpha` (e.g. `v1alpha1`). * Potrebbe contenere dei _bug_. Abilitare questa funzionalità potrebbe esporre al rischio di _bugs_. Disabilitata di default. * Il supporto di questa funzionalità potrebbe essere rimosso in ogni momento senza previa notifica. * Questa API potrebbe cambiare in modo incompatibile in rilasci futuri del Software e senza previa notifica. * Se ne raccomandata l'utilizzo solo in _clusters_ di test creati per un breve periodo di vita, a causa di potenziali _bugs_ e delle mancanza di un supporto di lungo periodo. * Livello beta: * Il nome di versione contiene `beta` (e.g. `v2beta3`). * Il codice è propriamente testato. Abilitare la funzionalità è considerato sicuro. Abilitata di default. * Il supporto per la funzionalità nel suo complesso non sarà rimosso, tuttavia potrebbe subire delle modifiche. * Lo schema e/o la semantica delle risorse potrebbe cambiare in modo incompatibile in successivi rilasci beta o stabili. Nel caso questo dovesse verificarsi, verrano fornite istruzioni per la migrazione alla versione successiva. Questo potrebbe richiedere la cancellazione, modifica, e la ri-creazione degli oggetti supportati da questa API. Questo processo di modifica potrebbe richiedere delle valutazioni. La modifica potrebbe richiedere un periodo di non disponibilità dell'applicazione che utilizza questa funzionalità. * Raccomandata solo per applicazioni non critiche per la vostra impresa a causa dei potenziali cambiamenti incompatibili in rilasci successivi. Se avete più _clusters_ che possono essere aggiornati separatamente, potreste essere in grado di gestire meglio questa limitazione. * **Per favore utilizzate le nostre versioni beta e forniteci riscontri relativamente ad esse! Una volta promosse a stabili, potrebbe non essere semplice apportare cambiamenti successivi.** * Livello stabile: * Il nome di versione è `vX` dove `X` è un intero. * Le funzionalità relative alle versioni stabili continueranno ad essere presenti per parecchie versioni successive. API groups ---------- Per facilitare l'estendibilità delle API di Kubernetes, sono stati implementati gli [_API groups_](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) . L'_API group_ è specificato nel percorso REST ed anche nel campo `apiVersion` di un oggetto serializzato. Al momento ci sono diversi _API groups_ in uso: 1. Il gruppo _core_, spesso referenziato come il _legacy group_, è disponibile al percorso REST `/api/v1` ed utilizza `apiVersion: v1`. 2. I gruppi basati su un nome specifico sono disponibili attraverso il percorso REST `/apis/$GROUP_NAME/$VERSION`, ed usano `apiVersion: $GROUP_NAME/$VERSION` (e.g. `apiVersion: batch/v1`). La lista completa degli _API groups_ supportati e' descritta nel documento [Kubernetes API reference](https://kubernetes.io/docs/reference/) . Vi sono due modi per supportati per estendere le API attraverso le [_custom resources_](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) : 1. [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) è pensato per utenti con esigenze CRUD basilari. 2. Utenti che necessitano di un nuovo completo set di API che utilizzi appieno la semantica di Kubernetes possono implementare il loro _apiserver_ ed utilizzare l'[_aggregator_](https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) per fornire ai propri utilizzatori la stessa esperienza a cui sono abituati con le API incluse nativamente in Kubernetes. Abilitare o disabilitare gli _API groups_ ----------------------------------------- Alcune risorse ed _API groups_ sono abilitati di default. Questi posso essere abilitati o disabilitati attraverso il settaggio/flag `--runtime-config` applicato sull'_apiserver_. `--runtime-config` accetta valori separati da virgola. Per esempio: per disabilitare `batch/v1`, usa la seguente configurazione `--runtime-config=batch/v1=false`, per abilitare `batch/v2alpha1`, utilizzate `--runtime-config=batch/v2alpha1`. Il _flag_ accetta set di coppie _chiave/valore_ separati da virgola che descrivono la configurazione a _runtime_ dell'_apiserver_. #### Nota: Abilitare o disabilitare risorse o gruppi richiede il riavvio dell'_apiserver_ e del _controller-manager_ affinché le modifiche specificate attraverso il flag `--runtime-config` abbiano effetto. Abilitare specifiche risorse nel gruppo extensions/v1beta1 ---------------------------------------------------------- DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies e ReplicaSets presenti nel gruppo di API `extensions/v1beta1` sono disabilitate di default. Per esempio: per abilitare deployments and daemonsets, utilizza la seguente configurazione `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. #### Nota: Abilitare/disabilitare una singola risorsa è supportato solo per il gruppo di API `extensions/v1beta1` per ragioni storiche. 2 - Architettura di Kubernetes ============================== 2.1 - Comunicazione Control Plane - Nodo ======================================== Questo documento cataloga le connessioni tra il piano di controllo (_control-plane_), in realtà l'apiserver, e il cluster Kubernetes. L'intento è di consentire agli utenti di personalizzare la loro installazione per rafforzare la configurazione di rete affinché il cluster possa essere eseguito su una rete pubblica (o su IP completamente pubblici resi disponibili da un fornitore di servizi cloud). Dal Nodo al control-plane ------------------------- Kubernetes adotta un pattern per le API di tipo _"hub-and-spoke"_. Tutte le chiamate delle API eseguite sui vari nodi sono effettuate verso l'apiserver (nessuno degli altri componenti principali è progettato per esporre servizi remoti). L'apiserver è configurato per l'ascolto di connessioni remote su una porta HTTPS protetta (443) con una o più forme di [autenticazioni client](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) abilitate. Si dovrebbero abilitare una o più forme di [autorizzazioni](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) , in particolare nel caso in cui siano ammesse [richieste anonime](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests) o [_token_ legati ad un account di servizio (_service account_)](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) . Il certificato pubblico (_public root certificate_) relativo al cluster corrente deve essere fornito ai vari nodi di modo che questi possano connettersi in modo sicuro all'apiserver insieme alle credenziali valide per uno specifico _client_. Ad esempio, nella configurazione predefinita di un cluster [GKE](https://cloud.google.com/kubernetes-engine?hl=it) , le credenziali del client fornite al kubelet hanno la forma di un certificato client. Si veda [inizializzazione TLS del kubelet TLS](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) per la fornitura automatica dei certificati client al _kubelet_. I Pod che desiderano connettersi all'apiserver possono farlo in modo sicuro sfruttando un account di servizio in modo che Kubernetes inserisca automaticamente il certificato pubblico di radice e un token valido al portatore (_bearer token_) all'interno Pod quando questo viene istanziato. In tutti i namespace è configurato un _Service_ con nome `kubernetes` con un indirizzo IP virtuale che viene reindirizzato (tramite _kube-proxy_) all'endpoint HTTPS dell'apiserver. Anche i componenti del piano d controllo comunicano con l'apiserver del cluster su di una porta sicura esposta da quest'ultimo. Di conseguenza, la modalità operativa predefinita per le connessioni dai nodi e dai Pod in esecuzione sui nodi verso il _control-plane_ è protetta da un'impostazione predefinita e può essere eseguita su reti non sicure e/o pubbliche. Dal control-plane al nodo ------------------------- Esistono due percorsi di comunicazione principali dal _control-plane_ (apiserver) verso i nodi. Il primo è dall'apiserver verso il processo _kubelet_ in esecuzione su ogni nodo nel cluster. Il secondo è dall'apiserver a ciascun nodo, Pod, o servizio attraverso la funzionalità proxy dell'apiserver. ### Dall'apiserver al _kubelet_ Le connessioni dall'apiserver al _kubelet_ vengono utilizzate per: * Prendere i log relativi ai vari Pod. * Collegarsi (attraverso kubectl) ai Pod in esecuzione. * Fornire la funzionalità di _port-forwarding_ per i _kubelet_. Queste connessioni terminano all'endpoint HTTPS del _kubelet_. Di default, l'apiserver non verifica il certificato servito dal _kubelet_, il che rende la connessione soggetta ad attacchi _man-in-the-middle_, e tale da essere considerato **non sicuro (unsafe)** se eseguito su reti non protette e/o pubbliche. Per verificare questa connessione, si utilizzi il parametro `--kubelet-certificate-authority` al fine di fornire all'apiserver un insieme di certificati radice da utilizzare per verificare il il certificato servito dal _kubelet_. Se questo non è possibile, si usi un [tunnel SSH](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) tra l'apiserver e il _kubelet_, se richiesto, per evitare il collegamento su una rete non protetta o pubblica. In fine, l'[autenticazione e/o l'autorizzazione del kubelet](https://kubernetes.io/docs/admin/kubelet-authentication-authorization/) dovrebbe essere abilitate per proteggere le API esposte dal _kubelet_. ### Dall'apiserver ai nodi, Pod, e servizi Le connessioni dall'apiserver verso un nodo, Pod o servizio avvengono in modalità predefinita su semplice connessione HTTP e quindi non sono né autenticate né criptata. Queste connessioni possono essere eseguite su una connessione HTTPS sicura mediante il prefisso `https:` al nodo, Pod o nome del servizio nell'URL dell'API, ma non valideranno il certificato fornito dall'endpoint HTTPS né forniranno le credenziali del client così anche se la connessione verrà criptata, non fornirà alcuna garanzia di integrità. **Non è attualmente sicuro** eseguire queste connessioni su reti non protette e/o pubbliche. ### I tunnel SSH Kubernetes supporta i _tunnel_ SSH per proteggere la comunicazione tra il _control-plane_ e i nodi. In questa configurazione, l'apiserver inizializza un tunnel SSH con ciascun nodo del cluster (collegandosi al server SSH in ascolto sulla porta 22) e fa passare tutto il traffico verso il _kubelet_, il nodo, il Pod, o il servizio attraverso questo tunnel. Questo tunnel assicura che il traffico non sia esposto al di fuori della rete su cui sono in esecuzioni i vari nodi. I tunnel SSH sono al momento deprecati ovvero non dovrebbero essere utilizzati a meno che ci siano delle esigenze particolari. Il servizio `Konnectivity` è pensato per rimpiazzare questo canale di comunicazione. ### Il servizio _Konnectivity_ FEATURE STATE: `Kubernetes v1.18 [beta]` Come rimpiazzo dei tunnel SSH, il servizio _Konnectivity_ fornisce un proxy a livello TCP per la comunicazione tra il _control-plane_ e il cluster. Il servizio _Konnectivity_ consiste in due parti: il _Konnectivity_ server e gli agenti _Konnectivity_, in esecuzione rispettivamente sul _control-plane_ e sui vari nodi. Gli agenti _Konnectivity_ inizializzano le connessioni verso il server _Konnectivity_ e mantengono le connessioni di rete. Una volta abilitato il servizio _Konnectivity_, tutto il traffico tra il _control-plane_ e i nodi passa attraverso queste connessioni. Si può fare riferimento al [tutorial per il servizio _Konnectivity_](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) per configurare il servizio _Konnectivity_ all'interno del cluster 2.2 - Concetti alla base del Cloud Controller Manager ===================================================== Il concetto di CCM (cloud controller manager), da non confondere con il binario, è stato originariamente creato per consentire di sviluppare Kubernetes indipendentemente dall'implementazione dello specifico cloud provider. Il cloud controller manager viene eseguito insieme ad altri componenti principali come il Kubernetes controller manager, il server API e lo scheduler. Può anche essere avviato come addon di Kubernetes, nel qual caso viene eseguito su Kubernetes. Il design del cloud controller manager è basato su un meccanismo di plug-in che consente ai nuovi provider cloud di integrarsi facilmente con Kubernetes creando un plug-in. Sono in atto programmi per l'aggiunta di nuovi provider di cloud su Kubernetes e per la migrazione dei provider che usano il vecchio metodo a questo nuovo metodo. Questo documento discute i concetti alla base del cloud controller manager e fornisce dettagli sulle funzioni associate. Ecco l'architettura di un cluster Kubernetes senza il gestore del controller cloud: ![Pre CCM Kube Arch](https://kubernetes.io/images/docs/pre-ccm-arch.png) Architettura ------------ Nel diagramma precedente, Kubernetes e il provider cloud sono integrati attraverso diversi componenti: * Kubelet * Kubernetes controller manager * Kubernetes API server Il CCM consolida tutta la logica dipendente dal cloud presente nei tre componenti precedenti, per creare un singolo punto di integrazione con il cloud. La nuova architettura con il CCM si presenta così: ![CCM Kube Arch](https://kubernetes.io/images/docs/post-ccm-arch.png) Componenti del CCM ------------------ Il CCM divide alcune funzionalità del Kubernetes controller manager (KCM) e le esegue in un differente processo. In particolare, toglie dal KCM le integrazioni con il cloud specifico. Il KCM ha i seguenti controller che dipendono dal cloud specifico: * Node controller * Volume controller * Route controller * Service controller Nella versione 1.9, il CCM esegue i seguenti controller dall'elenco precedente: * Node controller * Route controller * Service controller #### Nota: È stato deliberatamente deciso di non spostare il Volume controller nel CCM. Data la complessità del Volume controller e gli sforzi già fatti per astrarre le logiche specifiche dei singoli fornitori, è stato deciso che il Volume controller non verrà spostato nel CCM. Il piano originale per supportare i volumi utilizzando il CCM era di utilizzare [Flex](https://kubernetes.io/docs/concepts/storage/volumes/#flexVolume) per supportare volumi collegabili. Tuttavia, una implementazione parallela, nota come [CSI](https://kubernetes.io/docs/concepts/storage/volumes/#csi) è stata designata per sostituire Flex. Considerando queste evoluzioni, abbiamo deciso di adottare un approccio intermedio finché il CSI non è pronto. Funzioni del CCM ---------------- Il CCM eredita le sue funzioni da componenti di Kubernetes che dipendono da uno specifico provider di cloud. Questa sezione è strutturata sulla base di tali componenti. ### 1\. Kubernetes controller manager La maggior parte delle funzioni del CCM deriva dal KCM. Come menzionato nella sezione precedente, CCM esegue i seguenti cicli di controllo: * Node controller * Route controller * Service controller #### Node controller Il Node controller è responsabile per l'inizializzazione di un nodo ottenendo informazioni sui nodi in esecuzione nel cluster dal provider cloud. Il controller del nodo esegue le seguenti funzioni: 1. Inizializzare un nodo con le label zone/region specifiche per il cloud in uso. 2. Inizializzare un nodo con le specifiche, ad esempio, tipo e dimensione specifiche del cloud in uso. 3. Ottenere gli indirizzi di rete del nodo e l'hostname. 4. Nel caso in cui un nodo non risponda, controlla il cloud per vedere se il nodo è stato cancellato dal cloud. Se il nodo è stato eliminato dal cloud, elimina l'oggetto Nodo di Kubernetes. #### Route controller Il Route controller è responsabile della configurazione delle route nel cloud in modo che i container su nodi differenti del cluster Kubernetes possano comunicare tra loro. Il Route controller è utilizzabile solo dai cluster su Google Compute Engine. #### Service Controller Il Service Controller rimane in ascolto per eventi di creazione, aggiornamento ed eliminazione di servizi. In base allo stato attuale dei servizi in Kubernetes, configura i bilanciatori di carico forniti dal cloud (come gli ELB, i Google LB, o gli Oracle Cloud Infrastructure LB) per riflettere lo stato dei servizi in Kubernetes. Inoltre, assicura che i back-end dei bilanciatori di carico forniti dal cloud siano aggiornati. ### 2\. Kubelet Il Node Controller contiene l'implementazione dipendente dal cloud della kubelet. Prima dell'introduzione del CCM, la kubelet era responsabile dell'inizializzazione di un nodo con dettagli dipendenti dallo specifico cloud come gli indirizzi IP, le label region/zone e le informazioni sul tipo di istanza. L'introduzione del CCM ha spostato questa operazione di inizializzazione dalla kubelet al CCM. In questo nuovo modello, la kubelet inizializza un nodo senza informazioni specifiche del cloud. Tuttavia, aggiunge un blocco al nodo appena creato che rende il nodo non selezionabile per eseguire container finché il CCM non inizializza il nodo con le informazioni specifiche del cloud. Il CCM rimuove quindi questo blocco. Sistema a plug-in ----------------- Il cloud controller manager utilizza le interfacce di Go per consentire l'implementazione di implementazioni di qualsiasi cloud. In particolare, utilizza l'interfaccia CloudProvider definita [qui](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62) . L'implementazione dei quattro controller generici evidenziati sopra, alcune strutture, l'interfaccia cloudprovider condivisa rimarranno nel core di Kubernetes. Le implementazioni specifiche per i vari cloud saranno costruite al di fuori del core e implementeranno le interfacce definite nel core. Per ulteriori informazioni sullo sviluppo di plug-in, consultare [Developing Cloud Controller Manager](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/) . Autorizzazione -------------- Questa sezione dettaglia l'accesso richiesto dal CCM sui vari API objects per eseguire le sue operazioni. ### Node controller Il Node controller funziona solo con oggetti di tipo Node. Richiede l'accesso completo per ottenere, elencare, creare, aggiornare, applicare patch, guardare ed eliminare oggetti di tipo Node. v1/Node: * Get * List * Create * Update * Patch * Watch * Delete ### Route controller Il Route controller ascolta la creazione dell'oggetto Node e configura le rotte in modo appropriato. Richiede l'accesso in lettura agli oggetti di tipo Node. v1/Node: * Get ### Service controller Il Service controller resta in ascolto per eventi di creazione, aggiornamento ed eliminazione di oggetti di tipo Servizi, e configura gli endpoint per tali Servizi in modo appropriato. Per accedere ai Servizi, è necessario il permesso per list e watch. Per aggiornare i Servizi, sono necessari i permessi patch e update. Per impostare gli endpoint per i Servizi, richiede i permessi create, list, get, watch, e update. v1/Service: * List * Get * Watch * Patch * Update ### Others L'implementazione del core di CCM richiede l'accesso per creare eventi e, per garantire operazioni sicure, richiede l'accesso per creare ServiceAccounts. v1/Event: * Create * Patch * Update v1/ServiceAccount: * Create L'RBAC ClusterRole per il CCM ha il seguente aspetto: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cloud-controller-manager rules: - apiGroups: - "" resources: - events verbs: - create - patch - update - apiGroups: - "" resources: - nodes verbs: - '*' - apiGroups: - "" resources: - nodes/status verbs: - patch - apiGroups: - "" resources: - services verbs: - list - patch - update - watch - apiGroups: - "" resources: - serviceaccounts verbs: - create - apiGroups: - "" resources: - persistentvolumes verbs: - get - list - update - watch - apiGroups: - "" resources: - endpoints verbs: - create - get - list - watch - update Vendor Implementations ---------------------- I seguenti fornitori di cloud hanno una implementazione di CCM: * [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) * [AWS](https://github.com/kubernetes/cloud-provider-aws) * [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) * [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) * [GCP](https://github.com/kubernetes/cloud-provider-gcp) * [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) * [Linode](https://github.com/linode/linode-cloud-controller-manager) * [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) * [Oracle](https://github.com/oracle/oci-cloud-controller-manager) * [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) Cluster Administration ---------------------- Le istruzioni complete per la configurazione e l'esecuzione del CCM sono fornite [qui](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) . 2.3 - Controller ================ Nella robotica e nell'automazione, un _circuito di controllo_ (_control loop_) è un un'iterazione senza soluzione di continuità che regola lo stato di un sistema. Ecco un esempio di un circuito di controllo: il termostato di una stanza. Quando viene impostata la temperatura, si definisce attraverso il termostato lo _stato desiderato_. L'attuale temperatura nella stanza è invece lo _stato corrente_. Il termostato agisce per portare lo stato corrente il più vicino possibile allo stato desiderato accendendo e spegnendo le apparecchiature. In Kubernetes, i _controller_ sono circuiti di controllo che osservano lo stato del [cluster](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-cluster "Un'insieme di macchine, chiamate nodi, che eseguono container gestiti da Kubernetes. Un cluster ha almeno un Worker Node.") , e apportano o richiedono modifiche quando necessario. Ogni _controller_ prova a portare lo stato corrente del cluster verso lo stato desiderato. Il modello del controller ------------------------- Un _controller_ monitora almeno una tipo di risorsa registrata in Kubernetes. Questi [oggetti](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) hanno una proprietà chiamata _spec_ (specifica) che rappresenta lo stato desiderato. Il o i _controller_ per quella risorsa sono responsabili di mantenere lo stato corrente il più simile possibile rispetto allo stato desiderato. Il _controller_ potrebbe eseguire l'azione relativa alla risorsa in questione da sé; più comunemente, in Kubernetes, un _controller_ invia messaggi all'[API server](https://kubernetes.io/it/docs/concepts/architecture/#kube-apiserver "Componente della Control plane che serve le Kubernetes API.") che a sua volta li rende disponibili ad altri componenti nel cluster. Di seguito troverete esempi per questo scenario. ### Controllo attraverso l'API server Il [Job](https://kubernetes.io/it/docs/concepts/workloads/controllers/jobs-run-to-completion "Uno o più lavori (task) che vengono eseguiti fino al loro completamento.") _controller_ è un esempio di un _controller_ nativo in Kubernetes. I _controller_ nativi gestiscono lo stato interagendo con l'API server presente nel cluster. Il Job è una risorsa di Kubernetes che lancia uno o più [Pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") per eseguire un lavoro (task) e poi fermarsi. (Una volta che è stato [schedulato](https://kubernetes.io/docs/concepts/scheduling-eviction/) , un oggetto _Pod_ diventa parte dello stato desisderato di un dato _kubelet_). Quando il Job _controller_ vede un nuovo lavoro da svolgere si assicura che, da qualche parte nel cluster, i _kubelet_ anche sparsi su più nodi eseguano il numero corretto di _Pod_ necessari per eseguire il lavoro richiesto. Il Job _controller_ non esegue direttamente alcun _Pod_ o _container_ bensì chiede all'API server di creare o rimuovere i _Pod_. Altri componenti appartenenti al [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") reagiscono in base alle nuove informazioni (ci sono nuovi _Pod_ da creare e gestire) e cooperano al completamento del job. Dopo che un nuovo Job è stato creato, lo stato desiderato per quel Job è il suo completamento. Il Job _controller_ fa sì che lo stato corrente per quel Job sia il più vicino possibile allo stato desiderato: creare _Pod_ che eseguano il lavoro che deve essere effettuato attraverso il Job, così che il Job sia prossimo al completamento. I _controller_ aggiornano anche gli oggetti che hanno configurato. Ad esempio: una volta che il lavoro relativo ad un dato Job è stato completato, il Job _controller_ aggiorna l'oggetto Job segnandolo come `Finished`. (Questo è simile allo scenario del termostato che spegne un certo led per indicare che ora la stanza ha raggiungo la temperatura impostata) ### Controllo diretto A differenza del Job, alcuni _controller_ devono eseguire delle modifiche a parti esterne al cluster. Per esempio, se viene usato un circuito di controllo per assicurare che ci sia un numero sufficiente di [Nodi](https://kubernetes.io/it/docs/concepts/architecture/nodes/ "Un node è una macchina worker in Kubernetes.") nel cluster, allora il _controller_ ha bisogno che qualcosa al di fuori del cluster configuri i nuovi _Nodi_ quando sarà necessario. I _controller_ che interagiscono con un sistema esterno trovano il loro stato desiderato attraverso l'API server, quindi comunicano direttamente con un sistema esterno per portare il loro stato corrente più in linea possibile con lo stato desiderato (In realtà c'è un _controller_ che scala orizzontalmente i nodi nel cluster. Vedi [Cluster autoscaling](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) ). Stato desiderato versus corrente -------------------------------- Kubernetes ha una visione _cloud-native_ dei sistemi, ed è in grado di gestire continue modifiche. Il cluster viene modificato continuamente durante la sua attività ed il _circuito di controllo_ è in grado di risolvere automaticamente i possibili guasti. Fino a che i _controller_ del cluster sono in funzione ed in grado di apportare le dovute modifiche, non è rilevante che lo stato complessivo del cluster sia o meno stabile. Progettazione ------------- Come cardine della sua progettazione, Kubernetes usa vari _controller_ ognuno dei quali è responsabile per un particolare aspetto dello stato del cluster. Più comunemente, un dato _circuito di controllo_ (_controller_) usa un tipo di risorsa per il suo stato desiderato, ed utilizza anche risorse di altro tipo per raggiungere questo stato desiderato. Per esempio il Job _controller_ tiene traccia degli oggetti di tipo _Job_ (per scoprire nuove attività da eseguire) e degli oggetti di tipo _Pod_ (questi ultimi usati per eseguire i _Job_, e quindi per controllare quando il loro lavoro è terminato). In questo caso, qualcos'altro crea i _Job_, mentre il _Job_ _controller_ crea i _Pod_. È utile avere semplici _controller_ piuttosto che un unico, monolitico, _circuito di controllo_. I _controller_ possono guastarsi, quindi Kubernetes è stato disegnato per gestire questa eventualità. #### Nota: Ci possono essere diversi _controller_ che creato o aggiornano lo stesso tipo di oggetti. Dietro le quinte, i _controller_ di Kubernetes si preoccupano esclusivamente delle risorse (di altro tipo) collegate alla risorsa primaria da essi controllata. Per esempio, si possono avere _Deployment_ e _Job_; entrambe creano _Pod_. Il Job _controller_ non distrugge i _Pod_ creati da un _Deployment_, perché ci sono informazioni (_[labels](https://kubernetes.io/it/docs/concepts/overview/working-with-objects/labels "Tags di oggetti con attributi identificativi che sono significativi e pertinenti per gli utenti.") _) che vengono usate dal _controller_ per distinguere i _Pod_. I modi per eseguire i _controller_ ---------------------------------- Kubernetes annovera un insieme di _controller_ nativi che sono in esecuzione all'interno del [kube-controller-manager](https://kubernetes.io/it/docs/reference/command-line-tools-reference/kube-controller-manager/ "Componente della Control Plane che gestisce i controller.") . Questi _controller_ nativi forniscono importanti funzionalità di base. Il Deployment _controller_ ed il Job _controller_ sono esempi di _controller_ che vengono forniti direttamente da Kubernetes stesso (ovvero _controller_ "nativi"). Kubernetes consente di eseguire un _piano di controllo_(_control plane_) resiliente, di modo che se un dei _controller_ nativi dovesse fallire, un'altra parte del piano di controllo si occuperà di eseguire quel lavoro. Al fine di estendere Kubernetes, si possono avere _controller_ in esecuzione al di fuori del piano di controllo. Oppure, se si desidera, è possibile scriversi un nuovo _controller_. È possibile eseguire il proprio controller come una serie di _Pod_, oppure esternamente rispetto a Kubernetes. Quale sia la soluzione migliore, dipende dalla responsabilità di un dato controller. Voci correlate -------------- * Leggi in merito [Kubernetes control plane](https://kubernetes.io/it/docs/concepts/#kubernetes-control-plane) * Scopri alcune delle basi degli [oggetti di Kubernetes](https://kubernetes.io/it/docs/concepts/#kubernetes-objects) * Per saperne di più riguardo alle [API di Kubernetes](https://kubernetes.io/it/docs/concepts/overview/kubernetes-api/) * Se vuoi creare un tuo _controller_, guarda [i modelli per l'estensibilità](https://kubernetes.io/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Estendere Kubernetes. 3 - Containers ============== La tecnologia per distribuire un'applicazione insieme con le dipendenze necessarie per la sua esecuzione. Ogni _container_ che viene eseguito è riproducibile; la pratica di includere le dipendenze all'interno di ciascuno _container_ permette di ottenere sempre lo stesso risultato ad ogni esecuzione del medesimo _container_. I _Container_ permettono di disaccoppiare le applicazioni dall'infrastruttura del host su cui vengono eseguite. Questo approccio rende più facile il _deployment_ su cloud o sitemi operativi differenti tra loro. Immagine di container --------------------- L'[immagine di un container](https://kubernetes.io/it/docs/concepts/containers/images/) e' un pacchetto software che contiene tutto ciò che serve per eseguire un'applicazione: il codice sorgente e ciascun _runtime_ necessario, librerie applicative e di sistema, e le impostazioni predefinite per ogni configurazione necessaria. Un _container_ è immutabile per definizione: non è possibile modificare il codice di un _container_ in esecuzione. Se si ha un'applicazione containerizzata e la si vuole modificare, si deve costruire un nuovo _container_ che includa il cambiamento desiderato, e quindi ricreare il _container_ partendo dalla nuova immagine aggiornata. Container runtimes ------------------ Il container runtime è il software che è responsabile per l'esecuzione dei container. Kubernetes supporta diversi container runtimes: [Docker](http://www.docker.com/) , [containerd](https://containerd.io/) , [cri-o](https://cri-o.io/) , [rktlet](https://github.com/kubernetes-incubator/rktlet) e tutte le implementazioni di [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Voci correlate -------------- * Leggi in merito [immagine di container](https://kubernetes.io/it/docs/concepts/containers/images/) * Leggi in merito [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) 3.1 - Immagini ============== L'immagine di un container rappresenta dati binari che incapsulano un'applicazione e tutte le sue dipendenze software. Le immagini sono costituite da pacchetti software eseguibili che possono essere avviati in modalità standalone e su cui si possono fare ipotesi ben precise circa l'ambiente in cui vengono eseguiti. Tipicamente viene creata un'immagine di un'applicazione ed effettuato il _push_ su un registry (un repository pubblico di immagini) prima di poterne fare riferimento esplicito in un [Pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") Questa pagina va a delineare nello specifico il concetto di immagine di un container. I nomi delle immagini --------------------- Alle immagini dei container vengono normalmente attribuiti nomi come `pause`, `example/mycontainer`, o `kube-apiserver`. Le immagini possono anche contenere l'hostname del registry in cui le immagini sono pubblicate; ad esempio: `registro.fittizio.esempio/nomeimmagine`, ed è possibile che sia incluso nel nome anche il numero della porta; ad esempio: `registro.fittizio.esempio:10443/nomeimmagine`. Se non si specifica l'hostname di un registry, Kubernetes assume che ci si riferisca al registry pubblico di Docker. Dopo la parte relativa al nome dell'immagine si può aggiungere un _tag_ (come comunemente avviene per comandi come `docker` e `podman`). I tag permettono l'identificazione di differenti versioni della stessa serie di immagini. I tag delle immagini sono composti da lettere minuscole e maiuscole, numeri, underscore (`_`), punti (`.`), e trattini (`-`). Esistono regole aggiuntive relative a dove i caratteri separatori (`_`, `-`, and `.`) possano essere inseriti nel tag di un'immagine. Se non si specifica un tag, Kubernetes assume il tag `latest` che va a definire l'immagine disponibile più recente. #### Attenzione: Evitate di utilizzare il tag `latest` quando si rilasciano dei container in produzione, in quanto risulta difficile tracciare quale versione dell'immagine sia stata avviata e persino più difficile effettuare un rollback ad una versione precente. Invece, meglio specificare un tag specifico come ad esempio `v1.42.0`. Aggiornamento delle immagini ---------------------------- Quando un [Deployment](https://kubernetes.io/it/docs/concepts/workloads/controllers/deployment/ "Gestisce una applicazione replicata nel tuo cluster.") , [StatefulSet](https://kubernetes.io/it/docs/concepts/workloads/controllers/statefulset/ "Gestisce deployment e la scalabilità di un gruppo di Pod, con storage e identificativi persistenti per ogni Pod.") , Pod, o qualsiasi altro oggetto che includa un Pod template viene creato per la prima volta, la policy di default per il pull di tutti i container nel Pod è impostata su `IfNotPresent` (se non presente) se non specificato diversamente. Questa policy permette al [kubelet](https://kubernetes.io/it/docs/reference/generated/kubelet "Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.") di evitare di fare il pull di un'immagine se questa è già presente. Se necessario, si può forzare il pull in ogni occasione in uno dei seguenti modi: * impostando `imagePullPolicy` (specifica per il pull delle immagini) del container su `Always` (sempre). * omettendo `imagePullPolicy` ed usando il tag `:latest` (più recente) per l'immagine da utilizzare; Kubernetes imposterà la policy su `Always` (sempre). * omettendo `imagePullPolicy` ed il tag per l'immagine da utilizzare. * abilitando l'admission controller [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) . #### Nota: Il valore dell'impostazione `imagePullPolicy` del container è sempre presente quando l'oggetto viene creato per la prima volta e non viene aggiornato se il tag dell'immagine dovesse cambiare successivamente. Ad esempio, creando un Deployment con un'immagine il cui tag _non_ è `:latest`, e successivamente aggiornando il tag di quell'immagine a `:latest`, il campo `imagePullPolicy` _non_ cambierà su `Always`. È necessario modificare manualmente la policy di pull di ogni oggetto dopo la sua creazione. Quando `imagePullPolicy` è definito senza un valore specifico, esso è impostato su `Always`. Multi-architecture support nelle immagini ----------------------------------------- Oltre a fornire immagini binarie, un _container registry_ può fornire un [indice delle immagini disponibili per un container](https://github.com/opencontainers/image-spec/blob/master/image-index.md) . L'indice di un'immagine può puntare a più [file manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md) ciascuno per una versione specifica dell'architettura di un container. L'idea è che si può avere un unico nome per una stessa immagine (ad esempio: `pause`, `example/mycontainer`, `kube-apiserver`) e permettere a diversi sistemi di recuperare l'immagine binaria corretta a seconda dell'architettura della macchina che la sta utilizzando. Kubernetes stesso tipicamente nomina le immagini dei container tramite il suffisso `-$(ARCH)`. Per la garantire la retrocompatibilità è meglio generare le vecchie immagini con dei suffissi. L'idea è quella di generare, ad esempio, l'immagine `pause` con un manifest che include tutte le architetture supportate, affiancata, ad esempio, da `pause-amd64` che è retrocompatibile per le vecchie configurazioni o per quei file YAML in cui sono specificate le immagini con i suffissi. Utilizzare un private registry ------------------------------ I private registry possono richiedere l'utilizzo di chiavi per accedere alle immagini in essi contenute. Le credenziali possono essere fornite in molti modi: * configurando i nodi in modo tale da autenticarsi al private registry * tutti i pod possono acquisire informazioni da qualsiasi private registry configurato * è necessario che l'amministratore del cluster configuri i nodi in tal senso * tramite pre-pulled images (immagini pre-caricate sui nodi) * tutti i pod possono accedere alle immagini salvate sulla cache del nodo a cui si riferiscono * è necessario effettuare l'accesso come root di sistema su ogni nodo per inserire questa impostazione * specificando _ImagePullSecrets_ su un determinato pod * solo i pod che forniscono le proprie chiavi hanno la possibilità di accedere al private registry * tramite estensioni locali o specifiche di un _Vendor_ * se si sta utilizzando una configurazione personalizzata del nodo oppure se manualmente, o tramite il _cloud provider_, si implementa un meccanismo di autenticazione del nodo presso il _container registry_. Di seguito la spiegazione dettagliata di queste opzioni. ### Configurazione dei nodi per l'autenticazione ad un private registry Se si sta utilizzando Docker sui nodi, si può configurare il _Docker container runtime_ per autenticare il nodo presso un private container registry. Questo è un approccio possibile se si ha il controllo sulle configurazioni del nodo. #### Nota: Kubernetes di default supporta solo le sezioni `auths` e `HttpHeaders` nelle configurazioni relative a Docker. Eventuali _helper_ per le credenziali di Docker (`credHelpers` o `credsStore`) non sono supportati. Docker salva le chiavi per i registri privati in `$HOME/.dockercfg` oppure nel file `$HOME/.docker/config.json`. Inserendo lo stesso file nella lista seguente, kubelet lo utilizzerà per recuperare le credenziali quando deve fare il _pull_ delle immagini. * `{--root-dir:-/var/lib/kubelet}/config.json` * `{cwd of kubelet}/config.json` * `${HOME}/.docker/config.json` * `/.docker/config.json` * `{--root-dir:-/var/lib/kubelet}/.dockercfg` * `{cwd of kubelet}/.dockercfg` * `${HOME}/.dockercfg` * `/.dockercfg` #### Nota: Potrebbe essere necessario impostare `HOME=/root` esplicitamente come variabile d'ambiente del processo _kubelet_. Di seguito i passi consigliati per configurare l'utilizzo di un private registry da parte dei nodi del _cluster_. In questo esempio, eseguire i seguenti comandi sul proprio desktop/laptop: 1. Esegui `docker login [server]` per ogni _set_ di credenziali che vuoi utilizzare. Questo comando aggiornerà `$HOME/.docker/config.json` sul tuo PC. 2. Controlla il file `$HOME/.docker/config.json` in un editor di testo per assicurarti che contenga le credenziali che tu voglia utilizzare. 3. Recupera la lista dei tuoi nodi; ad esempio: * se vuoi utilizzare i nomi: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` * se vuoi recuperare gli indirizzi IP: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 4. Copia il tuo file locale `.docker/config.json` in uno dei path sopra riportati nella lista di ricerca. * ad esempio, per testare il tutto: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` #### Nota: Per i cluster di produzione, utilizza un configuration management tool per poter applicare le impostazioni su tutti i nodi laddove necessario. Puoi fare una verifica creando un Pod che faccia uso di un'immagine privata; ad esempio: kubectl apply -f - < --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL Se possiedi il file delle credenziali per Docker, anziché utilizzare il comando quì sopra puoi importare il file di credenziali come un Kubernetes [Secrets](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-secret "Contiene informazioni sensibili, come passwords, token OAuth, e chiavi ssh.") . [Creare un Secret a partire da credenziali Docker](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) fornisce la spiegazione dettagliata su come fare. Ciò è particolarmente utile se si utilizzano più _container registry_ privati, in quanto il comando `kubectl create secret docker-registry` genera un Secret che funziona con un solo private registry. #### Nota: I Pod possono fare riferimento ai Secret per il pull delle immagini soltanto nel proprio _namespace_, quindi questo procedimento deve essere svolto per ogni _namespace_. #### Fare riferimento ad imagePullSecrets in un Pod È possibile creare pod che referenzino quel Secret aggiungendo la sezione `imagePullSecrets` alla definizione del Pod. Ad esempio: cat < pod.yaml apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey EOF cat <> ./kustomization.yaml resources: - pod.yaml EOF Questo deve esser fatto per ogni Pod che utilizzi un private registry. Comunque, le impostazioni relative a questo campo possono essere automatizzate inserendo la sezione _imagePullSecrets_ nella definizione della risorsa [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) . Visitare la pagina [Aggiungere ImagePullSecrets ad un Service Account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) per istruzioni più dettagliate. Puoi utilizzarlo in congiunzione al file `.docker/config.json` configurato per ogni nodo. In questo caso, si applicherà un _merge_ delle credenziali. Casi d'uso ---------- Ci sono varie soluzioni per configurare i private registry. Di seguito, alcuni casi d'uso comuni e le soluzioni suggerite. 1. Cluster in cui sono utilizzate soltanto immagini non proprietarie (ovvero _open-source_). In questo caso non sussiste il bisogno di nascondere le immagini. * Utilizza immagini pubbliche da Docker hub. * Nessuna configurazione richiesta. * Alcuni _cloud provider_ mettono in _cache_ o effettuano il _mirror_ di immagini pubbliche, il che migliora la disponibilità delle immagini e ne riduce il tempo di _pull_. 2. Cluster con container avviati a partire da immagini proprietarie che dovrebbero essere nascoste a chi è esterno all'organizzazione, ma visibili a tutti gli utenti abilitati nel cluster. * Utilizza un private [Docker registry](https://docs.docker.com/registry/) . * Esso può essere ospitato da [Docker Hub](https://hub.docker.com/signup) , o da qualche altra piattaforma. * Configura manualmente il file .docker/config.json su ogni nodo come descritto sopra. * Oppure, avvia un private registry dietro il tuo firewall con accesso in lettura libero. * Non è necessaria alcuna configurazione di Kubernetes. * Utilizza un servizio di _container registry_ che controlli l'accesso alle immagini * Esso funzionerà meglio con una configurazione del cluster basata su _autoscaling_ che con una configurazione manuale del nodo. * Oppure, su un cluster dove la modifica delle configurazioni del nodo non è conveniente, utilizza `imagePullSecrets`. 3. Cluster con immagini proprietarie, alcune delle quali richiedono un controllo sugli accessi. * Assicurati che l'_admission controller_ [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod potenzialmente possono avere accesso a tutte le immagini. * Sposta i dati sensibili un un _Secret_, invece di inserirli in un'immagine. 4. Un cluster multi-tenant dove ogni tenant necessiti di un private registry. * Assicurati che l'_admission controller_ [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod di tutti i tenant potrebbero potenzialmente avere accesso a tutte le immagini. * Avvia un private registry che richieda un'autorizzazione all'accesso. * Genera delle credenziali di registry per ogni tenant, inseriscile in dei _Secret_, e popola i _Secret_ per ogni _namespace_ relativo ad ognuno dei tenant. * Il singolo tenant aggiunge così quel _Secret_ all'impostazione _imagePullSecrets_ di ogni _namespace_. Se si ha la necessità di accedere a più registri, si può generare un _Secret_ per ognuno di essi. Kubelet farà il _merge_ di ogni `imagePullSecrets` in un singolo file virtuale `.docker/config.json`. Voci correlate -------------- * Leggi [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 3.2 - Container Environment =========================== Questa pagina descrive le risorse disponibili nei Container eseguiti in Kubernetes. Container environment --------------------- Quando si esegue un Container in Kubernetes, le seguenti risorse sono rese disponibili: * Un filesystem, composto dal file system dell'[image](https://kubernetes.io/it/docs/concepts/containers/images/) e da uno o più [volumes](https://kubernetes.io/docs/concepts/storage/volumes/) . * Una serie di informazioni sul Container stesso. * Una serie di informazioni sugli oggetti nel cluster. ### Informazioni sul Container L' _hostname_ di un Container è il nome del Pod all'interno del quale è eseguito il Container. È consultabile tramite il comando `hostname` o tramite la funzione [`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) disponibile in libc. Il nome del Pod e il namespace possono essere resi disponibili come environment variables attraverso l'uso delle [downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) . Gli utenti possono aggiungere altre environment variables nella definizione del Pod; anche queste saranno disponibili nel Container come tutte le altre environment variables definite staticamente nella Docker image. ### Informazioni sul cluster Al momento della creazione del Container è generata una serie di environment variables con la lista di servizi in esecuzione nel cluster. Queste environment variables rispettano la sintassi dei Docker links. Per un servizio chiamato _foo_ che è in esecuzione in un Container di nome _bar_, le seguenti variabili sono generate: FOO_SERVICE_HOST= FOO_SERVICE_PORT= I servizi hanno un indirizzo IP dedicato e sono disponibili nei Container anche via DNS se il [DNS addon](http://releases.k8s.io/master/cluster/addons/dns/) è installato nel cluster. Voci correlate -------------- * Approfondisci [Container lifecycle hooks](https://kubernetes.io/it/docs/concepts/containers/container-lifecycle-hooks/) . * Esegui un tutorial su come [definire degli handlers per i Container lifecycle events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . 3.3 - Container Lifecycle Hooks =============================== Questa pagina descrive come i Container gestiti con kubelet possono utilizzare il lifecycle hook framework dei Container per l'esecuzione di codice eseguito in corrispondenza di alcuni eventi durante il loro ciclo di vita. Overview -------- Analogamente a molti framework di linguaggi di programmazione che hanno degli hooks legati al ciclo di vita dei componenti, come ad esempio Angular, Kubernetes fornisce ai Container degli hook legati al loro ciclo di vita dei Container. Gli hook consentono ai Container di essere consapevoli degli eventi durante il loro ciclo di gestione ed eseguire del codice implementato in un handler quando il corrispondente hook viene eseguito. Container hooks --------------- Esistono due tipi di hook che vengono esposti ai Container: `PostStart` Questo hook viene eseguito successivamente alla creazione del container. Tuttavia, non vi è garanzia che questo hook venga eseguito prima dell'ENTRYPOINT del container. Non vengono passati parametri all'handler. `PreStop` Questo hook viene eseguito prima della terminazione di un container a causa di una richiesta API o di un evento di gestione, come ad esempio un fallimento delle sonde di liveness/startup, preemption, risorse contese e altro. Una chiamata all'hook di `PreStop` fallisce se il container è in stato terminated o completed e l'hook deve finire prima che possa essere inviato il segnale di TERM per fermare il container. Il conto alla rovescia per la terminazione del Pod (grace period) inizia prima dell'esecuzione dell'hook `PreStop`, quindi indipendentemente dall'esito dell'handler, il container terminerà entro il grace period impostato. Non vengono passati parametri all'handler. Una descrizione più dettagliata riguardante al processo di terminazione dei Pod può essere trovata in [Terminazione dei Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) . ### Implementazione degli hook handler I Container possono accedere a un hook implementando e registrando un handler per tale hook. Ci sono due tipi di handler che possono essere implementati per i Container: * Exec - Esegue un comando specifico, tipo `pre-stop.sh`, all'interno dei cgroup e namespace del Container. Le risorse consumate dal comando vengono contate sul Container. * HTTP - Esegue una richiesta HTTP verso un endpoint specifico del Container. ### Esecuzione dell'hook handler Quando viene richiamato l'hook legato al lifecycle del Container, il sistema di gestione di Kubernetes esegue l'handler secondo l'azione dell'hook, `httpGet` e `tcpSocket` vengono eseguiti dal processo kubelet, mentre `exec` è eseguito nel Container. Le chiamate agli handler degli hook sono sincrone rispetto al contesto del Pod che contiene il Container. Questo significa che per un hook `PostStart`, l'ENTRYPOINT e l'hook si attivano in modo asincrono. Tuttavia, se l'hook impiega troppo tempo per essere eseguito o si blocca, il container non può raggiungere lo stato di `running`. Gli hook di `PreStop` non vengono eseguiti in modo asincrono dall'evento di stop del container; l'hook deve completare la sua esecuzione prima che l'evento TERM possa essere inviato. Se un hook di `PreStop` si blocca durante la sua esecuzione, la fase del Pod rimarrà `Terminating` finchè il Pod non sarà rimosso forzatamente dopo la scadenza del suo `terminationGracePeriodSeconds`. Questo grace period si applica al tempo totale necessario per effettuare sia l'esecuzione dell'hook di `PreStop` che per l'arresto normale del container. Se, per esempio, il `terminationGracePeriodSeconds` è di 60, e l'hook impiega 55 secondi per essere completato, e il container impiega 10 secondi per fermarsi normalmente dopo aver ricevuto il segnale, allora il container verrà terminato prima di poter completare il suo arresto, poiché `terminationGracePeriodSeconds` è inferiore al tempo totale (55+10) necessario perché queste due cose accadano. Se un hook `PostStart` o `PreStop` fallisce, allora il container viene terminato. Gli utenti dovrebbero mantenere i loro handler degli hook i più leggeri possibili. Ci sono casi, tuttavia, in cui i comandi di lunga durata hanno senso, come il salvataggio dello stato del container prima della sua fine. ### Garanzia della chiamata dell'hook La chiamata degli hook avviene _almeno una volta_, il che significa che un hook può essere chiamato più volte da un dato evento, come per `PostStart` o `PreStop`. Sta all'implementazione dell'hook gestire correttamente questo aspetto. Generalmente, vengono effettuate singole chiamate agli hook. Se, per esempio, la destinazione di hook HTTP non è momentaneamente in grado di ricevere traffico, non c'è alcun tentativo di re invio. In alcuni rari casi, tuttavia, può verificarsi una doppia chiamata. Per esempio, se un kubelet si riavvia nel mentre dell'invio di un hook, questo potrebbe essere chiamato per una seconda volta dopo che il kubelet è tornato in funzione. ### Debugging Hook handlers I log di un handler di hook non sono esposti negli eventi del Pod. Se un handler fallisce per qualche ragione, trasmette un evento. Per il `PostStart`, questo è l'evento di `FailedPostStartHook`, e per il `PreStop`, questo è l'evento di `FailedPreStopHook`. Puoi vedere questi eventi eseguendo `kubectl describe pod `. Ecco alcuni esempi di output di eventi dall'esecuzione di questo comando: Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook Voci correlate -------------- * Approfondisci [Container environment](https://kubernetes.io/it/docs/concepts/containers/container-environment/) . * Esegui un tutorial su come [definire degli handlers per i Container lifecycle events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . 4 - Configurazione ================== Risorse che fornisce Kubernetes per configurare i Pods. 4.1 - ConfigMaps ================ La ConfigMap è un oggetto API usato per memorizzare dati non riservati in coppie chiave-valore. I [Pods](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") possono utilizzare le ConfigMaps come variabili d'ambiente, argomenti da riga di comando, o come files di configurazione all'interno di un [Volume](https://kubernetes.io/it/docs/concepts/storage/volumes/ "Una cartella contenente dati, accessibile dai containers all'interno del pod.") . La ConfigMap ti permette di disaccoppiare le configurazioni specifiche per ambiente dalle [immagini del container](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-image "Istanza archiviata di un cointainer che contiene un insieme di software e librerie necessarie per eseguire l'applicazione.") , cosicchè le tue applicazioni siano facilmente portabili. #### Attenzione: La ConfigMap non fornisce riservatezza o cifratura dei dati. Se i dati che vuoi salvare sono confidenziali, usa un [Secret](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-secret "Contiene informazioni sensibili, come passwords, token OAuth, e chiavi ssh.") piuttosto che una ConfigMap, o usa uno strumento di terze parti per tenere privati i tuoi dati. Utilizzo -------- Usa una ConfigMap per tenere separati i dati di configurazione dal codice applicativo. Per esempio, immagina che stai sviluppando un'applicazione che puoi eseguire sul tuo computer (per lo sviluppo) e sul cloud (per gestire il traffico reale). Puoi scrivere il codice puntando a una variabile d'ambiente chiamata `DATABASE_HOST`. Localmente, puoi settare quella variabile a `localhost`. Nel cloud, la puoi settare referenziando il [Service](https://kubernetes.io/it/docs/concepts/services-networking/service/ "A way to expose an application running on a set of Pods as a network service.") di Kubernetes che espone la componente del database sul tuo cluster. Ciò ti permette di andare a recuperare l'immagine del container eseguita nel cloud e fare il debug dello stesso codice localmente se necessario. La ConfigMap non è pensata per sostenere una gran mole di dati. I dati memorizzati su una ConfigMap non possono superare 1 MiB. Se hai bisogno di memorizzare delle configurazioni che superano questo limite, puoi considerare di montare un volume oppure usare un database o un file service separato. Oggetto ConfigMap ----------------- La ConfigMap è un [oggetto](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/) API che ti permette di salvare configurazioni per poi poter essere riutilizzate da altri oggetti. A differenza di molti oggetti di Kubernetes che hanno una `spec`, la ConfigMap ha i campi `data` e `binaryData`. Questi campi accettano le coppie chiave-valore come valori. Entrambi i campi `data` e `binaryData` sono opzionali. Il campo `data` è pensato per contenere le stringhe UTF-8 mentre il campo `binaryData` è pensato per contenere dati binari come le stringhe codificate in base64. Il nome di una ConfigMap deve essere un nome valido per un sottodominio DNS. Ogni chiave sotto il campo `data` o `binaryData` deve consistere di caratteri alfanumerici, `-`, `_` o `.`. Le chiavi salvate sotto `data` non devono coincidere con le chiavi nel campo `binaryData`. Partendo dalla versione 1.19, puoi aggiungere il campo `immutable` alla definizione di ConfigMap per creare una [ConfigMap immutabile](https://kubernetes.io/it/docs/concepts/_print/#configmap-immutable) . ConfigMaps e Pods ----------------- Puoi scrivere una `spec` del Pod che si riferisce a una ConfigMap e configurare il o i containers in quel Pod sulla base dei dati presenti nella ConfigMap. Il Pod e la ConfigMap devono essere nello stesso Namespace. #### Nota: La `spec` di un [Pod statico](https://kubernetes.io/it/docs/tasks/configure-pod-container/static-pod/ "A pod managed directly by the kubelet daemon on a specific node.") non può riferirsi a una ConfigMap o ad altri oggetti API. Questo è un esempio di una ConfigMap che ha alcune chiavi con valori semplici, e altre chiavi dove il valore ha il formato di un frammento di configurazione. apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: # chiavi simili a proprietà; ogni chiave mappa un valore semplice player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # chiavi simili a files game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true Ci sono quattro modi differenti con cui puoi usare una ConfigMap per configurare un container all'interno di un Pod: 1. Argomento da riga di comando come entrypoint di un container 2. Variabile d'ambiente di un container 3. Aggiungere un file in un volume di sola lettura, per fare in modo che l'applicazione lo legga 4. Scrivere il codice da eseguire all'interno del Pod che utilizza l'API di Kubernetes per leggere la ConfigMap Questi metodologie differenti permettono di utilizzare diversi metodi per modellare i dati che saranno consumati. Per i primi tre metodi, il [kubelet](https://kubernetes.io/it/docs/reference/generated/kubelet "Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.") utilizza i dati della ConfigMap quando lancia il container (o più) in un Pod. Per il quarto metodo dovrai scrivere il codice per leggere la ConfigMap e i suoi dati. Comunque, poiché stai utilizzando l'API di Kubernetes direttamente, la tua applicazione può sottoscriversi per ottenere aggiornamenti ogniqualvolta la ConfigMap cambia, e reagire quando ciò accade. Accedendo direttamente all'API di Kubernetes, questa tecnica ti permette anche di accedere a una ConfigMap in namespace differenti. Ecco un esempio di Pod che usa i valori da `game-demo` per configurare il container: apiVersion: v1 kind: Pod metadata: name: configmap-demo-pod spec: containers: - name: demo image: alpine command: ["sleep", "3600"] env: # Definire la variabile d'ambiente - name: PLAYER_INITIAL_LIVES # Notare che il case qui è differente # dal nome della key nella ConfigMap. valueFrom: configMapKeyRef: name: game-demo # La ConfigMap da cui proviene il valore. key: player_initial_lives # La chiave da recuperare. - name: UI_PROPERTIES_FILE_NAME valueFrom: configMapKeyRef: name: game-demo key: ui_properties_file_name volumeMounts: - name: config mountPath: "/config" readOnly: true volumes: # Settare i volumi al livello del Pod, in seguito montarli nei containers all'interno del Pod - name: config configMap: # Fornire il nome della ConfigMap che vuoi montare. name: game-demo # Una lista di chiavi dalla ConfigMap per essere creata come file items: - key: "game.properties" path: "game.properties" - key: "user-interface.properties" path: "user-interface.properties" Una ConfigMap non differenzia tra le proprietà di una singola linea e un file con più linee e valori. L'importante è il modo in cui i Pods e gli altri oggetti consumano questi valori. Per questo esempio, definire un volume e montarlo all'interno del container `demo` come `/config` crea due files, `/config/game.properties` e `/config/user-interface.properties`, sebbene ci siano quattro chiavi nella ConfigMap. Ciò avviene perché la definizione del Pod specifica una lista di `items` nella sezione dei `volumes`. Se ometti del tutto la lista degli `items`, ogni chiave nella ConfigMap diventerà un file con lo stesso nome della chiave, e otterrai 4 files. Usare le ConfigMaps ------------------- Le ConfigMaps possono essere montate come volumi. Le ConfigMaps possono anche essere utilizzate da altre parti del sistema, senza essere direttamente esposte al Pod. Per esempio, le ConfigMaps possono contenere l'informazione che altre parti del sistema utilizzeranno per la loro configurazione. La maniera più comune per usare le ConfigMaps è di configurare i containers che sono in esecuzione in un Pod nello stesso namespace. Puoi anche utilizzare una ConfigMap separatamente. Per esempio, potresti incontrare [addons](https://kubernetes.io/it/docs/concepts/cluster-administration/addons/ "Resources that extend the functionality of Kubernetes.") o [operators](https://kubernetes.io/it/docs/concepts/extend-kubernetes/operator/ "A specialized controller used to manage a custom resource") che adattano il loro comportamento in base a una ConfigMap. ### Usare le ConfigMaps come files in un Pod Per utilizzare una ConfigMap in un volume all'interno di un Pod: 1. Creare una ConfigMap o usarne una che già esiste. Più Pods possono utilizzare la stessa ConfigMap. 2. Modificare la definizione del Pod per aggiungere un volume sotto `.spec.volumes[]`. Nominare il volume in qualsiasi modo, e avere un campo `.spec.volumes[].configMap.name` configurato per referenziare il tuo oggetto ConfigMap. 3. Aggiungere un `.spec.containers[].volumeMounts[]` a ogni container che necessiti di una ConfigMap. Nello specifico `.spec.containers[].volumeMounts[].readOnly = true` e `.spec.containers[].volumeMounts[].mountPath` in una cartella inutilizzata dove vorresti che apparisse la ConfigMap. 4. Modificare l'immagine o il comando utilizzato così che il programma cerchi i files in quella cartella. Ogni chiave nella sezione `data` della ConfigMap si converte in un file sotto `mountPath`. Questo è un esempio di un Pod che monta una ConfigMap in un volume: apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true volumes: - name: foo configMap: name: myconfigmap Ogni ConfigMap che desideri utilizzare deve essere referenziata in `.spec.volumes`. Se c'è più di un container nel Pod, allora ogni container necessita del suo blocco `volumeMounts`, ma solamente un `.spec.volumes` è necessario ConfigMap. #### Le ConfigMaps montate sono aggiornate automaticamente Quando una ConfigMap è utilizzata in un volume ed è aggiornata, anche le chiavi vengono aggiornate. Il kubelet controlla se la ConfigMap montata è aggiornata ad ogni periodo di sincronizzazione. Ad ogni modo, il kubelet usa la sua cache locale per ottenere il valore attuale della ConfigMap. Il tipo di cache è configurabile usando il campo `ConfigMapAndSecretChangeDetectionStrategy` nel [KubeletConfiguration struct](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/) . Una ConfigMap può essere propagata per vista (default), ttl-based, o redirigendo tutte le richieste direttamente all'API server. Come risultato, il ritardo totale dal momento in cui la ConfigMap è aggiornata al momento in cui nuove chiavi sono propagate al Pod può essere tanto lungo quanto il periodo della sincronizzazione del kubelet + il ritardo della propagazione della cache, dove il ritardo della propagazione della cache dipende dal tipo di cache scelta (è uguale rispettivamente al ritardo della propagazione, ttl della cache, o zero). Le ConfigMaps consumate come variabili d'ambiente non sono aggiornate automaticamente e necessitano di un riavvio del pod. #### Nota: Un container utilizzando una ConfigMap come un [subPath](https://kubernetes.io/docs/concepts/storage/volumes#using-subpath) volume mount non riceverà gli aggiornamenti della ConfigMap. ConfigMaps Immutabili --------------------- FEATURE STATE: `Kubernetes v1.21 [stable]` La funzionalità di Kubernetes _Immutable Secrets and ConfigMaps_ fornisce un'opzione per configurare Secrets individuali e ConfigMaps come immutabili. Per clusters che usano le ConfigMaps come estensione (almeno decine o centinaia di ConfigMap uniche montate nel Pod), prevenire i cambiamenti nei loro dati ha i seguenti vantaggi: * protezione da aggiornamenti accidentali (o non voluti) che potrebbero causare l'interruzione di applicazioni * miglioramento della performance del tuo cluster riducendo significativamente il carico sul kube-apiserver, chiudendo l'ascolto sulle ConfigMaps che sono segnate come immutabili. Questa funzionalità è controllata dal `ImmutableEphemeralVolumes` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) . Puoi creare una ConfigMap immutabile settando il campo `immutable` a `true`. Per esempio: apiVersion: v1 kind: ConfigMap metadata: ... data: ... immutable: true Una volta che una ConfigMap è segnata come immutabile, _non_ è possibile invertire questo cambiamento né cambiare il contenuto del campo `data` o `binaryData` field. Puoi solamente cancellare e ricreare la ConfigMap. Poiché i Pods hanno un puntamento verso la ConfigMap eliminata, è raccomandato di ricreare quei Pods. Voci correlate -------------- * Leggi in merito [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) . * Leggi [Configura un Pod per utilizzare una ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) . * Leggi in merito [Modificare una ConfigMap (o qualsiasi altro oggetto di Kubernetes)](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) * Leggi [The Twelve-Factor App](https://12factor.net/) per comprendere il motivo di separare il codice dalla configurazione. 5 - Amministrazione del Cluster =============================== 5.1 - Proxy in Kubernetes ========================= Questa pagina spiega i proxy utilizzati con Kubernetes. Proxy ----- Esistono diversi proxy che puoi incontrare quando usi Kubernetes: 1. Il [kubectl proxy](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#direct-accessing-the-rest-api) :     - viene eseguito sul computer di un utente o in un pod     - collega un localhost address all'apiserver di Kubernetes     - il client comunica con il proxy in HTTP     - il proxy comunica con l'apiserver in HTTPS     - individua l'apiserver     - aggiunge gli header di autenticazione 1. L'[apiserver proxy](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services) :     - è un proxy presente nell'apiserver     - collega un utente al di fuori del cluster agli IP del cluster che altrimenti potrebbero non essere raggiungibili     - è uno dei processi dell'apiserver     - il client comunica con il proxy in HTTPS (o HTTP se l'apiserver è configurato in tal modo)     - il proxy comunica con il target via HTTP o HTTPS come scelto dal proxy utilizzando le informazioni disponibili     - può essere utilizzato per raggiungere un nodo, un pod o un servizio     - esegue il bilanciamento del carico quando viene utilizzato per raggiungere un servizio 1. Il [kube proxy](https://kubernetes.io/docs/concepts/services-networking/service/#ips-and-vips) :     - è eseguito su ciascun nodo     - fa da proxy per comunicazioni UDP, TCP e SCTP     - non gestisce il protocollo HTTP     - esegue il bilanciamento del carico     - è usato solo per raggiungere i servizi 1. Un proxy/bilanciatore di carico di fronte agli apiserver:     - la sua esistenza e implementazione variano da cluster a cluster (ad esempio nginx)     - si trova tra i client e uno o più apiserver     - funge da bilanciatore di carico se ci sono più di un apiserver. 1. Cloud Load Balancer su servizi esterni:     - sono forniti da alcuni fornitori di servizi cloud (ad es. AWS ELB, Google Cloud Load Balancer)     - vengono creati automaticamente quando il servizio Kubernetes ha tipo `LoadBalancer`     - solitamente supporta solo UDP / TCP     - il supporto SCTP dipende dall'implementazione del bilanciatore di carico del provider cloud     - l'implementazione varia a seconda del provider cloud. Gli utenti di Kubernetes in genere non devono preoccuparsi alcun proxy, se non i primi due tipi. L'amministratore del cluster in genere assicurerà che gli altri tipi di proxy siano impostati correttamente. Richiedere reindirizzamenti --------------------------- I proxy hanno sostituito le funzioni di reindirizzamento. I reindirizzamenti sono stati deprecati. 6 - Esempio di modello di concetto ================================== #### Nota: Assicurati anche di [creare una voce nel sommario](https://kubernetes.io/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) per il tuo nuovo documento. Questa pagina spiega ... Comprendendo ... ---------------- Kubernetes fornisce ... Usando ... ---------- Usare Voci correlate -------------- **\[Sezione opzionale\]** * Ulteriori informazioni su [Scrivere un nuovo argomento](https://kubernetes.io/docs/home/contribuisci/scrivi-nuovo-argomento/) . * Vedi [Uso dei modelli di pagina - Modello di concetto](https://kubernetes.io/docs/home/contribuis/page-templates/#concept_template) su come utilizzare questo modello. --- # Przechowywanie danych | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/concepts/storage/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/concepts/storage/) . Przechowywanie danych ===================== Trwałe i tymczasowe mechanizmy przechowywania danych dla Podów w klastrze. --- # Kubernetes Documentation | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/docs/home/_print/#) . [Return to the regular view of this page](https://kubernetes.io/docs/home/) . Kubernetes Documentation ======================== Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation. * 1: [Available Documentation Versions](https://kubernetes.io/docs/home/_print/#pg-92dfff0ca612d0bff40171aa9df6c4ae) 1 - Available Documentation Versions ==================================== This website contains documentation for the current version of Kubernetes and the four previous versions of Kubernetes. The availability of documentation for a Kubernetes version is separate from whether that release is currently supported. Read [Support period](https://kubernetes.io/releases/patch-releases/#support-period) to learn about which versions of Kubernetes are officially supported, and for how long. --- # कुबेरनेट्स प्रलेखन | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/home/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/home/) . कुबेरनेट्स प्रलेखन ================== कुबेरनेट्स कंटेनरीकृत एप्लीकेशन के परिनियोजन, स्केलिंग और प्रबंधन को स्वचालित करने के लिए एक ओपन सोर्स कंटेनर ऑर्केस्ट्रेशन इंजन है| यह ओपन सोर्स प्रोजेक्ट Cloud Native Computing Foundation द्वारा होस्ट किया गया है। * 1: [प्रलेखन के उपलब्ध संस्करण](https://kubernetes.io/hi/docs/home/_print/#pg-92dfff0ca612d0bff40171aa9df6c4ae) 1 - प्रलेखन के उपलब्ध संस्करण ============================= इस वेबसाइट में कुबेरनेट्स के वर्तमान और चार पिछले संस्करण के प्रलेखन शामिल हैं। --- # Kubernetes Dokumentation | Kubernetes Das ist eine für den Ausdruck optimierte Ansicht des gesamten Kapitels inkl. Unterseiten. [Druckvorgang starten](https://kubernetes.io/de/docs/home/_print/#) . [Zur Standardansicht zurückkehren](https://kubernetes.io/de/docs/home/) . Kubernetes Dokumentation ======================== * 1: [Unterstützte Versionen der Kubernetes-Dokumentation](https://kubernetes.io/de/docs/home/_print/#pg-92dfff0ca612d0bff40171aa9df6c4ae) 1 - Unterstützte Versionen der Kubernetes-Dokumentation ======================================================= Diese Website enthält Dokumentation für die aktuelle Version von Kubernetes und die vier vorherigen Versionen von Kubernetes. --- # उत्तम प्रथाएं | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/setup/best-practices/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/setup/best-practices/) . उत्तम प्रथाएं ============= --- # Administrasi Klaster | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#) . [Return to the regular view of this page](https://kubernetes.io/id/docs/concepts/cluster-administration/) . Administrasi Klaster ==================== * 1: [Ikhtisar Administrasi Klaster](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-fb494ea3b1874bd753dcd11c3f35c2dc) * 2: [Sertifikat](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-2bf9a93ab5ba014fb6ff70b22c29d432) * 3: [Penyedia Layanan Cloud](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-d0e81230313a2684e7b7e40b21834e30) * 4: [Mengelola Resource](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-3aeeecf7cdb2a21eb4b31db7a71c81e2) * 5: [Jaringan Klaster](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-d649067a69d8d5c7e71564b42b96909e) * 6: [Arsitektur Logging](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-c4b1e87a84441f8a90699a345ce48d68) * 7: [Metrik untuk Komponen Sistem Kubernetes](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-cbfd3654996eae9fcdef009f70fa83f0) * 8: [Konfigurasi Garbage Collection pada kubelet](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-2e05a56491965ae320c2662590b2ca18) * 9: [Berbagai Proxy di Kubernetes](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-08e94e6a480e0d6b2de72d84a1b97617) * 10: [Metrik controller manager](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-d5cc46b61677b53f61a407d20bdd0830) * 11: [Instalasi Add-ons](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-85d633ae590aa20ec024f1b7af1d74fc) * 12: [Prioritas dan Kesetaraan API (API Priority and Fairness)](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#pg-31c9327d2332c585341b64ddafa19cdd) 1 - Ikhtisar Administrasi Klaster ================================= Ikhtisar administrasi klaster ini ditujukan untuk siapapun yang akan membuat atau mengelola klaster Kubernetes. Diharapkan untuk memahami beberapa [konsep](https://kubernetes.io/id/docs/concepts/) dasar Kubernetes sebelumnya. Perencanaan Klaster ------------------- Lihat panduan di [Persiapan](https://kubernetes.io/id/docs/setup/) untuk mempelajari beberapa contoh tentang bagaimana merencanakan, mengatur dan mengonfigurasi klaster Kubernetes. Solusi yang akan dipaparkan di bawah ini disebut _distro_. Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan: * Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan _high-availability_, _multi-node_? Pilihlah distro yang paling sesuai dengan kebutuhanmu. * **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada _multiple zone_](https://kubernetes.io/id/docs/concepts/cluster-administration/federation/) . * Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) , atau **_hosting_ sendiri klastermu**? * Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster. * **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](https://kubernetes.io/id/docs/concepts/cluster-administration/networking/) yang paling sesuai. * Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**? * Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis _binary_, namun menawarkan lebih banyak variasi pilihan. * Pastikan kamu paham dan terbiasa dengan beberapa [komponen](https://kubernetes.io/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster. Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji dengan versi terkini dari Kubernetes. Mengelola Klaster ----------------- * [Mengelola klaster](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/) akan menjabarkan beberapa topik terkait _lifecycle_ dari klaster: membuat klaster baru, melakukan _upgrade_ pada _node master_ dan _worker_, melakukan pemeliharaan _node_ (contoh: _upgrade_ kernel), dan melakukan _upgrade_ versi Kubernetes API pada klaster yang sedang berjalan. * Pelajari bagaimana cara [mengatur _node_](https://kubernetes.io/docs/concepts/nodes/node/) . * Pelajari bagaimana cara membuat dan mengatur kuota resource [(_resource quota_)](https://kubernetes.io/id/docs/concepts/policy/resource-quotas/) untuk _shared_ klaster. Mengamankan Klaster ------------------- * [Sertifikat (_certificate_)](https://kubernetes.io/id/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa _tool chains_. * [Kubernetes _Container Environment_](https://kubernetes.io/id/docs/concepts/containers/container-environment-variables/) akan menjelaskan _environment_ untuk kontainer yang dikelola oleh Kubelet pada Kubernetes _node_. * [Mengontrol Akses ke Kubernetes API](https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/) akan menjabarkan bagaimana cara mengatur izin (_permission_) untuk akun pengguna dan _service account_. * [Autentikasi](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) akan menjelaskan autentikasi di Kubernetes, termasuk ragam pilihan autentikasi. * [Otorisasi](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) dibedakan dari autentikasi, digunakan untuk mengontrol bagaimana _HTTP call_ ditangani. * [Menggunakan _Admission Controllers_](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) akan menjelaskan _plug-in_ yang akan melakukan intersep permintaan sebelum menuju ke server Kubernetes API, setelah autentikasi dan otorisasi dilakukan. * [Menggunakan Sysctls pada Klaster Kubernetes](https://kubernetes.io/docs/concepts/cluster-administration/sysctl-cluster/) akan menjabarkan tentang cara menggunakan perintah `sysctl` pada _command-line_ untuk mengatur parameter kernel. * [Audit](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) akan menjelaskan bagaimana cara berinteraksi dengan log audit Kubernetes. ### Mengamankan Kubelet * [Komunikasi Master-Node](https://kubernetes.io/docs/concepts/architecture/master-node-communication/) * [TLS _bootstrapping_](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) * [Autentikasi/Otorisasi Kubelet](https://kubernetes.io/docs/admin/kubelet-authentication-authorization/) Layanan Tambahan Klaster ------------------------ * [Integrasi DNS](https://kubernetes.io/id/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara _resolve_ suatu nama DNS langsung pada _service_ Kubernetes. * [_Logging_ dan _Monitoring_ Aktivitas Klaster](https://kubernetes.io/id/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara _logging_ bekerja di Kubernetes serta bagaimana cara mengimplementasikannya. 2 - Sertifikat ============== Saat menggunakan autentikasi sertifikat klien, kamu dapat membuat sertifikat secara manual melalui `easyrsa`, `openssl` atau `cfssl`. ### easyrsa **easyrsa** dapat digunakan untuk menghasilkan sertifikat klaster kamu secara manual. 1. Unduh, buka paket, dan inisialisasi versi tambal easyrsa3. curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz tar xzf easy-rsa.tar.gz cd easy-rsa-master/easyrsa3 ./easyrsa init-pki 2. Hasilkan CA. (`--batch` untuk atur mode otomatis. `--req-cn` untuk menggunakan _default_ CN.) ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass 3. Hasilkan sertifikat dan kunci _server_. Argumen `--subject-alt-name` digunakan untuk mengatur alamat IP dan nama DNS yang dapat diakses oleh _server_ API. `MASTER_CLUSTER_IP` biasanya merupakan IP pertama dari CIDR _service cluster_ yang diset dengan argumen `--service-cluster-ip-range` untuk _server_ API dan komponen manajer pengontrol. Argumen `--days` digunakan untuk mengatur jumlah hari masa berlaku sertifikat. Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama _domain_ DNS _default_. ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ "IP:${MASTER_CLUSTER_IP},"\ "DNS:kubernetes,"\ "DNS:kubernetes.default,"\ "DNS:kubernetes.default.svc,"\ "DNS:kubernetes.default.svc.cluster,"\ "DNS:kubernetes.default.svc.cluster.local" \ --days=10000 \ build-server-full server nopass 4. Salin `pki/ca.crt`, `pki/issued/server.crt`, dan `pki/private/server.key` ke direktori kamu. 5. Isi dan tambahkan parameter berikut ke dalam parameter mulai _server_ API: --client-ca-file=/yourdirectory/ca.crt --tls-cert-file=/yourdirectory/server.crt --tls-private-key-file=/yourdirectory/server.key ### openssl **openssl** secara manual dapat menghasilkan sertifikat untuk klaster kamu. 1. Hasilkan ca.key dengan 2048bit: openssl genrsa -out ca.key 2048 2. Hasilkan ca.crt berdasarkan ca.key (gunakan -days untuk mengatur waktu efektif sertifikat): openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt 3. Hasilkan server.key dengan 2048bit: openssl genrsa -out server.key 2048 4. Buat _file_ konfigurasi untuk menghasilkan _Certificate Signing Request_ (CSR). Pastikan untuk mengganti nilai yang ditandai dengan kurung sudut (mis. ``) dengan nilai sebenarnya sebelum menyimpan ke _file_ (mis. `csr.conf`). Perhatikan bahwa nilai `MASTER_CLUSTER_IP` adalah layanan IP klaster untuk _server_ API seperti yang dijelaskan dalam subbagian sebelumnya. Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama _domain_ DNS _default_. [ req ] default_bits = 2048 prompt = no default_md = sha256 req_extensions = req_ext distinguished_name = dn [ dn ] C = ST = L = O = OU = CN = [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = kubernetes DNS.2 = kubernetes.default DNS.3 = kubernetes.default.svc DNS.4 = kubernetes.default.svc.cluster DNS.5 = kubernetes.default.svc.cluster.local IP.1 = IP.2 = [ v3_ext ] authorityKeyIdentifier=keyid,issuer:always basicConstraints=CA:FALSE keyUsage=keyEncipherment,dataEncipherment extendedKeyUsage=serverAuth,clientAuth subjectAltName=@alt_names 5. Hasilkan permintaan penandatanganan sertifikat berdasarkan _file_ konfigurasi: openssl req -new -key server.key -out server.csr -config csr.conf 6. Hasilkan sertifikat _server_ menggunakan ca.key, ca.crt dan server.csr: openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out server.crt -days 10000 \ -extensions v3_ext -extfile csr.conf -sha256 7. Lihat sertifikat: openssl x509 -noout -text -in ./server.crt Terakhir, tambahkan parameter yang sama ke dalam parameter mulai _server_ API. ### cfssl **cfssl** adalah alat lain untuk pembuatan sertifikat. 1. Unduh, buka paket dan siapkan _command line tools_ seperti yang ditunjukkan di bawah ini. Perhatikan bahwa kamu mungkin perlu menyesuaikan contoh perintah berdasarkan arsitektur perangkat keras dan versi cfssl yang kamu gunakan. curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl chmod +x cfssl curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson chmod +x cfssljson curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo chmod +x cfssl-certinfo 2. Buat direktori untuk menyimpan _artifacts_ dan inisialisasi cfssl: mkdir cert cd cert ../cfssl print-defaults config > config.json ../cfssl print-defaults csr > csr.json 3. Buat _file_ konfigurasi JSON untuk menghasilkan _file_ CA, misalnya, `ca-config.json`: { "signing": { "default": { "expiry": "8760h" }, "profiles": { "kubernetes": { "usages": [\ "signing",\ "key encipherment",\ "server auth",\ "client auth"\ ], "expiry": "8760h" } } } } 4. Buat _file_ konfigurasi JSON untuk CA _certificate signing request_ (CSR), misalnya, `ca-csr.json`. Pastikan untuk mengganti nilai yang ditandai dengan kurung sudut dengan nilai sebenarnya yang ingin kamu gunakan. { "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "names":[{\ "C": "",\ "ST": "",\ "L": "",\ "O": "",\ "OU": ""\ }] } 5. Hasilkan kunci CA (`ca-key.pem`) dan sertifikat (`ca.pem`): ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca 6. Buat _file_ konfigurasi JSON untuk menghasilkan kunci dan sertifikat untuk API _server_, misalnya, `server-csr.json`. Pastikan untuk mengganti nilai dalam kurung sudut dengan nilai sebenarnya yang ingin kamu gunakan. `MASTER_CLUSTER_IP` adalah layanan klaster IP untuk _server_ API seperti yang dijelaskan dalam subbagian sebelumnya. Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama _domain_ DNS _default_. { "CN": "kubernetes", "hosts": [\ "127.0.0.1",\ "",\ "",\ "kubernetes",\ "kubernetes.default",\ "kubernetes.default.svc",\ "kubernetes.default.svc.cluster",\ "kubernetes.default.svc.cluster.local"\ ], "key": { "algo": "rsa", "size": 2048 }, "names": [{\ "C": "",\ "ST": "",\ "L": "",\ "O": "",\ "OU": ""\ }] } 7. Buat kunci dan sertifikat untuk server API, yang mana awalnya di simpan masing-masing ke dalam _file_ `server-key.pem` dan `server.pem`: ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ --config=ca-config.json -profile=kubernetes \ server-csr.json | ../cfssljson -bare server Distribusi Sertifikat _Self-Signed_ CA -------------------------------------- _Node_ klien dapat menolak untuk mengakui sertifikat CA yang ditandatangani sendiri sebagai valid. Untuk _deployment_ non-produksi, atau untuk _deployment_ yang berjalan di belakang _firewall_ perusahaan, kamu dapat mendistribusikan sertifikat CA yang ditandatangani sendiri untuk semua klien dan _refresh_ daftar lokal untuk sertifikat yang valid. Pada setiap klien, lakukan operasi berikut: sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d.... done. Sertifikat API -------------- Kamu dapat menggunakan API `Certificate.k8s.io` untuk menyediakan sertifikat x509 yang digunakan untuk autentikasi seperti yang didokumentasikan [di sini](https://kubernetes.io/id/docs/tasks/tls/managing-tls-in-a-cluster) . 3 - Penyedia Layanan Cloud ========================== Laman ini akan menjelaskan bagaimana cara mengelola Kubernetes yang berjalan pada penyedia layanan cloud tertentu. ### Kubeadm [Kubeadm](https://kubernetes.io/id/docs/reference/setup-tools/kubeadm/) merupakan salah satu cara yang banyak digunakan untuk membuat klaster Kubernetes. Kubeadm memiliki beragam opsi untuk mengatur konfigurasi spesifik untuk penyedia layanan cloud. Salah satu contoh yang biasa digunakan pada penyedia cloud _in-tree_ yang dapat diatur dengan kubeadm adalah sebagai berikut: apiVersion: kubeadm.k8s.io/v1beta1 kind: InitConfiguration nodeRegistration: kubeletExtraArgs: cloud-provider: "openstack" cloud-config: "/etc/kubernetes/cloud.conf" --- apiVersion: kubeadm.k8s.io/v1beta1 kind: ClusterConfiguration kubernetesVersion: v1.13.0 apiServer: extraArgs: cloud-provider: "openstack" cloud-config: "/etc/kubernetes/cloud.conf" extraVolumes: - name: cloud hostPath: "/etc/kubernetes/cloud.conf" mountPath: "/etc/kubernetes/cloud.conf" controllerManager: extraArgs: cloud-provider: "openstack" cloud-config: "/etc/kubernetes/cloud.conf" extraVolumes: - name: cloud hostPath: "/etc/kubernetes/cloud.conf" mountPath: "/etc/kubernetes/cloud.conf" Penyedia layanan cloud _in-tree_ biasanya membutuhkan `--cloud-provider` dan `--cloud-config` yang ditentukan sebelumnya pada _command lines_ untuk [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver/) , [kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager/) dan [kubelet](https://kubernetes.io/docs/admin/kubelet/) . Konten dari _file_ yang ditentukan pada `--cloud-config` untuk setiap provider akan dijabarkan di bawah ini. Untuk semua penyedia layanan cloud eksternal, silakan ikuti instruksi pada repositori masing-masing penyedia layanan. AWS --- Bagian ini akan menjelaskan semua konfigurasi yang dapat diatur saat menjalankan Kubernetes pada Amazon Web Services. ### Nama Node Penyedia layanan cloud AWS menggunakan nama DNS privat dari _instance_ AWS sebagai nama dari objek Kubernetes Node. ### _Load Balancer_ Kamu dapat mengatur [load balancers eksternal](https://kubernetes.io/id/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini. apiVersion: v1 kind: Service metadata: name: example namespace: kube-system labels: run: example annotations: service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #ganti nilai ini service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http spec: type: LoadBalancer ports: - port: 443 targetPort: 5556 protocol: TCP selector: app: example Pengaturan lainnya juga dapat diaplikasikan pada layanan _load balancer_ di AWS dengan menggunakan anotasi-anotasi. Berikut ini akan dijelaskan anotasi yang didukung oleh AWS ELB: * `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: Digunakan untuk menentukan interval pengeluaran log akses. * `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: Digunakan untuk mengaktifkan atau menonaktifkan log akses. * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: Digunakan untuk menentukan nama _bucket_ S3 log akses. * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Digunakan untuk menentukan prefix _bucket_ S3 log akses. * `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Digunakan untuk menentukan daftar tag tambahan pada ELB dengan menggunakan parameter _key-value_. Contoh: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`. * `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Digunakan untuk menentukan protokol yang digunakan oleh _backend_ (pod) di belakang _listener_. Jika diset ke `http` (default) atau `https`, maka akan dibuat HTTPS _listener_ yang akan mengakhiri koneksi dan meneruskan _header_. Jika diset ke `ssl` atau `tcp`, maka akan digunakan "raw" SSL _listener_. Jika diset ke `http` dan `aws-load-balancer-ssl-cert` tidak digunakan, maka akan digunakan HTTP _listener_. * `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Digunakan untuk meminta _secure_ _listener_. Nilai yang dimasukkan adalah sertifikat ARN yang valid. Info lebih lanjut lihat [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN merupakan IAM atau CM certificate ARN, contoh: `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Digunakan untuk mengaktifkan atau menonaktfkan _connection draining_. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Digunakan untuk menentukan _connection draining timeout_. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Digunakan untuk menentukan _idle connection timeout_. * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Digunakan untuk mengaktifkan atau menonaktifkan _cross-zone load balancing_. * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Digunakan untuk menentukan grup keamanan yang akan ditambahkan pada ELB yang dibuat. * `service.beta.kubernetes.io/aws-load-balancer-internal`: Digunakan sebagai indikasi untuk menggunakan internal ELB. * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Digunakan untuk mengaktifkan _proxy protocol_ pada ELB. Saat ini hanya dapat menerima nilai `*` yang berarti mengaktifkan _proxy protocol_ pada semua ELB _backends_. Di masa mendatang kamu juga dapat mengatur agar _proxy protocol_ hanya aktif pada _backends_ tertentu.. * `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: Digunakan untuk menentukan daftar port--yang dipisahkan koma-- yang akan menggunakan SSL/HTTPS _listeners_. Nilai _default_ yaitu `*` (semua). Informasi anotasi untuk AWS di atas diperoleh dari komentar pada [aws.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go) Azure ----- ### Nama Node Penyedia layanan cloud Azure menggunakan _hostname_ dari _node_ (yang ditentukan oleh kubelet atau menggunakan `--hostname-override`) sebagai nama dari objek Kubernetes Node. Perlu diperhatikan bahwa nama Kubernetes Node harus sesuai dengan nama Azure VM. CloudStack ---------- ### Nama Node Penyedia layanan cloud CloudStack menggunakan _hostname_ dari _node_ (yang ditentukan kubelet atau menggunakan `--hostname-override`) sebagai nama dari objek Kubernetes Node. Perlu diperhatikan bahwa nama Kubernetes Node harus sesuai dengan nama Cloudstack VM. GCE --- ### Nama Node Penyedia layanan cloud GCE menggunakan _hostname_ dari _node_ (yang ditentukan kubelet atau menggunakan `--hostname-override`) sebagai nama dari objek Kubernetes Node. Perlu diperhatikan bahwa segmen pertama dari nama Kubernetes Node harus sesuai dengan nama _instance_ GCE (contoh: sebuah _node_ dengan nama `kubernetes-node-2.c.my-proj.internal` harus sesuai dengan _instance_ yang memiliki nama `kubernetes-node-2`). OpenStack --------- Bagian ini akan menjelaskan semua konfigurasi yang dapat diatur saat menggunakan OpenStack dengan Kubernetes. ### Nama Node Penyedia layanan cloud OpenStack menggunakan nama _instance_ (yang diperoleh dari metadata OpenStack) sebagai nama objek Kubernetes Node. Perlu diperhatikan bahwa nama _instance_ harus berupa nama Kubernetes Node yang valid agar kubelet dapat mendaftarkan objek Node-nya. ### Layanan Penyedia layanan cloud OpenStack menggunakan beragam layanan OpenStack yang tersedia sebagai _underlying cloud_ agar dapat mendukung Kubernetes: | Layanan | Versi API | Wajib | | --- | --- | --- | | Block Storage (Cinder) | V1†, V2, V3 | Tidak | | Compute (Nova) | V2 | Tidak | | Identity (Keystone) | V2‡, V3 | Ya | | Load Balancing (Neutron) | V1§, V2 | Tidak | | Load Balancing (Octavia) | V2 | Tidak | † Block Storage V1 API tidak lagi didukung, dukungan Block Storage V3 API telah ditambahkan pada Kubernetes 1.9. ‡ Identity V2 API tidak lagi didukung dan akan dihapus oleh penyedia layanan pada rilis mendatang. Pada rilis "Queens", OpenStack tidak lagi mengekspos Identity V2 API. § Dukungan Load Balancing V1 API telah dihapus pada Kubernetes 1.9. _Service discovery_ dilakukan dengan menggunakan katalog layanan/servis (_service catalog_) yang diatur oleh OpenStack Identity (Keystone) menggunakan `auth-url` yang ditentukan pada konfigurasi penyedia layanan. Penyedia layanan akan menurunkan fungsionalitas secara perlahan saat layanan OpenStack selain Keystone tidak tersedia dan akan menolak dukungan fitur yang terdampak. Beberapa fitur tertentu dapat diaktifkan atau dinonaktfikan tergantung dari ekstensi yang diekspos oleh Neutron pada _underlying cloud_. ### cloud.conf Kubernetes berinteraksi dengan OpenStack melalui _file_ cloud.conf. _File_ ini akan menyuplai Kubernetes dengan kredensial dan lokasi dari Openstack _auth endpoint_. Kamu dapat membuat _file_ cloud.conf dengan menambahkan rincian berikut ini di dalam _file_: #### Konfigurasi pada umumnya Berikut ini merupakan contoh dan konfigurasi yang biasa digunakan dan akan mencakup semua pilihan yang paling sering dibutuhkan. _File_ ini akan merujuk pada _endpoint_ dari Keystone OpenStack, serta menyediakan rincian bagaimana cara mengautentikasi dengannya, termasuk cara mengatur _load balancer_: [Global] username=user password=pass auth-url=https:///identity/v3 tenant-id=c869168a828847f39f7f06edd7305637 domain-id=2a73b8f597c04551a0fdc8e95544be8a [LoadBalancer] subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a ##### Global Konfigurasi untuk penyedia layanan OpenStack berikut ini akan membahas bagian konfigurasi global sehingga harus berada pada bagian `[Global]` dari _file_ `cloud.conf`: * `auth-url` (Wajib): URL dari API keystone digunakan untuk autentikasi. ULR ini dapat ditemukan pada bagian Access dan Security > API Access > Credentials di laman panel kontrol OpenStack. * `username` (Wajib): Merujuk pada username yang dikelola keystone. * `password` (Wajib): Merujuk pada kata sandi yang dikelola keystone. * `tenant-id` (Wajib): Digunakan untuk menentukan id dari _project_ tempat kamu membuat _resources_. * `tenant-name` (Opsional): Digunakan untuk menentukan nama dari _project_ tempat kamu ingin membuat _resources_. * `trust-id` (Opsional): Digunakan untuk menentukan _identifier of the trust_ untuk digunakan sebagai otorisasi. Suatu _trust_ merepresentasikan otorisasi dari suatu pengguna (_the trustor_) untuk didelegasikan pada pengguna lain (_the trustee_), dan dapat digunakan oleh _trustee_ berperan sebagai _the trustor_. _Trust_ yang tersedia dapat ditemukan pada _endpoint_ `/v3/OS-TRUST/trusts` dari Keystone API. * `domain-id` (Opsional): Digunakan untuk menentukan id dari domain tempat _user_ kamu berada. * `domain-name` (Opsional): Digunakan untuk menentukan nama dari domain tempat _user_ kamu berada. * `region` (Opsional): Digunakan untuk menentukan _identifier_ dari region saat digunakan pada multi-region OpenStack cloud. Sebuah region merupakan pembagian secara umum dari _deployment_ OpenStack. Meskipun region tidak wajib berkorelasi secara geografis, suatu _deployment_ dapat menggunakan nama geografis sebagai region _identifier_ seperti `us-east`. Daftar region yang tersedia dapat ditemukan pada _endpoint_ `/v3/regions` dari Keystone API. * `ca-file` (Optional): Digunakan untuk menentukan path dari _file_ _custom_ CA. Saat menggunakan Keystone V3 - yang mengganti istilah _tenant_ menjadi _project_ - nilai `tenant-id` akan secara otomatis dipetakan pada _project_ yang sesuai di API. ##### _Load Balancer_ Konfigurasi berikut ini digunakan untuk mengatur _load balancer_ dan harus berada pada bagian `[LoadBalancer]` dari _file_ `cloud.conf`: * `lb-version` (Opsional): Digunakan untuk menonaktifkan pendeteksian versi otomatis. Nilai yang valid yaitu `v1` atau `v2`. Jika tidak ditentukan, maka pendeteksian otomatis akan memilih versi tertinggi yang didukung dari _underlying_ OpenStack cloud. * `use-octavia` (Opsional): Digunakan untuk menentukan apakah akan menggunakan _endpoint_ dari layanan Octavia LBaaS. Nilai yang valid yaitu `true` atau `false`. Jika diset nilai `true` namun Octavia LBaaS V2 tidak dapat ditemukan, maka _load balancer_ akan kembali menggunakan _endpoint_ dari Neutron LBaaS V2. Nilai _default_ adalah `false`. * `subnet-id` (Opsional): Digunakan untuk menentukan id dari subnet yang ingin kamu buat _load balancer_ di dalamnya. Nilai id ini dapat dilihat pada Network > Networks. Klik pada jaringan yang sesuai untuk melihat subnet di dalamnya. * `floating-network-id` (Opsional): Jika diset, maka akan membuat _floating_ IP untuk _load balancer_. * `lb-method` (Opsional): Digunakan untuk menentukan algoritma pendistribusian yang akan digunakan. Nilai yang valid yaitu `ROUND_ROBIN`, `LEAST_CONNECTIONS`, atau `SOURCE_IP`. Jika tidak diset, maka akan menggunakan algoritma _default_ yaitu `ROUND_ROBIN`. * `lb-provider` (Opsional): Digunakan untuk menentukan penyedia dari _load balancer_. Jika tidak ditentukan, maka akan menggunakan penyedia _default_ yang ditentukan pada Neutron. * `create-monitor` (Opsional): Digunakan untuk menentukan apakah akan membuat atau tidak monitor kesehatan untuk Neutron _load balancer_. Nilai yang valid yaitu `true` dan `false`. Nilai _default_ adalah `false`. Jika diset nilai `true` maka `monitor-delay`, `monitor-timeout`, dan `monitor-max-retries` juga harus diset. * `monitor-delay` (Opsional): Waktu antara pengiriman _probes_ ke anggota dari _load balancer_. Mohon pastikan kamu memasukkan waktu yang valid. Nilai waktu yang valid yaitu "ns", "us" (atau "µs"), "ms", "s", "m", "h" * `monitor-timeout` (Opsional): Waktu maksimum dari monitor untuk menunggu balasan ping sebelum _timeout_. Nilai ini harus lebih kecil dari nilai _delay_. Mohon pastikan kamu memasukkan waktu yang valid. Nilai waktu yang valid yaitu "ns", "us" (atau "µs"), "ms", "s", "m", "h" * `monitor-max-retries` (Opsional): Jumlah gagal ping yang diizinkan sebelum mengubah status anggota _load balancer_ menjadi INACTIVE. Harus berupa angka antara 1 dan 10. * `manage-security-groups` (Opsional): Digunakan untuk menentukan apakah _load balancer_ akan mengelola aturan grup keamanan sendiri atau tidak. Nilai yang valid adalah `true` dan `false`. Nilai _default_ adalah `false`. Saat diset ke `true` maka nilai `node-security-group` juga harus ditentukan. * `node-security-group` (Opsional): ID dari grup keamanan yang akan dikelola. ##### _Block Storage_ Konfigurasi untuk penyedia layanan OpenStack berikut ini digunakan untuk mengatur penyimpanan blok atau _block storage_ dan harus berada pada bagian `[BlockStorage]` dari _file_ `cloud.conf`: * `bs-version` (Opsional): Digunakan untuk menonaktifkan fitur deteksi versi otomatis. Nilai yang valid yaitu `v1`, `v2`, `v3` dan `auto`. Jika diset ke `auto` maka pendeteksian versi otomatis akan memilih versi tertinggi yang didukung oleh _underlying_ OpenStack cloud. Nilai _default_ jika tidak diset adalah `auto`. * `trust-device-path` (Opsional): Pada umumnya nama _block device_ yang ditentukan oleh Cinder (contoh: `/dev/vda`) tidak dapat diandalkan. Opsi ini dapat mengatur hal tersebut. Jika diset ke `true` maka akan menggunakan nama _block device_ yang ditentukan oleh Cinder. Nilai _default_ adalah `false` yang berarti _path_ dari _device_ akan ditentukan oleh nomor serialnya serta pemetaan dari `/dev/disk/by-id`, dan ini merupakan cara yang direkomendasikan. * `ignore-volume-az` (Opsional): Digunakan untuk mengatur penggunaan _availability zone_ saat menautkan volumes Cinder. Jika Nova dan Cinder memiliki _availability zones_ yang berbeda, opsi ini harus diset `true`. Skenario seperti ini yang umumnya terjadi, yaitu saat terdapat banyak Nova _availability zones_ namun hanya ada satu Cinder _availability zone_. Nilai _default_ yaitu `false` digunakan untuk mendukung penggunaan pada rilis terdahulu, tetapi nilai ini dapat berubah pada rilis mendatang. Jika menjalankan Kubernetes dengan versi <= 1.8 pada OpenStack yang menggunakan _paths_ alih-alih menggunakan port untuk membedakan antara _endpoints_, maka mungkin dibutuhkan untuk secara eksplisit mengatur parameter `bs-version`. Contoh _endpoint_ yang berdasarkan _path_ yaitu `http://foo.bar/volume` sedangkan endpoint yang berdasarkan port memiliki bentuk seperti ini `http://foo.bar:xxx`. Pada lingkungan yang menggunakan _endpoint_ berdasarkan _path_ dan Kubernetes menggunakan logika deteksi-otomatis yang lama, maka _error_ `BS API version autodetection failed.` akan muncul saat mencoba melepaskan volume. Untuk mengatasi isu ini, dimungkinkan untuk memaksa penggunaan Cinder API versi 2 dengan menambahkan baris berikut ini pada konfigurasi penyedia cloud: [BlockStorage] bs-version=v2 ##### Metadata Konfigurasi untuk OpenStack berikut ini digunakan untuk mengatur metadata dan harus berada pada bagian `[Metadata]` dari _file_ `cloud.conf`: * `search-order` (Opsional): Konfigurasi berikut ini digunakan untuk mengatur bagaimana cara provider mengambil metadata terkait dengan _instance_ yang dijalankannya. Nilai _default_ yaitu `configDrive,metadataService` yang berarti provider akan mengambil metadata terkait _instance_ dari _config drive_ terlebih dahulu jika tersedia, namun jika tidak maka akan menggunakan layanan metadata. Nilai alternatif lainnya yaitu: * `configDrive` - Hanya mengambil metadata _instance_ dari _config drive_. * `metadataService` - Hanya mengambil data _instance_ dari layanan metadata. * `metadataService,configDrive` - Mengambil metadata _instance_ dari layanan metadata terlebih dahulu jika tersedia, jika tidak maka akan mengambil dari _config drive_. Pengaturan ini memang sebaiknya dilakukan sebab metadata pada _config drive_ bisa saja lambat laun akan kedaluwarsa, sedangkan layanan metadata akan selalu menyediakan metadata yang paling mutakhir. Tidak semua penyedia layanan cloud OpenStack menyediakan kedua layanan _config drive_ dan layanan metadata dan mungkin hanya salah satu saja yang tersedia. Oleh sebab itu nilai _default_ diatur agar dapat memeriksa keduanya. ##### Router Konfigurasi untuk Openstack berikut ini digunakan untuk mengatur _plugin_ jaringan Kubernetes [kubenet](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#kubenet) dan harus berada pada bagian `[Router]` dari _file_ `cloud.conf`: * `router-id` (Opsional): Jika Neutron pada _underlying cloud_ mendukung ekstensi `extraroutes` maka gunakan `router-id` untuk menentukan router mana yang akan ditambahkan rute di dalamnya. Router yang dipilih harus menjangkau jaringan privat tempat _node_ klaster berada (biasanya hanya ada satu jaringan _node_, dan nilai ini harus nilai dari _default_ router pada jaringan _node_). Nilai ini dibutuhkan untuk dapat menggunakan [kubenet](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#kubenet) pada OpenStack. OVirt ----- ### Nama Node Penyedia layanan cloud OVirt menggunakan _hostname_ dari _node_ (yang ditentukan kubelet atau menggunakan `--hostname-override`) sebagai nama dari objek Kubernetes Node. Perlu diperhatikan bahwa nama Kubernetes Node harus sesuai dengan VM FQDN (yang ditampilkan oleh OVirt di bawah `...`) Photon ------ ### Nama Node Penyedia layanan cloud Photon menggunakan _hostname_ dari _node_ (yang ditentukan kubelet atau menggunakan `--hostname-override`) sebagai nama dari objek Kubernetes Node. Perlu diperhatikan bahwa nama Kubernetes Node name harus sesuai dengan nama Photon VM (atau jika `overrideIP` diset ke true pada `--cloud-config`, nama Kubernetes Node harus sesuai dengan alamat IP Photon VM). VSphere ------- ### Nama Node Penyedia layanan cloud VSphere menggunakan _hostname_ yang terdeteksi dari _node_ (yang ditentukan oleh kubelet) sebagai nama dari objek Kubernetes Node. Parameter `--hostname-override` diabaikan oleh penyedia layanan cloud VSphere. IBM Cloud Kubernetes Service ---------------------------- ### Node Komputasi Saat menggunakan layanan IBM Cloud Kubernetes Service, kamu dapat membuat klaster yang terdiri dari campuran antara mesin virtual dan fisik (_bare metal_) sebagai _node_ di _single zone_ atau _multiple zones_ pada satu region. Untuk informasi lebih lanjut, lihat [Perencanaan klaster dan pengaturan worker node](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters) . Nama dari objek Kubernetes Node yaitu alamat IP privat dari IBM Cloud Kubernetes Service _worker node instance_. ### Jaringan Penyedia layanan IBM Cloud Kubernetes Service menyediakan VLAN untuk membuat jaringan node yang terisolasi dengan kinerja tinggi. Kamu juga dapat membuat _custom firewall_ dan _policy_ jaringan Calico untuk menambah lapisan perlindungan ekstra bagi klaster kamu, atau hubungkan klaster kamu dengan _on-prem_ data center via VPN. Untuk informasi lebih lanjut, lihat [Perencanaan jaringan privat dan in-cluster](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster) . Untuk membuka aplikasi ke publik atau di dalam klaster, kamu dapat menggunakan NodePort, LoadBalancer, atau Ingress. Kamu juga dapat menyesuaikan aplikasi _load balancer_ Ingress dengan anotasi. Untuk informasi lebih lanjut, lihat [Perencanaan untuk membuka aplikasi dengan jaringan eksternal](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning) . ### Penyimpanan Penyedia layanan IBM Cloud Kubernetes Service memanfaatkan Kubernetes-native _persistent volumes_ agar pengguna dapat melakukan _mount_ _file_, block, dan penyimpanan objek cloud ke aplikasi mereka. Kamu juga dapat menggunakan _database-as-a-service_ dan _add-ons_ pihak ketiga sebagai penyimpanan _persistent_ untuk data kamu. Untuk informasi lebih lanjut, lihat [Perencanaan penyimpanan persistent yang selalu tersedia (_highly available_)](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning) . Baidu Cloud Container Engine ---------------------------- ### Nama Node Penyedia layanan cloud Baidu menggunakan alamat IP privat dari _node_ (yang ditentukan oleh kubelet atau menggunakan `--hostname-override`) sebagai nama dari objek Kubernetes Node. Perlu diperhatikan bahwa nama Kubernetes Node harus sesuai dengan alamat IP privat dari Baidu VM. 4 - Mengelola Resource ====================== Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](https://kubernetes.io/id/docs/concepts/configuration/overview/) dan [label](https://kubernetes.io/id/docs/concepts/overview/working-with-objects/labels/) . Mengelola konfigurasi _resource_ -------------------------------- Banyak aplikasi memerlukan beberapa _resource_, seperti Deployment dan Service. Pengelolaan beberapa _resource_ dapat disederhanakan dengan mengelompokkannya dalam berkas yang sama (dengan pemisah `---` pada YAML). Contohnya: [`application/nginx-app.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/id/examples/application/nginx-app.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy application/nginx-app.yaml to clipboard") apiVersion: v1 kind: Service metadata: name: my-nginx-svc labels: app: nginx spec: type: LoadBalancer ports: - port: 80 selector: app: nginx --- apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 Beberapa _resource_ dapat dibuat seolah-olah satu _resource_: kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml service/my-nginx-svc created deployment.apps/my-nginx created _Resource_ akan dibuat dalam urutan seperti pada berkas. Oleh karena itu, lebih baik menyalakan _service_ lebih dahulu agar menjamin _scheduler_ dapat menyebar _pod_ yang terkait _service_ selagi _pod_ dibangkitkan oleh _controller_, seperti Deployment. `kubectl apply` juga dapat menerima beberapa argumen `-f`: kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml Selain berkas, kita dapat juga memasukkan direktori sebagai argumen: kubectl apply -f https://k8s.io/examples/application/nginx/ `kubectl` akan membaca berkas apapun yang berakhiran `.yaml`, `.yml`, or `.json`. Sangat disarankan untuk meletakkan sumber daya yang ada dalam _microservice_ atau _tier_ aplikasi yang sama dalam satu berkas, dan mengelompokkan semua berkas terkait aplikasimu dalam satu direktori. Jika _tier_ masing-masing aplikasi terikat dengan DNS, maka kamu dapat melakukan _deploy_ semua komponen teknologi yang dibutuhkan bersama-sama. Lokasi konfigurasi dapat juga diberikan dalam bentuk URL. Ini berguna ketika ingin menjalankan berkas konfigurasi dari Github: kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml deployment.apps/my-nginx created Operasi majemuk dalam kubectl ----------------------------- Pembuatan _resource_ bukanlah satu-satunya operasi yang bisa dijalankan `kubectl` secara majemuk. Contoh lainnya adalah mengekstrak nama _resource_ dari berkas konfigurasi untuk menjalankan operasi lainnya, seperti untuk menghapus _resource_ yang telah dibuat: kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml deployment.apps "my-nginx" deleted service "my-nginx-svc" deleted Pada kasus dua _resource_, mudah untuk memasukkan keduanya pada _command line_ menggunakan sintaks _resource_/nama: kubectl delete deployments/my-nginx services/my-nginx-svc Namun, untuk _resource_ yang lebih banyak, memasukkan selektor (_label query_) menggunakan `-l` atau `--selector` untuk memfilter _resource_ berdasarkan label akan lebih mudah: kubectl delete deployment,services -l app=nginx deployment.apps "my-nginx" deleted service "my-nginx-svc" deleted Karena `kubectl` mengembalikan nama resource yang sama dengan sintaks yang diterima, mudah untuk melanjutkan operasi menggunakan `$()` atau `xargs`: kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service) NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx-svc LoadBalancer 10.0.0.208 80/TCP 0s Dengan perintah di atas, pertama kita buat resource di dalam `examples/application/nginx/`. Lalu tampilkan resources yang terbentuk dengan format keluaran `-o name` (menampilkan tiap resource dalam format resource/nama). Kemudian lakukan `grep` hanya pada "service", dan tampilkan dengan `kubectl get`. Untuk dapat menggunakan perintah di atas pada direktori yang bertingkat, kamu dapat memberi argumen `--recursive` atau `-R` bersama dengan argumen `--filename,-f`. Misalnya ada sebuah direktori `project/k8s/development` memuat semua manifests yang berkaitan dengan _development environment_. Manifest akan tersusun berdasarkan tipe resource: project/k8s/development ├── configmap │   └── my-configmap.yaml ├── deployment │   └── my-deployment.yaml └── pvc └── my-pvc.yaml Secara _default_, menjalankan operasi majemuk pada `project/k8s/development` hanya akan terbatas pada direktori terluar saja. Sehingga ketika kita menjalankan operasi pembuatan dengan perintah berikut, kita akan mendapatkan pesan kesalahan: kubectl apply -f project/k8s/development error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin) Solusinya, tambahkan argumen `--recursive` atau `-R` bersama dengan `--filename,-f`, seperti: kubectl apply -f project/k8s/development --recursive configmap/my-config created deployment.apps/my-deployment created persistentvolumeclaim/my-pvc created Argumen `--recursive` berjalan pada operasi apapun yang menerima argumen `--filename,-f` seperti: `kubectl {create,get,delete,describe,rollout} etc.` Argumen `--recursive` juga berjalan saat beberapa argumen `-f` diberikan: kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive namespace/development created namespace/staging created configmap/my-config created deployment.apps/my-deployment created persistentvolumeclaim/my-pvc created Jika kamu tertarik mempelajari lebih lanjut tentang `kubectl`, silahkan baca [Ikhtisar kubectl](https://kubernetes.io/id/docs/reference/kubectl/overview/) . Memakai label secara efektif ---------------------------- Contoh yang kita lihat sejauh ini hanya menggunakan paling banyak satu label pada _resource_. Ada banyak skenario ketika membutuhkan beberapa label untuk membedakan sebuah kelompok dari yang lainnya. Sebagai contoh, aplikasi yang berbeda akan menggunakan label `app` yang berbeda, tapi pada aplikasi _multitier_, seperti pada [contoh buku tamu](https://github.com/kubernetes/examples/tree/main/guestbook/) , tiap _tier_ perlu dibedakan. Misal untuk menandai _tier frontend_ bisa menggunakan label: labels: app: guestbook tier: frontend sementara itu Redis _master_ dan _slave_ memiliki label `tier` yang berbeda. Bisa juga menggunakan label tambahan `role`: labels: app: guestbook tier: backend role: master dan labels: app: guestbook tier: backend role: slave Label memungkinkan kita untuk memilah _resource_ dengan pembeda berupa label: kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml kubectl get pods -Lapp -Ltier -Lrole NAME READY STATUS RESTARTS AGE APP TIER ROLE guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master guestbook-redis-slave-2q2yf 1/1 Running 0 1m guestbook backend slave guestbook-redis-slave-qgazl 1/1 Running 0 1m guestbook backend slave my-nginx-divi2 1/1 Running 0 29m nginx my-nginx-o0ef1 1/1 Running 0 29m nginx kubectl get pods -lapp=guestbook,role=slave NAME READY STATUS RESTARTS AGE guestbook-redis-slave-2q2yf 1/1 Running 0 3m guestbook-redis-slave-qgazl 1/1 Running 0 3m Deploy dengan Canary -------------------- Skenario lain yang menggunakan beberapa label yaitu saat membedakan deployment komponen yang sama namun dengan rilis atau konfigurasi yang berbeda. Adalah praktik yang umum untuk mendeploy sebuah _canary_ dari rilis aplikasi yang baru (berdasarkan _tag image_ dalam templat _pod_) bersamaan dengan rilis sebelumnya. Ini memungkinkan rilis yang baru dapat menerima _live traffic_ sebelum benar-benar menggantikan rilis yang lama. Salah satu alternatif yaitu kamu dapat memakai label `track` untuk membedakan antar rilis. Rilis primer dan stabil akan memiliki label `track` yang berisi `stable`: name: frontend replicas: 3 ... labels: app: guestbook tier: frontend track: stable ... image: gb-frontend:v3 kemudian kamu buat lagi rilis _frontend_ buku tamu yang membawa label `track` yang berbeda (misal `canary`), sehingga _pod_ dalam kedua rilis tidak beririsan: name: frontend-canary replicas: 1 ... labels: app: guestbook tier: frontend track: canary ... image: gb-frontend:v4 Servis _frontend_ akan meliputi kedua set replika dengan menentukan subset bersama dari para labelnya (tanpa `track`). Sehingga _traffic_ akan diarahkan ke kedua aplikasi: selector: app: guestbook tier: frontend Kamu dapat mengatur jumlah replika rilis _stable_ dan _canary_ untuk menentukan rasio dari tiap rilis yang akan menerima _traffic production live_ (dalam kasus ini 3:1). Ketika telah yakin, kamu dapat memindahkan _track stable_ ke rilis baru dan menghapus _canary_. Untuk contoh yang lebih jelas, silahkan cek [tutorial melakukan deploy Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary) . Memperbarui label ----------------- Kadang, _pod_ dan _resource_ lain yang sudah ada harus dilabeli ulang sebelum membuat _resource_ baru. Hal ini dapat dilakukan dengan perintah `kubectl label`. Contohnya jika kamu ingin melabeli ulang semua _pod_ nginx sebagai _frontend tier_, tinggal jalankan: kubectl label pods -l app=nginx tier=fe pod/my-nginx-2035384211-j5fhi labeled pod/my-nginx-2035384211-u2c7e labeled pod/my-nginx-2035384211-u3t6x labeled Perintah ini melakukan filter pada semua _pod_ dengan label "app=nginx", lalu melabelinya dengan "tier=fe". Untuk melihat _pod_ yang telah dilabeli, jalankan: kubectl get pods -l app=nginx -L tier NAME READY STATUS RESTARTS AGE TIER my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe Akan muncul semua _pod_ dengan "app=nginx" dan sebuah kolom label tambahan yaitu tier (ditentukan dengan `-L` atau `--label-columns`). Untuk informasi lebih lanjut, silahkan baca [label](https://kubernetes.io/id/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#label) . Memperbarui anotasi ------------------- Kadang resource perlu ditambahkan anotasi. Anotasi adalah metadata sembarang yang tidak unik, seperti _tools, libraries_, dsb yang digunakan oleh klien API . Ini dapat dilakukan dengan `kubectl annotate`. Sebagai contoh: kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' kubectl get pods my-nginx-v4-9gw19 -o yaml apiVersion: v1 kind: pod metadata: annotations: description: my frontend running nginx ... Untuk informasi lebih lanjut, silahkan lihat laman [annotations](https://kubernetes.io/id/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#annotate) . Memperbesar dan memperkecil aplikasi kamu ----------------------------------------- Saat beban aplikasi naik maupun turun, mudah untuk mengubah kapasitas dengan `kubectl`. Contohnya, untuk menurunkan jumlah replika nginx dari 3 ke 1, lakukan: kubectl scale deployment/my-nginx --replicas=1 deployment.apps/my-nginx scaled Sekarang kamu hanya memiliki satu _pod_ yang dikelola oleh deployment. kubectl get pods -l app=nginx NAME READY STATUS RESTARTS AGE my-nginx-2035384211-j5fhi 1/1 Running 0 30m Agar sistem dapat menyesuaikan jumlah replika nginx yang dibutuhkan secara otomatis dari 1 hingga 3, lakukan: kubectl autoscale deployment/my-nginx --min=1 --max=3 horizontalpodautoscaler.autoscaling/my-nginx autoscaled Sekarang jumlah replika nginx akan secara otomatis naik dan turun sesuai kebutuhan. Informasi tambahan dapat dilihat pada dokumen [kubectl scale](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#scale) , [kubectl autoscale](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#autoscale) dan [horizontal _pod_ autoscaler](https://kubernetes.io/id/docs/tasks/run-application/horizontal-pod-autoscale/) . Pembaruan resource di tempat ---------------------------- Kadang kita perlu membuat pembaruan kecil, yang tidak mengganggu pada _resource_ yang telah dibuat. ### kubectl apply Disarankan untuk menyimpan berkas-berkas konfigurasi dalam _source control_ (lihat [konfigurasi sebagai kode](http://martinfowler.com/bliki/InfrastructureAsCode.html) ). Sehingga berkas dapat dipelihara dan diatur dalam versi bersama dengan kode milik _resource_ yang diatur oleh konfigurasi tersebut. Berikutnya, kamu dapat menggunakan [`kubectl apply`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#apply) untuk membarui perubahan konfigurasi ke klaster. Perintah ini akan membandingkan versi konfigurasi yang disuplai dengan versi sebelumnya yang telah berjalan dan memasang perubahan yang kamu buat tanpa mengganti properti yang tidak berubah sama sekali. kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml deployment.apps/my-nginx configured Perhatikan bahwa `kubectl apply` memasang anotasi pada _resource_ untuk menentukan perubahan pada konfigurasi sejak terakhir dipanggil. Ketika dijalankan, `kubectl apply` melakukan pembandingan _three-way_ antara konfigurasi sebelumnya, masukan yang disuplai, dan konfigurasi _resource_ sekarang, untuk dapat menentukan cara memodifikasi _resource_. Saat ini, _resource_ dibuat tanpa ada anotasi. Jadi pemanggilan pertama pada `kubectl apply` akan dikembalikan pada perbandingan _two-way_ antara masukan pengguna dan konfigurasi _resource_ sekarang. Saat pemanggilan pertama ini, tidak ada penghapusan set properti yang terdeteksi saat _resource_ dibuat. Sehingga, tidak ada yang dihapus. Tiap `kubectl apply`, atau perintah lain yang memodifikasi konfigurasi seperti `kubectl replace` dan `kubectl edit` dijalankan, anotasi akan diperbarui. Sehingga memungkinkan operasi `kubectl apply` untuk mendeteksi dan melakukan penghapusan secara perbandingan _three-way_. ### kubectl edit Sebagai alternatif, kamu juga dapat membarui resource dengan `kubectl edit`: kubectl edit deployment/my-nginx Ini sama dengan melakukan `get` pada _resource_, mengubahnya di text editor, kemudian menjalankan`apply` pada _resource_ dengan versi terkini: kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml vi /tmp/nginx.yaml # lakukan pengubahan, lalu simpan berkas kubectl apply -f /tmp/nginx.yaml deployment.apps/my-nginx configured rm /tmp/nginx.yaml Cara demikian memungkinkan kamu membuat perubahan signifikan dengan mudah. Lihat bahwa kamu juga dapat menentukan editor dengan variabel environment `EDITOR` atau `KUBE_EDITOR`. Untuk informasi tambahan, silahkan lihat laman [kubectl edit](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#edit) . ### kubectl patch Kamu dapat menggunakan `kubectl patch` untuk membarui obyek API di tempat. Perintah ini mendukung patch JSON, _patch_ gabungan JSON, dan _strategic merge patch_. Lihat [Update API Objects in Place Using kubectl patch](https://kubernetes.io/docs/tasks/run-application/update-api-object-kubectl-patch/) dan [kubectl patch](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#patch) . Pembaruan disruptif ------------------- Pada kasus tertentu, kamu mungkin perlu memperbarui field resource yang tidak dapat diperbarui setelah diinisiasi atau kamu ingin membuat perubahan rekursif segera, seperti memperbaiki _pod_ yang rusak saat menjalankan Deployment. Untuk mengubah field seperti itu, gunakan `replace --force` yang akan menghapus dan membuat ulang resource. Dalam kasus ini kamu dapat mengubah berkas konfigurasi awalnya: kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force deployment.apps/my-nginx deleted deployment.apps/my-nginx replaced Membarui aplikasi tanpa memadamkan servis ----------------------------------------- Suatu saat, kamu akan perlu untuk membarui aplikasi yang telah terdeploy, biasanya dengan mengganti _image_ atau _tag_ sebagaimana dalam skenario _canary deployment_ di atas. `kubectl` mendukung beberapa operasi pembaruan, masing-masing dapat digunakan pada skenario berbeda. Kami akan memandumu untuk membuat dan membarui aplikasi melalui Deployment. Misal kamu telah menjalankan nginx versi 1.7.9: kubectl run my-nginx --image=nginx:1.7.9 --replicas=3 deployment.apps/my-nginx created Untuk memperbarui versi ke 1.9.1, ganti `.spec.template.spec.containers[0].image` dari `nginx:1.7.9` ke `nginx:1.9.1`, dengan perintah kubectl yang telah dipelajari di atas. kubectl edit deployment/my-nginx Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](https://kubernetes.io/id/docs/concepts/workloads/controllers/deployment/) . Selanjutnya ----------- * [Pelajari tentang bagaimana memakai `kubectl` untuk memeriksa dan _debug_ aplikasi.](https://kubernetes.io/id/docs/tasks/debug-application-cluster/debug-application-introspection/) * [Praktik Terbaik dan Tips Konfigurasi](https://kubernetes.io/id/docs/concepts/configuration/overview/) 5 - Jaringan Klaster ==================== Jaringan adalah bagian utama dari Kubernetes, tetapi bisa menjadi sulit untuk memahami persis bagaimana mengharapkannya bisa bekerja. Ada 4 masalah yang berbeda untuk diatasi: 1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh [Pod](https://kubernetes.io/id/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`. 2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini. 3. Komunikasi Pod dengan Service: ini terdapat di [Service](https://kubernetes.io/id/docs/concepts/services-networking/service/) . 4. Komunikasi eksternal dengan Service: ini terdapat di [Service](https://kubernetes.io/id/docs/concepts/services-networking/service/) . Kubernetes adalah tentang berbagi mesin antar aplikasi. Pada dasarnya, saat berbagi mesin harus memastikan bahwa dua aplikasi tidak mencoba menggunakan _port_ yang sama. Mengkoordinasikan _port_ di banyak pengembang sangat sulit dilakukan pada skala yang berbeda dan memaparkan pengguna ke masalah tingkat klaster yang di luar kendali mereka. Alokasi _port_ yang dinamis membawa banyak komplikasi ke sistem - setiap aplikasi harus menganggap _port_ sebagai _flag_, _server_ API harus tahu cara memasukkan nomor _port_ dinamis ke dalam blok konfigurasi, Service-Service harus tahu cara menemukan satu sama lain, dll. Sebaliknya daripada berurusan dengan ini, Kubernetes mengambil pendekatan yang berbeda. Model jaringan Kubernetes ------------------------- Setiap Pod mendapatkan alamat IP sendiri. Ini berarti kamu tidak perlu secara langsung membuat tautan antara Pod dan kamu hampir tidak perlu berurusan dengan memetakan _port_ kontainer ke _port_ pada _host_. Ini menciptakan model yang bersih, kompatibel dengan yang sebelumnya dimana Pod dapat diperlakukan seperti halnya VM atau _host_ fisik dari perspektif alokasi _port_, penamaan, _service discovery_, _load balancing_, konfigurasi aplikasi, dan migrasi. Kubernetes memberlakukan persyaratan mendasar berikut pada setiap implementasi jaringan (kecuali kebijakan segmentasi jaringan yang disengaja): * Pod pada suatu Node dapat berkomunikasi dengan semua Pod pada semua Node tanpa NAT * agen pada suatu simpul (mis. _daemon_ sistem, kubelet) dapat berkomunikasi dengan semua Pod pada Node itu Catatan: Untuk platform yang mendukung Pod yang berjalan di jaringan _host_ (mis. Linux): * Pod di jaringan _host_ dari sebuah Node dapat berkomunikasi dengan semua Pod pada semua Node tanpa NAT Model ini tidak hanya sedikit kompleks secara keseluruhan, tetapi pada prinsipnya kompatibel dengan keinginan Kubernetes untuk memungkinkan _low-friction porting_ dari aplikasi dari VM ke kontainer. Jika pekerjaan kamu sebelumnya dijalankan dalam VM, VM kamu memiliki IP dan dapat berbicara dengan VM lain di proyek yang sama. Ini adalah model dasar yang sama. Alamat IP Kubernetes ada di lingkup Pod - kontainer dalam Pod berbagi jaringan _namespace_ mereka - termasuk alamat IP mereka. Ini berarti bahwa kontainer dalam Pod semua dapat mencapai _port_ satu sama lain di `_localhost_`. Ini juga berarti bahwa kontainer dalam Pod harus mengoordinasikan penggunaan _port_, tetapi ini tidak berbeda dari proses di VM. Ini disebut model "IP-per-pod". Bagaimana menerapkan model jaringan Kubernetes ---------------------------------------------- Ada beberapa cara agar model jaringan ini dapat diimplementasikan. Dokumen ini bukan studi lengkap tentang berbagai metode, tetapi semoga berfungsi sebagai pengantar ke berbagai teknologi dan berfungsi sebagai titik awal. Opsi jaringan berikut ini disortir berdasarkan abjad - urutan tidak menyiratkan status istimewa apa pun. ### ACI [Infrastruktur Sentral Aplikasi Cisco](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) menawarkan solusi SDN overlay dan underlay terintegrasi yang mendukung kontainer, mesin virtual, dan _bare metal server_. [ACI](https://www.github.com/noironetworks/aci-containers) menyediakan integrasi jaringan kontainer untuk ACI. Tinjauan umum integrasi disediakan [di sini](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf) . ### AOS dari Apstra [AOS](http://www.apstra.com/products/aos/) adalah sistem Jaringan Berbasis Intent yang menciptakan dan mengelola lingkungan pusat data yang kompleks dari platform terintegrasi yang sederhana. AOS memanfaatkan desain terdistribusi sangat _scalable_ untuk menghilangkan pemadaman jaringan sambil meminimalkan biaya. Desain Referensi AOS saat ini mendukung _host_ yang terhubung dengan Lapis-3 yang menghilangkan masalah peralihan Lapis-2 yang lama. Host Lapis-3 ini bisa berupa _server_ Linux (Debian, Ubuntu, CentOS) yang membuat hubungan tetangga BGP secara langsung dengan _top of rack switches_ (TORs). AOS mengotomatisasi kedekatan perutean dan kemudian memberikan kontrol yang halus atas _route health injections_ (RHI) yang umum dalam _deployment_ Kubernetes. AOS memiliki banyak kumpulan endpoint REST API yang memungkinkan Kubernetes dengan cepat mengubah kebijakan jaringan berdasarkan persyaratan aplikasi. Peningkatan lebih lanjut akan mengintegrasikan model Grafik AOS yang digunakan untuk desain jaringan dengan penyediaan beban kerja, memungkinkan sistem manajemen ujung ke ujung untuk layanan cloud pribadi dan publik. AOS mendukung penggunaan peralatan vendor umum dari produsen termasuk Cisco, Arista, Dell, Mellanox, HPE, dan sejumlah besar sistem white-box dan sistem operasi jaringan terbuka seperti Microsoft SONiC, Dell OPX, dan Cumulus Linux. Detail tentang cara kerja sistem AOS dapat diakses di sini: [http://www.apstra.com/products/how-it-works/](http://www.apstra.com/products/how-it-works/) ### AWS VPC CNI untuk Kubernetes [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) menawarkan jaringan AWS _Virtual Private Cloud_ (VPC) terintegrasi untuk klaster Kubernetes. Plugin CNI ini menawarkan _throughput_ dan ketersediaan tinggi, latensi rendah, dan _jitter_ jaringan minimal. Selain itu, pengguna dapat menerapkan jaringan AWS VPC dan praktik keamanan terbaik untuk membangun klaster Kubernetes. Ini termasuk kemampuan untuk menggunakan catatan aliran VPC, kebijakan perutean VPC, dan grup keamanan untuk isolasi lalu lintas jaringan. Menggunakan _plugin_ CNI ini memungkinkan Pod Kubernetes memiliki alamat IP yang sama di dalam Pod seperti yang mereka lakukan di jaringan VPC. CNI mengalokasikan AWS _Elastic Networking Interfaces_ (ENIs) ke setiap node Kubernetes dan menggunakan rentang IP sekunder dari setiap ENI untuk Pod pada Node. CNI mencakup kontrol untuk pra-alokasi ENI dan alamat IP untuk waktu mulai Pod yang cepat dan memungkinkan klaster besar hingga 2.000 Node. Selain itu, CNI dapat dijalankan bersama [Calico untuk penegakan kebijakan jaringan](https://docs.aws.amazon.com/eks/latest/userguide/calico.html) . Proyek AWS VPC CNI adalah _open source_ dengan [dokumentasi di GitHub](https://github.com/aws/amazon-vpc-cni-k8s) . ### Big Cloud Fabric dari Big Switch Networks [Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) adalah arsitektur jaringan asli layanan cloud, yang dirancang untuk menjalankan Kubernetes di lingkungan cloud pribadi / lokal. Dengan menggunakan SDN fisik & _virtual_ terpadu, Big Cloud Fabric menangani masalah yang sering melekat pada jaringan kontainer seperti penyeimbangan muatan, visibilitas, pemecahan masalah, kebijakan keamanan & pemantauan lalu lintas kontainer. Dengan bantuan arsitektur multi-penyewa Pod virtual pada Big Cloud Fabric, sistem orkestrasi kontainer seperti Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm akan terintegrasi secara alami bersama dengan sistem orkestrasi VM seperti VMware, OpenStack & Nutanix. Pelanggan akan dapat terhubung dengan aman berapa pun jumlah klasternya dan memungkinkan komunikasi antar penyewa di antara mereka jika diperlukan. Terbaru ini BCF diakui oleh Gartner sebagai visioner dalam [_Magic Quadrant_](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html) . Salah satu penyebaran BCF Kubernetes di tempat (yang mencakup Kubernetes, DC/OS & VMware yang berjalan di beberapa DC di berbagai wilayah geografis) juga dirujuk [di sini](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/) . ### Cilium [Cilium](https://github.com/cilium/cilium) adalah perangkat lunak _open source_ untuk menyediakan dan secara transparan mengamankan konektivitas jaringan antar kontainer aplikasi. Cilium mengetahui L7/HTTP dan dapat memberlakukan kebijakan jaringan pada L3-L7 menggunakan model keamanan berbasis identitas yang dipisahkan dari pengalamatan jaringan. ### CNI-Genie dari Huawei [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) adalah _plugin_ CNI yang memungkinkan Kubernetes \[secara bersamaan memiliki akses ke berbagai implementasi\]([https://github.com/Huawei-PaaS](https://github.com/Huawei-PaaS) /CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) dari \[model jaringan Kubernetes\] ([https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model](https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) ) dalam _runtime_. Ini termasuk setiap implementasi yang berjalan sebagai [_plugin_ CNI](https://github.com/containernetworking/cni#3rd-party-plugins) , seperti [Flannel](https://github.com/coreos/flannel#flannel) , [Calico](http://docs.projectcalico.org/) , [Romana](http://romana.io/) , [Weave-net](https://www.weave.works/products/weave-net/) . CNI-Genie juga mendukung [menetapkan beberapa alamat IP ke sebuah Pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-address-per-pod) , masing-masing dari _plugin_ CNI yang berbeda. ### cni-ipvlan-vpc-k8s [cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) berisi satu set _plugin_ CNI dan IPAM untuk menyediakan kemudahan, host-lokal, latensi rendah, _throughput_ tinggi , dan tumpukan jaringan yang sesuai untuk Kubernetes dalam lingkungan Amazon Virtual Private Cloud (VPC) dengan memanfaatkan Amazon Elastic Network Interfaces (ENI) dan mengikat IP yang dikelola AWS ke Pod-Pod menggunakan _driver_ IPvlan _kernel_ Linux dalam mode L2. Plugin ini dirancang untuk secara langsung mengkonfigurasi dan _deploy_ dalam VPC. Kubelet melakukan _booting_ dan kemudian mengkonfigurasi sendiri dan memperbanyak penggunaan IP mereka sesuai kebutuhan tanpa memerlukan kompleksitas yang sering direkomendasikan untuk mengelola jaringan _overlay_, BGP, menonaktifkan pemeriksaan sumber/tujuan, atau menyesuaikan tabel rute VPC untuk memberikan _subnet_ per _instance_ ke setiap _host_ (yang terbatas hingga 50-100 masukan per VPC). Singkatnya, cni-ipvlan-vpc-k8s secara signifikan mengurangi kompleksitas jaringan yang diperlukan untuk menggunakan Kubernetes yang berskala di dalam AWS. ### Contiv [Contiv](https://github.com/contiv/netplugin) menyediakan jaringan yang dapat dikonfigurasi (_native_ l3 menggunakan BGP, _overlay_ menggunakan vxlan, classic l2, atau Cisco-SDN / ACI) untuk berbagai kasus penggunaan. [Contiv](https://contivpp.io/) semuanya open sourced. ### Contrail / Tungsten Fabric [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) , berdasarkan [Tungsten Fabric](https://tungsten.io/) , adalah platform virtualisasi jaringan dan manajemen kebijakan _multi-cloud_ yang benar-benar terbuka. Contrail dan Tungsten Fabric terintegrasi dengan berbagai sistem orkestrasi seperti Kubernetes, OpenShift, OpenStack dan Mesos, dan menyediakan mode isolasi yang berbeda untuk mesin _virtual_, banyak kontainer / banyak Pod dan beban kerja _bare metal_. ### DANM \[DANM\] ([https://github.com/nokia/danm](https://github.com/nokia/danm) ) adalah solusi jaringan untuk beban kerja telco yang berjalan di klaster Kubernetes. Dibangun dari komponen-komponen berikut: * Plugin CNI yang mampu menyediakan antarmuka IPVLAN dengan fitur-fitur canggih * Modul IPAM built-in dengan kemampuan mengelola dengan jumlah banyak, _cluster-wide_, _discontinous_ jaringan L3 dan menyediakan skema dinamis, statis, atau tidak ada permintaan skema IP * Metaplugin CNI yang mampu melampirkan beberapa antarmuka jaringan ke kontainer, baik melalui CNI sendiri, atau mendelegasikan pekerjaan ke salah satu solusi CNI populer seperti SRI-OV, atau Flannel secara paralel * Pengontrol Kubernetes yang mampu mengatur secara terpusat antarmuka VxLAN dan VLAN dari semua _host_ Kubernetes * Pengontrol Kubernetes lain yang memperluas konsep _service discovery_ berbasis servis untuk bekerja di semua antarmuka jaringan Pod Dengan _toolset_ ini, DANM dapat memberikan beberapa antarmuka jaringan yang terpisah, kemungkinan untuk menggunakan ujung belakang jaringan yang berbeda dan fitur IPAM canggih untuk Pod. ### Flannel \[Flannel\] ([https://github.com/coreos/flannel#flannel](https://github.com/coreos/flannel#flannel) ) adalah jaringan overlay yang sangat sederhana yang memenuhi persyaratan Kubernetes. Banyak orang telah melaporkan kesuksesan dengan Flannel dan Kubernetes. ### Google Compute Engine (GCE) Untuk skrip konfigurasi klaster Google Compute Engine, [perutean lanjutan](https://cloud.google.com/vpc/docs/routes) digunakan untuk menetapkan setiap VM _subnet_ (standarnya adalah `/24` - 254 IP). Setiap lalu lintas yang terikat untuk _subnet_ itu akan dialihkan langsung ke VM oleh _fabric_ jaringan GCE. Ini adalah tambahan untuk alamat IP "utama" yang ditugaskan untuk VM, yang NAT'ed untuk akses internet keluar. Sebuah linux _bridge_ (disebut `cbr0`) dikonfigurasikan untuk ada pada subnet itu, dan diteruskan ke _flag_ `-bridge` milik docker. Docker dimulai dengan: DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" Jembatan ini dibuat oleh Kubelet (dikontrol oleh _flag_ `--network-plugin=kubenet`) sesuai dengan `.spec.podCIDR` yang dimiliki oleh Node. Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan `cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE. GCE sendiri tidak tahu apa-apa tentang IP ini, jadi tidak akan NAT untuk lalu lintas internet keluar. Untuk mencapai itu aturan iptables digunakan untuk menyamar (alias SNAT - untuk membuatnya seolah-olah paket berasal dari lalu lintas `Node` itu sendiri) yang terikat untuk IP di luar jaringan proyek GCE (10.0.0.0/8). iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE Terakhir IP forwarding diaktifkan di kernel (sehingga kernel akan memproses paket untuk kontainer yang dijembatani): sysctl net.ipv4.ip_forward=1 Hasil dari semua ini adalah bahwa semua Pod dapat saling menjangkau dan dapat keluar lalu lintas ke internet. ### Jaguar [Jaguar](https://gitlab.com/sdnlab/jaguar) adalah solusi open source untuk jaringan Kubernetes berdasarkan OpenDaylight. Jaguar menyediakan jaringan overlay menggunakan vxlan dan Jaguar CNIPlugin menyediakan satu alamat IP per Pod. ### Knitter [Knitter](https://github.com/ZTE/Knitter/) adalah solusi jaringan yang mendukung banyak jaringan di Kubernetes. Solusi ini menyediakan kemampuan manajemen penyewa dan manajemen jaringan. Knitter mencakup satu set solusi jaringan kontainer NFV ujung ke ujung selain beberapa pesawat jaringan, seperti menjaga alamat IP untuk aplikasi, migrasi alamat IP, dll. ### Kube-OVN [Kube-OVN](https://github.com/alauda/kube-ovn) adalah _fabric_ jaringan kubernetes berbasis OVN untuk _enterprises_. Dengan bantuan OVN/OVS, solusi ini menyediakan beberapa fitur jaringan _overlay_ canggih seperti _subnet_, QoS, alokasi IP statis, _mirroring traffic_, _gateway_, kebijakan jaringan berbasis _openflow_, dan proksi layanan. ### Kube-router [Kube-router](https://github.com/cloudnativelabs/kube-router) adalah solusi jaringan yang dibuat khusus untuk Kubernetes yang bertujuan untuk memberikan kinerja tinggi dan kesederhanaan operasional. Kube-router menyediakan Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html) berbasis proksi layanan, solusi jaringan berbasis penerusan _pod-to-pod_ Linux _kernel_ tanpa _overlay_, dan penegak kebijakan jaringan berbasis _iptables/ipset_. ### L2 networks and linux bridging Jika Anda memiliki jaringan L2 yang "bodoh", seperti saklar sederhana di _environment_ "bare-metal", kamu harus dapat melakukan sesuatu yang mirip dengan pengaturan GCE di atas. Perhatikan bahwa petunjuk ini hanya dicoba dengan sangat sederhana - sepertinya berhasil, tetapi belum diuji secara menyeluruh. Jika kamu menggunakan teknik ini dan telah menyempurnakan prosesnya, tolong beri tahu kami. Ikuti bagian "With Linux Bridge devices" dari [tutorial yang sangat bagus ini](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) dari Lars Kellogg-Stedman. ### Multus (plugin Multi-Jaringan) [Multus](https://github.com/Intel-Corp/multus-cni) adalah plugin Multi CNI untuk mendukung fitur Banyak Jaringan di Kubernetes menggunakan objek jaringan berbasis CRD di Kubernetes. Multus mendukung semua [plugin referensi](https://github.com/containernetworking/plugins) (mis. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) , [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp) , \[Macvlan\]([https://github.com/containernetworking/plugins/tree/master/plugins/main](https://github.com/containernetworking/plugins/tree/master/plugins/main) / macvlan)) yang mengimplementasikan spesifikasi CNI dan plugin pihak ke-3 (mis. [Calico](https://github.com/projectcalico/cni-plugin) , [Weave](https://github.com/weaveworks/weave) , [Cilium](https://github.com/cilium/cilium) , [Contiv](https://github.com/contiv/netplugin) ). Selain itu, Multus mendukung [SRIOV](https://github.com/hustcat/sriov-cni) , [DPDK](https://github.com/Intel-Corp/sriov-cni) , [OVS- DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) beban kerja di Kubernetes dengan aplikasi cloud asli dan aplikasi berbasis NFV di Kubernetes. ### NSX-T [VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) adalah virtualisasi jaringan dan platform keamanan. NSX-T dapat menyediakan virtualisasi jaringan untuk lingkungan multi-cloud dan multi-hypervisor dan berfokus pada kerangka kerja dan arsitektur aplikasi yang muncul yang memiliki titik akhir dan tumpukan teknologi yang heterogen. Selain hypervisor vSphere, lingkungan ini termasuk hypervisor lainnya seperti KVM, wadah, dan bare metal. [NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) menyediakan integrasi antara NSX-T dan pembuat wadah seperti Kubernetes, serta integrasi antara NSX-T dan platform CaaS / PaaS berbasis-kontainer seperti Pivotal Container Service (PKS) dan OpenShift. ### Nuage Networks VCS (Layanan Cloud Virtual) [Nuage](http://www.nuagenetworks.net/) menyediakan platform SDN (Software-Defined Networking) berbasis kebijakan yang sangat skalabel. Nuage menggunakan Open vSwitch _open source_ untuk data _plane_ bersama dengan SDN Controller yang kaya fitur yang dibangun pada standar terbuka. Platform Nuage menggunakan _overlay_ untuk menyediakan jaringan berbasis kebijakan yang mulus antara Kubernetes Pod-Pod dan lingkungan non-Kubernetes (VM dan server _bare metal_). Model abstraksi kebijakan Nuage dirancang dengan mempertimbangkan aplikasi dan membuatnya mudah untuk mendeklarasikan kebijakan berbutir halus untuk aplikasi. Mesin analisis _real-time_ platform memungkinkan pemantauan visibilitas dan keamanan untuk aplikasi Kubernetes. ### OVN (Open Virtual Networking) OVN adalah solusi virtualisasi jaringan opensource yang dikembangkan oleh komunitas Open vSwitch. Ini memungkinkan seseorang membuat switch logis, router logis, ACL stateful, load-balancers dll untuk membangun berbagai topologi jaringan virtual. Proyek ini memiliki plugin dan dokumentasi Kubernetes spesifik di [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) . ### Project Calico [Project Calico](http://docs.projectcalico.org/) adalah penyedia jaringan wadah sumber terbuka dan mesin kebijakan jaringan. Calico menyediakan solusi jaringan dan kebijakan kebijakan jaringan yang sangat berskala untuk menghubungkan Pod Kubernetes berdasarkan prinsip jaringan IP yang sama dengan internet, untuk Linux (open source) dan Windows (milik - tersedia dari [Tigera](https://www.tigera.io/essentials/) ). Calico dapat digunakan tanpa enkapsulasi atau _overlay_ untuk menyediakan jaringan pusat data skala tinggi yang berkinerja tinggi. Calico juga menyediakan kebijakan keamanan jaringan berbutir halus, berdasarkan niat untuk Pod Kubernetes melalui _firewall_ terdistribusi. Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solusi jaringan lain seperti Flannel, alias [kanal](https://github.com/tigera/canal) , atau jaringan GCE, AWS atau Azure asli. ### Romana [Romana](http://romana.io/) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](https://kubernetes.io/id/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan. ### Weave Net dari Weaveworks [Weave Net](https://www.weave.works/products/weave-net/) adalah jaringan yang tangguh dan mudah digunakan untuk Kubernetes dan aplikasi yang dihostingnya. Weave Net berjalan sebagai [plug-in CNI](https://www.weave.works/docs/net/latest/cni-plugin/) atau berdiri sendiri. Di kedua versi, itu tidak memerlukan konfigurasi atau kode tambahan untuk dijalankan, dan dalam kedua kasus, jaringan menyediakan satu alamat IP per Pod - seperti standar untuk Kubernetes. Selanjutnya ----------- Desain awal model jaringan dan alasannya, dan beberapa rencana masa depan dijelaskan secara lebih rinci dalam [dokumen desain jaringan](https://git.k8s.io/community/contributors/design-proposals/network/networking.md) . 6 - Arsitektur Logging ====================== Log aplikasi dan sistem dapat membantu kamu untuk memahami apa yang terjadi di dalam klaster kamu. Log berguna untuk mengidentifikasi dan menyelesaikan masalah serta memonitor aktivitas klaster. Hampir semua aplikasi modern mempunyai sejenis mekanisme log sehingga hampir semua mesin kontainer didesain untuk mendukung suatu mekanisme _logging_. Metode _logging_ yang paling mudah untuk aplikasi dalam bentuk kontainer adalah menggunakan _standard output_ dan _standard error_. Namun, fungsionalitas bawaan dari mesin kontainer atau _runtime_ biasanya tidak cukup memadai sebagai solusi log. Contohnya, jika sebuah kontainer gagal, sebuah pod dihapus, atau suatu _node_ mati, kamu biasanya tetap menginginkan untuk mengakses log dari aplikasimu. Oleh sebab itu, log sebaiknya berada pada penyimpanan dan _lifecyle_ yang terpisah dari node, pod, atau kontainer. Konsep ini dinamakan sebagai _logging_ pada level klaster. _Logging_ pada level klaster ini membutuhkan _backend_ yang terpisah untuk menyimpan, menganalisis, dan mengkueri log. Kubernetes tidak menyediakan solusi bawaan untuk penyimpanan data log, namun kamu dapat mengintegrasikan beragam solusi _logging_ yang telah ada ke dalam klaster Kubernetes kamu. Arsitektur _logging_ pada level klaster yang akan dijelaskan berikut mengasumsikan bahwa sebuah _logging backend_ telah tersedia baik di dalam maupun di luar klastermu. Meskipun kamu tidak tertarik menggunakan _logging_ pada level klaster, penjelasan tentang bagaimana log disimpan dan ditangani pada node di bawah ini mungkin dapat berguna untukmu. Hal dasar _logging_ pada Kubernetes ----------------------------------- Pada bagian ini, kamu dapat melihat contoh tentang dasar _logging_ pada Kubernetes yang mengeluarkan data pada _standard output_. Demonstrasi berikut ini menggunakan sebuah [spesifikasi pod](https://kubernetes.io/examples/debug/counter-pod.yaml) dengan kontainer yang akan menuliskan beberapa teks ke _standard output_ tiap detik. [`debug/counter-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/id/examples/debug/counter-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy debug/counter-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: [/bin/sh, -c,\ 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'] Untuk menjalankan pod ini, gunakan perintah berikut: kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml Keluarannya adalah: pod/counter created Untuk mengambil log, gunakan perintah `kubectl logs` sebagai berikut: kubectl logs counter Keluarannya adalah: 0: Mon Jan 1 00:00:00 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001 ... Kamu dapat menambahkan parameter `--previous` pada perintah `kubectl logs` untuk mengambil log dari kontainer sebelumnya yang gagal atau _crash_. Jika pod kamu memiliki banyak kontainer, kamu harus menspesifikasikan kontainer mana yang kamu ingin akses lognya dengan menambahkan nama kontainer pada perintah tersebut. Lihat [dokumentasi `kubectl logs`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs) untuk informasi lebih lanjut. Node-level _logging_ -------------------- ![Node-level logging](https://kubernetes.io/images/docs/user-guide/logging/logging-node-level.png) Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview) , yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam berkas dalam format json. #### Catatan: _Logging driver_ json dari Docker memperlakukan tiap baris sebagai pesan yang terpisah. Saat menggunakan _logging driver_ Docker, tidak ada dukungan untuk menangani pesan _multi-line_. Kamu harus menangani pesan _multi-line_ pada level agen log atau yang lebih tinggi. Secara _default_, jika suatu kontainer _restart_, kubelet akan menjaga kontainer yang mati tersebut beserta lognya. Namun jika suatu pod dibuang dari _node_, maka semua hal dari kontainernya juga akan dibuang, termasuk lognya. Hal lain yang perlu diperhatikan dalam _logging_ pada level _node_ adalah implementasi rotasi log, sehingga log tidak menghabiskan semua penyimpanan yang tersedia pada _node._ Kubernetes saat ini tidak bertanggung jawab dalam melakukan rotasi log, namun _deployment tool_ seharusnya memberikan solusi terhadap masalah tersebut. Contohnya, pada klaster Kubernetes, yang di _deployed_ menggunakan `kube-up.sh`, terdapat alat bernama [`logrotate`](https://linux.die.net/man/8/logrotate) yang dikonfigurasi untuk berjalan tiap jamnya. Kamu juga dapat menggunakan _runtime_ kontainer untuk melakukan rotasi log otomatis, misalnya menggunakan `log-opt` Docker. Pada `kube-up.sh`, metode terakhir digunakan untuk COS _image_ pada GCP, sedangkan metode pertama digunakan untuk lingkungan lainnya. Pada kedua metode, secara _default_ akan dilakukan rotasi pada saat berkas log melewati 10MB. Sebagai contoh, kamu dapat melihat informasi lebih rinci tentang bagaimana `kube-up.sh` mengatur _logging_ untuk COS _image_ pada GCP yang terkait dengan [_script_](https://github.com/kubernetes/kubernetes/blob/main/cluster/gce/gci/configure-helper.sh) . Saat kamu menjalankan perintah [`kubectl logs`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs) seperti pada contoh tadi, kubelet di _node_ tersebut akan menangani permintaan untuk membaca langsung isi berkas log sebagai respon. #### Catatan: Saat ini, jika suatu sistem eksternal telah melakukan rotasi, hanya konten dari berkas log terbaru yang akan tersedia melalui perintah `kubectl logs`. Contoh, jika terdapat sebuah berkas 10MB, `logrotate` akan melakukan rotasi sehingga akan ada dua buah berkas, satu dengan ukuran 10MB, dan satu berkas lainnya yang kosong. Maka `kubectl logs` akan mengembalikan respon kosong. ### Komponen sistem log Terdapat dua jenis komponen sistem: yaitu yang berjalan di dalam kontainer dan komponen lain yang tidak berjalan di dalam kontainer. Sebagai contoh: * Kubernetes _scheduler_ dan kube-proxy berjalan di dalam kontainer. * Kubelet dan _runtime_ kontainer, contohnya Docker, tidak berjalan di dalam kontainer. Pada mesin yang menggunakan systemd, kubelet dan runtime _runtime_ menulis ke journald. Jika systemd tidak tersedia, keduanya akan menulis ke berkas `.log` pada folder `/var/log`. Komponen sistem di dalam kontainer akan selalu menuliskan ke folder `/var/log`, melewati mekanisme _default logging_. Mereka akan menggunakan _logging library_ [klog](https://github.com/kubernetes/klog) . Kamu dapat menemukan konvensi tentang tingkat kegawatan _logging_ untuk komponen-komponen tersebut pada [dokumentasi _development logging_](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) . Seperti halnya pada log kontainer, komponen sistem yang menuliskan log pada folder `/var/log` juga harus melakukan rotasi log. Pada klaster Kubernetes yang menggunakan `kube-up.sh`, log tersebut telah dikonfigurasi dan akan dirotasi oleh `logrotate` secara harian atau saat ukuran log melebihi 100MB. Arsitektur klaster-level _logging_ ---------------------------------- Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level klaster, ada beberapa pendekatan yang dapat kamu pertimbangkan. Berikut beberapa diantaranya: * Menggunakan agen _logging_ pada level _node_ yang berjalan pada setiap _node_. * Menggunakan kontainer _sidecar_ khusus untuk _logging_ aplikasi di dalam pod. * Mengeluarkan log langsung ke _backend_ dari dalam aplikasi ### Menggunakan agen node-level _logging_ ![Menggunakan agen node-level logging](https://kubernetes.io/images/docs/user-guide/logging/logging-with-node-agent.png) Kamu dapat mengimplementasikan klaster-level _logging_ dengan menggunakan agen yang berjalan pada setiap _node_. Agen _logging_ merupakan perangkat khusus yang akan mengekspos log atau mengeluarkan log ke _backend_. Umumnya agen _logging_ merupakan kontainer yang memiliki akses langsung ke direktori tempat berkas log berada dari semua kontainer aplikasi yang berjalan pada _node_ tersebut. Karena agen _logging_ harus berjalan pada setiap _node_, umumnya dilakukan dengan menggunakan replika DaemonSet, _manifest_ pod, atau menjalankan proses khusus pada _node_. Namun dua cara terakhir sudah dideprekasi dan sangat tidak disarankan. Menggunakan agen _logging_ pada level _node_ merupakan cara yang paling umum dan disarankan untuk klaster Kubernetes. Hal ini karena hanya dibutuhkan satu agen tiap node dan tidak membutuhkan perubahan apapun dari sisi aplikasi yang berjalan pada _node_. Namun, node-level _logging_ hanya dapat dilakukan untuk aplikasi yang menggunakan _standard output_ dan _standard error_. Kubernetes tidak menspesifikasikan khusus suatu agen _logging_, namun ada dua agen _logging_ yang dimasukkan dalam rilis Kubernetes: [Stackdriver Logging](https://kubernetes.io/docs/user-guide/logging/stackdriver) untuk digunakan pada Google Cloud Platform, dan [Elasticsearch](https://kubernetes.io/docs/user-guide/logging/elasticsearch) . Kamu dapat melihat informasi dan instruksi pada masing-masing dokumentasi. Keduanya menggunakan [fluentd](http://www.fluentd.org/) dengan konfigurasi kustom sebagai agen pada _node_. ### Menggunakan kontainer _sidecar_ dengan agen _logging_ Kamu dapat menggunakan kontainer _sidecar_ dengan salah satu cara berikut: * Kontainer _sidecar_ mengeluarkan log aplikasi ke `stdout` miliknya sendiri. * Kontainer _sidecar_ menjalankan agen _logging_ yang dikonfigurasi untuk mengambil log dari aplikasi kontainer. #### Kontainer _streaming_ _sidecar_ ![Kontainer sidecar dengan kontainer streaming](https://kubernetes.io/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) Kamu dapat memanfaatkan kubelet dan agen _logging_ yang telah berjalan pada tiap _node_ dengan menggunakan kontainer _sidecar_. Kontainer _sidecar_ dapat membaca log dari sebuah berkas, _socket_ atau journald. Tiap kontainer _sidecar_ menuliskan log ke `stdout` atau `stderr` mereka sendiri. Dengan menggunakan cara ini kamu dapat memisahkan aliran log dari bagian-bagian yang berbeda dari aplikasimu, yang beberapa mungkin tidak mendukung log ke `stdout` dan `stderr`. Perubahan logika aplikasimu dengan menggunakan cara ini cukup kecil, sehingga hampir tidak ada _overhead_. Selain itu, karena `stdout` dan `stderr` ditangani oleh kubelet, kamu juga dapat menggunakan alat bawaan seperti `kubectl logs`. Sebagai contoh, sebuah pod berjalan pada satu kontainer tunggal, dan kontainer menuliskan ke dua berkas log yang berbeda, dengan dua format yang berbeda pula. Berikut ini _file_ konfigurasi untuk Pod: [`admin/logging/two-files-counter-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/id/examples/admin/logging/two-files-counter-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy admin/logging/two-files-counter-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {} Hal ini akan menyulitkan untuk mengeluarkan log dalam format yang berbeda pada aliran log yang sama, meskipun kamu dapat me-_redirect_ keduanya ke `stdout` dari kontainer. Sebagai gantinya, kamu dapat menggunakan dua buah kontainer _sidecar_. Tiap kontainer _sidecar_ dapat membaca suatu berkas log tertentu dari _shared volume_ kemudian mengarahkan log ke `stdout`\-nya sendiri. Berikut _file_ konfigurasi untuk pod yang memiliki dua buah kontainer _sidecard_: [`admin/logging/two-files-counter-pod-streaming-sidecar.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/id/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy admin/logging/two-files-counter-pod-streaming-sidecar.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox:1.28 args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-log-1 image: busybox:1.28 args: [/bin/sh, -c, 'tail -n+1 -F /var/log/1.log'] volumeMounts: - name: varlog mountPath: /var/log - name: count-log-2 image: busybox:1.28 args: [/bin/sh, -c, 'tail -n+1 -F /var/log/2.log'] volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {} Saat kamu menjalankan pod ini, kamu dapat mengakses tiap aliran log secara terpisah dengan menjalankan perintah berikut: kubectl logs counter count-log-1 0: Mon Jan 1 00:00:00 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001 ... kubectl logs counter count-log-2 Mon Jan 1 00:00:00 UTC 2001 INFO 0 Mon Jan 1 00:00:01 UTC 2001 INFO 1 Mon Jan 1 00:00:02 UTC 2001 INFO 2 ... Agen node-level yang terpasang di klastermu akan mengambil aliran log tersebut secara otomatis tanpa perlu melakukan konfigurasi tambahan. Bahkan jika kamu mau, kamu dapat mengonfigurasi agen untuk melakukan _parse_ baris log tergantung dari kontainer sumber awalnya. Sedikit catatan, meskipun menggunakan memori dan CPU yang cukup rendah (sekitar beberapa milicore untuk CPU dan beberapa megabytes untuk memori), penulisan log ke _file_ kemudian mengalirkannya ke `stdout` dapat berakibat penggunaan disk yang lebih besar. Jika kamu memiliki aplikasi yang menuliskan ke _file_ tunggal, umumnya lebih baik menggunakan `/dev/stdout` sebagai tujuan daripada menggunakan pendekatan dengan kontainer _sidecar_. Kontainer _sidecar_ juga dapat digunakan untuk melakukan rotasi berkas log yang tidak dapat dirotasi oleh aplikasi itu sendiri. Contoh dari pendekatan ini adalah sebuah kontainer kecil yang menjalankan rotasi log secara periodik. Namun, direkomendasikan untuk menggunakan `stdout` dan `stderr` secara langsung dan menyerahkan kebijakan rotasi dan retensi pada kubelet. #### Kontainer _sidecar_ dengan agen _logging_ ![Kontainer sidecar dengan agen logging](https://kubernetes.io/images/docs/user-guide/logging/logging-with-sidecar-agent.png) Jika agen node-level _logging_ tidak cukup fleksible untuk kebutuhanmu, kamu dapat membuat kontainer _sidecar_ dengan agen _logging_ yang terpisah, yang kamu konfigurasi spesifik untuk berjalan dengan aplikasimu. #### Catatan: Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat penggunaan _resource_ yang signifikan. Selain itu, kamu tidak dapat mengakses log itu dengan menggunakan perintah `kubectl logs`, karena mereka tidak dikontrol oleh kubelet. Sebagai contoh, kamu dapat menggunakan [Stackdriver](https://kubernetes.io/docs/tasks/debug-application-cluster/logging-stackdriver/) , yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](https://kubernetes.io/id/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd. [`admin/logging/fluentd-sidecar-config.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/id/examples/admin/logging/fluentd-sidecar-config.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy admin/logging/fluentd-sidecar-config.yaml to clipboard") apiVersion: v1 kind: ConfigMap metadata: name: fluentd-config data: fluentd.conf: | type tail format none path /var/log/1.log pos_file /var/log/1.log.pos tag count.format1 type tail format none path /var/log/2.log pos_file /var/log/2.log.pos tag count.format2 type google_cloud #### Catatan: Konfigurasi fluentd berada diluar cakupan artikel ini. Untuk informasi lebih lanjut tentang cara mengonfigurasi fluentd, silakan lihat [dokumentasi resmi fluentd](http://docs.fluentd.org/) . _File_ yang kedua mendeskripsikan sebuah pod yang memiliki kontainer _sidecar_ yang menjalankan fluentd. Pod ini melakukan _mount_ sebuah volume yang akan digunakan fluentd untuk mengambil data konfigurasinya. [`admin/logging/two-files-counter-pod-agent-sidecar.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/id/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy admin/logging/two-files-counter-pod-agent-sidecar.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-agent image: registry.k8s.io/fluentd-gcp:1.30 env: - name: FLUENTD_ARGS value: -c /etc/fluentd-config/fluentd.conf volumeMounts: - name: varlog mountPath: /var/log - name: config-volume mountPath: /etc/fluentd-config volumes: - name: varlog emptyDir: {} - name: config-volume configMap: name: fluentd-config Setelah beberapa saat, kamu akan mendapati pesan log pada _interface_ Stackdriver. Ingat, ini hanya contoh saja dan kamu dapat mengganti fluentd dengan agen _logging_ lainnya, yang dapat membaca sumber apa saja dari dalam kontainer aplikasi. ### Mengekspos log langsung dari aplikasi ![Mengekspos log langsung dari aplikasi](https://kubernetes.io/images/docs/user-guide/logging/logging-from-application.png) Kamu dapat mengimplementasikan klaster-level _logging_ dengan mengekspos atau mengeluarkan log langsung dari tiap aplikasi; namun cara implementasi mekanisme _logging_ tersebut diluar cakupan dari Kubernetes. 7 - Metrik untuk Komponen Sistem Kubernetes =========================================== Metrik dari komponen sistem dapat memberikan gambaran yang lebih baik tentang apa yang sedang terjadi di dalam sistem. Metrik sangat berguna untuk membuat dasbor (_dashboard_) dan peringatan (_alert_). Komponen Kubernetes mengekspos metrik dalam [format Prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) . Format ini berupa teks biasa yang terstruktur, dirancang agar orang dan mesin dapat membacanya. Metrik-metrik dalam Kubernetes ------------------------------ Dalam kebanyakan kasus, metrik tersedia pada _endpoint_ `/metrics` dari server HTTP. Untuk komponen yang tidak mengekspos _endpoint_ secara bawaan, _endpoint_ tersebut dapat diaktifkan dengan menggunakan opsi `--bind-address`. Contoh-contoh untuk komponen tersebut adalah: * [kube-controller-manager](https://kubernetes.io/id/docs/reference/generated/kube-controller-manager/ "Komponen control plane yang menjalankan pengontrol.") * [kube-proxy](https://kubernetes.io/id/docs/reference/command-line-tools-reference/kube-proxy/ "kube-proxy merupakan proksi jaringan yang berjalan pada setiap node di dalam klaster.") * [kube-apiserver](https://kubernetes.io/id/docs/reference/generated/kube-apiserver/ "Komponen control plane yang mengekspos API Kubernetes. Merupakan front-end dari control plane Kubernetes.") * [kube-scheduler](https://kubernetes.io/id/docs/reference/generated/kube-scheduler/ "Komponen control plane yang bertugas mengamati Pod baru yang belum ditempatkan di node manapun dan kemudian memilihkan node di mana Pod baru tersebut akan dijalankan.") * [kubelet](https://kubernetes.io/id/docs/reference/generated/kubelet "Agen yang dijalankan pada setiap node di klaster yang bertugas untuk memastikan kontainer dijalankan di dalam Pod.") Di dalam lingkungan produksi, kamu mungkin ingin mengonfigurasi [Server Prometheus](https://prometheus.io/) atau pengambil metrik (_metrics scraper_) lainnya untuk mengumpulkan metrik-metrik ini secara berkala dan membuatnya tersedia dalam semacam pangkalan data deret waktu (_time series database_). Perlu dicatat bahwa [kubelet](https://kubernetes.io/id/docs/reference/generated/kubelet "Agen yang dijalankan pada setiap node di klaster yang bertugas untuk memastikan kontainer dijalankan di dalam Pod.") juga mengekspos metrik pada _endpoint-endpoint_ seperti `/metrics/cadvisor`, `/metrics/resource` dan `/metrics/probes`. Metrik-metrik tersebut tidak memiliki siklus hidup yang sama. Jika klastermu menggunakan [RBAC](https://kubernetes.io/id/docs/reference/access-authn-authz/rbac/ "Mengelola keputusan otorisasi, memungkinkan admin untuk mengonfigurasi kebijakan akses secara dinamis melalui API Kubernetes.") , maka membaca metrik memerlukan otorisasi melalui _user_, _group_, atau ServiceAccount dengan ClusterRole yang memperbolehkan untuk mengakses `/metrics`. Sebagai contoh: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus rules: - nonResourceURLs: - "/metrics" verbs: - get Siklus hidup metrik ------------------- Metrik alfa (_alpha_) → Metrik stabil → Metrik usang (_deprecated_) → Metrik tersembunyi → Metrik terhapus Metrik alfa tidak memiliki jaminan stabilitas. Metrik ini dapat dimodifikasi atau dihapus kapan saja. Metrik stabil dijamin tidak akan mengalami perubahan. Hal ini berarti: * Metrik stabil tanpa penanda usang (_deprecated signature_) tidak akan dihapus ataupun diganti namanya * Jenis metrik stabil tidak akan dimodifikasi Metrik usang dijadwalkan untuk dihapus, tetapi masih tersedia untuk digunakan. Metrik ini mencakup anotasi versi di mana metrik ini dianggap menjadi usang. Sebagai contoh: * Sebelum menjadi usang # HELP some_counter this counts things # TYPE some_counter counter some_counter 0 * Setelah menjadi usang # HELP some_counter (Deprecated since 1.15.0) this counts things # TYPE some_counter counter some_counter 0 Metrik tersembunyi tidak lagi dipublikasikan untuk pengambilan metrik (_scraping_), tetapi masih tersedia untuk digunakan. Untuk menggunakan metrik tersembunyi, lihat bagian [Menampilkan metrik tersembunyi](https://kubernetes.io/id/docs/concepts/cluster-administration/_print/#menampilkan-metrik-tersembunyi) . Metrik yang terhapus tidak lagi dipublikasikan dan tidak dapat digunakan lagi. Menampilkan metrik tersembunyi ------------------------------ Seperti yang dijelaskan di atas, admin dapat mengaktifkan metrik tersembunyi melalui opsi baris perintah pada biner (program) tertentu. Ini dimaksudkan untuk digunakan sebagai jalan keluar bagi admin jika mereka melewatkan migrasi metrik usang dalam rilis terakhir. Opsi `show-hidden-metrics-for-version` menerima input versi yang kamu inginkan untuk menampilkan metrik usang dalam rilis tersebut. Versi tersebut dinyatakan sebagai x.y, di mana x adalah versi mayor, y adalah versi minor. Versi _patch_ tidak diperlukan meskipun metrik dapat menjadi usang dalam rilis _patch_, alasannya adalah kebijakan penandaan metrik usang dijalankan terhadap rilis minor. Opsi tersebut hanya dapat menerima input versi minor sebelumnya sebagai nilai. Semua metrik yang disembunyikan di versi sebelumnya akan dikeluarkan jika admin mengatur versi sebelumnya ke `show-hidden-metrics-for-version`. Versi yang terlalu lama tidak diperbolehkan karena melanggar kebijakan untuk metrik usang. Ambil metrik `A` sebagai contoh, di sini diasumsikan bahwa `A` sudah menjadi usang di versi 1.n. Berdasarkan kebijakan metrik usang, kita dapat mencapai kesimpulan berikut: * Pada rilis `1.n`, metrik menjadi usang, dan dapat dikeluarkan secara bawaan. * Pada rilis `1.n+1`, metrik disembunyikan secara bawaan dan dapat dikeluarkan dengan baris perintah `show-hidden-metrics-for-version=1.n`. * Pada rilis `1.n+2`, metrik harus dihapus dari _codebase_. Tidak ada jalan keluar lagi. Jika kamu meningkatkan versi dari rilis `1.12` ke `1.13`, tetapi masih bergantung pada metrik `A` yang usang di `1.12`, kamu harus mengatur metrik tersembunyi melalui baris perintah: `--show-hidden-metrics = 1.12` dan ingatlah untuk menghapus ketergantungan terhadap metrik ini sebelum meningkatkan versi rilis ke `1.14`. Menonaktifkan metrik akselerator -------------------------------- kubelet mengumpulkan metrik akselerator melalui cAdvisor. Untuk mengumpulkan metrik ini, untuk akselerator seperti GPU NVIDIA, kubelet membuka koneksi dengan _driver_ GPU. Ini berarti untuk melakukan perubahan infrastruktur (misalnya, pemutakhiran _driver_), administrator klaster perlu menghentikan agen kubelet. Pengumpulkan metrik akselerator sekarang menjadi tanggung jawab vendor dibandingkan kubelet. Vendor harus menyediakan sebuah kontainer untuk mengumpulkan metrik dan mengeksposnya ke layanan metrik (misalnya, Prometheus). [Gerbang fitur `DisableAcceleratorUsageMetrics`](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) menonaktifkan metrik yang dikumpulkan oleh kubelet, dengan [lini masa (_timeline_) untuk mengaktifkan fitur ini secara bawaan](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria) . Metrik komponen --------------- ### Metrik kube-controller-manager Metrik _controller manager_ memberikan gambaran penting tentang kinerja dan kesehatan _controller manager_. Metrik ini mencakup metrik _runtime_ bahasa Go yang umum seperti jumlah go\_routine dan metrik khusus pengontrol seperti latensi permintaan etcd atau latensi API Cloudprovider (AWS, GCE, OpenStack) yang dapat digunakan untuk mengukur kesehatan klaster. Mulai dari Kubernetes 1.7, metrik Cloudprovider yang detail tersedia untuk operasi penyimpanan untuk GCE, AWS, Vsphere, dan OpenStack. Metrik ini dapat digunakan untuk memantau kesehatan operasi _persistent volume_. Misalnya, untuk GCE metrik-metrik berikut ini dipanggil: cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ### Metrik kube-scheduler FEATURE STATE: `Kubernetes v1.20 [alpha]` Penjadwal mengekspos metrik opsional yang melaporkan sumber daya yang diminta dan limit yang diinginkan dari semua pod yang berjalan. Metrik ini dapat digunakan untuk membangun dasbor perencanaan kapasitas, mengevaluasi limit penjadwalan yang digunakan saat ini atau secara historis, dengan cepat mengidentifikasi beban kerja yang tidak dapat dijadwalkan karena kurangnya sumber daya, dan membandingkan permintaan sumber daya oleh pod dengan penggunaannya yang aktual. kube-scheduler mengidentifikasi [permintaan dan limit](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) sumber daya yang dikonfigurasi untuk setiap Pod; jika permintaan atau limit bukan nol, kube-scheduler akan melaporkan deret waktu (_timeseries_) metrik. Deret waktu diberi label dengan: * namespace * nama pod * node di mana pod dijadwalkan atau _string_ kosong jika belum dijadwalkan * prioritas * penjadwal yang ditugaskan untuk pod itu * nama dari sumber daya (misalnya, `cpu`) * satuan dari sumber daya jika diketahui (misalnya, `cores`) Setelah pod selesai (memiliki `restartPolicy` `Never` atau `OnFailure` dan berada dalam fase pod `Succeeded` atau `Failed`, atau telah dihapus dan semua kontainer dalam keadaan Terminated) deret metrik tidak lagi dilaporkan karena penjadwal sekarang sudah dibebaskan untuk menjadwalkan pod lain untuk dijalankan. Metrik yang dibahas pada bagian ini dikenal sebagai `kube_pod_resource_request` dan `kube_pod_resource_limit`. Metrik diekspos melalui _endpoint_ HTTP `/metrics/resources` dan memerlukan otorisasi yang sama seperti endpoint `/metrics` pada penjadwal. Kamu harus menggunakan opsi `--show-hidden-metrics-for-version=1.20` untuk mengekspos metrik-metrik stabilitas alfa ini. Selanjutnya ----------- * Baca tentang [format teks Prometheus](https://github.com/prometheus/docs/blob/main/docs/instrumenting/exposition_formats.md#text-based-format) untuk berbagai metrik * Baca tentang [kebijakan _deprecation_ Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) 8 - Konfigurasi Garbage Collection pada kubelet =============================================== _Garbage collection_ merupakan fitur kubelet yang sangat bermanfaat, yang akan membersihkan _image-image_ dan juga kontainer-kontainer yang tidak lagi digunakan. Kubelet akan melakukan _garbage collection_ untuk kontainer setiap satu menit dan _garbage collection_ untuk _image_ setiap lima menit. Perangkat _garbage collection_ eksternal tidak direkomendasikan karena perangkat tersebut berpotensi merusak perilaku kubelet dengan menghilangkan kontainer-kontainer yang sebenarnya masih diperlukan. _Garbage Collection_ untuk _Image_ ---------------------------------- Kubernetes mengelola _lifecycle_ untuk seluruh _image_ melalui _imageManager_, dengan bantuan cadvisor. _Policy_ untuk melakukan _garbage collection_ memperhatikan dua hal: `HighThresholdPercent` dan `LowThresholdPercent`. Penggunaan disk yang melewati batas atas (_high threshold_) akan men-_trigger_ _garbage collection_. _Garbage collection_ akan mulai menghapus dari _image-image_ yang paling jarang digunakan (_least recently used_) sampai menemui batas bawah (_low threshold_) kembali. _Garbage Collection_ untuk Kontainer ------------------------------------ _Policy_ untuk melakukan _garbage collection_ pada kontainer memperhatikan tiga variabel yang ditentukan oleh pengguna (_user-defined_). `MinAge` merupakan umur minimal dimana suatu kontainer dapat terkena _garbage collection_. `MaxPerPodContainer` merupakan jumlah maksimum yang diperbolehkan untuk setiap pod (UID, container name) _pair_ memiliki kontainer-kontainer yang sudah mati (_dead containers_). `MaxContainers` merupakan jumlah maksimal total dari seluruh kontainer yang sudah mati. Semua variabel ini dapat dinonaktifkan secara individual, dengan mengatur `MinAge` ke angka nol serta mengatur `MaxPerPodContainer` dan `MaxContainers` ke angka di bawah nol. Kubelet akan mengambil tindakan untuk kontainer-kontainer yang tidak dikenal, sudah dihapus, atau diluar batasan-batasan yang diatur sebelumnya melalui _flag_. Kontainer-kontainer yang paling lama (tertua) biasanya akan dihapus terlebih dahulu. `MaxPerPodContainer` dan `MaxContainer` berpotensi mengalami konflik satu sama lain pada situasi saat menjaga jumlah maksimal kontainer per pod (`MaxPerPodContainer`) akan melebihi jumlah kontainer mati (_dead containers_) yang diperbolehkan (`MaxContainers`). `MaxPerPodContainer` dapat diatur sedemikian rupa dalam situasi ini: Seburuk-buruhknya dengan melakukan _downgrade_ `MaxPerPodContainer` ke angka 1 dan melakukan _evict_ kontainer-kontainer yang paling lama. Selain itu, kontainer-kontainer milik Pod yang telah dihapus akan dihilangkan saat umur mereka telah melebihi `MinAge`. Kontainer-kontainer yang tidak dikelola oleh kubelet akan terbebas dari _garbage collection_. Konfigurasi Pengguna -------------------- Para pengguna dapat mengatur _threshold-threshold_ untuk melakukan _tuning_ pada _garbage collection image_ melalui _flag-flag_ kubelet sebagai berikut: 1. `image-gc-high-threshold`, persentase dari penggunaan disk yang men-_trigger_ proses _garbage collection_ untuk _image_. _Default_\-nya adalah 85%. 2. `image-gc-low-threshold`, persentase dari penggunaan disk dimana _garbage collection_ berusaha menghapus _image_. _Default_\-nya adalah 80%. Kami juga memperbolehkan para pengguna untuk menyesuaikan _policy garbage collection_ melalui _flag-flag_ kubelet sebagai berikut: 1. `minimum-container-ttl-duration`, umur minimal untuk setiap kontainer yang sudah selesai (_finished_) sebelum terkena _garbage collection_. _Default_\-nya adalah 0 menit, yang berarti setiap kontainer yang telah selesai akan terkena _garbage collection_. 2. `maximum-dead-containers-per-container`, jumlah maksimal dari kontainer-kontainer lama yang diperbolehkan ada secara global. _Default_\-nya adalah -1, yang berarti tidak ada batasannya untuk global. Kontainer-kontainer dapat berpotensi terkena _garbage collection_ sebelum kegunaannya telah usang. Kontainer-kontainer ini memliki log dan data lainnya yang bisa saja berguna saat _troubleshoot_. Sangat direkomendasikan untuk menetapkan angka yang cukup besar pada `maximum-dead-containers-per-container`, untuk memperbolehkan paling tidak 1 kontainer mati untuk dijaga (_retained_) per jumlah kontainer yang diharapkan. Angka yang lebih besar untuk `maximum-dead-containers` juga direkomendasikan untuk alasan serupa. Lihat [isu ini](https://github.com/kubernetes/kubernetes/issues/13287) untuk penjelasan lebih lanjut. _Deprecation_ ------------- Beberapa fitur _Garbage Collection_ pada kubelet di laman ini akan digantikan oleh fitur _eviction_ nantinya, termasuk: | _Flag Existing_ | _Flag_ Baru | Alasan | | --- | --- | --- | | `--image-gc-high-threshold` | `--eviction-hard` atau `--eviction-soft` | sinyal _eviction_ yang ada (_existing_) dapat men-_trigger_ _garbage collection_ | | `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | hal serupa dapat diperoleh dengan _eviction reclaim_ | | `--maximum-dead-containers` | | _deprecated_ saat log yang telah usang tersimpan di luar konteks kontainer | | `--maximum-dead-containers-per-container` | | _deprecated_ saat log yang telah usang tersimpan di luar konteks kontainer | | `--minimum-container-ttl-duration` | | _deprecated_ saat log yang telah usang tersimpan di luar konteks kontainer | | `--low-diskspace-threshold-mb` | `--eviction-hard` atau `eviction-soft` | _eviction_ memberi generalisasi _threshold_ disk untuk _resource-resource_ lainnya | | `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | _eviction_ memberi generalisasi transisi tekanan _disk_ (_disk pressure_)untuk _resource-resource_ lainnya | Selanjutnya ----------- Lihat [Konfigurasi untuk Menangani Kehabisan _Resource_](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/) untuk penjelasan lebih lanjut. 9 - Berbagai Proxy di Kubernetes ================================ Laman ini menjelaskan berbagai _proxy_ yang ada di dalam Kubernetes. Berbagai Jenis _Proxy_ ---------------------- Ada beberapa jenis _proxy_ yang akan kamu temui saat menggunakan Kubernetes: 1. [kubectl proxy](https://kubernetes.io/id/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api) : * dijalankan pada _desktop_ pengguna atau di dalam sebuah Pod * melakukan _proxy_ dari alamat localhost ke apiserver Kubernetes * dari klien menuju _proxy_ menggunakan HTTP * dari _proxy_ menuju apiserver menggunakan HTTPS * mencari lokasi apiserver * menambahkan _header_ autentikasi 2. [apiserver proxy](https://kubernetes.io/id/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services) : * merupakan sebuah _bastion_ yang ada di dalam apiserver * menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau * dijalankan bersama _process-process_ apiserver * dari klien menuju _proxy_ menggunakan HTTPS (atau http jika dikonfigurasi pada apiserver) * dari _proxy_ menuju target menggunakan HTTP atau HTTPS, tergantung pilihan yang diambil oleh _proxy_ melalui informasi yang ada * dapat digunakan untuk menghubungi Node, Pod, atau Service * melakukan _load balancing_ saat digunakan untuk menjangkau sebuah Service 3. [kube proxy](https://kubernetes.io/id/docs/concepts/services-networking/service/#ips-and-vips) : * dijalankan pada setiap Node * melakukan _proxy_ untuk UDP, TCP dan SCTP * tidak mengerti HTTP * menyediakan _load balancing_ * hanya digunakan untuk menjangkau berbagai Service 4. Sebuah _Proxy/Load-balancer_ di depan satu atau banyak apiserver: * keberadaan dan implementasinya bervariasi tergantung pada klaster (contohnya nginx) * ada di antara seluruh klien dan satu/banyak apiserver * jika ada beberapa apiserver, berfungsi sebagai _load balancer_ 5. _Cloud Load Balancer_ pada servis eksternal: * disediakan oleh beberapa penyedia layanan cloud, seperti AWS ELB, Google Cloud Load Balancer * dibuat secara otomatis ketika Service dari Kubernetes dengan tipe `LoadBalancer` * biasanya hanya tersedia untuk UDP/TCP * _support_ untuk SCTP tergantung pada _load balancer_ yang diimplementasikan oleh penyedia cloud * implementasi bervariasi tergantung pada penyedia cloud Pengguna Kubernetes biasanya hanya cukup perlu tahu tentang kubectl _proxy_ dan apiserver _proxy_. Untuk _proxy-proxy_ lain di luar ini, admin klaster biasanya akan memastikan konfigurasinya dengan benar. Melakukan _request redirect_ ---------------------------- _Proxy_ telah menggantikan fungsi _redirect_. _Redirect_ telah terdeprekasi. 10 - Metrik controller manager ============================== Metrik _controller manager_ memberikan informasi penting tentang kinerja dan kesehatan dari _controller manager_. Tentang metrik _controller manager_ ----------------------------------- Metrik _controller manager_ ini berfungsi untuk memberikan informasi penting tentang kinerja dan kesehatan dari _controller manager_. Metrik ini juga berisi tentang metrik umum dari _runtime_ bahasa pemrograman Go seperti jumlah _go\_routine_ dan metrik spesifik dari _controller_ seperti latensi dari etcd _request_ atau latensi API dari penyedia layanan _cloud_ (AWS, GCE, OpenStack) yang dapat digunakan untuk mengukur kesehatan dari klaster. Mulai dari Kubernetes 1.7, metrik yang lebih mendetil tentang operasi penyimpanan dari penyedia layanan _cloud_ juga telah tersedia. Metrik-metrik ini dapat digunakan untuk memonitor kesehatan dari operasi _persistent volume_. Berikut merupakan contoh nama metrik yang disediakan GCE: cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} Konfigurasi ----------- Pada sebuah klaster, informasi metrik _controller manager_ dapat diakses melalui `http://localhost:10252/metrics` dari _host_ tempat _controller manager_ dijalankan. Metrik ini dikeluarkan dalam bentuk [format prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) serta mudah untuk dibaca manusia. Pada _environment_ produksi, kamu mungkin juga ingin mengonfigurasi prometheus atau pengumpul metrik lainnya untuk mengumpulkan metrik-metrik ini secara berkala dalam bentuk basis data _time series_. 11 - Instalasi Add-ons ====================== _Add-ons_ berfungsi untuk menambah serta memperluas fungsionalitas dari Kubernetes. Laman ini akan menjabarkan beberapa _add-ons_ yang tersedia serta tautan instruksi bagaimana cara instalasi masing-masing _add-ons_. _Add-ons_ pada setiap bagian akan diurutkan secara alfabet - pengurutan ini tidak dilakukan berdasarkan status preferensi atau keunggulan. Jaringan dan _Policy_ Jaringan ------------------------------ * [ACI](https://www.github.com/noironetworks/aci-containers) menyediakan integrasi jaringan kontainer dan keamanan jaringan dengan Cisco ACI. * [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) merupakan penyedia jaringan L3 yang aman dan _policy_ jaringan. * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) menggabungkan Flannel dan Calico, menyediakan jaringan serta _policy_ jaringan. * [Cilium](https://github.com/cilium/cilium) merupakan _plugin_ jaringan L3 dan _policy_ jaringan yang dapat menjalankan _policy_ HTTP/API/L7 secara transparan. Mendukung mode _routing_ maupun _overlay/encapsulation_. * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam _plugin_ CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus. * [Contiv](https://contivpp.io/) menyediakan jaringan yang dapat dikonfigurasi (_native_ L3 menggunakan BGP, _overlay_ menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta _policy framework_ yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](https://github.com/contiv) . Laman [instalasi](https://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk klaster dengan kubeadm maupun non-kubeadm. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) , yang berbasis dari [Tungsten Fabric](https://tungsten.io/) , merupakan sebuah proyek _open source_ yang menyediakan virtualisasi jaringan _multi-cloud_ serta platform manajemen _policy_. Contrail dan Tungsten Fabric terintegrasi dengan sistem orkestrasi lainnya seperti Kubernetes, OpenShift, OpenStack dan Mesos, serta menyediakan mode isolasi untuk mesin virtual (VM), kontainer/pod dan _bare metal_. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) merupakan penyedia jaringan _overlay_ yang dapat digunakan pada Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) merupakan solusi jaringan yang mendukung multipel jaringan pada Kubernetes. * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) merupakan sebuah multi _plugin_ agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua _plugin_ CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada _workload_ Kubernetes. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti _Pivotal Container Service_ (PKS) dan OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan _policy-based_ jaringan antara Kubernetes Pods dan non-Kubernetes _environment_ dengan _monitoring_ visibilitas dan keamanan. * [Romana](http://romana.io/) merupakan solusi jaringan _Layer_ 3 untuk jaringan pod yang juga mendukung [_NetworkPolicy_ API](https://kubernetes.io/id/docs/concepts/services-networking/network-policies/) . Instalasi Kubeadm _add-on_ ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize) . * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta _policy_ jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal. _Service Discovery_ ------------------- * [CoreDNS](https://coredns.io/) merupakan server DNS yang fleksibel, mudah diperluas yang dapat [diinstal](https://github.com/coredns/helm) sebagai _in-cluster_ DNS untuk pod. Visualisasi & Kontrol --------------------- * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) merupakan antarmuka web dasbor untuk Kubernetes. _Add-ons_ Terdeprekasi ---------------------- Ada beberapa _add-on_ lain yang didokumentasikan pada direktori deprekasi [_cluster/addons_](https://git.k8s.io/kubernetes/cluster/addons) . _Add-on_ lain yang dipelihara dan dikelola dengan baik dapat ditulis di sini. Ditunggu PR-nya! 12 - Prioritas dan Kesetaraan API (API Priority and Fairness) ============================================================= FEATURE STATE: `Kubernetes v1.18 [alpha]` Mengontrol perilaku server API dari Kubernetes pada situasi beban berlebih merupakan tugas utama dari administrator klaster. [kube-apiserver](https://kubernetes.io/id/docs/reference/generated/kube-apiserver/ "Komponen control plane yang mengekspos API Kubernetes. Merupakan front-end dari control plane Kubernetes.") memiliki beberapa kontrol yang tersedia (seperti opsi `--max-request-inflight` dan `--max-mutating-request-inflight` pada baris perintah atau _command-line_) untuk membatasi jumlah pekerjaan luar biasa yang akan diterima, untuk mencegah banjirnya permintaan masuk dari beban berlebih yang berpotensi untuk menghancurkan server API. Namun opsi ini tidak cukup untuk memastikan bahwa permintaan yang paling penting dapat diteruskan pada saat kondisi lalu lintas (_traffic_) yang cukup tinggi. Fitur Prioritas dan Kesetaraan API atau _API Priority and Fairness_ (APF) adalah alternatif untuk meningkatkan batasan _max-inflight_ seperti yang disebutkan di atas. APF mengklasifikasi dan mengisolasi permintaan dengan cara yang lebih halus. Fitur ini juga memperkenalkan jumlah antrian yang terbatas, sehingga tidak ada permintaan yang ditolak pada saat terjadi lonjakan permintaan dalam waktu yang sangat singkat. Permintaan dibebaskan dari antrian dengan menggunakan teknik antrian yang adil (_fair queuing_) sehingga, sebagai contoh, perilaku buruk dari satu [controller](https://kubernetes.io/id/docs/concepts/architecture/controller/ "Kontrol tertutup yang mengawasi kondisi bersama dari klaster melalui apiserver dan membuat perubahan yang mencoba untuk membawa kondisi saat ini ke kondisi yang diinginkan.") tidak seharusnya mengakibatkan _controller_ yang lain menderita (meskipun pada tingkat prioritas yang sama). #### Perhatian: Permintaan yang diklasifikasikan sebagai "long running" - terutama _watch_ - tidak mengikuti filter prioritas dan kesetaraan API. Dimana ini juga berlaku pada opsi `--max-request-inflight` tanpa mengaktifkan APF. Mengaktifkan prioritas dan kesetaraan API ----------------------------------------- Fitur APF dikontrol oleh sebuah gerbang fitur (_feature gate_) dan fitur ini tidak diaktifkan secara bawaan. Silahkan lihat [gerbang fitur](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) untuk penjelasan umum tentang gerbang fitur dan bagaimana cara mengaktifkan dan menonaktifkannya. Nama gerbang fitur untuk APF adalah "APIPriorityAndFairness". Fitur ini melibatkan sebuah [Grup API](https://kubernetes.io/id/docs/concepts/overview/kubernetes-api/#api-groups "Sekumpulan path terkait pada API Kubernetes.") yang harus juga diaktifkan. Kamu bisa melakukan ini dengan menambahkan opsi pada baris perintah berikut pada permintaan ke `kube-apiserver` kamu: kube-apiserver \ --feature-gates=APIPriorityAndFairness=true \ --runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true \ # …dan opsi-opsi lainnya seperti biasa Opsi pada baris perintah `--enable-priority-and-fairness=false` akan menonaktifkan fitur APF, bahkan ketika opsi yang lain telah mengaktifkannya. Konsep ------ Ada beberapa fitur lainnya yang terlibat dalam fitur APF. Permintaan yang masuk diklasifikasikan berdasarkan atribut permintaan dengan menggunakan FlowSchema, dan diserahkan ke tingkat prioritas. Tingkat prioritas menambahkan tingkat isolasi dengan mempertahankan batas konkurensi yang terpisah, sehingga permintaan yang diserahkan ke tingkat prioritas yang berbeda tidak dapat membuat satu sama lain menderita. Dalam sebuah tingkat prioritas, algoritma _fair-queuing_ mencegah permintaan dari _flows_ yang berbeda akan memberikan penderitaan kepada yang lainnya, dan memperbolehkan permintaan untuk dimasukkan ke dalam antrian untuk mencegah pelonjakan lalu lintas yang akan menyebabkan gagalnya permintaan, walaupun pada saat beban rata-ratanya cukup rendah. ### Tingkat prioritas (_Priority Level_) Tanpa pengaktifan APF, keseluruhan konkurensi dalam server API dibatasi oleh opsi pada `kube-apiserver` `--max-request-inflight` dan `--max-mutating-request-inflight`. Dengan pengaktifan APF, batas konkurensi yang ditentukan oleh opsi ini akan dijumlahkan dan kemudian jumlah tersebut dibagikan untuk sekumpulan tingkat prioritas (_priority level_) yang dapat dikonfigurasi. Setiap permintaan masuk diserahkan ke sebuah tingkat prioritas, dan setiap tingkat prioritas hanya akan meneruskan sebanyak mungkin permintaan secara bersamaan sesuai dengan yang diijinkan dalam konfigurasi. Konfigurasi bawaan, misalnya, sudah mencakup tingkat prioritas terpisah untuk permintaan dalam rangka pemilihan pemimpin (_leader-election_), permintaan dari _controller_ bawaan, dan permintaan dari Pod. Hal ini berarti bahwa Pod yang berperilaku buruk, yang bisa membanjiri server API dengan permintaan, tidak akan mampu mencegah kesuksesan pemilihan pemimpin atau tindakan yang dilakukan oleh _controller_ bawaan. ### Antrian (_Queuing_) Bahkan dalam sebuah tingkat prioritas mungkin akan ada sumber lalu lintas yang berbeda dalam jumlah besar. Dalam situasi beban berlebih, sangat penting untuk mencegah satu aliran permintaan dari penderitaan karena aliran yang lainnya (khususnya, dalam kasus yang relatif umum dari sebuah klien tunggal bermasalah (_buggy_) yang dapat membanjiri _kube-apiserver_ dengan permintaan, klien bermasalah itu idealnya tidak memiliki banyak dampak yang bisa diukur terhadap klien yang lainnya). Hal ini ditangani dengan menggunakan algoritma _fair-queuing_ untuk memproses permintaan yang diserahkan oleh tingkat prioritas yang sama. Setiap permintaan diserahkan ke sebuah _flow_, yang diidentifikasi berdasarkan nama FlowSchema yang sesuai, ditambah dengan _flow distinguisher_ - yang bisa saja didasarkan pada pengguna yang meminta, sumber daya Namespace dari target, atau tidak sama sekali - dan sistem mencoba untuk memberikan bobot yang hampir sama untuk permintaan dalam _flow_ yang berbeda dengan tingkat prioritas yang sama. Setelah mengklasifikasikan permintaan ke dalam sebuah _flow_, fitur APF kemudian dapat menyerahkan permintaan ke dalam sebuah antrian. Penyerahan ini menggunakan teknik yang dikenal sebagai [\_shuffle sharding\_](https://kubernetes.io/id/docs/reference/glossary/?all=true#term-shuffle-sharding "A technique for assigning requests to queues that provides better isolation than hashing modulo the number of queues.") , yang membuat penggunaan antrian yang relatif efisien untuk mengisolasi _flow_ dengan intensitas rendah dari _flow_ dengan intensitas tinggi. Detail dari algoritma antrian dapat disesuaikan untuk setiap tingkat prioritas, dan memperbolehkan administrator untuk menukar (_trade off_) dengan penggunaan memori, kesetaraan (properti dimana _flow_ yang independen akan membuat semua kemajuan ketika total dari lalu lintas sudah melebihi kapasitas), toleransi untuk lonjakan lalu lintas, dan penambahan latensi yang dihasilkan oleh antrian. ### Permintaan yang dikecualikan (_Exempt Request_) Beberapa permintaan dianggap cukup penting sehingga mereka tidak akan mengikuti salah satu batasan yang diberlakukan oleh fitur ini. Pengecualian ini untuk mencegah konfigurasi _flow control_ yang tidak terkonfigurasi dengan baik sehingga tidak benar-benar menonaktifkan server API. Bawaan (_Default_) ------------------ Fitur APF dikirimkan dengan konfigurasi yang disarankan dimana konfigurasi itu seharusnya cukup untuk bereksperimen; jika klaster kamu cenderung mengalami beban berat maka kamu harus mempertimbangkan konfigurasi apa yang akan bekerja paling baik. Kelompok konfigurasi yang disarankan untuk semua permintaan terbagi dalam lima prioritas kelas: * Tingkat prioritas `system` diperuntukkan bagi permintaan dari grup `system:nodes`, mis. Kubelet, yang harus bisa menghubungi server API agar mendapatkan _workload_ untuk dijadwalkan. * Tingkat prioritas `leader-election` diperuntukkan bagi permintaan dalam pemilihan pemimpin (_leader election_) dari _controller_ bawaan (khususnya, permintaan untuk `endpoint`, `configmaps`, atau `leases` yang berasal dari `system:kube-controller-manager` atau pengguna `system:kube-scheduler` dan akun Service di Namespace `kube-system`). Hal ini penting untuk mengisolasi permintaan ini dari lalu lintas yang lain karena kegagalan dalam pemilihan pemimpin menyebabkan _controller_ akan gagal dan memulai kembali (_restart_), yang pada akhirnya menyebabkan lalu lintas yang lebih mahal karena _controller_ yang baru perlu menyinkronkan para informannya. * Tingkat prioritas `workload-high` diperuntukkan bagi permintaan yang lain dari _controller_ bawaan.    * Tingkat prioritas `workload-low` diperuntukkan bagi permintaan dari akun Service yang lain, yang biasanya mencakup semua permintaan dari _controller_ yang bekerja didalam Pod.    * Tingkat prioritas `global-default` menangani semua lalu lintas lainnya, mis. perintah interaktif `kubectl` yang dijalankan oleh pengguna yang tidak memiliki hak khusus. Kemudian, ada dua PriorityLevelConfiguration dan dua FlowSchema yang telah dibangun dan tidak mungkin ditimpa ulang: * Tingkat prioritas khusus `exempt` diperuntukkan bagi permintaan yang tidak akan dikenakan _flow control_ sama sekali: permintaan itu akan selalu diteruskan sesegera mungkin. FlowSchema `exempt` khusus mengklasifikasikan semua permintaan dari kelompok `system:masters` ke dalam tingkat prioritas khusus ini. Kamu juga dapat menentukan FlowSchema lain yang mengarahkan permintaan lain ke tingkat prioritas ini juga, apabila permintaan tersebut sesuai. * Tingkat prioritas khusus `catch-all` digunakan secara kombinasi dengan spesial FlowSchema `catch-all` untuk memastikan bahwa setiap permintaan mendapatkan proses klasifikasi. Biasanya kamu tidak harus bergantung pada konfigurasi _catch-all_ ini, dan kamu seharusnya membuat FlowSchema _catch-all_ dan PriorityLevelConfiguration kamu sendiri (atau gunakan konfigurasi `global-default` yang sudah diinstal secara bawaan) secara benar. Untuk membantu menemukan kesalahan konfigurasi yang akan melewatkan beberapa klasifikasi permintaan, maka tingkat prioritas `catch-all` hanya wajib mengijinkan satu konkurensi bersama dan tidak melakukan memasukkan permintaan dalam antrian, sehingga membuat lalu lintas yang secara relatif hanya sesuai dengan FlowSchema `catch-all` akan ditolak dengan kode kesalahan HTTP 429. Sumber daya (_Resource_) ------------------------ _Flow control_ API melibatkan dua jenis sumber daya. [PriorityLevelConfiguration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) yang menentukan kelas isolasi yang tersedia, bagian dari konkurensi anggaran yang tersedia yang masing-masing dapat menangani bagian tersebut, dan memperbolehkan untuk melakukan _fine-tuning_ terhadap perilaku antrian. [FlowSchema](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io) yang digunakan untuk mengklasifikasikan permintaan individu yang masuk, mencocokkan masing-masing dengan setiap PriorityLevelConfiguration. ### PriorityLevelConfiguration Sebuah PriorityLevelConfiguration merepresentasikan sebuah kelas isolasi tunggal. Setiap PriorityLevelConfiguration memiliki batas independensi dalam hal jumlah permintaan yang belum diselesaikan, dan batasan dalam hal jumlah permintaan yang mengantri. Batas konkurensi untuk PriorityLevelConfiguration tidak disebutkan dalam jumlah permintaan secara mutlak, melainkan dalam "concurrency shares." Total batas konkurensi untuk server API didistribusikan di antara PriorityLevelConfiguration yang ada secara proporsional dengan "concurrency shares" tersebut. Ini mengizinkan seorang administrator klaster untuk meningkatkan atau menurunkan jumlah total lalu lintas ke sebuah server dengan memulai kembali `kube-apiserver` dengan nilai opsi `--max-request-inflight` (atau `--max-mutating-request-inflight`) yang berbeda, dan semua PriorityLevelConfiguration akan melihat konkurensi maksimum yang diizinkan kepadanya untuk menaikkan (atau menurunkan) dalam fraksi yang sama. #### Perhatian: Dengan fitur Prioritas dan Kesetaraan yang diaktifkan, batas total konkurensi untuk server diatur pada nilai penjumlahan dari `--max-request-inflight` dan `--max-mutating-request-inflight`. Tidak akan ada lagi perbedaan antara permintaan yang bermutasi dan permintaan yang tidak bermutasi; jika kamu ingin melayaninya secara terpisah untuk suatu sumber daya yang ada, maka perlu membuat FlowSchema terpisah yang sesuai dengan masing-masing kata kerja dari permintaan yang bermutasi dan yang tidak bermutasi tersebut. Ketika jumlah permintaan masuk yang diserahkan kepada sebuah PriorityLevelConfiguration melebihi dari tingkat konkurensi yang diizinkan, bagian `type` dari spesifikasinya menentukan apa yang akan terjadi pada permintaan selanjutnya. Tipe `Reject` berarti bahwa kelebihan lalu lintas akan segera ditolak dengan kode kesalahan HTTP 429 (yang artinya terlalu banyak permintaan). Tipe `Queue` berarti permintaan di atas batas tersebut akan mengantri, dengan teknik _sharding shuffle_ dan _fair queuing_ yang digunakan untuk menyelaraskan kemajuan antara _flow_ permintaan. Konfigurasi antrian memungkinkan mengatur algoritma _fair queuing_ untuk sebuah tingkat prioritas. Detail algoritma dapat dibaca di [proposal pembaharuan](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness) , namun secara singkat: * Meningkatkan `queue` (antrian) berarti mengurangi tingkat tabrakan antara _flow_ yang berbeda, sehingga berakibat pada biaya untuk meningkatkan penggunaan memori. Nilai 1 di sini secara efektif menonaktifkan logika _fair-queuing_, tetapi masih mengizinkan permintaan untuk dimasukkan kedalam antrian. * Meningkatkan `queueLengthLimit` berarti memperbolehkan lonjakan yang lebih besar dari lalu lintas untuk berkelanjutan tanpa menggagalkan permintaan apa pun, dengan konsekuensi akan meningkatkan latensi dan penggunaan memori. * Mengubah `handSize` berarti memperbolehkan kamu untuk menyesuaikan probabilitas tabrakan antara    _flow_ yang berbeda dan keseluruhan konkurensi yang tersedia untuk satu _flow_ tunggal dalam situasi beban berlebih. #### Catatan: `HandSize` yang lebih besar membuat dua _flow_ individual berpeluang kecil untuk bertabrakan (dan dimana _flow_ yang satu bisa membuat _flow_ yang lain menderita), tetapi akan lebih memungkinkan bahwa _flow_ dalam jumlah kecil akan dapat mendominasi apiserver. `HandSize` yang lebih besar juga berpotensi meningkatkan jumlah latensi yang diakibatkan oleh satu _flow_ lalu lintas tunggal yang tinggi. Jumlah maksimum permintaan dalam antrian yang diijinkan dari sebuah _flow_ tunggal adalah `handSize * queueLengthLimit`. Berikut ini adalah tabel yang menunjukkan koleksi konfigurasi _shuffle sharding_ yang menarik, dimana setiap probabilitas _mouse_ (_flow_ dengan intensitas rendah) yang diberikan akan dimampatkan oleh _elephant_ (_flow_ dengan intensitas tinggi) dalam sebuah koleksi ilustratif dari jumlah _elephant_ yang berbeda. Silahkan lihat pada [https://play.golang.org/p/Gi0PLgVHiUg](https://play.golang.org/p/Gi0PLgVHiUg) , yang digunakan untuk menghitung nilai-nilai dalam tabel ini. | | | | | | | --- | --- | --- | --- | --- |Contoh Konfigurasi Shuffle Sharding | HandSize | Queues | 1 elephant | 4 elephants | 16 elephants | | --- | --- | --- | --- | --- | | 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 | | 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 | | 10 | 64 | 6.601827268370426e-12 | 0.00045571320990370776 | 0.49999929150089345 | | 9 | 64 | 3.6310049976037345e-11 | 0.00045501212304112273 | 0.4282314876454858 | | 8 | 64 | 2.25929199850899e-10 | 0.0004886697053040446 | 0.35935114681123076 | | 8 | 128 | 6.994461389026097e-13 | 3.4055790161620863e-06 | 0.02746173137155063 | | 7 | 128 | 1.0579122850901972e-11 | 6.960839379258192e-06 | 0.02406157386340147 | | 7 | 256 | 7.597695465552631e-14 | 6.728547142019406e-08 | 0.0006709661542533682 | | 6 | 256 | 2.7134626662687968e-12 | 2.9516464018476436e-07 | 0.0008895654642000348 | | 6 | 512 | 4.116062922897309e-14 | 4.982983350480894e-09 | 2.26025764343413e-05 | | 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 | ### FlowSchema FlowSchema mencocokkan beberapa permintaan yang masuk dan menetapkan permintaan ke dalam sebuah tingkat prioritas. Setiap permintaan masuk diuji dengan setiap FlowSchema secara bergiliran, dimulai dari yang terendah secara numerik --- yang kita anggap sebagai yang tertinggi secara logis --- `matchingPrecedence` dan begitu seterusnya. FlowSchema yang cocok pertama kali akan menang. #### Perhatian: Hanya FlowSchema yang pertama kali cocok untuk permintaan yang diberikan yang akan dianggap penting. Jika ada banyak FlowSchema yang cocok dengan sebuah permintaan masuk, maka akan ditetapkan berdasarkan salah satu yang mempunyai `matchingPrecedence` tertinggi. Jika ada beberapa FlowSchema dengan nilai `matchingPrecedence` yang sama dan cocok dengan permintaan yang sama juga, permintaan dengan leksikografis `name` yang lebih kecil akan menang, tetapi akan lebih baik untuk tidak mengandalkan metode ini, dan sebaiknya perlu memastikan bahwa tidak ada dua FlowSchema yang memiliki `matchingPrecedence` yang sama. Sebuah FlowSchema dianggap cocok dengan sebuah permintaan yang diberikan jika setidaknya salah satu dari `rules` nya ada yang cocok. Sebuah aturan (_rule_) cocok jika setidaknya satu dari `subject` _dan_ ada salah satu dari `resourceRules` atau `nonResourceRules` (tergantung dari apakah permintaan yang masuk adalah untuk URL sumber daya atau non-sumber daya) yang cocok dengan permintaan tersebut. Untuk bagian `name` dalam subjek, dan bagian `verbs`, `apiGroups`, `resources`, `namespaces`, dan `nonResourceURLs` dalam aturan sumber daya dan non-sumber daya, _wildcard_ `*` mungkin bisa ditetapkan untuk mencocokkan semua nilai pada bagian yang diberikan, sehingga secara efektif menghapusnya dari pertimbangan. Sebuah `DistinguisherMethod.type` dari FlowSchema menentukan bagaimana permintaan yang cocok dengan Skema itu akan dipisahkan menjadi _flow_. Nilai tipe itu bisa jadi `ByUser`, dalam hal ini satu pengguna yang meminta tidak akan bisa menghabiskan kapasitas dari pengguna lain, atau bisa juga `ByNamespace`, dalam hal ini permintaan sumber daya di salah satu Namespace tidak akan bisa menyebabkan penderitaan bagi permintaan akan sumber daya dalam kapasitas Namespace yang lain, atau bisa juga kosong (atau `distinguisherMethod` dihilangkan seluruhnya), dalam hal ini semua permintaan yang cocok dengan FlowSchema ini akan dianggap sebagai bagian dari sebuah _flow_ tunggal. Pilihan yang tepat untuk FlowSchema yang diberikan akan bergantung pada sumber daya dan lingkungan khusus kamu. Diagnosis --------- Setiap respons HTTP dari server API dengan fitur prioritas dan kesetaraan yang diaktifkan memiliki dua _header_ tambahan: `X-Kubernetes-PF-FlowSchema-UID` dan `X-Kubernetes-PF-PriorityLevel-UID`, yang mencatat skema _flow_ yang cocok dengan permintaan dan tingkat prioritas masing-masing. Name Objek API tidak termasuk dalam _header_ ini jika pengguna peminta tidak memiliki izin untuk melihatnya, jadi ketika melakukan _debugging_ kamu dapat menggunakan perintah seperti ini kubectl get flowschema -o custom-columns="uid:{metadata.uid},name:{metadata.name}" kubectl get prioritylevelconfiguration -o custom-columns="uid:{metadata.uid},name:{metadata.name}" untuk mendapatkan pemetaan UID ke names baik untuk FlowSchema maupun PriorityLevelConfiguration. Observabilitas -------------- Saat kamu mengaktifkan fitur Prioritas dan Kesetaraan API atau APF, kube-apiserver akan mengeluarkan metrik tambahan. Dengan memantau metrik ini dapat membantu kamu untuk menentukan apakah konfigurasi kamu tidak tepat dalam membatasi lalu lintas yang penting, atau menemukan beban kerja yang berperilaku buruk yang dapat membahayakan kesehatan dari sistem. * `apiserver_flowcontrol_rejected_requests_total` menghitung permintaan yang ditolak, mengelompokkannya berdasarkan nama dari tingkat prioritas yang ditetapkan, nama FlowSchema yang ditetapkan, dan alasan penolakan tersebut. Alasan penolakan akan mengambil dari salah satu alasan-alasan berikut: * `queue-full`, yang mengindikasikan bahwa sudah terlalu banyak permintaan yang menunggu dalam antrian, * `concurrency-limit`, yang mengindikasikan bahwa PriorityLevelConfiguration telah dikonfigurasi untuk menolak, bukan untuk memasukan permintaan berlebih ke dalam antrian, atau * `time-out`, yang mengindikasikan bahwa permintaan masih dalam antrian ketika batas waktu antriannya telah berakhir. * `apiserver_flowcontrol_dispatched_requests_total` menghitung permintaan yang sudah mulai dieksekusi, mengelompokkannya berdasarkan nama dari tingkat prioritas yang ditetapkan, dan nama dari FlowSchema yang ditetapkan. * `apiserver_flowcontrol_current_inqueue_requests` memberikan jumlah total sesaat secara instan dari permintaan dalam antrian (bukan yang dieksekusi), dan mengelompokkannya berdasarkan tingkat prioritas dan FlowSchema. * `apiserver_flowcontrol_current_executing_requests` memberikan jumlah total yang instan dari permintaan yang dieksekusi, dan mengelompokkannya berdasarkan tingkat prioritas dan FlowSchema. * `apiserver_flowcontrol_request_queue_length_after_enqueue` memberikan histogram dari panjang antrian untuk semua antrian yang ada, mengelompokkannya berdasarkan tingkat prioritas dan FlowSchema, berdasarkan pengambilan sampel oleh permintaan _enqueued_. Setiap permintaan yang mendapatkan antrian berkontribusi ke satu sampel dalam histogramnya, pelaporan panjang antrian dilakukan setelah permintaan yang mengantri tersebut ditambahkan. Perlu dicatat bahwa ini akan menghasilkan statistik yang berbeda dengan survei yang tidak bias. #### Catatan: Nilai asing atau tidak biasa dalam histogram akan berarti ada kemungkinan sebuah _flow_ (misalnya, permintaan oleh satu pengguna atau untuk satu _namespace_, tergantung pada konfigurasinya) telah membanjiri server API, dan sedang dicekik. Sebaliknya, jika histogram dari satu tingkat prioritas menunjukkan bahwa semua antrian dalam prioritas level itu lebih panjang daripada level prioritas yang lainnya, mungkin akan sesuai untuk meningkatkan _concurrency shares_ dari PriorityLevelConfiguration itu. * `apiserver_flowcontrol_request_concurrency_limit` memberikan hasil perhitungan batas konkurensi (berdasarkan pada batas konkurensi total dari server API dan _concurrency share_ dari PriorityLevelConfiguration) untuk setiap PriorityLevelConfiguration. * `apiserver_flowcontrol_request_wait_duration_seconds` memberikan histogram tentang bagaimana permintaan yang panjang dihabiskan dalam antrian, mengelompokkannya berdasarkan FlowSchema yang cocok dengan permintaan, tingkat prioritas yang ditetapkan, dan apakah permintaan tersebut berhasil dieksekusi atau tidak. #### Catatan: Karena setiap FlowSchema selalu memberikan permintaan untuk satu PriorityLevelConfiguration, kamu dapat menambahkan histogram untuk semua FlowSchema dalam satu tingkat prioritas untuk mendapatkan histogram yang efektif dari permintaan yang ditetapkan ke tingkat prioritas tersebut. * `apiserver_flowcontrol_request_execution_seconds` memberikan histogram tentang bagaimana caranya permintaan yang panjang diambil untuk benar-benar dieksekusi, mengelompokkannya berdasarkan FlowSchema yang cocok dengan permintaan dan tingkat prioritas yang ditetapkan pada permintaan tersebut. Selanjutnya ----------- Untuk latar belakang informasi mengenai detail desain dari prioritas dan kesetaraan API, silahkan lihat [proposal pembaharuan](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness) . Kamu juga dapat membuat saran dan permintaan akan fitur melalui [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) . --- # Konfiguracja | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/concepts/configuration/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/concepts/configuration/) . Konfiguracja ============ Zasoby Kubernetesa wykorzystywane do konfiguracji Podów. --- # Amministrazione del Cluster | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/concepts/cluster-administration/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/concepts/cluster-administration/) . Amministrazione del Cluster =========================== * 1: [Proxy in Kubernetes](https://kubernetes.io/it/docs/concepts/cluster-administration/_print/#pg-08e94e6a480e0d6b2de72d84a1b97617) 1 - Proxy in Kubernetes ======================= Questa pagina spiega i proxy utilizzati con Kubernetes. Proxy ----- Esistono diversi proxy che puoi incontrare quando usi Kubernetes: 1. Il [kubectl proxy](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#direct-accessing-the-rest-api) :     - viene eseguito sul computer di un utente o in un pod     - collega un localhost address all'apiserver di Kubernetes     - il client comunica con il proxy in HTTP     - il proxy comunica con l'apiserver in HTTPS     - individua l'apiserver     - aggiunge gli header di autenticazione 1. L'[apiserver proxy](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services) :     - è un proxy presente nell'apiserver     - collega un utente al di fuori del cluster agli IP del cluster che altrimenti potrebbero non essere raggiungibili     - è uno dei processi dell'apiserver     - il client comunica con il proxy in HTTPS (o HTTP se l'apiserver è configurato in tal modo)     - il proxy comunica con il target via HTTP o HTTPS come scelto dal proxy utilizzando le informazioni disponibili     - può essere utilizzato per raggiungere un nodo, un pod o un servizio     - esegue il bilanciamento del carico quando viene utilizzato per raggiungere un servizio 1. Il [kube proxy](https://kubernetes.io/docs/concepts/services-networking/service/#ips-and-vips) :     - è eseguito su ciascun nodo     - fa da proxy per comunicazioni UDP, TCP e SCTP     - non gestisce il protocollo HTTP     - esegue il bilanciamento del carico     - è usato solo per raggiungere i servizi 1. Un proxy/bilanciatore di carico di fronte agli apiserver:     - la sua esistenza e implementazione variano da cluster a cluster (ad esempio nginx)     - si trova tra i client e uno o più apiserver     - funge da bilanciatore di carico se ci sono più di un apiserver. 1. Cloud Load Balancer su servizi esterni:     - sono forniti da alcuni fornitori di servizi cloud (ad es. AWS ELB, Google Cloud Load Balancer)     - vengono creati automaticamente quando il servizio Kubernetes ha tipo `LoadBalancer`     - solitamente supporta solo UDP / TCP     - il supporto SCTP dipende dall'implementazione del bilanciatore di carico del provider cloud     - l'implementazione varia a seconda del provider cloud. Gli utenti di Kubernetes in genere non devono preoccuparsi alcun proxy, se non i primi due tipi. L'amministratore del cluster in genere assicurerà che gli altri tipi di proxy siano impostati correttamente. Richiedere reindirizzamenti --------------------------- I proxy hanno sostituito le funzioni di reindirizzamento. I reindirizzamenti sono stati deprecati. --- # Kubernetes — Dokumentacja | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/home/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/home/) . Kubernetes — Dokumentacja ========================= Kubernetes to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach. Gospodarzem tego projektu o otwartym kodzie źródłowym jest Cloud Native Computing Foundation. * 1: [Dostępne wersje dokumentacji](https://kubernetes.io/pl/docs/home/_print/#pg-92dfff0ca612d0bff40171aa9df6c4ae) 1 - Dostępne wersje dokumentacji ================================ Ten serwis zawiera dokumentację do bieżącej i czterech poprzednich wersji Kubernetesa. Dostępność dokumentacji obejmującej konkretną wersję Kubernetesa nie oznacza automatycznie, że dana wersja Kubernetesa jest ciągle aktywnie wspierana. Zajrzyj do dokumentu [Support period](https://kubernetes.io/releases/patch-releases/#support-period) , aby dowiedzieć się, do kiedy objęte wsparciem są poszczególne wersje Kubernetesa. --- # TLS | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/tasks/tls/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/tasks/tls/) . TLS === अपने क्लस्टर के भीतर ट्रैफ़िक को ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) का उपयोग करके सुरक्षित करना समझें। * 1: [क्यूबलेट के लिए प्रमाणपत्र आवर्तन कॉन्फ़िगर करें](https://kubernetes.io/hi/docs/tasks/tls/_print/#pg-1272b18ac0c008f6ffc2c62a29fa929f) 1 - क्यूबलेट के लिए प्रमाणपत्र आवर्तन कॉन्फ़िगर करें ==================================================== यह पृष्ठ दिखाता है कि क्यूबलेट के लिए प्रमाणपत्र आवर्तन कैसे सक्षम और कॉन्फ़िगर कर सकते है। फ़ीचर स्थिति: `Kubernetes v1.19 [stable]` शुरू करने से पहले ----------------- * कम से कम कुबेरनेट्स संस्करण 1.8.0 या उसके बाद की आवश्यकता है। अवलोकन ------ क्यूबलेट प्रमाणपत्रों का उपयोग कुबरनेट्स API के साथ प्रमाणित करने के लिए करता है। डिफ़ॉल्ट रूप से, ये प्रमाणपत्र एक वर्ष की समाप्ति के साथ जारी किए जाते हैं ताकि उन्हें बार-बार नवीनीकृत करने की आवश्यकता न हो। कुबरनेट्स में [क्यूबलेट प्रमाणपत्र आवर्तन](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) शामिल है, जो स्वचालित रूप से एक नई कुंजी उत्पन्न करेगा जो स्वचालित रूप से एक नई कुंजी उत्पन्न करेगा और वर्तमान प्रमाणपत्र की समाप्ति के करीब आने पर कुबरनेट्स API से एक नया प्रमाणपत्र अनुरोध करेगा। एक बार नया प्रमाणपत्र उपलब्ध हो जाने पर, यह कुबरनेट्स API के साथ कनेक्शन को प्रमाणित करने के लिए उपयोग किया जाएगा। क्लाइंट प्रमाणपत्र रोटेशन सक्षम करना ------------------------------------ `kubelet` प्रक्रिया एक प्राचल `--rotate-certificates` स्वीकार करती है जो नियंत्रित करती है कि क्या कुबलेट स्वचालित रूप से वर्तमान में उपयोग किए जा रहे प्रमाणपत्र की समाप्ति के करीब आने पर एक नया प्रमाणपत्र अनुरोध करेगा। `kube-controller-manager` प्रक्रिया एक प्राचल स्वीकार करती है `--cluster-signing-duration` (`--experimental-cluster-signing-duration` 1.19 से पहले) जो नियंत्रित करता है कि प्रमाणपत्र कितने समय के लिए जारी किए जाएंगे। प्रमाणपत्र रोटेशन कॉन्फ़िगरेशन को समझना --------------------------------------- जब एक कुबलेट शुरू होता है, यदि इसे बूटस्ट्रैप करने के लिए कॉन्फ़िगर किया गया है (उपयोग करते हुए `--bootstrap-kubeconfig` फ्लैग), तो यह कुबरनेट्स API से कनेक्ट करने और एक प्रमाणपत्र हस्ताक्षर अनुरोध जारी करने के लिए अपने प्रारंभिक प्रमाणपत्र का उपयोग करेगा। आप प्रमाणपत्र हस्ताक्षर अनुरोधों की स्थिति देख सकते हैं: kubectl get csr शुरुआत में, किसी नोड पर कुबलेट से एक प्रमाणपत्र हस्ताक्षर अनुरोध की स्थिति `Pending` होगी। यदि प्रमाणपत्र हस्ताक्षर अनुरोध विशिष्ट मानदंडों को पूरा करता है, तो इसे नियंत्रक प्रबंधक द्वारा स्वचालित रूप से अनुमोदित किया जाएगा, और फिर इसकी स्थिति `Approved` होगी। इसके बाद, नियंत्रक प्रबंधक एक प्रमाणपत्र पर हस्ताक्षर करेगा, जो `--cluster-signing-duration` पैरामीटर द्वारा निर्दिष्ट अवधि के लिए जारी किया जाएगा, और हस्ताक्षरित प्रमाणपत्र को प्रमाणपत्र हस्ताक्षर अनुरोध से जोड़ा जाएगा। कुबलेट कुबरनेट्स API से हस्ताक्षरित प्रमाणपत्र प्राप्त करेगा और इसे डिस्क पर लिखेगा, `--cert-dir` द्वारा निर्दिष्ट स्थान में। फिर कुबलेट कुबरनेट्स API से कनेक्ट करने के लिए नए प्रमाणपत्र का उपयोग करेगा। जैसे ही हस्ताक्षरित प्रमाणपत्र की समाप्ति निकट आती है, कुबलेट स्वचालित रूप से कुबरनेट्स API का उपयोग करके एक नया प्रमाणपत्र हस्ताक्षर अनुरोध जारी करेगा। यह प्रमाणपत्र पर शेष समय के 30% और 10% के बीच किसी भी बिंदु पर हो सकता है। फिर से, नियंत्रक प्रबंधक स्वचालित रूप से प्रमाणपत्र अनुरोध को अनुमोदित करेगा और प्रमाणपत्र हस्ताक्षर अनुरोध से एक हस्ताक्षरित प्रमाणपत्र जोड़ेगा। कुबलेट कुबरनेट्स API से नया हस्ताक्षरित प्रमाणपत्र प्राप्त करेगा और इसे डिस्क पर लिखेगा। फिर यह कुबरनेट्स API के साथ कनेक्शन को नए प्रमाणपत्र का उपयोग करके पुन: कनेक्ट करने के लिए अपडेट करेगा। --- # Kubectl Reference Docs * [**GETTING STARTED**](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-strong-getting-started-strong-) * [create](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#create) * [_clusterrole_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-clusterrole-em-) * [_clusterrolebinding_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-clusterrolebinding-em-) * [_configmap_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-configmap-em-) * [_cronjob_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-cronjob-em-) * [_deployment_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-) * [_ingress_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-ingress-em-) * [_job_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-job-em-) * [_namespace_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-namespace-em-) * [_poddisruptionbudget_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-poddisruptionbudget-em-) * [_priorityclass_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-priorityclass-em-) * [_quota_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-quota-em-) * [_role_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-role-em-) * [_rolebinding_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-rolebinding-em-) * [_secret_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-em-) * [_secret docker-registry_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-docker-registry-em-) * [_secret generic_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-generic-em-) * [_secret tls_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-tls-em-) * [_service_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-service-em-) * [_service clusterip_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-service-clusterip-em-) * [_service externalname_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-service-externalname-em-) * [_service loadbalancer_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-service-loadbalancer-em-) * [_service nodeport_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-service-nodeport-em-) * [_serviceaccount_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-serviceaccount-em-) * [_token_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) * [get](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get) * [run](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#run) * [expose](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#expose) * [delete](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#delete) * [**APP MANAGEMENT**](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-strong-app-management-strong-) * [apply](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) * [_edit-last-applied_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-edit-last-applied-em-) * [_set-last-applied_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-last-applied-em-) * [_view-last-applied_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-view-last-applied-em-) * [annotate](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#annotate) * [autoscale](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#autoscale) * [debug](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#debug) * [diff](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#diff) * [edit](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#edit) * [kustomize](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#kustomize) * [label](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#label) * [patch](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#patch) * [replace](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#replace) * [rollout](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#rollout) * [_history_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-history-em-) * [_pause_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-pause-em-) * [_restart_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-restart-em-) * [_resume_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-resume-em-) * [_status_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-status-em-) * [_undo_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-undo-em-) * [scale](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#scale) * [set](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#set) * [_env_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-env-em-) * [_image_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-image-em-) * [_resources_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-resources-em-) * [_selector_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-selector-em-) * [_serviceaccount_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-serviceaccount-em--1) * [_subject_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-subject-em-) * [wait](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#wait) * [**WORKING WITH APPS**](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-strong-working-with-apps-strong-) * [attach](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#attach) * [auth](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#auth) * [_can-i_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-can-i-em-) * [_reconcile_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-reconcile-em-) * [cp](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#cp) * [describe](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#describe) * [events](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#events) * [exec](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#exec) * [logs](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs) * [port-forward](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#port-forward) * [proxy](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#proxy) * [top](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#top) * [_node_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-node-em-) * [_pod_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-pod-em-) * [**CLUSTER MANAGEMENT**](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-strong-cluster-management-strong-) * [api-versions](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#api-versions) * [api-resources](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#api-resources) * [certificate](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#certificate) * [_approve_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-approve-em-) * [_deny_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-deny-em-) * [cluster-info](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#cluster-info) * [_dump_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-dump-em-) * [cordon](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#cordon) * [drain](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#drain) * [taint](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#taint) * [uncordon](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#uncordon) * [**KUBECTL SETTINGS AND USAGE**](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-strong-kubectl-settings-and-usage-strong-) * [alpha](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#alpha) * [_auth_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-auth-em-) * [_auth whoami_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-auth-whoami-em-) * [completion](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#completion) * [config](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#config) * [_current-context_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-current-context-em-) * [_delete-cluster_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-delete-cluster-em-) * [_delete-context_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-delete-context-em-) * [_delete-user_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-delete-user-em-) * [_get-clusters_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-get-clusters-em-) * [_get-contexts_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-get-contexts-em-) * [_get-users_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-get-users-em-) * [_rename-context_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-rename-context-em-) * [_set_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-em-) * [_set-cluster_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-cluster-em-) * [_set-context_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) * [_set-credentials_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-credentials-em-) * [_unset_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-unset-em-) * [_use-context_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-use-context-em-) * [_view_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-view-em-) * [explain](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#explain) * [options](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#options) * [plugin](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#plugin) * [_list_](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-list-em-) * [version](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#version) [Copyright 2020 The Kubernetes Authors.](https://github.com/kubernetes/kubernetes) * example **GETTING STARTED** =================== This section contains the most basic commands for getting a workload running on your cluster. * `run` will start running 1 or more instances of a container image on your cluster. * `expose` will load balance traffic across the running instances, and can create a HA proxy for accessing the containers from outside the cluster. Once your workloads are running, you can use the commands in the [WORKING WITH APPS](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-strong-working-with-apps-strong-) section to inspect them. * * * create ====== > Create a pod using the data in pod.json kubectl create -f ./pod.json > Create a pod based on the JSON passed into stdin cat pod.json | kubectl create -f - > Edit the data in registry.yaml in JSON then create the resource using the edited data kubectl create -f registry.yaml --edit -o json Create a resource from a file or from stdin. JSON and YAML formats are accepted. ### Usage `$ kubectl create -f FILENAME` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | edit | | false | Edit the API resource before creating | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files to use to create the resource | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | raw | | | Raw URI to POST to the server. Uses the transport specified by the kubeconfig file. | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | | windows-line-endings | | false | Only relevant if --edit=true. Defaults to the line ending native to your platform. | * * * _clusterrole_ ------------- > Create a cluster role named "pod-reader" that allows user to perform "get", "watch" and "list" on pods kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods > Create a cluster role named "pod-reader" with ResourceName specified kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod > Create a cluster role named "foo" with API Group specified kubectl create clusterrole foo --verb=get,list,watch --resource=rs.apps > Create a cluster role named "foo" with SubResource specified kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status > Create a cluster role name "foo" with NonResourceURL specified kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* > Create a cluster role name "monitoring" with AggregationRule specified kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" Create a cluster role. ### Usage `$ kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | aggregation-rule | | | An aggregation label selector for combining ClusterRoles. | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | non-resource-url | | \[\] | A partial url that user should have access to. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | resource | | \[\] | Resource that the rule applies to | | resource-name | | \[\] | Resource in the white list that the rule applies to, repeat this flag for multiple items | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | | verb | | \[\] | Verb that applies to the resources contained in the rule | * * * _clusterrolebinding_ -------------------- > Create a cluster role binding for user1, user2, and group1 using the cluster-admin cluster role kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1 Create a cluster role binding for a particular cluster role. ### Usage `$ kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | clusterrole | | | ClusterRole this ClusterRoleBinding should reference | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | group | | \[\] | Groups to bind to the clusterrole. The flag can be repeated to add multiple groups. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | serviceaccount | | \[\] | Service accounts to bind to the clusterrole, in the format :. The flag can be repeated to add multiple service accounts. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | user | | \[\] | Usernames to bind to the clusterrole. The flag can be repeated to add multiple users. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _configmap_ ----------- > Create a new config map named my-config based on folder bar kubectl create configmap my-config --from-file=path/to/bar > Create a new config map named my-config with specified keys instead of file basenames on disk kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt > Create a new config map named my-config with key1=config1 and key2=config2 kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2 > Create a new config map named my-config from the key=value pairs in the file kubectl create configmap my-config --from-file=path/to/bar > Create a new config map named my-config from an env file kubectl create configmap my-config --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env Create a config map based on a file, directory, or specified literal value. A single config map may package one or more key/value pairs. When creating a config map based on a file, the key will default to the basename of the file, and the value will default to the file content. If the basename is an invalid key, you may specify an alternate key. When creating a config map based on a directory, each file whose basename is a valid key in the directory will be packaged into the config map. Any directory entries except regular files are ignored (e.g. subdirectories, symlinks, devices, pipes, etc). ### Usage `$ kubectl create configmap NAME [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | append-hash | | false | Append a hash of the configmap to its name. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | from-env-file | | \[\] | Specify the path to a file to read lines of key=val pairs to create a configmap. | | from-file | | \[\] | Key file can be specified using its file path, in which case file basename will be used as configmap key, or optionally with a key and file path, in which case the given key will be used. Specifying a directory will iterate each named file in the directory whose basename is a valid configmap key. | | from-literal | | \[\] | Specify a key and literal value to insert in configmap (i.e. mykey=somevalue) | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _cronjob_ --------- > Create a cron job kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" > Create a cron job with a command kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- date Create a cron job with the specified name. ### Usage `$ kubectl create cronjob NAME --image=image --schedule='0/5 * * * ?' -- [COMMAND] [args...]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | image | | | Image name to run. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | restart | | | job's restart policy. supported values: OnFailure, Never | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | schedule | | | A schedule in the Cron format the job should be run with. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _deployment_ ------------ > Create a deployment named my-dep that runs the busybox image kubectl create deployment my-dep --image=busybox > Create a deployment with a command kubectl create deployment my-dep --image=busybox -- date > Create a deployment named my-dep that runs the nginx image with 3 replicas kubectl create deployment my-dep --image=nginx --replicas=3 > Create a deployment named my-dep that runs the busybox image and expose port 5701 kubectl create deployment my-dep --image=busybox --port=5701 Create a deployment with the specified name. ### Usage `$ kubectl create deployment NAME --image=image -- [COMMAND] [args...]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | image | | \[\] | Image names to run. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | port | | \-1 | The port that this container exposes. | | replicas | r | 1 | Number of replicas to create. Default is 1. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _ingress_ --------- > Create a single ingress called 'simple' that directs requests to foo.com/bar to svc # svc1:8080 with a tls secret "my-cert" kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert" > Create a catch all ingress of "/path" pointing to service svc:port and Ingress Class as "otheringress" kubectl create ingress catch-all --class=otheringress --rule="/path=svc:port" > Create an ingress with two annotations: ingress.annotation1 and ingress.annotations2 kubectl create ingress annotated --class=default --rule="foo.com/bar=svc:port" \ --annotation ingress.annotation1=foo \ --annotation ingress.annotation2=bla > Create an ingress with the same host and multiple paths kubectl create ingress multipath --class=default \ --rule="foo.com/=svc:port" \ --rule="foo.com/admin/=svcadmin:portadmin" > Create an ingress with multiple hosts and the pathType as Prefix kubectl create ingress ingress1 --class=default \ --rule="foo.com/path*=svc:8080" \ --rule="bar.com/admin*=svc2:http" > Create an ingress with TLS enabled using the default ingress certificate and different path types kubectl create ingress ingtls --class=default \ --rule="foo.com/=svc:https,tls" \ --rule="foo.com/path/subpath*=othersvc:8080" > Create an ingress with TLS enabled using a specific secret and pathType as Prefix kubectl create ingress ingsecret --class=default \ --rule="foo.com/*=svc:8080,tls=secret1" > Create an ingress with a default backend kubectl create ingress ingdefault --class=default \ --default-backend=defaultsvc:http \ --rule="foo.com/*=svc:8080,tls=secret1" Create an ingress with the specified name. ### Usage `$ kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | annotation | | \[\] | Annotation to insert in the ingress object, in the format annotation=value | | class | | | Ingress Class to be used | | default-backend | | | Default service for backend, in format of svcname:port | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | rule | | \[\] | Rule in format host/path=service:port\[,tls=secretname\]. Paths containing the leading character '\*' are considered pathType=Prefix. tls argument is optional. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _job_ ----- > Create a job kubectl create job my-job --image=busybox > Create a job with a command kubectl create job my-job --image=busybox -- date > Create a job from a cron job named "a-cronjob" kubectl create job test-job --from=cronjob/a-cronjob Create a job with the specified name. ### Usage `$ kubectl create job NAME --image=image [--from=cronjob/name] -- [COMMAND] [args...]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | from | | | The name of the resource to create a Job from (only cronjob is supported). | | image | | | Image name to run. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _namespace_ ----------- > Create a new namespace named my-namespace kubectl create namespace my-namespace Create a namespace with the specified name. ### Usage `$ kubectl create namespace NAME [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _poddisruptionbudget_ --------------------- > Create a pod disruption budget named my-pdb that will select all pods with the app=rails label # and require at least one of them being available at any point in time kubectl create poddisruptionbudget my-pdb --selector=app=rails --min-available=1 > Create a pod disruption budget named my-pdb that will select all pods with the app=nginx label # and require at least half of the pods selected to be available at any point in time kubectl create pdb my-pdb --selector=app=nginx --min-available=50% Create a pod disruption budget with the specified name, selector, and desired minimum available pods. ### Usage `$ kubectl create poddisruptionbudget NAME --selector=SELECTOR --min-available=N [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | max-unavailable | | | The maximum number or percentage of unavailable pods this budget requires. | | min-available | | | The minimum number or percentage of available pods this budget requires. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | selector | | | A label selector to use for this budget. Only equality-based selector requirements are supported. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _priorityclass_ --------------- > Create a priority class named high-priority kubectl create priorityclass high-priority --value=1000 --description="high priority" > Create a priority class named default-priority that is considered as the global default priority kubectl create priorityclass default-priority --value=1000 --global-default=true --description="default priority" > Create a priority class named high-priority that cannot preempt pods with lower priority kubectl create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never" Create a priority class with the specified name, value, globalDefault and description. ### Usage `$ kubectl create priorityclass NAME --value=VALUE --global-default=BOOL [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | description | | | description is an arbitrary string that usually provides guidelines on when this priority class should be used. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | global-default | | false | global-default specifies whether this PriorityClass should be considered as the default priority. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | preemption-policy | | PreemptLowerPriority | preemption-policy is the policy for preempting pods with lower priority. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | | value | | 0 | the value of this priority class. | * * * _quota_ ------- > Create a new resource quota named my-quota kubectl create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10 > Create a new resource quota named best-effort kubectl create quota best-effort --hard=pods=100 --scopes=BestEffort Create a resource quota with the specified name, hard limits, and optional scopes. ### Usage `$ kubectl create quota NAME [--hard=key1=value1,key2=value2] [--scopes=Scope1,Scope2] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | hard | | | A comma-delimited set of resource=quantity pairs that define a hard limit. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | scopes | | | A comma-delimited set of quota scopes that must all match each object tracked by the quota. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _role_ ------ > Create a role named "pod-reader" that allows user to perform "get", "watch" and "list" on pods kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods > Create a role named "pod-reader" with ResourceName specified kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod > Create a role named "foo" with API Group specified kubectl create role foo --verb=get,list,watch --resource=rs.apps > Create a role named "foo" with SubResource specified kubectl create role foo --verb=get,list,watch --resource=pods,pods/status Create a role with single rule. ### Usage `$ kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | resource | | \[\] | Resource that the rule applies to | | resource-name | | \[\] | Resource in the white list that the rule applies to, repeat this flag for multiple items | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | | verb | | \[\] | Verb that applies to the resources contained in the rule | * * * _rolebinding_ ------------- > Create a role binding for user1, user2, and group1 using the admin cluster role kubectl create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1 Create a role binding for a particular role or cluster role. ### Usage `$ kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | clusterrole | | | ClusterRole this RoleBinding should reference | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | group | | \[\] | Groups to bind to the role. The flag can be repeated to add multiple groups. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | role | | | Role this RoleBinding should reference | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | serviceaccount | | \[\] | Service accounts to bind to the role, in the format :. The flag can be repeated to add multiple service accounts. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | user | | \[\] | Usernames to bind to the role. The flag can be repeated to add multiple users. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _secret_ -------- Create a secret using specified subcommand. ### Usage `$ kubectl create secret` * * * _secret docker-registry_ ------------------------ > If you don't already have a .dockercfg file, you can create a dockercfg secret directly by using: kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL > Create a new secret named my-secret from ~/.docker/config.json kubectl create secret docker-registry my-secret --from-file=.dockerconfigjson=path/to/.docker/config.json Create a new secret for use with Docker registries. Dockercfg secrets are used to authenticate against Docker registries. When using the Docker command line to push images, you can authenticate to a given registry by running: '$ docker login DOCKER\_REGISTRY\_SERVER --username=DOCKER\_USER --password=DOCKER\_PASSWORD --email=DOCKER\_EMAIL'. That produces a ~/.dockercfg file that is used by subsequent 'docker push' and 'docker pull' commands to authenticate to the registry. The email address is optional. When creating applications, you may have a Docker registry that requires authentication. In order for the nodes to pull images on your behalf, they must have the credentials. You can provide this information by creating a dockercfg secret and attaching it to your service account. ### Usage `$ kubectl create secret docker-registry NAME --docker-username=user --docker-password=password --docker-email=email [--docker-server=string] [--from-file=[key=]source] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | append-hash | | false | Append a hash of the secret to its name. | | docker-email | | | Email for Docker registry | | docker-password | | | Password for Docker registry authentication | | docker-server | | [https://index.docker.io/v1/](https://index.docker.io/v1/) | Server location for Docker registry | | docker-username | | | Username for Docker registry authentication | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | from-file | | \[\] | Key files can be specified using their file path, in which case a default name will be given to them, or optionally with a name and file path, in which case the given name will be used. Specifying a directory will iterate each named file in the directory that is a valid secret key. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _secret generic_ ---------------- > Create a new secret named my-secret with keys for each file in folder bar kubectl create secret generic my-secret --from-file=path/to/bar > Create a new secret named my-secret with specified keys instead of names on disk kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-file=ssh-publickey=path/to/id_rsa.pub > Create a new secret named my-secret with key1=supersecret and key2=topsecret kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret > Create a new secret named my-secret using a combination of a file and a literal kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-literal=passphrase=topsecret > Create a new secret named my-secret from env files kubectl create secret generic my-secret --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env Create a secret based on a file, directory, or specified literal value. A single secret may package one or more key/value pairs. When creating a secret based on a file, the key will default to the basename of the file, and the value will default to the file content. If the basename is an invalid key or you wish to chose your own, you may specify an alternate key. When creating a secret based on a directory, each file whose basename is a valid key in the directory will be packaged into the secret. Any directory entries except regular files are ignored (e.g. subdirectories, symlinks, devices, pipes, etc). ### Usage `$ kubectl create secret generic NAME [--type=string] [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | append-hash | | false | Append a hash of the secret to its name. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | from-env-file | | \[\] | Specify the path to a file to read lines of key=val pairs to create a secret. | | from-file | | \[\] | Key files can be specified using their file path, in which case a default name will be given to them, or optionally with a name and file path, in which case the given name will be used. Specifying a directory will iterate each named file in the directory that is a valid secret key. | | from-literal | | \[\] | Specify a key and literal value to insert in secret (i.e. mykey=somevalue) | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | type | | | The type of secret to create | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _secret tls_ ------------ > Create a new TLS secret named tls-secret with the given key pair kubectl create secret tls tls-secret --cert=path/to/tls.cert --key=path/to/tls.key Create a TLS secret from the given public/private key pair. The public/private key pair must exist beforehand. The public key certificate must be .PEM encoded and match the given private key. ### Usage `$ kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | append-hash | | false | Append a hash of the secret to its name. | | cert | | | Path to PEM encoded public key certificate. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | key | | | Path to private key associated with given certificate. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _service_ --------- Create a service using a specified subcommand. ### Usage `$ kubectl create service` * * * _service clusterip_ ------------------- > Create a new ClusterIP service named my-cs kubectl create service clusterip my-cs --tcp=5678:8080 > Create a new ClusterIP service named my-cs (in headless mode) kubectl create service clusterip my-cs --clusterip="None" Create a ClusterIP service with the specified name. ### Usage `$ kubectl create service clusterip NAME [--tcp=:] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | clusterip | | | Assign your own ClusterIP or set to 'None' for a 'headless' service (no loadbalancing). | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | tcp | | \[\] | Port pairs can be specified as ':'. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _service externalname_ ---------------------- > Create a new ExternalName service named my-ns kubectl create service externalname my-ns --external-name bar.com Create an ExternalName service with the specified name. ExternalName service references to an external DNS address instead of only pods, which will allow application authors to reference services that exist off platform, on other clusters, or locally. ### Usage `$ kubectl create service externalname NAME --external-name external.name [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | external-name | | | External name of service | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | tcp | | \[\] | Port pairs can be specified as ':'. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _service loadbalancer_ ---------------------- > Create a new LoadBalancer service named my-lbs kubectl create service loadbalancer my-lbs --tcp=5678:8080 Create a LoadBalancer service with the specified name. ### Usage `$ kubectl create service loadbalancer NAME [--tcp=port:targetPort] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | tcp | | \[\] | Port pairs can be specified as ':'. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _service nodeport_ ------------------ > Create a new NodePort service named my-ns kubectl create service nodeport my-ns --tcp=5678:8080 Create a NodePort service with the specified name. ### Usage `$ kubectl create service nodeport NAME [--tcp=port:targetPort] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | node-port | | 0 | Port used to expose the service on each node in a cluster. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | tcp | | \[\] | Port pairs can be specified as ':'. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _serviceaccount_ ---------------- > Create a new service account named my-service-account kubectl create serviceaccount my-service-account Create a service account with the specified name. ### Usage `$ kubectl create serviceaccount NAME [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-create | Name of the manager used to track field ownership. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * _token_ ------- > Request a token to authenticate to the kube-apiserver as the service account "myapp" in the current namespace kubectl create token myapp > Request a token for a service account in a custom namespace kubectl create token myapp --namespace myns > Request a token with a custom expiration kubectl create token myapp --duration 10m > Request a token with a custom audience kubectl create token myapp --audience https://example.com > Request a token bound to an instance of a Secret object kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret > Request a token bound to an instance of a Secret object with a specific uid kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret --bound-object-uid 0d4691ed-659b-4935-a832-355f77ee47cc Request a service account token. ### Usage `$ kubectl create token SERVICE_ACCOUNT_NAME` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | audience | | \[\] | Audience of the requested token. If unset, defaults to requesting a token for use with the Kubernetes API server. May be repeated to request a token valid for multiple audiences. | | bound-object-kind | | | Kind of an object to bind the token to. Supported kinds are Pod, Secret. If set, --bound-object-name must be provided. | | bound-object-name | | | Name of an object to bind the token to. The token will expire when the object is deleted. Requires --bound-object-kind. | | bound-object-uid | | | UID of an object to bind the token to. Requires --bound-object-kind and --bound-object-name. If unset, the UID of the existing object is used. | | duration | | 0s | Requested lifetime of the issued token. The server may return a token with a longer or shorter lifetime. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * get === > List all pods in ps output format kubectl get pods > List all pods in ps output format with more information (such as node name) kubectl get pods -o wide > List a single replication controller with specified NAME in ps output format kubectl get replicationcontroller web > List deployments in JSON output format, in the "v1" version of the "apps" API group kubectl get deployments.v1.apps -o json > List a single pod in JSON output format kubectl get -o json pod web-pod-13je7 > List a pod identified by type and name specified in "pod.yaml" in JSON output format kubectl get -f pod.yaml -o json > List resources from a directory with kustomization.yaml - e.g. dir/kustomization.yaml kubectl get -k dir/ > Return only the phase value of the specified pod kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}} > List resource information in custom columns kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image > List all replication controllers and services together in ps output format kubectl get rc,services > List one or more resources by their type and names kubectl get rc/web service/frontend pods/web-pod-13je7 > List status subresource for a single pod. kubectl get pod web-pod-13je7 --subresource status Display one or many resources. Prints a table of the most important information about the specified resources. You can filter the list using a label selector and the --selector flag. If the desired resource type is namespaced you will only see results in your current namespace unless you pass --all-namespaces. By specifying the output as 'template' and providing a Go template as the value of the --template flag, you can filter the attributes of the fetched resources. Use "kubectl api-resources" for a complete list of supported resources. ### Usage `$ kubectl get [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file|custom-columns|custom-columns-file|wide] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all-namespaces | A | false | If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace. | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | chunk-size | | 500 | Return large lists in chunks rather than all at once. Pass 0 to disable. This flag is beta and may change in the future. | | field-selector | | | Selector (field query) to filter on, supports '=', '==', and '!='.(e.g. --field-selector key1=value1,key2=value2). The server only supports a limited number of field queries per type. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | ignore-not-found | | false | If the requested object does not exist the command will return exit code 0. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | label-columns | L | \[\] | Accepts a comma separated list of labels that are going to be presented as columns. Names are case-sensitive. You can also use multiple flag options like -L label1 -L label2... | | no-headers | | false | When using the default or custom-column output format, don't print headers (default print headers). | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file, custom-columns, custom-columns-file, wide). See custom columns \[[https://kubernetes.io/docs/reference/kubectl/#custom-columns](https://kubernetes.io/docs/reference/kubectl/#custom-columns)
\], golang template \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\] and jsonpath template \[[https://kubernetes.io/docs/reference/kubectl/jsonpath/](https://kubernetes.io/docs/reference/kubectl/jsonpath/)
\]. | | output-watch-events | | false | Output watch event objects when --watch or --watch-only is used. Existing objects are output as initial ADDED events. | | raw | | | Raw URI to request from the server. Uses the transport specified by the kubeconfig file. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | server-print | | true | If true, have the server return the appropriate table output. Supports extension APIs and CRDs. | | show-kind | | false | If present, list the resource type for the requested object(s). | | show-labels | | false | When printing, show all labels as the last column (default hide labels column) | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | sort-by | | | If non-empty, sort list types using this field specification. The field specification is expressed as a JSONPath expression (e.g. '{.metadata.name}'). The field in the API resource specified by this JSONPath expression must be an integer or a string. | | subresource | | | If specified, gets the subresource of the requested object. Must be one of \[status scale\]. This flag is alpha and may change in the future. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | use-openapi-print-columns | | false | If true, use x-kubernetes-print-column metadata (if present) from the OpenAPI schema for displaying a resource. | | watch | w | false | After listing/getting the requested object, watch for changes. | | watch-only | | false | Watch for changes to the requested object(s), without listing/getting first. | * * * run === > Start a nginx pod kubectl run nginx --image=nginx > Start a hazelcast pod and let the container expose port 5701 kubectl run hazelcast --image=hazelcast/hazelcast --port=5701 > Start a hazelcast pod and set environment variables "DNS\_DOMAIN=cluster" and "POD\_NAMESPACE=default" in the container kubectl run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default" > Start a hazelcast pod and set labels "app=hazelcast" and "env=prod" in the container kubectl run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod" > Dry run; print the corresponding API objects without creating them kubectl run nginx --image=nginx --dry-run=client > Start a nginx pod, but overload the spec with a partial set of values parsed from JSON kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }' > Start a busybox pod and keep it in the foreground, don't restart it if it exits kubectl run -i -t busybox --image=busybox --restart=Never > Start the nginx pod using the default command, but use custom arguments (arg1 .. argN) for that command kubectl run nginx --image=nginx -- ... > Start the nginx pod using a different command and custom arguments kubectl run nginx --image=nginx --command -- ... Create and run a particular image in a pod. ### Usage `$ kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client] [--overrides=inline-json] [--command] -- [COMMAND] [args...]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | annotations | | \[\] | Annotations to apply to the pod. | | attach | | false | If true, wait for the Pod to start running, and then attach to the Pod as if 'kubectl attach ...' were called. Default false, unless '-i/--stdin' is set, in which case the default is true. With '--restart=Never' the exit code of the container process is returned. | | cascade | | background | Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents (e.g. Pods created by a ReplicationController). Defaults to background. | | command | | false | If true and extra arguments are present, use them as the 'command' field in the container, rather than the 'args' field which is the default. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | env | | \[\] | Environment variables to set in the container. | | expose | | false | If true, create a ClusterIP service associated with the pod. Requires `--port`. | | field-manager | | kubectl-run | Name of the manager used to track field ownership. | | filename | f | \[\] | to use to replace the resource. | | force | | false | If true, immediately remove resources from API and bypass graceful deletion. Note that immediate deletion of some resources may result in inconsistency or data loss and requires confirmation. | | grace-period | | \-1 | Period of time in seconds given to the resource to terminate gracefully. Ignored if negative. Set to 1 for immediate shutdown. Can only be set to 0 when --force is true (force deletion). | | image | | | The image for the container to run. | | image-pull-policy | | | The image pull policy for the container. If left empty, this value will not be specified by the client and defaulted by the server. | | kustomize | k | | Process a kustomization directory. This flag can't be used together with -f or -R. | | labels | l | | Comma separated labels to apply to the pod. Will override previous values. | | leave-stdin-open | | false | If the pod is started in interactive mode or with stdin, leave stdin open after the first attach completes. By default, stdin will be closed after the first attach completes. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | override-type | | merge | The method used to override the generated object: json, merge, or strategic. | | overrides | | | An inline JSON override for the generated object. If this is non-empty, it is used to override the generated object. Requires that the object supply a valid apiVersion field. | | pod-running-timeout | | 1m0s | The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running | | port | | | The port that this container exposes. | | privileged | | false | If true, run the container in privileged mode. | | quiet | q | false | If true, suppress prompt messages. | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | restart | | Always | The restart policy for this Pod. Legal values \[Always, OnFailure, Never\]. | | rm | | false | If true, delete the pod after it exits. Only valid when attaching to the container, e.g. with '--attach' or with '-i/--stdin'. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | stdin | i | false | Keep stdin open on the container in the pod, even if nothing is attached. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | timeout | | 0s | The length of time to wait before giving up on a delete, zero means determine a timeout from the size of the object | | tty | t | false | Allocate a TTY for the container in the pod. | | wait | | false | If true, wait for resources to be gone before returning. This waits for finalizers. | * * * expose ====== > Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000 kubectl expose rc nginx --port=80 --target-port=8000 > Create a service for a replication controller identified by type and name specified in "nginx-controller.yaml", which serves on port 80 and connects to the containers on port 8000 kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000 > Create a service for a pod valid-pod, which serves on port 444 with the name "frontend" kubectl expose pod valid-pod --port=444 --name=frontend > Create a second service based on the above service, exposing the container port 8443 as port 443 with the name "nginx-https" kubectl expose service nginx --port=443 --target-port=8443 --name=nginx-https > Create a service for a replicated streaming application on port 4100 balancing UDP traffic and named 'video-stream'. kubectl expose rc streamer --port=4100 --protocol=UDP --name=video-stream > Create a service for a replicated nginx using replica set, which serves on port 80 and connects to the containers on port 8000 kubectl expose rs nginx --port=80 --target-port=8000 > Create a service for an nginx deployment, which serves on port 80 and connects to the containers on port 8000 kubectl expose deployment nginx --port=80 --target-port=8000 Expose a resource as a new Kubernetes service. Looks up a deployment, service, replica set, replication controller or pod by name and uses the selector for that resource as the selector for a new service on the specified port. A deployment or replica set will be exposed as a service only if its selector is convertible to a selector that service supports, i.e. when the selector contains only the matchLabels component. Note that if no port is specified via --port and the exposed resource has multiple ports, all will be re-used by the new service. Also if no labels are specified, the new service will re-use the labels from the resource it exposes. Possible resources include (case insensitive): pod (po), service (svc), replicationcontroller (rc), deployment (deploy), replicaset (rs) ### Usage `$ kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP|SCTP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | cluster-ip | | | ClusterIP to be assigned to the service. Leave empty to auto-allocate, or set to 'None' to create a headless service. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | external-ip | | | Additional external IP address (not managed by Kubernetes) to accept for the service. If this IP is routed to a node, the service can be accessed by this IP in addition to its generated service IP. | | field-manager | | kubectl-expose | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to expose a service | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | labels | l | | Labels to apply to the service created by this call. | | load-balancer-ip | | | IP to assign to the LoadBalancer. If empty, an ephemeral IP will be created and used (cloud-provider specific). | | name | | | The name for the newly created object. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | override-type | | merge | The method used to override the generated object: json, merge, or strategic. | | overrides | | | An inline JSON override for the generated object. If this is non-empty, it is used to override the generated object. Requires that the object supply a valid apiVersion field. | | port | | | The port that the service should serve on. Copied from the resource being exposed, if unspecified | | protocol | | | The network protocol for the service to be created. Default is 'TCP'. | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | selector | | | A label selector to use for this service. Only equality-based selector requirements are supported. If empty (the default) infer the selector from the replication controller or replica set.) | | session-affinity | | | If non-empty, set the session affinity for the service to this; legal values: 'None', 'ClientIP' | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | target-port | | | Name or number for the port on the container that the service should direct traffic to. Optional. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | type | | | Type for this service: ClusterIP, NodePort, LoadBalancer, or ExternalName. Default is 'ClusterIP'. | * * * delete ====== > Delete a pod using the type and name specified in pod.json kubectl delete -f ./pod.json > Delete resources from a directory containing kustomization.yaml - e.g. dir/kustomization.yaml kubectl delete -k dir > Delete resources from all files that end with '.json' - i.e. expand wildcard characters in file names kubectl delete -f '*.json' > Delete a pod based on the type and name in the JSON passed into stdin cat pod.json | kubectl delete -f - > Delete pods and services with same names "baz" and "foo" kubectl delete pod,service baz foo > Delete pods and services with label name=myLabel kubectl delete pods,services -l name=myLabel > Delete a pod with minimal delay kubectl delete pod foo --now > Force delete a pod on a dead node kubectl delete pod foo --force > Delete all pods kubectl delete pods --all Delete resources by file names, stdin, resources and names, or by resources and label selector. JSON and YAML formats are accepted. Only one type of argument may be specified: file names, resources and names, or resources and label selector. Some resources, such as pods, support graceful deletion. These resources define a default period before they are forcibly terminated (the grace period) but you may override that value with the --grace-period flag, or pass --now to set a grace-period of 1. Because these resources often represent entities in the cluster, deletion may not be acknowledged immediately. If the node hosting a pod is down or cannot reach the API server, termination may take significantly longer than the grace period. To force delete a resource, you must specify the --force flag. Note: only a subset of resources support graceful deletion. In absence of the support, the --grace-period flag is ignored. IMPORTANT: Force deleting pods does not wait for confirmation that the pod's processes have been terminated, which can leave those processes running until the node detects the deletion and completes graceful deletion. If your processes use shared storage or talk to a remote API and depend on the name of the pod to identify themselves, force deleting those pods may result in multiple processes running on different machines using the same identification which may lead to data corruption or inconsistency. Only force delete pods when you are sure the pod is terminated, or if your application can tolerate multiple copies of the same pod running at once. Also, if you force delete pods, the scheduler may place new pods on those nodes before the node has released those resources and causing those pods to be evicted immediately. Note that the delete command does NOT do resource version checks, so if someone submits an update to a resource right when you submit a delete, their update will be lost along with the rest of the resource. After a CustomResourceDefinition is deleted, invalidation of discovery cache may take up to 6 hours. If you don't want to wait, you might want to run "kubectl api-resources" to refresh the discovery cache. ### Usage `$ kubectl delete ([-f FILENAME] | [-k DIRECTORY] | TYPE [(NAME | -l label | --all)])` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Delete all resources, in the namespace of the specified resource types. | | all-namespaces | A | false | If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace. | | cascade | | background | Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents (e.g. Pods created by a ReplicationController). Defaults to background. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-selector | | | Selector (field query) to filter on, supports '=', '==', and '!='.(e.g. --field-selector key1=value1,key2=value2). The server only supports a limited number of field queries per type. | | filename | f | \[\] | containing the resource to delete. | | force | | false | If true, immediately remove resources from API and bypass graceful deletion. Note that immediate deletion of some resources may result in inconsistency or data loss and requires confirmation. | | grace-period | | \-1 | Period of time in seconds given to the resource to terminate gracefully. Ignored if negative. Set to 1 for immediate shutdown. Can only be set to 0 when --force is true (force deletion). | | ignore-not-found | | false | Treat "resource not found" as a successful delete. Defaults to "true" when --all is specified. | | kustomize | k | | Process a kustomization directory. This flag can't be used together with -f or -R. | | now | | false | If true, resources are signaled for immediate shutdown (same as --grace-period=1). | | output | o | | Output mode. Use "-o name" for shorter output (resource/name). | | raw | | | Raw URI to DELETE to the server. Uses the transport specified by the kubeconfig file. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | timeout | | 0s | The length of time to wait before giving up on a delete, zero means determine a timeout from the size of the object | | wait | | true | If true, wait for resources to be gone before returning. This waits for finalizers. | **APP MANAGEMENT** ================== This section contains commands for creating, updating, deleting, and viewing your workloads in a Kubernetes cluster. * * * apply ===== > Apply the configuration in pod.json to a pod kubectl apply -f ./pod.json > Apply resources from a directory containing kustomization.yaml - e.g. dir/kustomization.yaml kubectl apply -k dir/ > Apply the JSON passed into stdin to a pod cat pod.json | kubectl apply -f - > Apply the configuration from all files that end with '.json' - i.e. expand wildcard characters in file names kubectl apply -f '*.json' > Note: --prune is still in Alpha # Apply the configuration in manifest.yaml that matches label app=nginx and delete all other resources that are not in the file and match label app=nginx kubectl apply --prune -f manifest.yaml -l app=nginx > Apply the configuration in manifest.yaml and delete all the other config maps that are not in the file kubectl apply --prune -f manifest.yaml --all --prune-allowlist=core/v1/ConfigMap Apply a configuration to a resource by file name or stdin. The resource name must be specified. This resource will be created if it doesn't exist yet. To use 'apply', always create the resource initially with either 'apply' or 'create --save-config'. JSON and YAML formats are accepted. Alpha Disclaimer: the --prune functionality is not yet complete. Do not use unless you are aware of what the current state is. See [https://issues.k8s.io/34274](https://issues.k8s.io/34274) . ### Usage `$ kubectl apply (-f FILENAME | -k DIRECTORY)` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources in the namespace of the specified resource types. | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | cascade | | background | Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents (e.g. Pods created by a ReplicationController). Defaults to background. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-client-side-apply | Name of the manager used to track field ownership. | | filename | f | \[\] | The files that contain the configurations to apply. | | force | | false | If true, immediately remove resources from API and bypass graceful deletion. Note that immediate deletion of some resources may result in inconsistency or data loss and requires confirmation. | | force-conflicts | | false | If true, server-side apply will force the changes against conflicts. | | grace-period | | \-1 | Period of time in seconds given to the resource to terminate gracefully. Ignored if negative. Set to 1 for immediate shutdown. Can only be set to 0 when --force is true (force deletion). | | kustomize | k | | Process a kustomization directory. This flag can't be used together with -f or -R. | | openapi-patch | | true | If true, use openapi to calculate diff when the openapi presents and the resource can be found in the openapi spec. Otherwise, fall back to use baked-in types. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | overwrite | | true | Automatically resolve conflicts between the modified and live configuration by using values from the modified configuration | | prune | | false | Automatically delete resource objects, that do not appear in the configs and are created by either apply or create --save-config. Should be used with either -l or --all. | | prune-allowlist | | \[\] | Overwrite the default allowlist with for --prune | | prune-whitelist | | \[\] | Overwrite the default whitelist with for --prune | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | server-side | | false | If true, apply runs in the server instead of the client. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | timeout | | 0s | The length of time to wait before giving up on a delete, zero means determine a timeout from the size of the object | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | | wait | | false | If true, wait for resources to be gone before returning. This waits for finalizers. | * * * _edit-last-applied_ ------------------- > Edit the last-applied-configuration annotations by type/name in YAML kubectl apply edit-last-applied deployment/nginx > Edit the last-applied-configuration annotations by file in JSON kubectl apply edit-last-applied -f deploy.yaml -o json Edit the latest last-applied-configuration annotations of resources from the default editor. The edit-last-applied command allows you to directly edit any API resource you can retrieve via the command-line tools. It will open the editor defined by your KUBE\_EDITOR, or EDITOR environment variables, or fall back to 'vi' for Linux or 'notepad' for Windows. You can edit multiple objects, although changes are applied one at a time. The command accepts file names as well as command-line arguments, although the files you point to must be previously saved versions of resources. The default format is YAML. To edit in JSON, specify "-o json". The flag --windows-line-endings can be used to force Windows line endings, otherwise the default for your operating system will be used. In the event an error occurs while updating, a temporary file will be created on disk that contains your unapplied changes. The most common error when updating a resource is another editor changing the resource on the server. When this occurs, you will have to apply your changes to the newer version of the resource, or update your temporary saved copy to include the latest resource version. ### Usage `$ kubectl apply edit-last-applied (RESOURCE/NAME | -f FILENAME)` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | field-manager | | kubectl-client-side-apply | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files to use to edit the resource | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | | windows-line-endings | | false | Defaults to the line ending native to your platform. | * * * _set-last-applied_ ------------------ > Set the last-applied-configuration of a resource to match the contents of a file kubectl apply set-last-applied -f deploy.yaml > Execute set-last-applied against each configuration file in a directory kubectl apply set-last-applied -f path/ > Set the last-applied-configuration of a resource to match the contents of a file; will create the annotation if it does not already exist kubectl apply set-last-applied -f deploy.yaml --create-annotation=true Set the latest last-applied-configuration annotations by setting it to match the contents of a file. This results in the last-applied-configuration being updated as though 'kubectl apply -f ' was run, without updating any other parts of the object. ### Usage `$ kubectl apply set-last-applied -f FILENAME` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | create-annotation | | false | Will create 'last-applied-configuration' annotations if current objects doesn't have one | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | filename | f | \[\] | Filename, directory, or URL to files that contains the last-applied-configuration annotations | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _view-last-applied_ ------------------- > View the last-applied-configuration annotations by type/name in YAML kubectl apply view-last-applied deployment/nginx > View the last-applied-configuration annotations by file in JSON kubectl apply view-last-applied -f deploy.yaml -o json View the latest last-applied-configuration annotations by type/name or file. The default output will be printed to stdout in YAML format. You can use the -o option to change the output format. ### Usage `$ kubectl apply view-last-applied (TYPE [NAME | -l label] | TYPE/NAME | -f FILENAME)` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources in the namespace of the specified resource types | | filename | f | \[\] | Filename, directory, or URL to files that contains the last-applied-configuration annotations | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | yaml | Output format. Must be one of (yaml, json) | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | * * * annotate ======== > Update pod 'foo' with the annotation 'description' and the value 'my frontend' # If the same annotation is set multiple times, only the last value will be applied kubectl annotate pods foo description='my frontend' > Update a pod identified by type and name in "pod.json" kubectl annotate -f pod.json description='my frontend' > Update pod 'foo' with the annotation 'description' and the value 'my frontend running nginx', overwriting any existing value kubectl annotate --overwrite pods foo description='my frontend running nginx' > Update all pods in the namespace kubectl annotate pods --all description='my frontend running nginx' > Update pod 'foo' only if the resource is unchanged from version 1 kubectl annotate pods foo description='my frontend running nginx' --resource-version=1 > Update pod 'foo' by removing an annotation named 'description' if it exists # Does not require the --overwrite flag kubectl annotate pods foo description- Update the annotations on one or more resources. All Kubernetes objects support the ability to store additional data with the object as annotations. Annotations are key/value pairs that can be larger than labels and include arbitrary string values such as structured JSON. Tools and system extensions may use annotations to store their own data. Attempting to set an annotation that already exists will fail unless --overwrite is set. If --resource-version is specified and does not match the current resource version on the server the command will fail. Use "kubectl api-resources" for a complete list of supported resources. ### Usage `$ kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources, in the namespace of the specified resource types. | | all-namespaces | A | false | If true, check the specified action in all namespaces. | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-annotate | Name of the manager used to track field ownership. | | field-selector | | | Selector (field query) to filter on, supports '=', '==', and '!='.(e.g. --field-selector key1=value1,key2=value2). The server only supports a limited number of field queries per type. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to update the annotation | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | list | | false | If true, display the annotations for a given resource. | | local | | false | If true, annotation will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | overwrite | | false | If true, allow annotations to be overwritten, otherwise reject annotation updates that overwrite existing annotations. | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | resource-version | | | If non-empty, the annotation update will only succeed if this is the current resource-version for the object. Only valid when specifying a single resource. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * autoscale ========= > Auto scale a deployment "foo", with the number of pods between 2 and 10, no target CPU utilization specified so a default autoscaling policy will be used kubectl autoscale deployment foo --min=2 --max=10 > Auto scale a replication controller "foo", with the number of pods between 1 and 5, target CPU utilization at 80% kubectl autoscale rc foo --max=5 --cpu-percent=80 Creates an autoscaler that automatically chooses and sets the number of pods that run in a Kubernetes cluster. Looks up a deployment, replica set, stateful set, or replication controller by name and creates an autoscaler that uses the given resource as a reference. An autoscaler can automatically increase or decrease number of pods deployed within the system as needed. ### Usage `$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | cpu-percent | | \-1 | The target average CPU utilization (represented as a percent of requested CPU) over all the pods. If it's not specified or negative, a default autoscaling policy will be used. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-autoscale | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to autoscale. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | max | | \-1 | The upper limit for the number of pods that can be set by the autoscaler. Required. | | min | | \-1 | The lower limit for the number of pods that can be set by the autoscaler. If it's not specified or negative, the server will apply a default value. | | name | | | The name for the newly created object. If not specified, the name of the input resource will be used. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * debug ===== > Create an interactive debugging session in pod mypod and immediately attach to it. # (requires the EphemeralContainers feature to be enabled in the cluster) kubectl debug mypod -it --image=busybox > Create a debug container named debugger using a custom automated debugging image. # (requires the EphemeralContainers feature to be enabled in the cluster) kubectl debug --image=myproj/debug-tools -c debugger mypod > Create a copy of mypod adding a debug container and attach to it kubectl debug mypod -it --image=busybox --copy-to=my-debugger > Create a copy of mypod changing the command of mycontainer kubectl debug mypod -it --copy-to=my-debugger --container=mycontainer -- sh > Create a copy of mypod changing all container images to busybox kubectl debug mypod --copy-to=my-debugger --set-image=*=busybox > Create a copy of mypod adding a debug container and changing container images kubectl debug mypod -it --copy-to=my-debugger --image=debian --set-image=app=app:debug,sidecar=sidecar:debug > Create an interactive debugging session on a node and immediately attach to it. # The container will run in the host namespaces and the host's filesystem will be mounted at /host kubectl debug node/mynode -it --image=busybox Debug cluster resources using interactive debugging containers. 'debug' provides automation for common debugging tasks for cluster objects identified by resource and name. Pods will be used by default if no resource is specified. The action taken by 'debug' varies depending on what resource is specified. Supported actions include: _Workload: Create a copy of an existing pod with certain attributes changed, for example changing the image tag to a new version. _Workload: Add an ephemeral container to an already running pod, for example to add debugging utilities without restarting the pod. \* Node: Create a new pod that runs in the node's host namespaces and can access the node's filesystem. ### Usage `$ kubectl debug (POD | TYPE[[.VERSION].GROUP]/NAME) [ -- COMMAND [args...] ]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | arguments-only | | false | If specified, everything after -- will be passed to the new container as Args instead of Command. | | attach | | false | If true, wait for the container to start running, and then attach as if 'kubectl attach ...' were called. Default false, unless '-i/--stdin' is set, in which case the default is true. | | container | c | | Container name to use for debug container. | | copy-to | | | Create a copy of the target Pod with this name. | | env | | \[\] | Environment variables to set in the container. | | image | | | Container image to use for debug container. | | image-pull-policy | | | The image pull policy for the container. If left empty, this value will not be specified by the client and defaulted by the server. | | profile | | legacy | Debugging profile. | | quiet | q | false | If true, suppress informational messages. | | replace | | false | When used with '--copy-to', delete the original Pod. | | same-node | | false | When used with '--copy-to', schedule the copy of target Pod on the same node. | | set-image | | \[\] | When used with '--copy-to', a list of name=image pairs for changing container images, similar to how 'kubectl set image' works. | | share-processes | | true | When used with '--copy-to', enable process namespace sharing in the copy. | | stdin | i | false | Keep stdin open on the container(s) in the pod, even if nothing is attached. | | target | | | When using an ephemeral container, target processes in this container name. | | tty | t | false | Allocate a TTY for the debugging container. | * * * diff ==== > Diff resources included in pod.json kubectl diff -f pod.json > Diff file read from stdin cat service.yaml | kubectl diff -f - Diff configurations specified by file name or stdin between the current online configuration, and the configuration as it would be if applied. The output is always YAML. KUBECTL\_EXTERNAL\_DIFF environment variable can be used to select your own diff command. Users can use external commands with params too, example: KUBECTL\_EXTERNAL\_DIFF="colordiff -N -u" By default, the "diff" command available in your path will be run with the "-u" (unified diff) and "-N" (treat absent files as empty) options. Exit status: 0 No differences were found. 1 Differences were found. >1 Kubectl or diff failed with an error. Note: KUBECTL\_EXTERNAL\_DIFF, if used, is expected to follow that convention. ### Usage `$ kubectl diff -f FILENAME` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | field-manager | | kubectl-client-side-apply | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files contains the configuration to diff | | force-conflicts | | false | If true, server-side apply will force the changes against conflicts. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | prune | | false | Include resources that would be deleted by pruning. Can be used with -l and default shows all resources would be pruned | | prune-allowlist | | \[\] | Overwrite the default whitelist with for --prune | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | server-side | | false | If true, apply runs in the server instead of the client. | | show-managed-fields | | false | If true, include managed fields in the diff. | * * * edit ==== > Edit the service named 'registry' kubectl edit svc/registry > Use an alternative editor KUBE_EDITOR="nano" kubectl edit svc/registry > Edit the job 'myjob' in JSON using the v1 API format kubectl edit job.v1.batch/myjob -o json > Edit the deployment 'mydeployment' in YAML and save the modified config in its annotation kubectl edit deployment/mydeployment -o yaml --save-config > Edit the deployment/mydeployment's status subresource kubectl edit deployment mydeployment --subresource='status' Edit a resource from the default editor. The edit command allows you to directly edit any API resource you can retrieve via the command-line tools. It will open the editor defined by your KUBE\_EDITOR, or EDITOR environment variables, or fall back to 'vi' for Linux or 'notepad' for Windows. You can edit multiple objects, although changes are applied one at a time. The command accepts file names as well as command-line arguments, although the files you point to must be previously saved versions of resources. Editing is done with the API version used to fetch the resource. To edit using a specific API version, fully-qualify the resource, version, and group. The default format is YAML. To edit in JSON, specify "-o json". The flag --windows-line-endings can be used to force Windows line endings, otherwise the default for your operating system will be used. In the event an error occurs while updating, a temporary file will be created on disk that contains your unapplied changes. The most common error when updating a resource is another editor changing the resource on the server. When this occurs, you will have to apply your changes to the newer version of the resource, or update your temporary saved copy to include the latest resource version. ### Usage `$ kubectl edit (RESOURCE/NAME | -f FILENAME)` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | field-manager | | kubectl-edit | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files to use to edit the resource | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | output-patch | | false | Output the patch if the resource is edited. | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | subresource | | | If specified, edit will operate on the subresource of the requested object. Must be one of \[status\]. This flag is alpha and may change in the future. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | | windows-line-endings | | false | Defaults to the line ending native to your platform. | * * * kustomize ========= > Build the current working directory kubectl kustomize > Build some shared configuration directory kubectl kustomize /home/config/production > Build from github kubectl kustomize https://github.com/kubernetes-sigs/kustomize.git/examples/helloWorld?ref=v1.0.6 Build a set of KRM resources using a 'kustomization.yaml' file. The DIR argument must be a path to a directory containing 'kustomization.yaml', or a git repository URL with a path suffix specifying same with respect to the repository root. If DIR is omitted, '.' is assumed. ### Usage `$ kubectl kustomize DIR` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | as-current-user | | false | use the uid and gid of the command executor to run the function in the container | | enable-alpha-plugins | | false | enable kustomize plugins | | enable-helm | | false | Enable use of the Helm chart inflator generator. | | enable-managedby-label | | false | enable adding app.kubernetes.io/managed-by | | env | e | \[\] | a list of environment variables to be used by functions | | helm-command | | helm | helm command (path to executable) | | load-restrictor | | LoadRestrictionsRootOnly | if set to 'LoadRestrictionsNone', local kustomizations may load files from outside their root. This does, however, break the relocatability of the kustomization. | | mount | | \[\] | a list of storage options read from the filesystem | | network | | false | enable network access for functions that declare it | | network-name | | bridge | the docker network to run the container in | | output | o | | If specified, write output to this path. | | reorder | | legacy | Reorder the resources just before output. Use 'legacy' to apply a legacy reordering (Namespaces first, Webhooks last, etc). Use 'none' to suppress a final reordering. | * * * label ===== > Update pod 'foo' with the label 'unhealthy' and the value 'true' kubectl label pods foo unhealthy=true > Update pod 'foo' with the label 'status' and the value 'unhealthy', overwriting any existing value kubectl label --overwrite pods foo status=unhealthy > Update all pods in the namespace kubectl label pods --all status=unhealthy > Update a pod identified by the type and name in "pod.json" kubectl label -f pod.json status=unhealthy > Update pod 'foo' only if the resource is unchanged from version 1 kubectl label pods foo status=unhealthy --resource-version=1 > Update pod 'foo' by removing a label named 'bar' if it exists # Does not require the --overwrite flag kubectl label pods foo bar- Update the labels on a resource. _A label key and value must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to 63 characters each. _Optionally, the key can begin with a DNS subdomain prefix and a single '/', like example.com/my-app. _If --overwrite is true, then existing labels can be overwritten, otherwise attempting to overwrite a label will result in an error. _If --resource-version is specified, then updates will use this resource version, otherwise the existing resource-version will be used. ### Usage `$ kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources, in the namespace of the specified resource types | | all-namespaces | A | false | If true, check the specified action in all namespaces. | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-label | Name of the manager used to track field ownership. | | field-selector | | | Selector (field query) to filter on, supports '=', '==', and '!='.(e.g. --field-selector key1=value1,key2=value2). The server only supports a limited number of field queries per type. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to update the labels | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | list | | false | If true, display the labels for a given resource. | | local | | false | If true, label will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | overwrite | | false | If true, allow labels to be overwritten, otherwise reject label updates that overwrite existing labels. | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | resource-version | | | If non-empty, the labels update will only succeed if this is the current resource-version for the object. Only valid when specifying a single resource. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * patch ===== > Partially update a node using a strategic merge patch, specifying the patch as JSON kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' > Partially update a node using a strategic merge patch, specifying the patch as YAML kubectl patch node k8s-node-1 -p $'spec:\n unschedulable: true' > Partially update a node identified by the type and name specified in "node.json" using strategic merge patch kubectl patch -f node.json -p '{"spec":{"unschedulable":true}}' > Update a container's image; spec.containers\[\*\].name is required because it's a merge key kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' > Update a container's image using a JSON patch with positional arrays kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' > Update a deployment's replicas through the scale subresource using a merge patch. kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}' Update fields of a resource using strategic merge patch, a JSON merge patch, or a JSON patch. JSON and YAML formats are accepted. Note: Strategic merge patch is not supported for custom resources. ### Usage `$ kubectl patch (-f FILENAME | TYPE NAME) [-p PATCH|--patch-file FILE]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-patch | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to update | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | local | | false | If true, patch will operate on the content of the file, not the server-side resource. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | patch | p | | The patch to be applied to the resource JSON file. | | patch-file | | | A file containing a patch to be applied to the resource. | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | subresource | | | If specified, patch will operate on the subresource of the requested object. Must be one of \[status scale\]. This flag is alpha and may change in the future. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | type | | strategic | The type of patch being provided; one of \[json merge strategic\] | * * * replace ======= > Replace a pod using the data in pod.json kubectl replace -f ./pod.json > Replace a pod based on the JSON passed into stdin cat pod.json | kubectl replace -f - > Update a single-container pod's image version (tag) to v4 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - > Force replace, delete and then re-create the resource kubectl replace --force -f ./pod.json Replace a resource by file name or stdin. JSON and YAML formats are accepted. If replacing an existing resource, the complete resource spec must be provided. This can be obtained by $ kubectl get TYPE NAME -o yaml ### Usage `$ kubectl replace -f FILENAME` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | cascade | | background | Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents (e.g. Pods created by a ReplicationController). Defaults to background. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-replace | Name of the manager used to track field ownership. | | filename | f | \[\] | The files that contain the configurations to replace. | | force | | false | If true, immediately remove resources from API and bypass graceful deletion. Note that immediate deletion of some resources may result in inconsistency or data loss and requires confirmation. | | grace-period | | \-1 | Period of time in seconds given to the resource to terminate gracefully. Ignored if negative. Set to 1 for immediate shutdown. Can only be set to 0 when --force is true (force deletion). | | kustomize | k | | Process a kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | raw | | | Raw URI to PUT to the server. Uses the transport specified by the kubeconfig file. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | save-config | | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | subresource | | | If specified, replace will operate on the subresource of the requested object. Must be one of \[status scale\]. This flag is alpha and may change in the future. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | timeout | | 0s | The length of time to wait before giving up on a delete, zero means determine a timeout from the size of the object | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | | wait | | false | If true, wait for resources to be gone before returning. This waits for finalizers. | * * * rollout ======= > Rollback to the previous deployment kubectl rollout undo deployment/abc > Check the rollout status of a daemonset kubectl rollout status daemonset/foo > Restart a deployment kubectl rollout restart deployment/abc > Restart deployments with the app=nginx label kubectl rollout restart deployment --selector=app=nginx Manage the rollout of one or many resources. Valid resource types include: _deployments _daemonsets \* statefulsets ### Usage `$ kubectl rollout SUBCOMMAND` * * * _history_ --------- > View the rollout history of a deployment kubectl rollout history deployment/abc > View the details of daemonset revision 3 kubectl rollout history daemonset/abc --revision=3 View previous rollout revisions and configurations. ### Usage `$ kubectl rollout history (TYPE NAME | TYPE/NAME) [flags]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | revision | | 0 | See the details, including podTemplate of the revision specified | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _pause_ ------- > Mark the nginx deployment as paused # Any current state of the deployment will continue its function; new updates # to the deployment will not have an effect as long as the deployment is paused kubectl rollout pause deployment/nginx Mark the provided resource as paused. Paused resources will not be reconciled by a controller. Use "kubectl rollout resume" to resume a paused resource. Currently only deployments support being paused. ### Usage `$ kubectl rollout pause RESOURCE` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | field-manager | | kubectl-rollout | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _restart_ --------- > Restart a deployment kubectl rollout restart deployment/nginx > Restart a daemon set kubectl rollout restart daemonset/abc > Restart deployments with the app=nginx label kubectl rollout restart deployment --selector=app=nginx Restart a resource. Resource rollout will be restarted. ### Usage `$ kubectl rollout restart RESOURCE` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | field-manager | | kubectl-rollout | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _resume_ -------- > Resume an already paused deployment kubectl rollout resume deployment/nginx Resume a paused resource. Paused resources will not be reconciled by a controller. By resuming a resource, we allow it to be reconciled again. Currently only deployments support being resumed. ### Usage `$ kubectl rollout resume RESOURCE` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | field-manager | | kubectl-rollout | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _status_ -------- > Watch the rollout status of a deployment kubectl rollout status deployment/nginx Show the status of the rollout. By default 'rollout status' will watch the status of the latest rollout until it's done. If you don't want to wait for the rollout to finish then you can use --watch=false. Note that if a new rollout starts in-between, then 'rollout status' will continue watching the latest revision. If you want to pin to a specific revision and abort if it is rolled over by another revision, use --revision=N where N is the revision you need to watch for. ### Usage `$ kubectl rollout status (TYPE NAME | TYPE/NAME) [flags]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | revision | | 0 | Pin to a specific revision for showing its status. Defaults to 0 (last revision). | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | timeout | | 0s | The length of time to wait before ending watch, zero means never. Any other values should contain a corresponding time unit (e.g. 1s, 2m, 3h). | | watch | w | true | Watch the status of the rollout until it's done. | * * * _undo_ ------ > Roll back to the previous deployment kubectl rollout undo deployment/abc > Roll back to daemonset revision 3 kubectl rollout undo daemonset/abc --to-revision=3 > Roll back to the previous deployment with dry-run kubectl rollout undo --dry-run=server deployment/abc Roll back to a previous rollout. ### Usage `$ kubectl rollout undo (TYPE NAME | TYPE/NAME) [flags]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | to-revision | | 0 | The revision to rollback to. Default to 0 (last revision). | * * * scale ===== > Scale a replica set named 'foo' to 3 kubectl scale --replicas=3 rs/foo > Scale a resource identified by type and name specified in "foo.yaml" to 3 kubectl scale --replicas=3 -f foo.yaml > If the deployment named mysql's current size is 2, scale mysql to 3 kubectl scale --current-replicas=2 --replicas=3 deployment/mysql > Scale multiple replication controllers kubectl scale --replicas=5 rc/foo rc/bar rc/baz > Scale stateful set named 'web' to 3 kubectl scale --replicas=3 statefulset/web Set a new size for a deployment, replica set, replication controller, or stateful set. Scale also allows users to specify one or more preconditions for the scale action. If --current-replicas or --resource-version is specified, it is validated before the scale is attempted, and it is guaranteed that the precondition holds true when the scale is sent to the server. ### Usage `$ kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources in the namespace of the specified resource types | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | current-replicas | | \-1 | Precondition for current size. Requires that the current size of the resource match this value in order to scale. -1 (default) for no condition. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to set a new size | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | replicas | | 0 | The new desired number of replicas. Required. | | resource-version | | | Precondition for resource version. Requires that the current resource version match this value in order to scale. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | timeout | | 0s | The length of time to wait before giving up on a scale operation, zero means don't wait. Any other values should contain a corresponding time unit (e.g. 1s, 2m, 3h). | * * * set === Configure application resources. These commands help you make changes to existing application resources. ### Usage `$ kubectl set SUBCOMMAND` * * * _env_ ----- > Update deployment 'registry' with a new environment variable kubectl set env deployment/registry STORAGE_DIR=/local > List the environment variables defined on a deployments 'sample-build' kubectl set env deployment/sample-build --list > List the environment variables defined on all pods kubectl set env pods --all --list > Output modified deployment in YAML, and does not alter the object on the server kubectl set env deployment/sample-build STORAGE_DIR=/data -o yaml > Update all containers in all replication controllers in the project to have ENV=prod kubectl set env rc --all ENV=prod > Import environment from a secret kubectl set env --from=secret/mysecret deployment/myapp > Import environment from a config map with a prefix kubectl set env --from=configmap/myconfigmap --prefix=MYSQL_ deployment/myapp > Import specific keys from a config map kubectl set env --keys=my-example-key --from=configmap/myconfigmap deployment/myapp > Remove the environment variable ENV from container 'c1' in all deployment configs kubectl set env deployments --all --containers="c1" ENV- > Remove the environment variable ENV from a deployment definition on disk and # update the deployment config on the server kubectl set env -f deploy.json ENV- > Set some of the local shell environment into a deployment config on the server env | grep RAILS_ | kubectl set env -e - deployment/registry Update environment variables on a pod template. List environment variable definitions in one or more pods, pod templates. Add, update, or remove container environment variable definitions in one or more pod templates (within replication controllers or deployment configurations). View or modify the environment variable definitions on all containers in the specified pods or pod templates, or just those that match a wildcard. If "--env -" is passed, environment variables can be read from STDIN using the standard env syntax. Possible resources include (case insensitive): pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs) ### Usage `$ kubectl set env RESOURCE/NAME KEY_1=VAL_1 ... KEY_N=VAL_N` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | If true, select all resources in the namespace of the specified resource types | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | containers | c | \* | The names of containers in the selected pod templates to change - may use wildcards | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | env | e | \[\] | Specify a key-value pair for an environment variable to set into each container. | | field-manager | | kubectl-set | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files the resource to update the env | | from | | | The name of a resource from which to inject environment variables | | keys | | \[\] | Comma-separated list of keys to import from specified resource | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | list | | false | If true, display the environment and any changes in the standard format. this flag will removed when we have kubectl view env. | | local | | false | If true, set env will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | overwrite | | true | If true, allow environment to be overwritten, otherwise reject updates that overwrite existing environment. | | prefix | | | Prefix to append to variable names | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | resolve | | false | If true, show secret or configmap references when listing variables | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _image_ ------- > Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox' kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1 > Update all deployments' and rc's nginx container's image to 'nginx:1.9.1' kubectl set image deployments,rc nginx=nginx:1.9.1 --all > Update image of all containers of daemonset abc to 'nginx:1.9.1' kubectl set image daemonset abc *=nginx:1.9.1 > Print result (in yaml format) of updating nginx container image from local file, without hitting the server kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml Update existing container image(s) of resources. Possible resources include (case insensitive): pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs) ### Usage `$ kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources, in the namespace of the specified resource types | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-set | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | local | | false | If true, set image will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _resources_ ----------- > Set a deployments nginx container cpu limits to "200m" and memory to "512Mi" kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi > Set the resource request and limits for all containers in nginx kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi > Remove the resource requests for resources on containers in nginx kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0 > Print the result (in yaml format) of updating nginx container limits from a local, without hitting the server kubectl set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml Specify compute resource requirements (CPU, memory) for any resource that defines a pod template. If a pod is successfully scheduled, it is guaranteed the amount of resource requested, but may burst up to its specified limits. For each compute resource, if a limit is specified and a request is omitted, the request will default to the limit. Possible resources include (case insensitive): Use "kubectl api-resources" for a complete list of supported resources.. ### Usage `$ kubectl set resources (-f FILENAME | TYPE NAME) ([--limits=LIMITS & --requests=REQUESTS]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources, in the namespace of the specified resource types | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | containers | c | \* | The names of containers in the selected pod templates to change, all containers are selected by default - may use wildcards | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-set | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | limits | | | The resource requirement requests for this container. For example, 'cpu=100m,memory=256Mi'. Note that server side components may assign requests depending on the server configuration, such as limit ranges. | | local | | false | If true, set resources will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | requests | | | The resource requirement requests for this container. For example, 'cpu=100m,memory=256Mi'. Note that server side components may assign requests depending on the server configuration, such as limit ranges. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _selector_ ---------- > Set the labels and selector before creating a deployment/service pair kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f - kubectl create deployment my-dep -o yaml --dry-run=client | kubectl label --local -f - environment=qa -o yaml | kubectl create -f - Set the selector on a resource. Note that the new selector will overwrite the old selector if the resource had one prior to the invocation of 'set selector'. A selector must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to 63 characters. If --resource-version is specified, then updates will use this resource version, otherwise the existing resource-version will be used. Note: currently selectors can only be set on Service objects. ### Usage `$ kubectl set selector (-f FILENAME | TYPE NAME) EXPRESSIONS [--resource-version=version]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources in the namespace of the specified resource types | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-set | Name of the manager used to track field ownership. | | filename | f | \[\] | identifying the resource. | | local | | false | If true, annotation will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | true | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | resource-version | | | If non-empty, the selectors update will only succeed if this is the current resource-version for the object. Only valid when specifying a single resource. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _serviceaccount_ ---------------- > Set deployment nginx-deployment's service account to serviceaccount1 kubectl set serviceaccount deployment nginx-deployment serviceaccount1 > Print the result (in YAML format) of updated nginx deployment with the service account from local file, without hitting the API server kubectl set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run=client -o yaml Update the service account of pod template resources. Possible resources (case insensitive) can be: replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs), statefulset ### Usage `$ kubectl set serviceaccount (-f FILENAME | TYPE NAME) SERVICE_ACCOUNT` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources, in the namespace of the specified resource types | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-set | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to get from a server. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | local | | false | If true, set serviceaccount will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | record | | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _subject_ --------- > Update a cluster role binding for serviceaccount1 kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1 > Update a role binding for user1, user2, and group1 kubectl set subject rolebinding admin --user=user1 --user=user2 --group=group1 > Print the result (in YAML format) of updating rolebinding subjects from a local, without hitting the server kubectl create rolebinding admin --role=admin --user=admin -o yaml --dry-run=client | kubectl set subject --local -f - --user=foo -o yaml Update the user, group, or service account in a role binding or cluster role binding. ### Usage `$ kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources, in the namespace of the specified resource types | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-set | Name of the manager used to track field ownership. | | filename | f | \[\] | Filename, directory, or URL to files the resource to update the subjects | | group | | \[\] | Groups to bind to the role | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | local | | false | If true, set subject will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | serviceaccount | | \[\] | Service accounts to bind to the role | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | user | | \[\] | Usernames to bind to the role | * * * wait ==== > Wait for the pod "busybox1" to contain the status condition of type "Ready" kubectl wait --for=condition=Ready pod/busybox1 > The default value of status condition is true; you can wait for other targets after an equal delimiter (compared after Unicode simple case folding, which is a more general form of case-insensitivity): kubectl wait --for=condition=Ready=false pod/busybox1 > Wait for the pod "busybox1" to contain the status phase to be "Running". kubectl wait --for=jsonpath='{.status.phase}'=Running pod/busybox1 > Wait for the pod "busybox1" to be deleted, with a timeout of 60s, after having issued the "delete" command kubectl delete pod/busybox1 kubectl wait --for=delete pod/busybox1 --timeout=60s Experimental: Wait for a specific condition on one or many resources. The command takes multiple resources and waits until the specified condition is seen in the Status field of every given resource. Alternatively, the command can wait for the given set of resources to be deleted by providing the "delete" keyword as the value to the --for flag. A successful message will be printed to stdout indicating when the specified condition has been met. You can use -o option to change to output destination. ### Usage `$ kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available|--for=jsonpath='{}'=value]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all resources in the namespace of the specified resource types | | all-namespaces | A | false | If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace. | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | field-selector | | | Selector (field query) to filter on, supports '=', '==', and '!='.(e.g. --field-selector key1=value1,key2=value2). The server only supports a limited number of field queries per type. | | filename | f | \[\] | identifying the resource. | | for | | | The condition to wait on: \[delete\|condition=condition-name\[\=condition-value\]\|jsonpath='{JSONPath expression}'=JSONPath Condition\]. The default condition-value is true. Condition values are compared after Unicode simple case folding, which is a more general form of case-insensitivity. | | local | | false | If true, annotation will NOT contact api-server but run locally. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | true | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2) | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | timeout | | 30s | The length of time to wait before giving up. Zero means check once and don't wait, negative means wait for a week. | **WORKING WITH APPS** ===================== This section contains commands for inspecting and debugging your applications. * `logs` will print the logs from the specified pod + container. * `exec` can be used to get an interactive shell on a pod + container. * `describe` will print debug information about the given resource. * * * attach ====== > Get output from running pod mypod; use the 'kubectl.kubernetes.io/default-container' annotation # for selecting the container to be attached or the first container in the pod will be chosen kubectl attach mypod > Get output from ruby-container from pod mypod kubectl attach mypod -c ruby-container > Switch to raw terminal mode; sends stdin to 'bash' in ruby-container from pod mypod # and sends stdout/stderr from 'bash' back to the client kubectl attach mypod -c ruby-container -i -t > Get output from the first pod of a replica set named nginx kubectl attach rs/nginx Attach to a process that is already running inside an existing container. ### Usage `$ kubectl attach (POD | TYPE/NAME) -c CONTAINER` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | container | c | | Container name. If omitted, use the kubectl.kubernetes.io/default-container annotation for selecting the container to be attached or the first container in the pod will be chosen | | pod-running-timeout | | 1m0s | The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running | | quiet | q | false | Only print output from the remote session | | stdin | i | false | Pass stdin to the container | | tty | t | false | Stdin is a TTY | * * * auth ==== Inspect authorization ### Usage `$ kubectl auth` * * * _can-i_ ------- > Check to see if I can create pods in any namespace kubectl auth can-i create pods --all-namespaces > Check to see if I can list deployments in my current namespace kubectl auth can-i list deployments.apps > Check to see if I can do everything in my current namespace ("\*" means all) kubectl auth can-i '*' '*' > Check to see if I can get the job named "bar" in namespace "foo" kubectl auth can-i list jobs.batch/bar -n foo > Check to see if I can read pod logs kubectl auth can-i get pods --subresource=log > Check to see if I can access the URL /logs/ kubectl auth can-i get /logs/ > List all allowed actions in namespace "foo" kubectl auth can-i --list --namespace=foo Check whether an action is allowed. VERB is a logical Kubernetes API verb like 'get', 'list', 'watch', 'delete', etc. TYPE is a Kubernetes resource. Shortcuts and groups will be resolved. NONRESOURCEURL is a partial URL that starts with "/". NAME is the name of a particular Kubernetes resource. This command pairs nicely with impersonation. See --as global flag. ### Usage `$ kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all-namespaces | A | false | If true, check the specified action in all namespaces. | | list | | false | If true, prints all allowed actions. | | no-headers | | false | If true, prints allowed actions without headers | | quiet | q | false | If true, suppress output and just return the exit code. | | subresource | | | SubResource such as pod/log or deployment/scale | * * * _reconcile_ ----------- > Reconcile RBAC resources from a file kubectl auth reconcile -f my-rbac-rules.yaml Reconciles rules for RBAC role, role binding, cluster role, and cluster role binding objects. Missing objects are created, and the containing namespace is created for namespaced objects, if required. Existing roles are updated to include the permissions in the input objects, and remove extra permissions if --remove-extra-permissions is specified. Existing bindings are updated to include the subjects in the input objects, and remove extra subjects if --remove-extra-subjects is specified. This is preferred to 'apply' for RBAC resources so that semantically-aware merging of rules and subjects is done. ### Usage `$ kubectl auth reconcile -f FILENAME` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to reconcile. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | remove-extra-permissions | | false | If true, removes extra permissions added to roles | | remove-extra-subjects | | false | If true, removes extra subjects added to rolebindings | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * cp == > !!!Important Note!!! # Requires that the 'tar' binary is present in your container # image. If 'tar' is not present, 'kubectl cp' will fail. # # For advanced use cases, such as symlinks, wildcard expansion or # file mode preservation, consider using 'kubectl exec'. # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace tar cf - /tmp/foo | kubectl exec -i -n -- tar xf - -C /tmp/bar > Copy /tmp/foo from a remote pod to /tmp/bar locally kubectl exec -n -- tar cf - /tmp/foo | tar xf - -C /tmp/bar > Copy /tmp/foo\_dir local directory to /tmp/bar\_dir in a remote pod in the default namespace kubectl cp /tmp/foo_dir :/tmp/bar_dir > Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container kubectl cp /tmp/foo :/tmp/bar -c > Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace kubectl cp /tmp/foo /:/tmp/bar > Copy /tmp/foo from a remote pod to /tmp/bar locally kubectl cp /:/tmp/foo /tmp/bar Copy files and directories to and from containers. ### Usage `$ kubectl cp ` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | container | c | | Container name. If omitted, use the kubectl.kubernetes.io/default-container annotation for selecting the container to be attached or the first container in the pod will be chosen | | no-preserve | | false | The copied file/directory's ownership and permissions will not be preserved in the container | | retries | | 0 | Set number of retries to complete a copy operation from a container. Specify 0 to disable or any negative value for infinite retrying. The default is 0 (no retry). | * * * describe ======== > Describe a node kubectl describe nodes kubernetes-node-emt8.c.myproject.internal > Describe a pod kubectl describe pods/nginx > Describe a pod identified by type and name in "pod.json" kubectl describe -f pod.json > Describe all pods kubectl describe pods > Describe pods by label name=myLabel kubectl describe po -l name=myLabel > Describe all pods managed by the 'frontend' replication controller # (rc-created pods get the name of the rc as a prefix in the pod name) kubectl describe pods frontend Show details of a specific resource or group of resources. Print a detailed description of the selected resources, including related resources such as events or controllers. You may select a single object by name, all objects of that type, provide a name prefix, or label selector. For example: $ kubectl describe TYPE NAME\_PREFIX will first check for an exact match on TYPE and NAME\_PREFIX. If no such resource exists, it will output details for every resource that has a name prefixed with NAME\_PREFIX. Use "kubectl api-resources" for a complete list of supported resources. ### Usage `$ kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all-namespaces | A | false | If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace. | | chunk-size | | 500 | Return large lists in chunks rather than all at once. Pass 0 to disable. This flag is beta and may change in the future. | | filename | f | \[\] | Filename, directory, or URL to files containing the resource to describe | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-events | | true | If true, display events related to the described object. | * * * events ====== > List recent events in the default namespace. kubectl events > List recent events in all namespaces. kubectl events --all-namespaces > List recent events for the specified pod, then wait for more events and list them as they arrive. kubectl events --for pod/web-pod-13je7 --watch > List recent events in given format. Supported ones, apart from default, are json and yaml. kubectl events -oyaml > List recent only events in given event types kubectl events --types=Warning,Normal Display events Prints a table of the most important information about events. You can request events for a namespace, for all namespace, or filtered to only those pertaining to a specified resource. ### Usage `$ kubectl events [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file] [--for TYPE/NAME] [--watch] [--event=Normal,Warning]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all-namespaces | A | false | If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace. | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | chunk-size | | 500 | Return large lists in chunks rather than all at once. Pass 0 to disable. This flag is beta and may change in the future. | | for | | | Filter events to only those pertaining to the specified resource. | | no-headers | | false | When using the default output format, don't print headers. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | types | | \[\] | Output only events of given types. | | watch | w | false | After listing the requested events, watch for more events. | * * * exec ==== > Get output from running the 'date' command from pod mypod, using the first container by default kubectl exec mypod -- date > Get output from running the 'date' command in ruby-container from pod mypod kubectl exec mypod -c ruby-container -- date > Switch to raw terminal mode; sends stdin to 'bash' in ruby-container from pod mypod # and sends stdout/stderr from 'bash' back to the client kubectl exec mypod -c ruby-container -i -t -- bash -il > List contents of /usr from the first container of pod mypod and sort by modification time # If the command you want to execute in the pod has any flags in common (e.g. -i), # you must use two dashes (--) to separate your command's flags/arguments # Also note, do not surround your command and its flags/arguments with quotes # unless that is how you would execute it normally (i.e., do ls -t /usr, not "ls -t /usr") kubectl exec mypod -i -t -- ls -t /usr > Get output from running 'date' command from the first pod of the deployment mydeployment, using the first container by default kubectl exec deploy/mydeployment -- date > Get output from running 'date' command from the first pod of the service myservice, using the first container by default kubectl exec svc/myservice -- date Execute a command in a container. ### Usage `$ kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | container | c | | Container name. If omitted, use the kubectl.kubernetes.io/default-container annotation for selecting the container to be attached or the first container in the pod will be chosen | | filename | f | \[\] | to use to exec into the resource | | pod-running-timeout | | 1m0s | The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running | | quiet | q | false | Only print output from the remote session | | stdin | i | false | Pass stdin to the container | | tty | t | false | Stdin is a TTY | * * * logs ==== > Return snapshot logs from pod nginx with only one container kubectl logs nginx > Return snapshot logs from pod nginx with multi containers kubectl logs nginx --all-containers=true > Return snapshot logs from all containers in pods defined by label app=nginx kubectl logs -l app=nginx --all-containers=true > Return snapshot of previous terminated ruby container logs from pod web-1 kubectl logs -p -c ruby web-1 > Begin streaming the logs of the ruby container in pod web-1 kubectl logs -f -c ruby web-1 > Begin streaming the logs from all containers in pods defined by label app=nginx kubectl logs -f -l app=nginx --all-containers=true > Display only the most recent 20 lines of output in pod nginx kubectl logs --tail=20 nginx > Show all logs from pod nginx written in the last hour kubectl logs --since=1h nginx > Show logs from a kubelet with an expired serving certificate kubectl logs --insecure-skip-tls-verify-backend nginx > Return snapshot logs from first container of a job named hello kubectl logs job/hello > Return snapshot logs from container nginx-1 of a deployment named nginx kubectl logs deployment/nginx -c nginx-1 Print the logs for a container in a pod or specified resource. If the pod has only one container, the container name is optional. ### Usage `$ kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all-containers | | false | Get all containers' logs in the pod(s). | | container | c | | Print the logs of this container | | follow | f | false | Specify if the logs should be streamed. | | ignore-errors | | false | If watching / following pod logs, allow for any errors that occur to be non-fatal | | insecure-skip-tls-verify-backend | | false | Skip verifying the identity of the kubelet that logs are requested from. In theory, an attacker could provide invalid log content back. You might want to use this if your kubelet serving certificates have expired. | | limit-bytes | | 0 | Maximum bytes of logs to return. Defaults to no limit. | | max-log-requests | | 5 | Specify maximum number of concurrent logs to follow when using by a selector. Defaults to 5. | | pod-running-timeout | | 20s | The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running | | prefix | | false | Prefix each log line with the log source (pod name and container name) | | previous | p | false | If true, print the logs for the previous instance of the container in a pod if it exists. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | since | | 0s | Only return logs newer than a relative duration like 5s, 2m, or 3h. Defaults to all logs. Only one of since-time / since may be used. | | since-time | | | Only return logs after a specific date (RFC3339). Defaults to all logs. Only one of since-time / since may be used. | | tail | | \-1 | Lines of recent log file to display. Defaults to -1 with no selector, showing all log lines otherwise 10, if a selector is provided. | | timestamps | | false | Include timestamps on each line in the log output | * * * port-forward ============ > Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod kubectl port-forward pod/mypod 5000 6000 > Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the deployment kubectl port-forward deployment/mydeployment 5000 6000 > Listen on port 8443 locally, forwarding to the targetPort of the service's port named "https" in a pod selected by the service kubectl port-forward service/myservice 8443:https > Listen on port 8888 locally, forwarding to 5000 in the pod kubectl port-forward pod/mypod 8888:5000 > Listen on port 8888 on all addresses, forwarding to 5000 in the pod kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000 > Listen on port 8888 on localhost and selected IP, forwarding to 5000 in the pod kubectl port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000 > Listen on a random port locally, forwarding to 5000 in the pod kubectl port-forward pod/mypod :5000 Forward one or more local ports to a pod. Use resource type/name such as deployment/mydeployment to select a pod. Resource type defaults to 'pod' if omitted. If there are multiple pods matching the criteria, a pod will be selected automatically. The forwarding session ends when the selected pod terminates, and a rerun of the command is needed to resume forwarding. ### Usage `$ kubectl port-forward TYPE/NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | address | | \[localhost\] | Addresses to listen on (comma separated). Only accepts IP addresses or localhost as a value. When localhost is supplied, kubectl will try to bind on both 127.0.0.1 and ::1 and will fail if neither of these addresses are available to bind. | | pod-running-timeout | | 1m0s | The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running | * * * proxy ===== > To proxy all of the Kubernetes API and nothing else kubectl proxy --api-prefix=/ > To proxy only part of the Kubernetes API and also some static files # You can get pods info with 'curl localhost:8001/api/v1/pods' kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/ > To proxy the entire Kubernetes API at a different root # You can get pods info with 'curl localhost:8001/custom/api/v1/pods' kubectl proxy --api-prefix=/custom/ > Run a proxy to the Kubernetes API server on port 8011, serving static content from ./local/www/ kubectl proxy --port=8011 --www=./local/www/ > Run a proxy to the Kubernetes API server on an arbitrary local port # The chosen port for the server will be output to stdout kubectl proxy --port=0 > Run a proxy to the Kubernetes API server, changing the API prefix to k8s-api # This makes e.g. the pods API available at localhost:8001/k8s-api/v1/pods/ kubectl proxy --api-prefix=/k8s-api Creates a proxy server or application-level gateway between localhost and the Kubernetes API server. It also allows serving static content over specified HTTP path. All incoming data enters through one port and gets forwarded to the remote Kubernetes API server port, except for the path matching the static content path. ### Usage `$ kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | accept-hosts | | ^localhost$,^127.0.0.1$,^\[::1\]$ | Regular expression for hosts that the proxy should accept. | | accept-paths | | ^.\* | Regular expression for paths that the proxy should accept. | | address | | 127.0.0.1 | The IP address on which to serve on. | | api-prefix | | / | Prefix to serve the proxied API under. | | append-server-path | | false | If true, enables automatic path appending of the kube context server path to each request. | | disable-filter | | false | If true, disable request filtering in the proxy. This is dangerous, and can leave you vulnerable to XSRF attacks, when used with an accessible port. | | keepalive | | 0s | keepalive specifies the keep-alive period for an active network connection. Set to 0 to disable keepalive. | | port | p | 8001 | The port on which to run the proxy. Set to 0 to pick a random port. | | reject-methods | | ^$ | Regular expression for HTTP methods that the proxy should reject (example --reject-methods='POST,PUT,PATCH'). | | reject-paths | | ^/api/._/pods/._/exec,^/api/._/pods/._/attach | Regular expression for paths that the proxy should reject. Paths specified here will be rejected even accepted by --accept-paths. | | unix-socket | u | | Unix socket on which to run the proxy. | | www | w | | Also serve static files from the given directory under the specified prefix. | | www-prefix | P | /static/ | Prefix to serve static files under, if static file directory is specified. | * * * top === Display Resource (CPU/Memory) usage. The top command allows you to see the resource consumption for nodes or pods. This command requires Metrics Server to be correctly configured and working on the server. ### Usage `$ kubectl top` * * * _node_ ------ > Show metrics for all nodes kubectl top node > Show metrics for a given node kubectl top node NODE_NAME Display resource (CPU/memory) usage of nodes. The top-node command allows you to see the resource consumption of nodes. ### Usage `$ kubectl top node [NAME | -l label]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | no-headers | | false | If present, print output without headers | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-capacity | | false | Print node resources based on Capacity instead of Allocatable(default) of the nodes. | | sort-by | | | If non-empty, sort nodes list using specified field. The field can be either 'cpu' or 'memory'. | | use-protocol-buffers | | true | Enables using protocol-buffers to access Metrics API. | * * * _pod_ ----- > Show metrics for all pods in the default namespace kubectl top pod > Show metrics for all pods in the given namespace kubectl top pod --namespace=NAMESPACE > Show metrics for a given pod and its containers kubectl top pod POD_NAME --containers > Show metrics for the pods defined by label name=myLabel kubectl top pod -l name=myLabel Display resource (CPU/memory) usage of pods. The 'top pod' command allows you to see the resource consumption of pods. Due to the metrics pipeline delay, they may be unavailable for a few minutes since pod creation. ### Usage `$ kubectl top pod [NAME | -l label]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all-namespaces | A | false | If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace. | | containers | | false | If present, print usage of containers within a pod. | | field-selector | | | Selector (field query) to filter on, supports '=', '==', and '!='.(e.g. --field-selector key1=value1,key2=value2). The server only supports a limited number of field queries per type. | | no-headers | | false | If present, print output without headers. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | sort-by | | | If non-empty, sort pods list using specified field. The field can be either 'cpu' or 'memory'. | | sum | | false | Print the sum of the resource usage | | use-protocol-buffers | | true | Enables using protocol-buffers to access Metrics API. | **CLUSTER MANAGEMENT** ====================== * * * api-versions ============ > Print the supported API versions kubectl api-versions Print the supported API versions on the server, in the form of "group/version". ### Usage `$ kubectl api-versions` * * * api-resources ============= > Print the supported API resources kubectl api-resources > Print the supported API resources with more information kubectl api-resources -o wide > Print the supported API resources sorted by a column kubectl api-resources --sort-by=name > Print the supported namespaced resources kubectl api-resources --namespaced=true > Print the supported non-namespaced resources kubectl api-resources --namespaced=false > Print the supported API resources with a specific APIGroup kubectl api-resources --api-group=rbac.authorization.k8s.io Print the supported API resources on the server. ### Usage `$ kubectl api-resources` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | api-group | | | Limit to resources in the specified API group. | | cached | | false | Use the cached list of resources if available. | | categories | | \[\] | Limit to resources that belong the the specified categories. | | namespaced | | true | If false, non-namespaced resources will be returned, otherwise returning namespaced resources by default. | | no-headers | | false | When using the default or custom-column output format, don't print headers (default print headers). | | output | o | | Output format. One of: (wide, name). | | sort-by | | | If non-empty, sort list of resources using specified field. The field can be either 'name' or 'kind'. | | verbs | | \[\] | Limit to resources that support the specified verbs. | * * * certificate =========== Modify certificate resources. ### Usage `$ kubectl certificate SUBCOMMAND` * * * _approve_ --------- > Approve CSR 'csr-sqgzp' kubectl certificate approve csr-sqgzp Approve a certificate signing request. kubectl certificate approve allows a cluster admin to approve a certificate signing request (CSR). This action tells a certificate signing controller to issue a certificate to the requestor with the attributes requested in the CSR. SECURITY NOTICE: Depending on the requested attributes, the issued certificate can potentially grant a requester access to cluster resources or to authenticate as a requested identity. Before approving a CSR, ensure you understand what the signed certificate can do. ### Usage `$ kubectl certificate approve (-f FILENAME | NAME)` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to update | | force | | false | Update the CSR even if it is already approved. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * _deny_ ------ > Deny CSR 'csr-sqgzp' kubectl certificate deny csr-sqgzp Deny a certificate signing request. kubectl certificate deny allows a cluster admin to deny a certificate signing request (CSR). This action tells a certificate signing controller to not to issue a certificate to the requestor. ### Usage `$ kubectl certificate deny (-f FILENAME | NAME)` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | filename | f | \[\] | Filename, directory, or URL to files identifying the resource to update | | force | | false | Update the CSR even if it is already denied. | | kustomize | k | | Process the kustomization directory. This flag can't be used together with -f or -R. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * cluster-info ============ > Print the address of the control plane and cluster services kubectl cluster-info Display addresses of the control plane and services with label kubernetes.io/cluster-service=true. To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. ### Usage `$ kubectl cluster-info` * * * _dump_ ------ > Dump current cluster state to stdout kubectl cluster-info dump > Dump current cluster state to /path/to/cluster-state kubectl cluster-info dump --output-directory=/path/to/cluster-state > Dump all namespaces to stdout kubectl cluster-info dump --all-namespaces > Dump a set of namespaces to /path/to/cluster-state kubectl cluster-info dump --namespaces default,kube-system --output-directory=/path/to/cluster-state Dump cluster information out suitable for debugging and diagnosing cluster problems. By default, dumps everything to stdout. You can optionally specify a directory with --output-directory. If you specify a directory, Kubernetes will build a set of files in that directory. By default, only dumps things in the current namespace and 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces. The command also dumps the logs of all of the pods in the cluster; these logs are dumped into different directories based on namespace and pod name. ### Usage `$ kubectl cluster-info dump` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all-namespaces | A | false | If true, dump all namespaces. If true, --namespaces is ignored. | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | namespaces | | \[\] | A comma separated list of namespaces to dump. | | output | o | json | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | output-directory | | | Where to output the files. If empty or '-' uses stdout, otherwise creates a directory hierarchy in that directory | | pod-running-timeout | | 20s | The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * cordon ====== > Mark node "foo" as unschedulable kubectl cordon foo Mark node as unschedulable. ### Usage `$ kubectl cordon NODE` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | * * * drain ===== > Drain node "foo", even if there are pods not managed by a replication controller, replica set, job, daemon set or stateful set on it kubectl drain foo --force > As above, but abort if there are pods not managed by a replication controller, replica set, job, daemon set or stateful set, and use a grace period of 15 minutes kubectl drain foo --grace-period=900 Drain node in preparation for maintenance. The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the API server supports [https://kubernetes.io/docs/concepts/workloads/pods/disruptions/](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) eviction [https://kubernetes.io/docs/concepts/workloads/pods/disruptions/](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) . Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are daemon set-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any daemon set-managed pods, because those pods would be immediately replaced by the daemon set controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by a replication controller, replica set, daemon set, stateful set, or job, then drain will not delete any pods unless you use --force. --force will also allow deletion to proceed if the managing resource of one or more pods is missing. 'drain' waits for graceful termination. You should not operate on the machine until the command completes. When you are ready to put the node back into service, use kubectl uncordon, which will make the node schedulable again. [https://kubernetes.io/images/docs/kubectl\_drain.svg](https://kubernetes.io/images/docs/kubectl_drain.svg) Workflow[https://kubernetes.io/images/docs/kubectl\_drain.svg](https://kubernetes.io/images/docs/kubectl_drain.svg) ### Usage `$ kubectl drain NODE` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | chunk-size | | 500 | Return large lists in chunks rather than all at once. Pass 0 to disable. This flag is beta and may change in the future. | | delete-emptydir-data | | false | Continue even if there are pods using emptyDir (local data that will be deleted when the node is drained). | | delete-local-data | | false | Continue even if there are pods using emptyDir (local data that will be deleted when the node is drained). | | disable-eviction | | false | Force drain to use delete, even if eviction is supported. This will bypass checking PodDisruptionBudgets, use with caution. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | force | | false | Continue even if there are pods that do not declare a controller. | | grace-period | | \-1 | Period of time in seconds given to each pod to terminate gracefully. If negative, the default value specified in the pod will be used. | | ignore-daemonsets | | false | Ignore DaemonSet-managed pods. | | pod-selector | | | Label selector to filter pods on the node | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | skip-wait-for-delete-timeout | | 0 | If pod DeletionTimestamp older than N seconds, skip waiting for the pod. Seconds must be greater than 0 to skip. | | timeout | | 0s | The length of time to wait before giving up, zero means infinite | * * * taint ===== > Update node 'foo' with a taint with key 'dedicated' and value 'special-user' and effect 'NoSchedule' # If a taint with that key and effect already exists, its value is replaced as specified kubectl taint nodes foo dedicated=special-user:NoSchedule > Remove from node 'foo' the taint with key 'dedicated' and effect 'NoSchedule' if one exists kubectl taint nodes foo dedicated:NoSchedule- > Remove from node 'foo' all the taints with key 'dedicated' kubectl taint nodes foo dedicated- > Add a taint with key 'dedicated' on nodes having label mylabel=X kubectl taint node -l myLabel=X dedicated=foo:PreferNoSchedule > Add to node 'foo' a taint with key 'bar' and no value kubectl taint nodes foo bar:NoSchedule Update the taints on one or more nodes. _A taint consists of a key, value, and effect. As an argument here, it is expressed as key=value:effect. _The key must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to 253 characters. _Optionally, the key can begin with a DNS subdomain prefix and a single '/', like example.com/my-app. _The value is optional. If given, it must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to 63 characters. _The effect must be NoSchedule, PreferNoSchedule or NoExecute. _Currently taint can only apply to node. ### Usage `$ kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | all | | false | Select all nodes in the cluster | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | field-manager | | kubectl-taint | Name of the manager used to track field ownership. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | overwrite | | false | If true, allow taints to be overwritten, otherwise reject taint updates that overwrite existing taints. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | | validate | | strict | Must be one of: strict (or true), warn, ignore (or false).
"true" or "strict" will use a schema to validate the input and fail the request if invalid. It will perform server side validation if ServerSideFieldValidation is enabled on the api-server, but will fall back to less reliable client-side validation if not.
"warn" will warn about unknown or duplicate fields without blocking the request if server-side field validation is enabled on the API server, and behave as "ignore" otherwise.
"false" or "ignore" will not perform any schema validation, silently dropping any unknown or duplicate fields. | * * * uncordon ======== > Mark node "foo" as schedulable kubectl uncordon foo Mark node as schedulable. ### Usage `$ kubectl uncordon NODE` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | dry-run | | none | Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource. | | selector | l | | Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. | **KUBECTL SETTINGS AND USAGE** ============================== * * * alpha ===== These commands correspond to alpha features that are not enabled in Kubernetes clusters by default. ### Usage `$ kubectl alpha` * * * _auth_ ------ Inspect authorization ### Usage `$ kubectl alpha auth` * * * _auth whoami_ ------------- > Get your subject attributes. kubectl alpha auth whoami > Get your subject attributes in JSON format. kubectl alpha auth whoami -o json Experimental: Check who you are and your attributes (groups, extra). This command is helpful to get yourself aware of the current user attributes, especially when dynamic authentication, e.g., token webhook, auth proxy, or OIDC provider, is enabled in the Kubernetes cluster. ### Usage `$ kubectl alpha auth whoami` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | output | o | | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * completion ========== > Installing bash completion on macOS using homebrew ## If running Bash 3.2 included with macOS brew install bash-completion > or, if running Bash 4.1+ brew install bash-completion@2 > If kubectl is installed via homebrew, this should start working immediately ## If you've installed via other means, you may need add the completion to your completion directory kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl > Installing bash completion on Linux ## If bash-completion is not installed on Linux, install the 'bash-completion' package ## via your distribution's package manager. ## Load the kubectl completion code for bash into the current shell source <(kubectl completion bash) > Write bash completion code to a file and source it from .bash\_profile kubectl completion bash > ~/.kube/completion.bash.inc printf " > Kubectl shell completion source '$HOME/.kube/completion.bash.inc' " >> $HOME/.bash_profile source $HOME/.bash_profile > Load the kubectl completion code for zsh\[1\] into the current shell source <(kubectl completion zsh) > Set the kubectl completion code for zsh\[1\] to autoload on startup kubectl completion zsh > "${fpath[1]}/_kubectl" > Load the kubectl completion code for fish\[2\] into the current shell kubectl completion fish | source > To load completions for each session, execute once: kubectl completion fish > ~/.config/fish/completions/kubectl.fish > Load the kubectl completion code for powershell into the current shell kubectl completion powershell | Out-String | Invoke-Expression > Set kubectl completion code for powershell to run on startup ## Save completion code to a script and execute in the profile kubectl completion powershell > $HOME\.kube\completion.ps1 Add-Content $PROFILE "$HOME\.kube\completion.ps1" > Execute completion code in the profile Add-Content $PROFILE "if (Get-Command kubectl -ErrorAction SilentlyContinue) { kubectl completion powershell | Out-String | Invoke-Expression }" > Add completion code directly to the $PROFILE script kubectl completion powershell >> $PROFILE Output shell completion code for the specified shell (bash, zsh, fish, or powershell). The shell code must be evaluated to provide interactive completion of kubectl commands. This can be done by sourcing it from the .bash\_profile. Detailed instructions on how to do this are available here: for macOS: [https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#enable-shell-autocompletion](https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#enable-shell-autocompletion) for linux: [https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#enable-shell-autocompletion](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#enable-shell-autocompletion) for windows: [https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/#enable-shell-autocompletion](https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/#enable-shell-autocompletion) Note for zsh users: \[1\] zsh completions are only supported in versions of zsh >= 5.2. ### Usage `$ kubectl completion SHELL` * * * config ====== Modify kubeconfig files using subcommands like "kubectl config set current-context my-context" The loading order follows these rules: 1\. If the --kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takes place. 2\. If $KUBECONFIG environment variable is set, then it is used as a list of paths (normal path delimiting rules for your system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list. 3\. Otherwise, ${HOME}/.kube/config is used and no merging takes place. ### Usage `$ kubectl config SUBCOMMAND` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | kubeconfig | | | use a particular kubeconfig file | * * * _current-context_ ----------------- > Display the current-context kubectl config current-context Display the current-context. ### Usage `$ kubectl config current-context` * * * _delete-cluster_ ---------------- > Delete the minikube cluster kubectl config delete-cluster minikube Delete the specified cluster from the kubeconfig. ### Usage `$ kubectl config delete-cluster NAME` * * * _delete-context_ ---------------- > Delete the context for the minikube cluster kubectl config delete-context minikube Delete the specified context from the kubeconfig. ### Usage `$ kubectl config delete-context NAME` * * * _delete-user_ ------------- > Delete the minikube user kubectl config delete-user minikube Delete the specified user from the kubeconfig. ### Usage `$ kubectl config delete-user NAME` * * * _get-clusters_ -------------- > List the clusters that kubectl knows about kubectl config get-clusters Display clusters defined in the kubeconfig. ### Usage `$ kubectl config get-clusters` * * * _get-contexts_ -------------- > List all the contexts in your kubeconfig file kubectl config get-contexts > Describe one context in your kubeconfig file kubectl config get-contexts my-context Display one or many contexts from the kubeconfig file. ### Usage `$ kubectl config get-contexts [(-o|--output=)name)]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | no-headers | | false | When using the default or custom-column output format, don't print headers (default print headers). | | output | o | | Output format. One of: (name). | * * * _get-users_ ----------- > List the users that kubectl knows about kubectl config get-users Display users defined in the kubeconfig. ### Usage `$ kubectl config get-users` * * * _rename-context_ ---------------- > Rename the context 'old-name' to 'new-name' in your kubeconfig file kubectl config rename-context old-name new-name Renames a context from the kubeconfig file. CONTEXT\_NAME is the context name that you want to change. NEW\_NAME is the new name you want to set. Note: If the context being renamed is the 'current-context', this field will also be updated. ### Usage `$ kubectl config rename-context CONTEXT_NAME NEW_NAME` * * * _set_ ----- > Set the server field on the my-cluster cluster to [https://1.2.3.4](https://1.2.3.4/) kubectl config set clusters.my-cluster.server https://1.2.3.4 > Set the certificate-authority-data field on the my-cluster cluster kubectl config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -) > Set the cluster field in the my-context context to my-cluster kubectl config set contexts.my-context.cluster my-cluster > Set the client-key-data field in the cluster-admin user using --set-raw-bytes option kubectl config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true Set an individual value in a kubeconfig file. PROPERTY\_NAME is a dot delimited name where each token represents either an attribute name or a map key. Map keys may not contain dots. PROPERTY\_VALUE is the new value you want to set. Binary fields such as 'certificate-authority-data' expect a base64 encoded string unless the --set-raw-bytes flag is used. Specifying an attribute name that already exists will merge new fields on top of existing values. ### Usage `$ kubectl config set PROPERTY_NAME PROPERTY_VALUE` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | set-raw-bytes | | false | When writing a \[\]byte PROPERTY\_VALUE, write the given string directly without base64 decoding. | * * * _set-cluster_ ------------- > Set only the server field on the e2e cluster entry without touching other values kubectl config set-cluster e2e --server=https://1.2.3.4 > Embed certificate authority data for the e2e cluster entry kubectl config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt > Disable cert checking for the e2e cluster entry kubectl config set-cluster e2e --insecure-skip-tls-verify=true > Set custom TLS server name to use for validation for the e2e cluster entry kubectl config set-cluster e2e --tls-server-name=my-cluster-name > Set proxy url for the e2e cluster entry kubectl config set-cluster e2e --proxy-url=https://1.2.3.4 Set a cluster entry in kubeconfig. Specifying a name that already exists will merge new fields on top of existing values for those fields. ### Usage `$ kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certificate/authority] [--insecure-skip-tls-verify=true] [--tls-server-name=example.com]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | certificate-authority | | | Path to certificate-authority file for the cluster entry in kubeconfig | | embed-certs | | false | embed-certs for the cluster entry in kubeconfig | | insecure-skip-tls-verify | | false | insecure-skip-tls-verify for the cluster entry in kubeconfig | | proxy-url | | | proxy-url for the cluster entry in kubeconfig | | server | | | server for the cluster entry in kubeconfig | | tls-server-name | | | tls-server-name for the cluster entry in kubeconfig | * * * _set-context_ ------------- > Set the user field on the gce context entry without touching other values kubectl config set-context gce --user=cluster-admin Set a context entry in kubeconfig. Specifying a name that already exists will merge new fields on top of existing values for those fields. ### Usage `$ kubectl config set-context [NAME | --current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | cluster | | | cluster for the context entry in kubeconfig | | current | | false | Modify the current context | | namespace | | | namespace for the context entry in kubeconfig | | user | | | user for the context entry in kubeconfig | * * * _set-credentials_ ----------------- > Set only the "client-key" field on the "cluster-admin" # entry, without touching other values kubectl config set-credentials cluster-admin --client-key=~/.kube/admin.key > Set basic auth for the "cluster-admin" entry kubectl config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif > Embed client certificate data in the "cluster-admin" entry kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true > Enable the Google Compute Platform auth provider for the "cluster-admin" entry kubectl config set-credentials cluster-admin --auth-provider=gcp > Enable the OpenID Connect auth provider for the "cluster-admin" entry with additional args kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar > Remove the "client-secret" config value for the OpenID Connect auth provider for the "cluster-admin" entry kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret- > Enable new exec auth plugin for the "cluster-admin" entry kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1 > Define new exec auth plugin args for the "cluster-admin" entry kubectl config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2 > Create or update exec auth plugin environment variables for the "cluster-admin" entry kubectl config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2 > Remove exec auth plugin environment variables for the "cluster-admin" entry kubectl config set-credentials cluster-admin --exec-env=var-to-remove- Set a user entry in kubeconfig. Specifying a name that already exists will merge new fields on top of existing values. Client-certificate flags: --client-certificate=certfile --client-key=keyfile Bearer token flags: --token=bearer\_token Basic auth flags: --username=basic\_user --password=basic\_password Bearer token and basic auth are mutually exclusive. ### Usage `$ kubectl config set-credentials NAME [--client-certificate=path/to/certfile] [--client-key=path/to/keyfile] [--token=bearer_token] [--username=basic_user] [--password=basic_password] [--auth-provider=provider_name] [--auth-provider-arg=key=value] [--exec-command=exec_command] [--exec-api-version=exec_api_version] [--exec-arg=arg] [--exec-env=key=value]` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | auth-provider | | | Auth provider for the user entry in kubeconfig | | auth-provider-arg | | \[\] | 'key=value' arguments for the auth provider | | client-certificate | | | Path to client-certificate file for the user entry in kubeconfig | | client-key | | | Path to client-key file for the user entry in kubeconfig | | embed-certs | | false | Embed client cert/key for the user entry in kubeconfig | | exec-api-version | | | API version of the exec credential plugin for the user entry in kubeconfig | | exec-arg | | \[\] | New arguments for the exec credential plugin command for the user entry in kubeconfig | | exec-command | | | Command for the exec credential plugin for the user entry in kubeconfig | | exec-env | | \[\] | 'key=value' environment values for the exec credential plugin | | password | | | password for the user entry in kubeconfig | | token | | | token for the user entry in kubeconfig | | username | | | username for the user entry in kubeconfig | * * * _unset_ ------- > Unset the current-context kubectl config unset current-context > Unset namespace in foo context kubectl config unset contexts.foo.namespace Unset an individual value in a kubeconfig file. PROPERTY\_NAME is a dot delimited name where each token represents either an attribute name or a map key. Map keys may not contain dots. ### Usage `$ kubectl config unset PROPERTY_NAME` * * * _use-context_ ------------- > Use the context for the minikube cluster kubectl config use-context minikube Set the current-context in a kubeconfig file. ### Usage `$ kubectl config use-context CONTEXT_NAME` * * * _view_ ------ > Show merged kubeconfig settings kubectl config view > Show merged kubeconfig settings and raw certificate data and exposed secrets kubectl config view --raw > Get the password for the e2e user kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' Display merged kubeconfig settings or a specified kubeconfig file. You can use --output jsonpath={...} to extract specific values using a jsonpath expression. ### Usage `$ kubectl config view` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | allow-missing-template-keys | | true | If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. | | flatten | | false | Flatten the resulting kubeconfig file into self-contained output (useful for creating portable kubeconfig files) | | merge | | true | Merge the full hierarchy of kubeconfig files | | minify | | false | Remove all information not used by current-context from the output | | output | o | yaml | Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | | raw | | false | Display raw byte data and sensitive data | | show-managed-fields | | false | If true, keep the managedFields when printing objects in JSON or YAML format. | | template | | | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates \[[http://golang.org/pkg/text/template/#pkg-overview](http://golang.org/pkg/text/template/#pkg-overview)
\]. | * * * explain ======= > Get the documentation of the resource and its fields kubectl explain pods > Get the documentation of a specific field of a resource kubectl explain pods.spec.containers List the fields for supported resources. This command describes the fields associated with each supported API resource. Fields are identified via a simple JSONPath identifier: .\[.\] Add the --recursive flag to display all of the fields at once without descriptions. Information about each field is retrieved from the server in OpenAPI format. Use "kubectl api-resources" for a complete list of supported resources. ### Usage `$ kubectl explain RESOURCE` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | api-version | | | Get different explanations for particular API version (API group/version) | | recursive | | false | Print the fields of fields (Currently only 1 level deep) | * * * options ======= > Print flags inherited by all commands kubectl options Print the list of flags inherited by all commands ### Usage `$ kubectl options` * * * plugin ====== Provides utilities for interacting with plugins. Plugins provide extended functionality that is not part of the major command-line distribution. Please refer to the documentation and examples for more information about how write your own plugins. The easiest way to discover and install plugins is via the kubernetes sub-project krew. To install krew, visit [https://krew.sigs.k8s.io/docs/user-guide/setup/install/](https://krew.sigs.k8s.io/docs/user-guide/setup/install/) krew.sigs.k8s.io [https://krew.sigs.k8s.io/docs/user-guide/setup/install/](https://krew.sigs.k8s.io/docs/user-guide/setup/install/) ### Usage `$ kubectl plugin [flags]` * * * _list_ ------ > List all available plugins kubectl plugin list List all available plugin files on a user's PATH. Available plugin files are those that are: - executable - anywhere on the user's PATH - begin with "kubectl-" ### Usage `$ kubectl plugin list` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | name-only | | false | If true, display only the binary name of each plugin, rather than its full path | * * * version ======= > Print the client and server versions for the current context kubectl version Print the client and server version information for the current context. ### Usage `$ kubectl version` ### Flags | Name | Shorthand | Default | Usage | | --- | --- | --- | --- | | client | | false | If true, shows client version only (no server required). | | output | o | | One of 'yaml' or 'json'. | | short | | false | If true, print just the version number. | --- # Polityki | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/concepts/policy/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/concepts/policy/) . Polityki ======== Stosuj polityki do zarządzania bezpieczeństwem i wdrażania najlepszych praktyk. Polityki Kubernetesa to ustawienia kontrolujące inne konfiguracje lub sposób działania aplikacji w trakcie ich działania. Kubernetes oferuje różne formy polityk, opisane poniżej: Stosowanie polityk za pomocą obiektów API ----------------------------------------- Niektóre obiekty API spełniają rolę polityk. Oto kilka przykładów: * [NetworkPolicies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) mogą być używane do ograniczania ruchu przychodzącego i wychodzącego dla workload. * [LimitRanges](https://kubernetes.io/docs/concepts/policy/limit-range/) zarządzają ograniczeniami alokacji zasobów w różnych typach obiektów. * [ResourceQuotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) ogranicza zużycie zasobów dla [namespace](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/namespaces "An abstraction used by Kubernetes to support isolation of groups of resources within a single cluster.") . Stosowanie polityk za pomocą kontrolerów dopuszczania (ang. Admission Controllers) ---------------------------------------------------------------------------------- Kontroler dopuszczania (ang. Admission Controller - [admission controller](https://kubernetes.io/pl/docs/reference/access-authn-authz/admission-controllers/ "A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object.") ) działa na serwerze API i może weryfikować lub modyfikować żądania API. Niektóre takie kontrolery działają w celu zastosowania polityk. Na przykład kontroler [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) modyfikuje nowy Pod, aby ustawić politykę pobierania obrazów na `Always`. Kubernetes ma kilka wbudowanych kontrolerów dostępu, które można konfigurować za pomocą flagi `--enable-admission-plugins` serwera API. Szczegóły dotyczące kontrolerów dopuszczania są udokumentowane w dedykowanej sekcji: * [Kontrolery dopuszczania (ang. Admission Controllers)](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) Stosowanie polityk używając ValidatingAdmissionPolicy ----------------------------------------------------- Polityki walidacji przyjmowania (ang. Validating admission policies) umożliwiają wykonywanie konfigurowalnych kontroli walidacji na serwerze API przy użyciu wspólnego języka wyrażeń (CEL). Na przykład, `ValidatingAdmissionPolicy` może być używana do zakazania użycia tagu obrazu `latest`. Polityka `ValidatingAdmissionPolicy` działa na żądaniach API i może być używana do blokowania, audytowania oraz ostrzegania użytkowników o niezgodnych konfiguracjach. Szczegóły dotyczące API `ValidatingAdmissionPolicy`, wraz z przykładami, są udokumentowane w dedykowanej sekcji: * [Walidacja Polityki Dopuszczania (ang. Validating Admission Policy)](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) Stosowanie polityk przy użyciu dynamicznej kontroli dostępu ----------------------------------------------------------- Dynamiczne kontrolery dostępu (lub webhooki dostępu) działają poza serwerem API jako oddzielne aplikacje, które rejestrują się do odbierania żądań webhooków w celu przeprowadzania weryfikacji lub modyfikacji żądań API. Dynamiczne kontrolery dopuszczeń mogą być używane do stosowania polityk na żądaniach API i uruchamiania innych procesów opartych na politykach. Dynamiczny kontroler dopuszczeń może przeprowadzać skomplikowane kontrole, w tym te, które wymagają pobierania innych zasobów klastra i danych zewnętrznych. Na przykład, kontrola weryfikacji obrazu może wyszukiwać dane z rejestrów OCI, aby zatwierdzić podpisy i atestacje obrazów kontenerów. Szczegóły dotyczące dynamicznej kontroli dostępu są udokumentowane w dedykowanej sekcji: * [Dynamiczne Sterowanie Dostępem](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) ### Implementacje **Informacja:** Ta sekcja przekierowuje do projektów zewnętrznych (niżej ich lista alfabetyczna), które udostępniają funkcjonalności wymagane przez Kubernetesa. Autorzy Kubernetesa nie odpowiadają za te projekty. Jeśli chcesz dodać projekt do tego wykazu, zanim wprowadzisz zmiany, przeczytaj [nasz przewodnik](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) . Dynamiczne kontrolery dopuszczeń (Admission Controllers), które działają jako elastyczne silniki polityki, są rozwijane w ekosystemie Kubernetesa: * [Kubewarden](https://github.com/kubewarden) * [Kyverno](https://kyverno.io/) * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) * [Polaris](https://polaris.docs.fairwinds.com/admission-controller/) Stosowanie zasad za pomocą konfiguracji Kubelet ----------------------------------------------- Kubernetes pozwala na konfigurowanie Kubelet na każdym węźle roboczym. Niektóre konfiguracje Kubelet działają jako polityki: * [Limity i rezerwacje identyfikatorów procesów](https://kubernetes.io/docs/concepts/policy/pid-limiting/) są używane do ograniczania i rezerwacji dostępnych PID-ów. * [Menedżery zasobów węzła](https://kubernetes.io/docs/concepts/policy/node-resource-managers/) mogą zarządzać zasobami obliczeniowymi, pamięci oraz urządzeniami dla workloadów krytycznych pod względem opóźnień i o wysokiej przepustowości. --- # कुबेरनेटेस डॉक्स में योगदान दे | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/contribute/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/contribute/) . कुबेरनेटेस डॉक्स में योगदान दे ============================== * 1: [प्रलेखन शैली अवलोकन](https://kubernetes.io/hi/docs/contribute/_print/#pg-a2d946282df02cdeb47d9f54dfef198e) * 2: [साइट विश्लेषिकी देखना](https://kubernetes.io/hi/docs/contribute/_print/#pg-ed3187078744c086d64f3d804a926218) _कुबेरनेटस सभी योगदानकर्ताओ से सुधार का स्वागत करता है चाहे वो नए हो या अनुभवी!_ #### टिप्पणी: कुबेरनेटस मे योगदान करने के बारे मे अधिक जानकारी के लिए [योगदानकर्ता प्रलेखन](https://www.kubernetes.dev/docs/) देखें। इस वेबसाइट की देख रेख [कुबेरनेटस SIG Docs](https://kubernetes.io/hi/docs/contribute/#get-involved-with-sig-docs) द्वारा की जाती है। कुबेरनेटस प्रलेखन योगदानकर्ता : * मौजूदा विषयों को सुधारते हैं * नए विषय बनाते हैं * प्रलेखन का अनुवाद करते हैं * कुबेरनेटस रिलीज चक्र मे प्रलेखन की देख रेख और प्रकाशन करते हैं शुरू करना --------- कोई भी प्रलेखन के बारे मे इशू खोल सकता है या कुबेरनेटस वेबसाइट [`kubernetes/website` GitHub रिपॉजिटरी](https://github.com/kubernetes/website) मे बदलाव पुल अनुरोध (PR) द्वारा कर सकता है। आपको [Git](https://git-scm.com/) और [Github](https://skills.github.com/) की जानकारी होनी चाहिए ताकि आप कुबेरनेटेस समुदाय मे प्रभावी रूप से काम कर सकें। प्रलेखन मे सहयोग करने के लिए: 1. [योगदानकर्ता समझौता लाइसेन्स](https://github.com/kubernetes/community/blob/master/CLA.md) पर हस्ताक्षर करें। 2. [प्रलेखन रिपॉजिटरी](https://github.com/kubernetes/website) और वेबसाइट की [स्टैटिक साइट जनरेटर](https://gohugo.io/) से खुद को परिचित करें। 3. सुनिश्चित करें की आपको [पुल अनुरोध करना](https://kubernetes.io/docs/contribute/new-content/open-a-pr/) और [बदलाओ की समीक्षा](https://kubernetes.io/docs/contribute/review/reviewing-prs/) करना आता हो। flowchart TB subgraph third\[PR ओपन करे\] direction TB U\[ \] -.- Q\[विषय सुधारे\] --- N\[विषय निर्माण करे\] N --- O\[डॉक्स का अनुवाद करे\] O --- P\[K8s रिलीज़ चक्र के प्रलेखन \ को संचालित /प्रकाशित करें\] end subgraph second\[समीक्षा\] direction TB T\[ \] -.- D\[kubernetes/website \ रिपॉजिटरी \ को देखें\] --- E\[Hugo स्टैटिक साइट \ जनरेटर \ को देखें\] E --- F\[मूलभूत GitHub \ कमांड समझें\] F --- G\[ओपन PR की समीक्षा करे \ और समीक्षा प्रक्रिया \ को बदलें\] end subgraph first\[साइनअप\] direction TB S\[ \] -.- B\[CNCF \ योगदानकर्ता \ लइसेंस समझौता \ पर हस्ताक्षर करें\] --- C\[sig-docs स्लैक चैनल \ में जुड़ें\] C --- V\[kubernetes-sig-docs \ मेलिंग लिस्ट में जुड़ें\] V --- M\[साप्ताहिक \ sig-docs कॉल \ या स्लैक बैठक में शामिल हों\] end A(\[fa:fa-user नए \ योगदानकर्ता\]) --> first A --> second A --> third A --> H\[सवाल पूछे!!!\] classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey class S,T,U spacewhite class first,second,third white _**आकृति - नए योगदानकर्ताओं के लिए योगदान शुरू करने का रास्ता**_ ऊपर दी गई आकृति नए योगदानकर्ता के लिए दिशानिर्देश हैं। `Sign up` या `review` के लिए आप इनमे से कुछ या सभी निर्देशों का पालन कर सकते हैं। अब आप PR ओपन करने के लिए तैयार हैं जो आपके योगदान के उद्देश को पूरा करे जो `Open PR` खंड मे सूचीबद्ध हैं। आपके सभी प्रश्नों का सदैव स्वागत है। कुबेरनेटस समुदाय मे कुछ कार्यों के लिए अधिक विश्वास और अभिगम की आवश्यकता होती है। भूमिका और अनुमति के बारे मे ज्यादा जानकारी के लिए [SIG Docs मे भाग लेना](https://kubernetes.io/docs/contribute/participate/) को देखें। आपका पहला योगदान ---------------- आप अपने पहले योगदान की तैयारी के लिए दिए गए दिशानिर्देश को देख सकते हैं। नीचे दिया हुआ चित्र दिशानिर्देश और उसकी विस्तार मे जानकारी देता है। flowchart LR subgraph second\[पहला योगदान\] direction TB S\[ \] -.- G\[दूसरे K8s मेम्बर्स के \ PRs की समीक्षा करें\] --> A\[अपने पहले इशू (गुफ फर्स्ट इशू) \ के लिए kubernetes/website \ की इशू सूची पर जाएं\] --> B\[PR ओपन करें!!\] end subgraph first\[सूचित तैयारी\] direction TB T\[ \] -.- D\[योगदान अवलोकन को पढे\] -->E\[K8s विषय \ और विषय गाइड को पढ़ें\] E --> F\[Hugo पेज \ विषय के प्रकार \ और shortcodes के बारे मे जाने\] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,D,E,F,G grey class S,T spacewhite class first,second white **आकृति - आपके पहले योगदान की तैयारी** * योगदान करने के विभिन्न तरीकों को जानने के लिए [योगदानकर्ता अवलोकन](https://kubernetes.io/docs/contribute/new-content/overview/) को पढ़ें। * अच्छे प्रवेश बिन्दु के लिए [`kubernetes/website` इशू सूची](https://github.com/kubernetes/website/issues/) को जाचें। * मौजूदा प्रलेखन पर [Github का प्रयोग करते हुए पुल अनुरोध करॆ](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#changes-using-github) और इशू दाखिल करने के बारे मे अधिक जानें। * भाषा और सटीकता के लिए अन्य कुबेरनेटस समुदाय के सदस्यों के [पुल अनुरोध की समीक्षा करें](https://kubernetes.io/docs/contribute/review/reviewing-prs/) । * कुबेरनेटस [प्रकरण](https://kubernetes.io/docs/contribute/style/content-guide/) और [स्टाइल मार्गदर्शक](https://kubernetes.io/docs/contribute/style/style-guide/) को पढ़ें ताकि आप सूचित टिप्पणी दे सकें। * [पेज प्रलेखन टाइप](https://kubernetes.io/docs/contribute/style/page-content-types/) और [Hugo shortcodes](https://kubernetes.io/docs/contribute/style/hugo-shortcodes/) के बारे मे जानें। अगले कदम -------- * रिपॉजिटरी के [लोकल क्लोन से काम करना](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#fork-the-repo) सीखें। * [रिलीज़ में फीचर्स का](https://kubernetes.io/docs/contribute/new-content/new-features/) आलेख करे। * [SIG Docs](https://kubernetes.io/docs/contribute/participate/) मे भाग लें और [सदस्य या समीक्षक](https://kubernetes.io/docs/contribute/participate/roles-and-responsibilities/) बनें। * [स्थानीयकरण](https://kubernetes.io/docs/contribute/localization/) शुरू करे या उसमे सहायता करें। सिग डॉक्स मे शामिल हो --------------------- [SIG Docs](https://kubernetes.io/docs/contribute/participate/) योगदानकर्ताओ का एक समूह है जो कुबेरनेटेस प्रलेखन और वेबसाईट की देख रेख और उसे प्रकाशित करता है। SIG Docs मे शामिल होना कुबेरनेटस योगदानकर्ताओ (फीचर विकास या उससे अन्यथा) के लिए कुबेरनेटस परियोजना पर प्रभाव डालने का बेहतरीन तरीका है। SIG Docs भिन्न प्रकार से संवाद करते हैं: * [कुबेरनेटेस Slack चैनल मे #sig-docs से जुड़ें](https://slack.k8s.io/) और खुद का परिचय दें! * [kubernetes-sig-docs मेलिंग लिस्ट मे शामिल हो](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) , वहाँ व्यापक विचार-विमर्श होता है और आधिकारिक फैसले का अभिलेखन किया जाता है। * [SIG Docs विडिओ बैठक](https://github.com/kubernetes/community/tree/master/sig-docs) मे शामिल हो जो हर दो सप्ताह मे होती है। बैठक की घोषणा हमेशा `#sig-docs` पर की जाती है और [कुबेरनेटेस समुदाय बैठक कैलंडर](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles) में जोड़ दिया जाता है। आपको [Zoom client](https://zoom.us/download) डाउनलोड करने की जरूरत पड़ेगी या फोन की मदद से भी डायल कर सकते हैं। * जिन सप्ताह मे Zoom बैठक नहीं हुई हो तब SIG Docs अतुल्यकालिक बैठक को जॉइन करे जो Slack पर होती है। बैठक की घोषणा हमेशा `#sig-docs` पर होती है। बैठक की घोषणा के बाद आप किसी भी सूत्र मे 24 घंटे तक योगदान कर सकते है। योगदान करने के अन्य तरीके ------------------------- * [कुबेरनेटस समुदाय साइट](https://kubernetes.io/community/) पर जाए। Twitter या Slack Overflow मैं भाग ले, कुबेरनेटस स्थानीय आयोजन और मिलन के बारे मे जाने । * कुबेरनेटस फीचर विकास में शामिल होने के लिए [योगदानकर्ता चीटशीट](https://www.kubernetes.dev/docs/contributor-cheatsheet/) पढ़ें। * [कुबेरनेटस योगदानकर्ता](https://www.kubernetes.dev/) और [अतिरिक्त योगदानकर्ता साधन](https://www.kubernetes.dev/resources/) के बारे मे अधिक जानकारी के लिए योगदानकर्ता साइट पर जाएं। * [ब्लॉग पोस्ट या केस अध्ययन](https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/) प्रस्तुत करे। 1 - प्रलेखन शैली अवलोकन ======================= इस खंड के विषय लेखन शैली, सामग्री स्वरूपण, और संगठन, और कुबेरनेट्स प्रलेखन के लिए विशिष्ट Hugo अनुकूलन का उपयोग करने पर मार्गदर्शन प्रदान करते हैं। 2 - साइट विश्लेषिकी देखना ========================= इस पृष्ठ में Kubernetes.io विश्लेषिकी डैशबोर्ड के बारे में जानकारी है। [डैशबोर्ड देखें](https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04) । यह डैशबोर्ड Google Data Studio का उपयोग करके बनाया गया है और Google Analytics का उपयोग करके Kubernetes.io पर एकत्रित जानकारी दिखाता है। ### डैशबोर्ड का उपयोग करना डिफ़ॉल्ट रूप से, डैशबोर्ड पिछले 30 दिनों के सभी एकत्रित विश्लेषण दिखाता है। विभिन्न दिनांक सीमा मे आने वाला डेटा देखने के लिए date selector का उपयोग करें। अन्य फ़िल्टरिंग विकल्प आपको उपयोगकर्ता का स्थान, साइट तक पहुंचने के लिए उपयोग किए जाने वाले उपकरण, उपयोग किए गए दस्तावेज़ों के अनुवाद, और बहुत से चीज़ों का डेटा देखने की अनुमति देते हैं। यदि आप इस डैशबोर्ड में कोई समस्या देखते हैं, या किसी सुधार का अनुरोध करना चाहते हैं, तो कृपया [एक इशू बनाएं](https://github.com/kubernetes/website/issues/new/choose) । --- # Styl dokumentacji | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/contribute/style/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/contribute/style/) . Styl dokumentacji ================= * 1: [Typy treści](https://kubernetes.io/pl/docs/contribute/style/_print/#pg-69e79c7baae79b2f34332a745d62ddca) Tematy w tej sekcji zawierają wskazówki dotyczące stylu pisania, formatowania treści i organizacji, a także korzystania ze specyficznych dostosowań Hugo dla dokumentacji Kubernetesa. 1 - Typy treści =============== Dokumentacja Kubernetesa obejmuje kilka typów treści stron: * Pojęcia i koncepcje (ang. Concept) * Zadanie (ang. Task) * Samouczek (ang. Tutorial) * Materiały źródłowe (ang. Reference) Sekcje treści ------------- Każdy typ strony zawiera szereg sekcji zdefiniowanych przez komentarze Markdown i nagłówki HTML. Możesz dodać nagłówki do swojej strony za pomocą kodu `heading`. Komentarze i nagłówki pomagają utrzymać odpowiednią strukturę strony dla danego typu. Przykłady komentarzy w Markdown definiujących sekcje strony: Aby utworzyć typowe nagłówki na swoich stronach, użyj kodu `heading` z nazwą nagłówka. Przykłady nazw nagłówków: * whatsnext - co dalej * prerequisites - wymagania wstępne * objectives - cele * cleanup - sprzątanie * synopsis - streszczenie * seealso - zobacz także * options - opcje Na przykład, aby utworzyć nagłówek `whatsnext`, dodaj kod nagłówka z nazwą "whatsnext": ## {{% heading "whatsnext" %}} Możesz zadeklarować nagłówek `prerequisites` w następujący sposób: ## {{% heading "prerequisites" %}} Kod `heading` oczekuje jednego parametru typu string. Ten parametr nagłówka odpowiada prefiksowi zmiennej w plikach `i18n//.toml`. Na przykład: `i18n/en/en.toml`: [whatsnext_heading] other = "What's next" `i18n/ko/ko.toml`: [whatsnext_heading] other = "다음 내용" Typy zawartości --------------- Każdy typ zawartości nieformalnie definiuje swoją oczekiwaną strukturę strony. Twórz zawartość strony, korzystając z sugerowanych sekcji strony. ### Pojęcie (ang. Concept) Strona z pojęciami wyjaśnia określony aspekt Kubernetesa. Na przykład, strona koncepcyjna może opisywać obiekt Deployment w Kubernetesie i wyjaśniać jego rolę jako aplikacji po wdrożeniu, skalowaniu i aktualizacji. Zazwyczaj strony koncepcyjne nie zawierają instrukcji krok po kroku, lecz odsyłają do zadań lub samouczków. Aby napisać nową stronę z pojęciem, utwórz plik Markdown w podkatalogu katalogu `/content/en/docs/concepts`, z następującymi sekcjami: Strony koncepcyjne są podzielone na trzy sekcje: | Sekcja strony | | --- | | overview - przegląd | | body - treść | | whatsnext - co dalej | Sekcje `overview` i `body` pojawiają się jako komentarze na stronie z koncepcjami. Możesz dodać sekcję `whatsnext` do swojej strony za pomocą kodu `heading`. Wypełnij każdą sekcję treścią. Postępuj zgodnie z tymi wytycznymi: * Organizuj treści za pomocą nagłówków H2 i H3. * Dla `overview`, ustaw kontekst tematu za pomocą pojedynczego akapitu. * Dla `body` wyjaśnij koncepcję. * Dla `whatsnext`, podaj wypunktowaną listę tematów (maksymalnie 5), aby dowiedzieć się więcej o koncepcji. Strona [adnotacje](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/annotations/) jest opublikowanym przykładem strony koncepcyjnej. ### Zadanie (ang. Task) Strony opisujące wykonywanie zadań zawierają minimum wyjaśnień, ale zwykle podają odnośniki do dokumentacji objaśniającej pojęcia i szerszy kontekst danego tematu. Aby napisać nową stronę zadania, utwórz plik Markdown w podkatalogu katalogu `/content/en/docs/tasks`, z następującymi sekcjami: | Sekcja strony | | --- | | overview - przegląd | | prerequisites - wymagania wstępne | | steps - kroki | | discussion - dyskusja | | whatsnext - co dalej | Sekcje `overview`, `steps` i `discussion` pojawiają się jako komentarze na stronie zadania. Możesz dodać sekcje `prerequisites` i `whatsnext` do swojej strony za pomocą kodu `heading`. Każdą sekcję uzupełnij treścią. Użyj następujących wytycznych: * Użyj nagłówków poziomu H2 lub niższego (z dwoma wiodącymi znakami `#`). Sekcje są automatycznie tytułowane przez szablon. * Dla `overview` użyj akapitu, aby ustawić kontekst dla całego tematu. * Dla `prerequisites` używaj list punktowanych, kiedy to możliwe. Zaczynaj dodawać dodatkowe wymagania wstępne poniżej `include`. Domyślne wymagania wstępne obejmują działający klaster Kubernetesa. * Dla `steps` używaj numerowanych list. * Do omówienia użyj standardowej treści, aby rozwinąć informacje zawarte w sekcji `steps`. * Dla `whatsnext`, podaj listę punktowaną z maksymalnie 5 tematami, które mogą zainteresować czytelnika jako kolejne tematy do przeczytania. Przykład opublikowanego tematu zadania to [Korzystanie z proxy HTTP do uzyskania dostępu do API Kubernetesa](https://kubernetes.io/docs/tasks/extend-kubernetes/http-proxy-access-api/) . ### Samouczek (ang. Tutorial) Strona samouczka pokazuje, jak osiągnąć cel, który jest bardziej złożony niż pojedyncze zadanie. Zazwyczaj strona samouczka składa się z kilku sekcji, z których każda zawiera sekwencję kroków. Na przykład samouczek może przeprowadzać użytkownika przez przykładowy kod ilustrujący określoną funkcję Kubernetesa. Samouczki mogą zawierać ogólne wyjaśnienia, ale powinny odsyłać do powiązanych tematów koncepcyjnych w celu dogłębnego omówienia zagadnienia. Aby napisać nową stronę samouczka, utwórz plik Markdown w podkatalogu katalogu `/content/en/docs/tutorials`, z następującymi sekcjami: | Sekcja strony | | --- | | overview - przegląd | | prerequisites - wymagania wstępne | | objectives - cele | | lessoncontent - treść lekcji | | cleanup - sprzątanie | | whatsnext - co dalej | Sekcje `overview`, `objectives` i `lessoncontent` pojawiają się jako komentarze na stronie samouczka. Możesz dodać sekcje `prerequisites`, `cleanup` i `whatsnext` do swojej strony za pomocą kodu `heading`. Każdą sekcję uzupełnij treścią. Użyj następujących wytycznych: * Użyj nagłówków poziomu H2 lub niższego (z dwoma wiodącymi znakami `#`). Sekcje są automatycznie tytułowane przez szablon. * Dla `overview` użyj akapitu, aby ustawić kontekst dla całego tematu. * W przypadku `prerequisites` używaj, jeśli to możliwe, list punktowanych. Dodaj dodatkowe wymagania wstępne poniżej tych domyślnie uwzględnionych. * Dla `objectives`, używaj list wypunktowanych. * Dla `lessoncontent`, użyj mieszanki list numerowanych i treści narracyjnej w zależności od potrzeb. * W przypadku `cleanup`, użyj numerowanych list, aby opisać kroki niezbędne do posprzątania stanu klastra po zakończeniu zadania. * Dla `whatsnext`, podaj listę punktowaną z maksymalnie 5 tematami, które mogą zainteresować czytelnika jako kolejne tematy do przeczytania. Przykładem opublikowanego tematu samouczka jest [Uruchamianie aplikacji bezstanowej przy użyciu Deployment](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/) . ### Materiały źródłowe (ang. Reference) Każde narzędzie Kubernetesa ma swoją stronę materiałów źródłowych (ang. reference page), gdzie można znaleźć jego opis i listę dostępnych opcji. Dokumentacja ta jest generowana przez skrypty, które automatycznie pobierają informacje z poleceń narzędzia. Strona z odniesieniem do narzędzia ma kilka możliwych sekcji: | Sekcja strony | | --- | | streszczenie | | opcje | | opcje z nadrzędnych poleceń | | przykłady | | zobacz także | Przykłady opublikowanych stron referencyjnych narzędzi to: * [kubeadm init](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/) * [kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) * [kubectl](https://kubernetes.io/docs/reference/kubectl/kubectl/) Co dalej? --------- * Dowiedz się więcej o [Przewodniku stylu](https://kubernetes.io/docs/contribute/style/style-guide/) * Dowiedz się więcej o [Przewodniku treści](https://kubernetes.io/docs/contribute/style/content-guide/) * Dowiedz się więcej o [organizacji treści](https://kubernetes.io/docs/contribute/style/content-organization/) --- # Documentazione | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/it/docs/_print/#) . [Return to the regular view of this page](https://kubernetes.io/it/docs/) . Documentazione ============== * 1: [Glossario](https://kubernetes.io/it/docs/_print/#pg-2b03679960950df772fb4fe7d78427b9) * 2: [Documentazione di Kubernetes](https://kubernetes.io/it/docs/_print/#pg-e735cee7e913aa88bc0aa10594d12966) * 2.1: [Versioni supportate della documentazione di Kubernetes](https://kubernetes.io/it/docs/_print/#pg-92dfff0ca612d0bff40171aa9df6c4ae) * 3: [Concetti](https://kubernetes.io/it/docs/_print/#pg-dd948255948d6b59b32c471abcb62997) * 3.1: [Overview](https://kubernetes.io/it/docs/_print/#pg-0554ac387412eaf4e6e89b2f847dacde) * 3.1.1: [Cos'è Kubernetes?](https://kubernetes.io/it/docs/_print/#pg-45bdca6129cf540121623e903c18ba46) * 3.1.2: [I componenti di Kubernetes](https://kubernetes.io/it/docs/_print/#pg-13b0f1dbe89228e3d76d2ac231e245f1) * 3.1.3: [Le API di Kubernetes](https://kubernetes.io/it/docs/_print/#pg-0c745f42e623d2b70a53bc0e6db73d95) * 3.2: [Architettura di Kubernetes](https://kubernetes.io/it/docs/_print/#pg-2bf36ccd6b3dbeafecf87c39761b07c7) * 3.2.1: [Comunicazione Control Plane - Nodo](https://kubernetes.io/it/docs/_print/#pg-c0251def6da29b30afebfb04549f1703) * 3.2.2: [Concetti alla base del Cloud Controller Manager](https://kubernetes.io/it/docs/_print/#pg-bc804b02614d67025b4c788f1ca87fbc) * 3.2.3: [Controller](https://kubernetes.io/it/docs/_print/#pg-ca8819042a505291540e831283da66df) * 3.3: [Containers](https://kubernetes.io/it/docs/_print/#pg-a5f7383c83ab9eb9cd0e3c4c020b3ae6) * 3.3.1: [Immagini](https://kubernetes.io/it/docs/_print/#pg-16042b4652ad19e565c7263824029a43) * 3.3.2: [Container Environment](https://kubernetes.io/it/docs/_print/#pg-643212488f778acf04bebed65ba34441) * 3.3.3: [Container Lifecycle Hooks](https://kubernetes.io/it/docs/_print/#pg-e6941d969d81540208a3e78bc56f43bc) * 3.4: [Configurazione](https://kubernetes.io/it/docs/_print/#pg-275bea454e1cf4c5adeca4058b5af988) * 3.4.1: [ConfigMaps](https://kubernetes.io/it/docs/_print/#pg-6b5ccadd699df0904e8e9917c5450c4b) * 3.5: [Amministrazione del Cluster](https://kubernetes.io/it/docs/_print/#pg-285a3785fd3d20f437c28d87ca4dadca) * 3.5.1: [Proxy in Kubernetes](https://kubernetes.io/it/docs/_print/#pg-08e94e6a480e0d6b2de72d84a1b97617) * 3.6: [Esempio di modello di concetto](https://kubernetes.io/it/docs/_print/#pg-4c31edff4063c7b31c556b3eb1405c65) * 4: [Tutorials](https://kubernetes.io/it/docs/_print/#pg-68ec2370d0409cc27325be36693f9368) * 4.1: [Hello Minikube](https://kubernetes.io/it/docs/_print/#pg-5e3051fff9e84735871d9fb5e7b93f33) 1 - Glossario ============= 2 - Documentazione di Kubernetes ================================ 2.1 - Versioni supportate della documentazione di Kubernetes ============================================================ Questo sito contiene la documentazione della versione attuale di Kubernetes e delle quattro versioni precedenti di Kubernetes. 3 - Concetti ============ La sezione Concetti ti aiuta a conoscere le parti del sistema Kubernetes e le astrazioni utilizzate da Kubernetes per rappresentare il tuo cluster e ti aiuta ad ottenere una comprensione più profonda di come funziona Kubernetes. Overview -------- Per lavorare con Kubernetes, usi _gli oggetti API Kubernetes_ per descrivere lo _stato desiderato del tuo cluster_: quali applicazioni o altri carichi di lavoro vuoi eseguire, quali immagini del contenitore usano, numero di repliche, quali risorse di rete e disco vuoi rendere disponibile e altro ancora. Puoi impostare lo stato desiderato creando oggetti usando l'API di Kubernetes, in genere tramite l'interfaccia della riga di comando, `kubectl`. Puoi anche utilizzare direttamente l'API di Kubernetes per interagire con il cluster e impostare o modificare lo stato desiderato. Una volta impostato lo stato desiderato, il _Kubernetes Control Plane_ funziona per fare in modo che lo stato corrente del cluster corrisponda allo stato desiderato. Per fare ciò, Kubernetes esegue automaticamente una serie di attività, come l'avvio o il riavvio dei contenitori, il ridimensionamento del numero di repliche di una determinata applicazione e altro ancora. Il piano di controllo di Kubernetes è costituito da una raccolta di processi in esecuzione sul cluster: * Il **Kubernetes Master** è una raccolta di tre processi che vengono eseguiti su un singolo nodo nel cluster, che è designato come nodo principale. Questi processi sono: [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver/) , [kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager/) e [kube-scheduler](https://kubernetes.io/docs/admin/kube-scheduler/) . * Ogni singolo nodo non principale nel cluster esegue due processi:   \* **[kubelet](https://kubernetes.io/docs/admin/kubelet/) **, che comunica con il master di Kubernetes.   \* **[kube-proxy](https://kubernetes.io/docs/admin/kube-proxy/) **, un proxy di rete che riflette i servizi di rete di Kubernetes su ciascun nodo. Kubernetes Objects ------------------ kubernetes contiene una serie di astrazioni che rappresentano lo stato del tuo sistema: applicazioni e carichi di lavoro distribuiti in container, le loro risorse di rete e disco associate e altre informazioni su ciò che sta facendo il tuo cluster. Queste astrazioni sono rappresentate da oggetti nell'API di Kubernetes; guarda la [Panoramica degli oggetti di Kubernetes](https://kubernetes.io/docs/concepts/abstractions/overview/) per maggiori dettagli. Gli oggetti di base di Kubernetes includono: * [Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) * [Service](https://kubernetes.io/docs/concepts/services-networking/service/) * [Volume](https://kubernetes.io/docs/concepts/storage/volumes/) * [Namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) 209/5000 Inoltre, Kubernetes contiene una serie di astrazioni di livello superiore denominate Controllori. I controller si basano sugli oggetti di base e forniscono funzionalità aggiuntive e funzionalità di convenienza. Loro includono: * [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) * [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) * [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) * [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) * [Job](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) Kubernetes Control Plane ------------------------ Le varie parti del Piano di controllo di Kubernetes, come i master Kubernetes e i processi di Kubelet, regolano il modo in cui Kubernetes comunica con il cluster. Il Piano di controllo mantiene un registro di tutti gli oggetti Kubernetes nel sistema e esegue cicli di controllo continui per gestire lo stato di tali oggetti. In qualsiasi momento, i loop di controllo di Control Plane risponderanno ai cambiamenti nel cluster e lavoreranno per fare in modo che lo stato effettivo di tutti gli oggetti nel sistema corrisponda allo stato desiderato che hai fornito. Ad esempio, quando si utilizza l'API di Kubernetes per creare un oggetto di distribuzione, si fornisce un nuovo stato desiderato per il sistema. Il piano di controllo di Kubernetes registra la creazione dell'oggetto e svolge le tue istruzioni avviando le applicazioni richieste e pianificandole sui nodi del cluster, in modo che lo stato effettivo del cluster corrisponda allo stato desiderato. ### Kubernetes Master Il master Kubernetes è responsabile della gestione dello stato desiderato per il tuo cluster. Quando interagisci con Kubernetes, ad esempio utilizzando l'interfaccia della riga di comando `kubectl`, stai comunicando con il master di Kubernetes del cluster. > Il "master" si riferisce a una raccolta di processi che gestiscono lo stato del cluster. In genere questi processi vengono eseguiti tutti su un singolo nodo nel cluster e questo nodo viene anche definito master. Il master può anche essere replicato per disponibilità e ridondanza. ### Kubernetes Nodes I nodi di un cluster sono le macchine (VM, server fisici, ecc.) che eseguono i flussi di lavoro delle applicazioni e del cloud. Il master Kubernetes controlla ciascun nodo; raramente interagirai direttamente con i nodi. #### Object Metadata * [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) Voci correlate -------------- Se vuoi scrivere una pagina concettuale, vedi [Uso dei modelli di pagina](https://kubernetes.io/docs/home/contribute/page-templates/) per informazioni sul tipo di pagina di concetto e il modello di concetto. 3.1 - Overview ============== 3.1.1 - Cos'è Kubernetes? ========================= Kubernetes è una piattaforma portatile, estensibile e open-source per la gestione di carichi di lavoro e servizi containerizzati, in grado di facilitare sia la configurazione dichiarativa che l'automazione. La piattaforma vanta un grande ecosistema in rapida crescita. Servizi, supporto e strumenti sono ampiamente disponibili nel mondo Kubernetes . Questa pagina è una panoramica generale su Kubernetes. Kubernetes è una piattaforma portatile, estensibile e open-source per la gestione di carichi di lavoro e servizi containerizzati, in grado di facilitare sia la configurazione dichiarativa che l'automazione. La piattaforma vanta un grande ecosistema in rapida crescita. Servizi, supporto e strumenti sono ampiamente disponibili nel mondo Kubernetes . Il nome Kubernetes deriva dal greco, significa timoniere o pilota. Google ha reso open-source il progetto Kubernetes nel 2014. Kubernetes unisce [oltre quindici anni di esperienza di Google](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/) nella gestione di carichi di lavoro di produzione su scala mondiale con le migliori idee e pratiche della comunità. Facciamo un piccolo salto indietro ---------------------------------- Diamo un'occhiata alla ragione per cui Kubernetes è così utile facendo un piccolo salto indietro nel tempo. ![Deployment evolution](https://kubernetes.io/images/docs/Container_Evolution.svg) **L'era del deployment tradizionale:** All'inizio, le organizzazioni eseguivano applicazioni su server fisici. Non c'era modo di definire i limiti delle risorse per le applicazioni in un server fisico e questo ha causato non pochi problemi di allocazione delle risorse. Ad esempio, se più applicazioni vengono eseguite sullo stesso server fisico, si possono verificare casi in cui un'applicazione assorbe la maggior parte delle risorse e, di conseguenza, le altre applicazioni non hanno le prestazioni attese. Una soluzione per questo sarebbe di eseguire ogni applicazione su un server fisico diverso. Ma questa non è una soluzione ideale, dal momento che le risorse vengono sottoutilizzate, inoltre, questa pratica risulta essere costosa per le organizzazioni, le quali devono mantenere numerosi server fisici. **L'era del deployment virtualizzato:** Come soluzione venne introdotta la virtualizzazione. Essa consente di eseguire più macchine virtuali (VM) su una singola CPU fisica. La virtualizzazione consente di isolare le applicazioni in più macchine virtuali e fornisce un livello di sicurezza superiore, dal momento che le informazioni di un'applicazione non sono liberamente accessibili da un'altra applicazione. La virtualizzazione consente un migliore utilizzo delle risorse riducendo i costi per l'hardware, permette una migliore scalabilità, dato che un'applicazione può essere aggiunta o aggiornata facilmente, e ha molti altri vantaggi. Ogni VM è una macchina completa che esegue tutti i componenti, compreso il proprio sistema operativo, sopra all'hardware virtualizzato. **L'era del deployment in container:** I container sono simili alle macchine virtuali, ma presentano un modello di isolamento più leggero, condividendo il sistema operativo (OS) tra le applicazioni. Pertanto, i container sono considerati più leggeri. Analogamente a una macchina virtuale, un container dispone di una segregazione di filesystem, CPU, memoria, PID e altro ancora. Poiché sono disaccoppiati dall'infrastruttura sottostante, risultano portabili tra differenti cloud e diverse distribuzioni. I container sono diventati popolari dal momento che offrono molteplici vantaggi, ad esempio: * Creazione e distribuzione di applicazioni in modalità Agile: maggiore facilità ed efficienza nella creazione di immagini container rispetto all'uso di immagini VM. * Adozione di pratiche per lo sviluppo/test/rilascio continuativo: consente la frequente creazione e la distribuzione di container image affidabili, dando la possibilità di fare rollback rapidi e semplici (grazie all'immutabilità dell'immagine stessa). * Separazione delle fasi di Dev e Ops: le container image vengono prodotte al momento della compilazione dell'applicativo piuttosto che nel momento del rilascio, permettendo così di disaccoppiare le applicazioni dall'infrastruttura sottostante. * L'osservabilità non riguarda solo le informazioni e le metriche del sistema operativo, ma anche lo stato di salute e altri segnali dalle applicazioni. * Coerenza di ambiente tra sviluppo, test e produzione: i container funzionano allo stesso modo su un computer portatile come nel cloud. * Portabilità tra cloud e sistemi operativi differenti: lo stesso container funziona su Ubuntu, RHEL, CoreOS, on-premise, nei più grandi cloud pubblici e da qualsiasi altra parte. * Gestione incentrata sulle applicazioni: Aumenta il livello di astrazione dall'esecuzione di un sistema operativo su hardware virtualizzato all'esecuzione di un'applicazione su un sistema operativo utilizzando risorse logiche. * Microservizi liberamente combinabili, distribuiti, ad alta scalabilità: le applicazioni sono suddivise in pezzi più piccoli e indipendenti che possono essere distribuite e gestite dinamicamente - niente stack monolitici che girano su una singola grande macchina. * Isolamento delle risorse: le prestazioni delle applicazioni sono prevedibili. * Utilizzo delle risorse: alta efficienza e densità. Perché necessito di Kubernetes e cosa posso farci ------------------------------------------------- I container sono un buon modo per distribuire ed eseguire le tue applicazioni. In un ambiente di produzione, è necessario gestire i container che eseguono le applicazioni e garantire che non si verifichino interruzioni dei servizi. Per esempio, se un container si interrompe, è necessario avviare un nuovo container. Non sarebbe più facile se questo comportamento fosse gestito direttamente da un sistema? È proprio qui che Kubernetes viene in soccorso! Kubernetes ti fornisce un framework per far funzionare i sistemi distribuiti in modo resiliente. Kubernetes si occupa della scalabilità, failover, distribuzione delle tue applicazioni. Per esempio, Kubernetes può facilmente gestire i rilasci con modalità Canary deployment. Kubernetes ti fornisce: * **Scoperta dei servizi e bilanciamento del carico** Kubernetes può esporre un container usando un nome DNS o il suo indirizzo IP. Se il traffico verso un container è alto, Kubernetes è in grado di distribuire il traffico su più container in modo che il servizio rimanga stabile. * **Orchestrazione dello storage** Kubernetes ti permette di montare automaticamente un sistema di archiviazione di vostra scelta, come per esempio storage locale, dischi forniti da cloud pubblici, e altro ancora. * **Rollout e rollback automatizzati** Puoi utilizzare Kubernetes per descrivere lo stato desiderato per i propri container, e Kubernetes si occuperà di cambiare lo stato attuale per raggiungere quello desiderato ad una velocità controllata. Per esempio, puoi automatizzare Kubernetes per creare nuovi container per il tuo servizio, rimuovere i container esistenti e adattare le loro risorse a quelle richieste dal nuovo container. * **Ottimizzazione dei carichi** Fornisci a Kubernetes un cluster di nodi per eseguire i container. Puoi istruire Kubernetes su quanta CPU e memoria (RAM) ha bisogno ogni singolo container. Kubernetes allocherà i container sui nodi per massimizzare l'uso delle risorse a disposizione. * **Self-healing** Kubernetes riavvia i container che si bloccano, sostituisce container, termina i container che non rispondono agli health checks, e evita di far arrivare traffico ai container che non sono ancora pronti per rispondere correttamente. * **Gestione di informazioni sensibili e della configurazione** Kubernetes consente di memorizzare e gestire informazioni sensibili, come le password, i token OAuth e le chiavi SSH. Puoi distribuire e aggiornare le informazioni sensibili e la configurazione dell'applicazione senza dover ricostruire le immagini dei container e senza svelare le informazioni sensibili nella configurazione del tuo sistema. Cosa non è Kubernetes --------------------- Kubernetes non è un sistema PaaS (Platform as a Service) tradizionale e completo. Dal momento che Kubernetes opera a livello di container piuttosto che che a livello hardware, esso fornisce alcune caratteristiche generalmente disponibili nelle offerte PaaS, come la distribuzione, il ridimensionamento, il bilanciamento del carico, la registrazione e il monitoraggio. Tuttavia, Kubernetes non è monolitico, e queste soluzioni predefinite sono opzionali ed estensibili. Kubernetes fornisce gli elementi base per la costruzione di piattaforme di sviluppo, ma conserva le scelte dell'utente e la flessibilità dove è importante. Kubernetes: * Non limita i tipi di applicazioni supportate. Kubernetes mira a supportare una grande varietà di carichi di lavoro, compresi i carichi di lavoro stateless, stateful e elaborazione di dati. Se un'applicazione può essere eseguita in un container, dovrebbe funzionare alla grande anche su Kubernetes. * Non compila il codice sorgente e non crea i container. I flussi di Continuous Integration, Delivery, and Deployment (CI/CD) sono determinati dalla cultura e dalle preferenze dell'organizzazione e dai requisiti tecnici. * Non fornisce servizi a livello applicativo, come middleware (per esempio, bus di messaggi), framework di elaborazione dati (per esempio, Spark), database (per esempio, mysql), cache, né sistemi di storage distribuito (per esempio, Ceph) come servizi integrati. Tali componenti possono essere eseguiti su Kubernetes, e/o possono essere richiamati da applicazioni che girano su Kubernetes attraverso meccanismi come l'[Open Service Broker](https://openservicebrokerapi.org/) . * Non impone soluzioni di logging, monitoraggio o di gestione degli alert. Fornisce alcune integrazioni come dimostrazione, e meccanismi per raccogliere ed esportare le metriche. * Non fornisce né rende obbligatorio un linguaggio/sistema di configurazione (per esempio, Jsonnet). Fornisce un'API dichiarativa che può essere richiamata da qualsiasi sistema. * Non fornisce né adotta alcun sistema di gestione completa della macchina, configurazione, manutenzione, gestione o sistemi di self healing. * Inoltre, Kubernetes non è un semplice sistema di orchestrazione. Infatti, questo sistema elimina la necessità di orchestrazione. La definizione tecnica di orchestrazione è l'esecuzione di un flusso di lavoro definito: prima si fa A, poi B, poi C. Al contrario, Kubernetes è composto da un insieme di processi di controllo indipendenti e componibili che guidano costantemente lo stato attuale verso lo stato desiderato. Non dovrebbe importare come si passa dalla A alla C. Anche il controllo centralizzato non è richiesto. Questo si traduce in un sistema più facile da usare, più potente, robusto, resiliente ed estensibile. Voci correlate -------------- * Dai un'occhiata alla pagina [i componenti di Kubernetes](https://kubernetes.io/it/docs/concepts/overview/components/) * Sai già [Come Iniziare](https://kubernetes.io/docs/setup/) ? 3.1.2 - I componenti di Kubernetes ================================== Un cluster di Kubernetes è costituito da un insieme di componenti che sono, come minimo, un Control Plane e uno o più sistemi di elaborazione, detti nodi. Facendo il deployment di Kubernetes, ottieni un cluster. Un cluster Kubernetes è un'insieme di macchine, chiamate nodi, che eseguono container gestiti da Kubernetes. Un cluster ha almeno un Worker Node. Il/I Worker Node ospitano i Pod che eseguono i workload dell'utente. Il/I Control Plane Node gestiscono i Worker Node e tutto quanto accade all'interno del cluster. Per garantire la high-availability e la possibilità di failover del cluster, vengono utilizzati più Control Plane Node. Questo documento descrive i diversi componenti che sono necessari per avere un cluster Kubernetes completo e funzionante. Questo è un diagramma di un cluster Kubernetes con tutti i componenti e le loro relazioni. ![I componenti di Kubernetes](https://kubernetes.io/images/docs/components-of-kubernetes.png) Componenti della Control Plane ------------------------------ I componenti del Control Plane sono responsabili di tutte le decisioni globali sul cluster (ad esempio, lo scheduling) oltre che a rilevare e rispondere agli eventi del cluster (ad esempio, l'avvio di un nuovo [pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") quando il valore `replicas` di un deployment non è soddisfatto). I componenti della Control Plane possono essere eseguiti su qualsiasi nodo del cluster stesso. Solitamente, per semplicità, gli script di installazione tendono a eseguire tutti i componenti della Control Plane sulla stessa macchina, separando la Control Plane dai workload dell'utente. Vedi [creare un cluster in High-Availability](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) per un esempio di un'installazione multi-master. ### kube-apiserver L'API server è un componente di Kubernetes [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") che espone le Kubernetes API. L'API server è il front end del control plane di Kubernetes. La principale implementazione di un server Kubernetes API è [kube-apiserver](https://kubernetes.io/docs/reference/generated/kube-apiserver/) . kube-apiserver è progettato per scalare orizzontalmente, cioè scala aumentando il numero di istanze. Puoi eseguire multiple istanze di kube-apiserver e bilanciare il traffico tra queste istanze. ### etcd È un database key-value ridondato, che è usato da Kubernetes per salvare tutte le informazioni del cluster. Se il tuo cluster utilizza etcd per salvare le informazioni, assicurati di avere una strategia di [backup](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) per questi dati. Puoi trovare informazioni dettagliate su etcd sulla [documentazione](https://etcd.io/docs/) ufficiale. ### kube-scheduler Componente della Control Plane che controlla i pod appena creati che non hanno un nodo assegnato, e dopo averlo identificato glielo assegna. I fattori presi in considerazioni nell'individuare un nodo a cui assegnare l'esecuzione di un Pod includono la richiesta di risorse del Pod stesso e degli altri workload presenti nel sistema, i vincoli delle hardware/software/policy, le indicazioni di affinity e di anti-affinity, requisiti relativi alla disponibilità di dati/Volumes, le interferenze tra diversi workload e le scadenze. ### kube-controller-manager Componente della Control Plane che gestisce [controllers](https://kubernetes.io/it/docs/concepts/architecture/controller/ "Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato.") . Da un punto di vista logico, ogni [controller](https://kubernetes.io/it/docs/concepts/architecture/controller/ "Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato.") è un processo separato, ma per ridurre la complessità, tutti i principali controller di Kubernetes vengono raggruppati in un unico container ed eseguiti in un singolo processo. Alcuni esempi di controller gestiti dal kube-controller-manager sono: * Node Controller: Responsabile del monitoraggio dei nodi del cluster, e.g. della gestione delle azioni da eseguire quando un nodo diventa non disponibile. * Replication Controller: Responsabile per il mantenimento del corretto numero di Pod per ogni ReplicaSet presente nel sistema * Endpoints Controller: Popola gli oggetti Endpoints (cioè, mette in relazioni i Pods con i Services). * Service Account & Token Controllers: Creano gli account di default e i token di accesso alle API per i nuovi namespaces. ### cloud-controller-manager Un componente della [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") di Kubernetes che aggiunge logiche di controllo specifiche per il cloud. Il cloud-controller-manager ti permette di collegare il tuo cluster con le API del cloud provider e separa le componenti che interagiscono con la piattaforma cloud dai componenti che interagiscono solamente col cluster. Il cloud-controller-manager esegue dei controller specifici del tuo cloud provider. Se hai una installazione Kubernetes on premises, o un ambiente di laboratorio nel tuo PC, il cluster non ha un cloud-controller-manager. Come nel kube-controller-manager, il cloud-controller-manager combina diversi control loop logicamente indipendenti in un singolo binario che puoi eseguire come un singolo processo. Tu puoi scalare orizzontalmente (eseguire più di una copia) per migliorare la responsività o per migliorare la tolleranza ai fallimenti. I seguenti controller hanno dipendenze verso implementazioni di specifici cloud provider: * Node Controller: Per controllare se sul cloud provider i nodi che hanno smesso di rispondere sono stati cancellati * Route Controller: Per configurare le network route nella sottostante infrastruttura cloud * Service Controller: Per creare, aggiornare ed eliminare i load balancer del cloud provider Componenti dei Nodi ------------------- I componenti del nodo vengono eseguiti su ogni nodo, mantenendo i pod in esecuzione e fornendo l'ambiente di runtime Kubernetes. ### kubelet Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod. La kubelet riceve un set di PodSpecs che vengono forniti attraverso vari meccanismi, e si assicura che i container descritti in questi PodSpecs funzionino correttamente e siano sani. La kubelet non gestisce i container che non sono stati creati da Kubernetes. ### kube-proxy [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) è un proxy eseguito su ogni nodo del cluster, responsabile della gestione dei Kubernetes [Service](https://kubernetes.io/it/docs/concepts/services-networking/service/ "A way to expose an application running on a set of Pods as a network service.") . I kube-proxy mantengono le regole di networking sui nodi. Queste regole permettono la comunicazione verso gli altri nodi del cluster o l'esterno. Il kube-proxy usa le librerie del sistema operativo quando possible; in caso contrario il kube-proxy gestisce il traffico direttamente. ### Container Runtime Il container runtime è il software che è responsabile per l'esecuzione dei container. Kubernetes supporta diversi container runtimes: [Docker](http://www.docker.com/) , [containerd](https://containerd.io/) , [cri-o](https://cri-o.io/) , [rktlet](https://github.com/kubernetes-incubator/rktlet) e tutte le implementazioni di [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Addons ------ Gli Addons usano le risorse Kubernetes ([DaemonSet](https://kubernetes.io/it/docs/concepts/workloads/controllers/daemonset "Assicura che una copia di un Pod è attiva su tutti nodi di un cluster.") , [Deployment](https://kubernetes.io/it/docs/concepts/workloads/controllers/deployment/ "Gestisce una applicazione replicata nel tuo cluster.") , etc) per implementare funzionalità di cluster. Dal momento che gli addons forniscono funzionalità a livello di cluster, le risorse che necessitano di un namespace, vengono collocate nel namespace `kube-system`. Alcuni addons sono descritti di seguito; mentre per una più estesa lista di addons, per favore vedere [Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) . ### DNS Mentre gli altri addons non sono strettamente richiesti, tutti i cluster Kubernetes dovrebbero essere muniti di un [DNS del cluster](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) , dal momento che molte applicazioni lo necessitano. Il DNS del cluster è un server DNS aggiuntivo rispetto ad altri server DNS presenti nella rete, e si occupa specificatamente dei record DNS per i servizi Kubernetes. I container eseguiti da Kubernetes automaticamente usano questo server per la risoluzione DNS. ### Interfaccia web (Dashboard) La [Dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) è una interfaccia web per i cluster Kubernetes. Permette agli utenti di gestire e fare troubleshooting delle applicazioni che girano nel cluster, e del cluster stesso. ### Monitoraggio dei Container Il [Monitoraggio dei Container](https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/) salva serie temporali di metriche generiche dei container in un database centrale e fornisce una interfaccia in cui navigare i dati stessi. ### Log a livello di Cluster Un [log a livello di cluster](https://kubernetes.io/docs/concepts/cluster-administration/logging/) è responsabile per il salvataggio dei log dei container in un log centralizzato la cui interfaccia permette di cercare e navigare nei log. Voci correlate -------------- * Scopri i concetti relativi ai [Nodi](https://kubernetes.io/docs/concepts/architecture/nodes/) * Scopri i concetti relativi ai [Controller](https://kubernetes.io/it/docs/concepts/architecture/controller/) * Scopri i concetti relativi al [kube-scheduler](https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/) * Leggi la [documentazione](https://etcd.io/docs/) ufficiale di etcd 3.1.3 - Le API di Kubernetes ============================ Le API di Kubernetes ti permettono di interrogare e manipolare lo stato degli oggetti in Kubernetes. Il cuore del Control Plane di Kubernetes è l'API server e le API HTTP che esso espone. Ogni entità o componente che si interfaccia con il cluster (gli utenti, le singole parti del tuo cluster, i componenti esterni), comunica attraverso l'API server. Le convenzioni generali seguite dalle API sono descritte in [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) . Gli _endpoints_ delle API, la lista delle risorse esposte ed i relativi esempi sono descritti in [API Reference](https://kubernetes.io/docs/reference) . L'accesso alle API da remoto è discusso in [Controllare l'accesso alle API](https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/) . Le API di Kubernetes servono anche come riferimento per lo schema dichiarativo della configurazione del sistema stesso. Il comando [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) può essere usato per creare, aggiornare, cancellare ed ottenere le istanze delle risorse esposte attraverso le API. Kubernetes assicura la persistenza del suo stato (al momento in [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/) ) usando la rappresentazione delle risorse implementata dalle API. Kubernetes stesso è diviso in differenti componenti, i quali interagiscono tra loro attraverso le stesse API. Evoluzione delle API -------------------- In base alla nostra esperienza, ogni sistema di successo ha bisogno di evolvere ovvero deve estendersi aggiungendo funzionalità o modificare le esistenti per adattarle a nuovi casi d'uso. Le API di Kubernetes sono quindi destinate a cambiare e ad estendersi. In generale, ci si deve aspettare che nuove risorse vengano aggiunte di frequente cosi come nuovi campi possano altresì essere aggiunti a risorse esistenti. L'eliminazione di risorse o di campi devono seguire la [politica di deprecazione delle API](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) . In cosa consiste una modifica compatibile e come modificare le API è descritto dal [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md) . Definizioni OpenAPI e Swagger ----------------------------- La documentazione completa e dettagliata delle API è fornita attraverso la specifica [OpenAPI](https://www.openapis.org/) . Dalla versione 1.10 di Kubernetes, l'API server di Kubernetes espone le specifiche OpenAPI attraverso il seguente _endpoint_ `/openapi/v2`. Attraverso i seguenti _headers_ HTTP è possibile richiedere un formato specifico: | Header | Possibili Valori | | --- | --- | | Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (il content-type di default è `application/json` per `*/*` ovvero questo header può anche essere omesso) | | Accept-Encoding | `gzip` (questo header è facoltativo) | Prima della versione 1.14, gli _endpoints_ che includono il formato del nome all'interno del segmento (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) espongo le specifiche OpenAPI in formati differenti. Questi _endpoints_ sono deprecati, e saranno rimossi dalla versione 1.14 di Kubernetes. **Esempi per ottenere le specifiche OpenAPI**: | Prima della 1.10 | Dalla versione 1.10 di Kubernetes | | --- | --- | | GET /swagger.json | GET /openapi/v2 **Accept**: application/json | | GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: [application/com.github.proto-openapi.spec.v2@v1.0](mailto:application/com.github.proto-openapi.spec.v2@v1.0)
+protobuf | | GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: [application/com.github.proto-openapi.spec.v2@v1.0](mailto:application/com.github.proto-openapi.spec.v2@v1.0)
+protobuf **Accept-Encoding**: gzip | Kubernetes implementa per le sue API anche una serializzazione alternativa basata sul formato Protobuf che è stato pensato principalmente per la comunicazione intra-cluster, documentato nella seguente [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) , e i files IDL per ciascun schema si trovano nei _Go packages_ che definisco i tipi delle API. Prima della versione 1.14, l'_apiserver_ di Kubernetes espone anche un'_endpoint_, `/swaggerapi`, che può essere usato per ottenere le documentazione per le API di Kubernetes secondo le specifiche [Swagger v1.2](http://swagger.io/) . Questo _endpoint_ è deprecato, ed è stato rimosso nella versione 1.14 di Kubernetes. Versionamento delle API ----------------------- Per facilitare l'eliminazione di campi specifici o la modifica della rappresentazione di una data risorsa, Kubernetes supporta molteplici versioni della stessa API disponibili attraverso differenti indirizzi, come ad esempio `/api/v1` oppure `/apis/extensions/v1beta1`. Abbiamo deciso di versionare a livello di API piuttosto che a livello di risorsa o di campo per assicurare che una data API rappresenti una chiara, consistente vista delle risorse di sistema e dei sui comportamenti, e per abilitare un controllo degli accessi sia per le API in via di decommissionamento che per quelle sperimentali. Si noti che il versionamento delle API ed il versionamento del Software sono indirettamente collegati. La [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) descrive la relazione tra le versioni delle API ed le versioni del Software. Differenti versioni delle API implicano differenti livelli di stabilità e supporto. I criteri per ciascuno livello sono descritti in dettaglio nella [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions) . Queste modifiche sono qui ricapitolate: * Livello alpha: * Il nome di versione contiene `alpha` (e.g. `v1alpha1`). * Potrebbe contenere dei _bug_. Abilitare questa funzionalità potrebbe esporre al rischio di _bugs_. Disabilitata di default. * Il supporto di questa funzionalità potrebbe essere rimosso in ogni momento senza previa notifica. * Questa API potrebbe cambiare in modo incompatibile in rilasci futuri del Software e senza previa notifica. * Se ne raccomandata l'utilizzo solo in _clusters_ di test creati per un breve periodo di vita, a causa di potenziali _bugs_ e delle mancanza di un supporto di lungo periodo. * Livello beta: * Il nome di versione contiene `beta` (e.g. `v2beta3`). * Il codice è propriamente testato. Abilitare la funzionalità è considerato sicuro. Abilitata di default. * Il supporto per la funzionalità nel suo complesso non sarà rimosso, tuttavia potrebbe subire delle modifiche. * Lo schema e/o la semantica delle risorse potrebbe cambiare in modo incompatibile in successivi rilasci beta o stabili. Nel caso questo dovesse verificarsi, verrano fornite istruzioni per la migrazione alla versione successiva. Questo potrebbe richiedere la cancellazione, modifica, e la ri-creazione degli oggetti supportati da questa API. Questo processo di modifica potrebbe richiedere delle valutazioni. La modifica potrebbe richiedere un periodo di non disponibilità dell'applicazione che utilizza questa funzionalità. * Raccomandata solo per applicazioni non critiche per la vostra impresa a causa dei potenziali cambiamenti incompatibili in rilasci successivi. Se avete più _clusters_ che possono essere aggiornati separatamente, potreste essere in grado di gestire meglio questa limitazione. * **Per favore utilizzate le nostre versioni beta e forniteci riscontri relativamente ad esse! Una volta promosse a stabili, potrebbe non essere semplice apportare cambiamenti successivi.** * Livello stabile: * Il nome di versione è `vX` dove `X` è un intero. * Le funzionalità relative alle versioni stabili continueranno ad essere presenti per parecchie versioni successive. API groups ---------- Per facilitare l'estendibilità delle API di Kubernetes, sono stati implementati gli [_API groups_](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) . L'_API group_ è specificato nel percorso REST ed anche nel campo `apiVersion` di un oggetto serializzato. Al momento ci sono diversi _API groups_ in uso: 1. Il gruppo _core_, spesso referenziato come il _legacy group_, è disponibile al percorso REST `/api/v1` ed utilizza `apiVersion: v1`. 2. I gruppi basati su un nome specifico sono disponibili attraverso il percorso REST `/apis/$GROUP_NAME/$VERSION`, ed usano `apiVersion: $GROUP_NAME/$VERSION` (e.g. `apiVersion: batch/v1`). La lista completa degli _API groups_ supportati e' descritta nel documento [Kubernetes API reference](https://kubernetes.io/docs/reference/) . Vi sono due modi per supportati per estendere le API attraverso le [_custom resources_](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) : 1. [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) è pensato per utenti con esigenze CRUD basilari. 2. Utenti che necessitano di un nuovo completo set di API che utilizzi appieno la semantica di Kubernetes possono implementare il loro _apiserver_ ed utilizzare l'[_aggregator_](https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) per fornire ai propri utilizzatori la stessa esperienza a cui sono abituati con le API incluse nativamente in Kubernetes. Abilitare o disabilitare gli _API groups_ ----------------------------------------- Alcune risorse ed _API groups_ sono abilitati di default. Questi posso essere abilitati o disabilitati attraverso il settaggio/flag `--runtime-config` applicato sull'_apiserver_. `--runtime-config` accetta valori separati da virgola. Per esempio: per disabilitare `batch/v1`, usa la seguente configurazione `--runtime-config=batch/v1=false`, per abilitare `batch/v2alpha1`, utilizzate `--runtime-config=batch/v2alpha1`. Il _flag_ accetta set di coppie _chiave/valore_ separati da virgola che descrivono la configurazione a _runtime_ dell'_apiserver_. #### Nota: Abilitare o disabilitare risorse o gruppi richiede il riavvio dell'_apiserver_ e del _controller-manager_ affinché le modifiche specificate attraverso il flag `--runtime-config` abbiano effetto. Abilitare specifiche risorse nel gruppo extensions/v1beta1 ---------------------------------------------------------- DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies e ReplicaSets presenti nel gruppo di API `extensions/v1beta1` sono disabilitate di default. Per esempio: per abilitare deployments and daemonsets, utilizza la seguente configurazione `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. #### Nota: Abilitare/disabilitare una singola risorsa è supportato solo per il gruppo di API `extensions/v1beta1` per ragioni storiche. 3.2 - Architettura di Kubernetes ================================ 3.2.1 - Comunicazione Control Plane - Nodo ========================================== Questo documento cataloga le connessioni tra il piano di controllo (_control-plane_), in realtà l'apiserver, e il cluster Kubernetes. L'intento è di consentire agli utenti di personalizzare la loro installazione per rafforzare la configurazione di rete affinché il cluster possa essere eseguito su una rete pubblica (o su IP completamente pubblici resi disponibili da un fornitore di servizi cloud). Dal Nodo al control-plane ------------------------- Kubernetes adotta un pattern per le API di tipo _"hub-and-spoke"_. Tutte le chiamate delle API eseguite sui vari nodi sono effettuate verso l'apiserver (nessuno degli altri componenti principali è progettato per esporre servizi remoti). L'apiserver è configurato per l'ascolto di connessioni remote su una porta HTTPS protetta (443) con una o più forme di [autenticazioni client](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) abilitate. Si dovrebbero abilitare una o più forme di [autorizzazioni](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) , in particolare nel caso in cui siano ammesse [richieste anonime](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests) o [_token_ legati ad un account di servizio (_service account_)](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) . Il certificato pubblico (_public root certificate_) relativo al cluster corrente deve essere fornito ai vari nodi di modo che questi possano connettersi in modo sicuro all'apiserver insieme alle credenziali valide per uno specifico _client_. Ad esempio, nella configurazione predefinita di un cluster [GKE](https://cloud.google.com/kubernetes-engine?hl=it) , le credenziali del client fornite al kubelet hanno la forma di un certificato client. Si veda [inizializzazione TLS del kubelet TLS](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) per la fornitura automatica dei certificati client al _kubelet_. I Pod che desiderano connettersi all'apiserver possono farlo in modo sicuro sfruttando un account di servizio in modo che Kubernetes inserisca automaticamente il certificato pubblico di radice e un token valido al portatore (_bearer token_) all'interno Pod quando questo viene istanziato. In tutti i namespace è configurato un _Service_ con nome `kubernetes` con un indirizzo IP virtuale che viene reindirizzato (tramite _kube-proxy_) all'endpoint HTTPS dell'apiserver. Anche i componenti del piano d controllo comunicano con l'apiserver del cluster su di una porta sicura esposta da quest'ultimo. Di conseguenza, la modalità operativa predefinita per le connessioni dai nodi e dai Pod in esecuzione sui nodi verso il _control-plane_ è protetta da un'impostazione predefinita e può essere eseguita su reti non sicure e/o pubbliche. Dal control-plane al nodo ------------------------- Esistono due percorsi di comunicazione principali dal _control-plane_ (apiserver) verso i nodi. Il primo è dall'apiserver verso il processo _kubelet_ in esecuzione su ogni nodo nel cluster. Il secondo è dall'apiserver a ciascun nodo, Pod, o servizio attraverso la funzionalità proxy dell'apiserver. ### Dall'apiserver al _kubelet_ Le connessioni dall'apiserver al _kubelet_ vengono utilizzate per: * Prendere i log relativi ai vari Pod. * Collegarsi (attraverso kubectl) ai Pod in esecuzione. * Fornire la funzionalità di _port-forwarding_ per i _kubelet_. Queste connessioni terminano all'endpoint HTTPS del _kubelet_. Di default, l'apiserver non verifica il certificato servito dal _kubelet_, il che rende la connessione soggetta ad attacchi _man-in-the-middle_, e tale da essere considerato **non sicuro (unsafe)** se eseguito su reti non protette e/o pubbliche. Per verificare questa connessione, si utilizzi il parametro `--kubelet-certificate-authority` al fine di fornire all'apiserver un insieme di certificati radice da utilizzare per verificare il il certificato servito dal _kubelet_. Se questo non è possibile, si usi un [tunnel SSH](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) tra l'apiserver e il _kubelet_, se richiesto, per evitare il collegamento su una rete non protetta o pubblica. In fine, l'[autenticazione e/o l'autorizzazione del kubelet](https://kubernetes.io/docs/admin/kubelet-authentication-authorization/) dovrebbe essere abilitate per proteggere le API esposte dal _kubelet_. ### Dall'apiserver ai nodi, Pod, e servizi Le connessioni dall'apiserver verso un nodo, Pod o servizio avvengono in modalità predefinita su semplice connessione HTTP e quindi non sono né autenticate né criptata. Queste connessioni possono essere eseguite su una connessione HTTPS sicura mediante il prefisso `https:` al nodo, Pod o nome del servizio nell'URL dell'API, ma non valideranno il certificato fornito dall'endpoint HTTPS né forniranno le credenziali del client così anche se la connessione verrà criptata, non fornirà alcuna garanzia di integrità. **Non è attualmente sicuro** eseguire queste connessioni su reti non protette e/o pubbliche. ### I tunnel SSH Kubernetes supporta i _tunnel_ SSH per proteggere la comunicazione tra il _control-plane_ e i nodi. In questa configurazione, l'apiserver inizializza un tunnel SSH con ciascun nodo del cluster (collegandosi al server SSH in ascolto sulla porta 22) e fa passare tutto il traffico verso il _kubelet_, il nodo, il Pod, o il servizio attraverso questo tunnel. Questo tunnel assicura che il traffico non sia esposto al di fuori della rete su cui sono in esecuzioni i vari nodi. I tunnel SSH sono al momento deprecati ovvero non dovrebbero essere utilizzati a meno che ci siano delle esigenze particolari. Il servizio `Konnectivity` è pensato per rimpiazzare questo canale di comunicazione. ### Il servizio _Konnectivity_ FEATURE STATE: `Kubernetes v1.18 [beta]` Come rimpiazzo dei tunnel SSH, il servizio _Konnectivity_ fornisce un proxy a livello TCP per la comunicazione tra il _control-plane_ e il cluster. Il servizio _Konnectivity_ consiste in due parti: il _Konnectivity_ server e gli agenti _Konnectivity_, in esecuzione rispettivamente sul _control-plane_ e sui vari nodi. Gli agenti _Konnectivity_ inizializzano le connessioni verso il server _Konnectivity_ e mantengono le connessioni di rete. Una volta abilitato il servizio _Konnectivity_, tutto il traffico tra il _control-plane_ e i nodi passa attraverso queste connessioni. Si può fare riferimento al [tutorial per il servizio _Konnectivity_](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) per configurare il servizio _Konnectivity_ all'interno del cluster 3.2.2 - Concetti alla base del Cloud Controller Manager ======================================================= Il concetto di CCM (cloud controller manager), da non confondere con il binario, è stato originariamente creato per consentire di sviluppare Kubernetes indipendentemente dall'implementazione dello specifico cloud provider. Il cloud controller manager viene eseguito insieme ad altri componenti principali come il Kubernetes controller manager, il server API e lo scheduler. Può anche essere avviato come addon di Kubernetes, nel qual caso viene eseguito su Kubernetes. Il design del cloud controller manager è basato su un meccanismo di plug-in che consente ai nuovi provider cloud di integrarsi facilmente con Kubernetes creando un plug-in. Sono in atto programmi per l'aggiunta di nuovi provider di cloud su Kubernetes e per la migrazione dei provider che usano il vecchio metodo a questo nuovo metodo. Questo documento discute i concetti alla base del cloud controller manager e fornisce dettagli sulle funzioni associate. Ecco l'architettura di un cluster Kubernetes senza il gestore del controller cloud: ![Pre CCM Kube Arch](https://kubernetes.io/images/docs/pre-ccm-arch.png) Architettura ------------ Nel diagramma precedente, Kubernetes e il provider cloud sono integrati attraverso diversi componenti: * Kubelet * Kubernetes controller manager * Kubernetes API server Il CCM consolida tutta la logica dipendente dal cloud presente nei tre componenti precedenti, per creare un singolo punto di integrazione con il cloud. La nuova architettura con il CCM si presenta così: ![CCM Kube Arch](https://kubernetes.io/images/docs/post-ccm-arch.png) Componenti del CCM ------------------ Il CCM divide alcune funzionalità del Kubernetes controller manager (KCM) e le esegue in un differente processo. In particolare, toglie dal KCM le integrazioni con il cloud specifico. Il KCM ha i seguenti controller che dipendono dal cloud specifico: * Node controller * Volume controller * Route controller * Service controller Nella versione 1.9, il CCM esegue i seguenti controller dall'elenco precedente: * Node controller * Route controller * Service controller #### Nota: È stato deliberatamente deciso di non spostare il Volume controller nel CCM. Data la complessità del Volume controller e gli sforzi già fatti per astrarre le logiche specifiche dei singoli fornitori, è stato deciso che il Volume controller non verrà spostato nel CCM. Il piano originale per supportare i volumi utilizzando il CCM era di utilizzare [Flex](https://kubernetes.io/docs/concepts/storage/volumes/#flexVolume) per supportare volumi collegabili. Tuttavia, una implementazione parallela, nota come [CSI](https://kubernetes.io/docs/concepts/storage/volumes/#csi) è stata designata per sostituire Flex. Considerando queste evoluzioni, abbiamo deciso di adottare un approccio intermedio finché il CSI non è pronto. Funzioni del CCM ---------------- Il CCM eredita le sue funzioni da componenti di Kubernetes che dipendono da uno specifico provider di cloud. Questa sezione è strutturata sulla base di tali componenti. ### 1\. Kubernetes controller manager La maggior parte delle funzioni del CCM deriva dal KCM. Come menzionato nella sezione precedente, CCM esegue i seguenti cicli di controllo: * Node controller * Route controller * Service controller #### Node controller Il Node controller è responsabile per l'inizializzazione di un nodo ottenendo informazioni sui nodi in esecuzione nel cluster dal provider cloud. Il controller del nodo esegue le seguenti funzioni: 1. Inizializzare un nodo con le label zone/region specifiche per il cloud in uso. 2. Inizializzare un nodo con le specifiche, ad esempio, tipo e dimensione specifiche del cloud in uso. 3. Ottenere gli indirizzi di rete del nodo e l'hostname. 4. Nel caso in cui un nodo non risponda, controlla il cloud per vedere se il nodo è stato cancellato dal cloud. Se il nodo è stato eliminato dal cloud, elimina l'oggetto Nodo di Kubernetes. #### Route controller Il Route controller è responsabile della configurazione delle route nel cloud in modo che i container su nodi differenti del cluster Kubernetes possano comunicare tra loro. Il Route controller è utilizzabile solo dai cluster su Google Compute Engine. #### Service Controller Il Service Controller rimane in ascolto per eventi di creazione, aggiornamento ed eliminazione di servizi. In base allo stato attuale dei servizi in Kubernetes, configura i bilanciatori di carico forniti dal cloud (come gli ELB, i Google LB, o gli Oracle Cloud Infrastructure LB) per riflettere lo stato dei servizi in Kubernetes. Inoltre, assicura che i back-end dei bilanciatori di carico forniti dal cloud siano aggiornati. ### 2\. Kubelet Il Node Controller contiene l'implementazione dipendente dal cloud della kubelet. Prima dell'introduzione del CCM, la kubelet era responsabile dell'inizializzazione di un nodo con dettagli dipendenti dallo specifico cloud come gli indirizzi IP, le label region/zone e le informazioni sul tipo di istanza. L'introduzione del CCM ha spostato questa operazione di inizializzazione dalla kubelet al CCM. In questo nuovo modello, la kubelet inizializza un nodo senza informazioni specifiche del cloud. Tuttavia, aggiunge un blocco al nodo appena creato che rende il nodo non selezionabile per eseguire container finché il CCM non inizializza il nodo con le informazioni specifiche del cloud. Il CCM rimuove quindi questo blocco. Sistema a plug-in ----------------- Il cloud controller manager utilizza le interfacce di Go per consentire l'implementazione di implementazioni di qualsiasi cloud. In particolare, utilizza l'interfaccia CloudProvider definita [qui](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62) . L'implementazione dei quattro controller generici evidenziati sopra, alcune strutture, l'interfaccia cloudprovider condivisa rimarranno nel core di Kubernetes. Le implementazioni specifiche per i vari cloud saranno costruite al di fuori del core e implementeranno le interfacce definite nel core. Per ulteriori informazioni sullo sviluppo di plug-in, consultare [Developing Cloud Controller Manager](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/) . Autorizzazione -------------- Questa sezione dettaglia l'accesso richiesto dal CCM sui vari API objects per eseguire le sue operazioni. ### Node controller Il Node controller funziona solo con oggetti di tipo Node. Richiede l'accesso completo per ottenere, elencare, creare, aggiornare, applicare patch, guardare ed eliminare oggetti di tipo Node. v1/Node: * Get * List * Create * Update * Patch * Watch * Delete ### Route controller Il Route controller ascolta la creazione dell'oggetto Node e configura le rotte in modo appropriato. Richiede l'accesso in lettura agli oggetti di tipo Node. v1/Node: * Get ### Service controller Il Service controller resta in ascolto per eventi di creazione, aggiornamento ed eliminazione di oggetti di tipo Servizi, e configura gli endpoint per tali Servizi in modo appropriato. Per accedere ai Servizi, è necessario il permesso per list e watch. Per aggiornare i Servizi, sono necessari i permessi patch e update. Per impostare gli endpoint per i Servizi, richiede i permessi create, list, get, watch, e update. v1/Service: * List * Get * Watch * Patch * Update ### Others L'implementazione del core di CCM richiede l'accesso per creare eventi e, per garantire operazioni sicure, richiede l'accesso per creare ServiceAccounts. v1/Event: * Create * Patch * Update v1/ServiceAccount: * Create L'RBAC ClusterRole per il CCM ha il seguente aspetto: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cloud-controller-manager rules: - apiGroups: - "" resources: - events verbs: - create - patch - update - apiGroups: - "" resources: - nodes verbs: - '*' - apiGroups: - "" resources: - nodes/status verbs: - patch - apiGroups: - "" resources: - services verbs: - list - patch - update - watch - apiGroups: - "" resources: - serviceaccounts verbs: - create - apiGroups: - "" resources: - persistentvolumes verbs: - get - list - update - watch - apiGroups: - "" resources: - endpoints verbs: - create - get - list - watch - update Vendor Implementations ---------------------- I seguenti fornitori di cloud hanno una implementazione di CCM: * [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) * [AWS](https://github.com/kubernetes/cloud-provider-aws) * [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) * [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) * [GCP](https://github.com/kubernetes/cloud-provider-gcp) * [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) * [Linode](https://github.com/linode/linode-cloud-controller-manager) * [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) * [Oracle](https://github.com/oracle/oci-cloud-controller-manager) * [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) Cluster Administration ---------------------- Le istruzioni complete per la configurazione e l'esecuzione del CCM sono fornite [qui](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) . 3.2.3 - Controller ================== Nella robotica e nell'automazione, un _circuito di controllo_ (_control loop_) è un un'iterazione senza soluzione di continuità che regola lo stato di un sistema. Ecco un esempio di un circuito di controllo: il termostato di una stanza. Quando viene impostata la temperatura, si definisce attraverso il termostato lo _stato desiderato_. L'attuale temperatura nella stanza è invece lo _stato corrente_. Il termostato agisce per portare lo stato corrente il più vicino possibile allo stato desiderato accendendo e spegnendo le apparecchiature. In Kubernetes, i _controller_ sono circuiti di controllo che osservano lo stato del [cluster](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-cluster "Un'insieme di macchine, chiamate nodi, che eseguono container gestiti da Kubernetes. Un cluster ha almeno un Worker Node.") , e apportano o richiedono modifiche quando necessario. Ogni _controller_ prova a portare lo stato corrente del cluster verso lo stato desiderato. Il modello del controller ------------------------- Un _controller_ monitora almeno una tipo di risorsa registrata in Kubernetes. Questi [oggetti](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) hanno una proprietà chiamata _spec_ (specifica) che rappresenta lo stato desiderato. Il o i _controller_ per quella risorsa sono responsabili di mantenere lo stato corrente il più simile possibile rispetto allo stato desiderato. Il _controller_ potrebbe eseguire l'azione relativa alla risorsa in questione da sé; più comunemente, in Kubernetes, un _controller_ invia messaggi all'[API server](https://kubernetes.io/it/docs/concepts/architecture/#kube-apiserver "Componente della Control plane che serve le Kubernetes API.") che a sua volta li rende disponibili ad altri componenti nel cluster. Di seguito troverete esempi per questo scenario. ### Controllo attraverso l'API server Il [Job](https://kubernetes.io/it/docs/concepts/workloads/controllers/jobs-run-to-completion "Uno o più lavori (task) che vengono eseguiti fino al loro completamento.") _controller_ è un esempio di un _controller_ nativo in Kubernetes. I _controller_ nativi gestiscono lo stato interagendo con l'API server presente nel cluster. Il Job è una risorsa di Kubernetes che lancia uno o più [Pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") per eseguire un lavoro (task) e poi fermarsi. (Una volta che è stato [schedulato](https://kubernetes.io/docs/concepts/scheduling-eviction/) , un oggetto _Pod_ diventa parte dello stato desisderato di un dato _kubelet_). Quando il Job _controller_ vede un nuovo lavoro da svolgere si assicura che, da qualche parte nel cluster, i _kubelet_ anche sparsi su più nodi eseguano il numero corretto di _Pod_ necessari per eseguire il lavoro richiesto. Il Job _controller_ non esegue direttamente alcun _Pod_ o _container_ bensì chiede all'API server di creare o rimuovere i _Pod_. Altri componenti appartenenti al [control plane](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-control-plane "Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.") reagiscono in base alle nuove informazioni (ci sono nuovi _Pod_ da creare e gestire) e cooperano al completamento del job. Dopo che un nuovo Job è stato creato, lo stato desiderato per quel Job è il suo completamento. Il Job _controller_ fa sì che lo stato corrente per quel Job sia il più vicino possibile allo stato desiderato: creare _Pod_ che eseguano il lavoro che deve essere effettuato attraverso il Job, così che il Job sia prossimo al completamento. I _controller_ aggiornano anche gli oggetti che hanno configurato. Ad esempio: una volta che il lavoro relativo ad un dato Job è stato completato, il Job _controller_ aggiorna l'oggetto Job segnandolo come `Finished`. (Questo è simile allo scenario del termostato che spegne un certo led per indicare che ora la stanza ha raggiungo la temperatura impostata) ### Controllo diretto A differenza del Job, alcuni _controller_ devono eseguire delle modifiche a parti esterne al cluster. Per esempio, se viene usato un circuito di controllo per assicurare che ci sia un numero sufficiente di [Nodi](https://kubernetes.io/it/docs/concepts/architecture/nodes/ "Un node è una macchina worker in Kubernetes.") nel cluster, allora il _controller_ ha bisogno che qualcosa al di fuori del cluster configuri i nuovi _Nodi_ quando sarà necessario. I _controller_ che interagiscono con un sistema esterno trovano il loro stato desiderato attraverso l'API server, quindi comunicano direttamente con un sistema esterno per portare il loro stato corrente più in linea possibile con lo stato desiderato (In realtà c'è un _controller_ che scala orizzontalmente i nodi nel cluster. Vedi [Cluster autoscaling](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) ). Stato desiderato versus corrente -------------------------------- Kubernetes ha una visione _cloud-native_ dei sistemi, ed è in grado di gestire continue modifiche. Il cluster viene modificato continuamente durante la sua attività ed il _circuito di controllo_ è in grado di risolvere automaticamente i possibili guasti. Fino a che i _controller_ del cluster sono in funzione ed in grado di apportare le dovute modifiche, non è rilevante che lo stato complessivo del cluster sia o meno stabile. Progettazione ------------- Come cardine della sua progettazione, Kubernetes usa vari _controller_ ognuno dei quali è responsabile per un particolare aspetto dello stato del cluster. Più comunemente, un dato _circuito di controllo_ (_controller_) usa un tipo di risorsa per il suo stato desiderato, ed utilizza anche risorse di altro tipo per raggiungere questo stato desiderato. Per esempio il Job _controller_ tiene traccia degli oggetti di tipo _Job_ (per scoprire nuove attività da eseguire) e degli oggetti di tipo _Pod_ (questi ultimi usati per eseguire i _Job_, e quindi per controllare quando il loro lavoro è terminato). In questo caso, qualcos'altro crea i _Job_, mentre il _Job_ _controller_ crea i _Pod_. È utile avere semplici _controller_ piuttosto che un unico, monolitico, _circuito di controllo_. I _controller_ possono guastarsi, quindi Kubernetes è stato disegnato per gestire questa eventualità. #### Nota: Ci possono essere diversi _controller_ che creato o aggiornano lo stesso tipo di oggetti. Dietro le quinte, i _controller_ di Kubernetes si preoccupano esclusivamente delle risorse (di altro tipo) collegate alla risorsa primaria da essi controllata. Per esempio, si possono avere _Deployment_ e _Job_; entrambe creano _Pod_. Il Job _controller_ non distrugge i _Pod_ creati da un _Deployment_, perché ci sono informazioni (_[labels](https://kubernetes.io/it/docs/concepts/overview/working-with-objects/labels "Tags di oggetti con attributi identificativi che sono significativi e pertinenti per gli utenti.") _) che vengono usate dal _controller_ per distinguere i _Pod_. I modi per eseguire i _controller_ ---------------------------------- Kubernetes annovera un insieme di _controller_ nativi che sono in esecuzione all'interno del [kube-controller-manager](https://kubernetes.io/it/docs/reference/command-line-tools-reference/kube-controller-manager/ "Componente della Control Plane che gestisce i controller.") . Questi _controller_ nativi forniscono importanti funzionalità di base. Il Deployment _controller_ ed il Job _controller_ sono esempi di _controller_ che vengono forniti direttamente da Kubernetes stesso (ovvero _controller_ "nativi"). Kubernetes consente di eseguire un _piano di controllo_(_control plane_) resiliente, di modo che se un dei _controller_ nativi dovesse fallire, un'altra parte del piano di controllo si occuperà di eseguire quel lavoro. Al fine di estendere Kubernetes, si possono avere _controller_ in esecuzione al di fuori del piano di controllo. Oppure, se si desidera, è possibile scriversi un nuovo _controller_. È possibile eseguire il proprio controller come una serie di _Pod_, oppure esternamente rispetto a Kubernetes. Quale sia la soluzione migliore, dipende dalla responsabilità di un dato controller. Voci correlate -------------- * Leggi in merito [Kubernetes control plane](https://kubernetes.io/it/docs/concepts/#kubernetes-control-plane) * Scopri alcune delle basi degli [oggetti di Kubernetes](https://kubernetes.io/it/docs/concepts/#kubernetes-objects) * Per saperne di più riguardo alle [API di Kubernetes](https://kubernetes.io/it/docs/concepts/overview/kubernetes-api/) * Se vuoi creare un tuo _controller_, guarda [i modelli per l'estensibilità](https://kubernetes.io/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Estendere Kubernetes. 3.3 - Containers ================ La tecnologia per distribuire un'applicazione insieme con le dipendenze necessarie per la sua esecuzione. Ogni _container_ che viene eseguito è riproducibile; la pratica di includere le dipendenze all'interno di ciascuno _container_ permette di ottenere sempre lo stesso risultato ad ogni esecuzione del medesimo _container_. I _Container_ permettono di disaccoppiare le applicazioni dall'infrastruttura del host su cui vengono eseguite. Questo approccio rende più facile il _deployment_ su cloud o sitemi operativi differenti tra loro. Immagine di container --------------------- L'[immagine di un container](https://kubernetes.io/it/docs/concepts/containers/images/) e' un pacchetto software che contiene tutto ciò che serve per eseguire un'applicazione: il codice sorgente e ciascun _runtime_ necessario, librerie applicative e di sistema, e le impostazioni predefinite per ogni configurazione necessaria. Un _container_ è immutabile per definizione: non è possibile modificare il codice di un _container_ in esecuzione. Se si ha un'applicazione containerizzata e la si vuole modificare, si deve costruire un nuovo _container_ che includa il cambiamento desiderato, e quindi ricreare il _container_ partendo dalla nuova immagine aggiornata. Container runtimes ------------------ Il container runtime è il software che è responsabile per l'esecuzione dei container. Kubernetes supporta diversi container runtimes: [Docker](http://www.docker.com/) , [containerd](https://containerd.io/) , [cri-o](https://cri-o.io/) , [rktlet](https://github.com/kubernetes-incubator/rktlet) e tutte le implementazioni di [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Voci correlate -------------- * Leggi in merito [immagine di container](https://kubernetes.io/it/docs/concepts/containers/images/) * Leggi in merito [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) 3.3.1 - Immagini ================ L'immagine di un container rappresenta dati binari che incapsulano un'applicazione e tutte le sue dipendenze software. Le immagini sono costituite da pacchetti software eseguibili che possono essere avviati in modalità standalone e su cui si possono fare ipotesi ben precise circa l'ambiente in cui vengono eseguiti. Tipicamente viene creata un'immagine di un'applicazione ed effettuato il _push_ su un registry (un repository pubblico di immagini) prima di poterne fare riferimento esplicito in un [Pod](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") Questa pagina va a delineare nello specifico il concetto di immagine di un container. I nomi delle immagini --------------------- Alle immagini dei container vengono normalmente attribuiti nomi come `pause`, `example/mycontainer`, o `kube-apiserver`. Le immagini possono anche contenere l'hostname del registry in cui le immagini sono pubblicate; ad esempio: `registro.fittizio.esempio/nomeimmagine`, ed è possibile che sia incluso nel nome anche il numero della porta; ad esempio: `registro.fittizio.esempio:10443/nomeimmagine`. Se non si specifica l'hostname di un registry, Kubernetes assume che ci si riferisca al registry pubblico di Docker. Dopo la parte relativa al nome dell'immagine si può aggiungere un _tag_ (come comunemente avviene per comandi come `docker` e `podman`). I tag permettono l'identificazione di differenti versioni della stessa serie di immagini. I tag delle immagini sono composti da lettere minuscole e maiuscole, numeri, underscore (`_`), punti (`.`), e trattini (`-`). Esistono regole aggiuntive relative a dove i caratteri separatori (`_`, `-`, and `.`) possano essere inseriti nel tag di un'immagine. Se non si specifica un tag, Kubernetes assume il tag `latest` che va a definire l'immagine disponibile più recente. #### Attenzione: Evitate di utilizzare il tag `latest` quando si rilasciano dei container in produzione, in quanto risulta difficile tracciare quale versione dell'immagine sia stata avviata e persino più difficile effettuare un rollback ad una versione precente. Invece, meglio specificare un tag specifico come ad esempio `v1.42.0`. Aggiornamento delle immagini ---------------------------- Quando un [Deployment](https://kubernetes.io/it/docs/concepts/workloads/controllers/deployment/ "Gestisce una applicazione replicata nel tuo cluster.") , [StatefulSet](https://kubernetes.io/it/docs/concepts/workloads/controllers/statefulset/ "Gestisce deployment e la scalabilità di un gruppo di Pod, con storage e identificativi persistenti per ogni Pod.") , Pod, o qualsiasi altro oggetto che includa un Pod template viene creato per la prima volta, la policy di default per il pull di tutti i container nel Pod è impostata su `IfNotPresent` (se non presente) se non specificato diversamente. Questa policy permette al [kubelet](https://kubernetes.io/it/docs/reference/generated/kubelet "Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.") di evitare di fare il pull di un'immagine se questa è già presente. Se necessario, si può forzare il pull in ogni occasione in uno dei seguenti modi: * impostando `imagePullPolicy` (specifica per il pull delle immagini) del container su `Always` (sempre). * omettendo `imagePullPolicy` ed usando il tag `:latest` (più recente) per l'immagine da utilizzare; Kubernetes imposterà la policy su `Always` (sempre). * omettendo `imagePullPolicy` ed il tag per l'immagine da utilizzare. * abilitando l'admission controller [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) . #### Nota: Il valore dell'impostazione `imagePullPolicy` del container è sempre presente quando l'oggetto viene creato per la prima volta e non viene aggiornato se il tag dell'immagine dovesse cambiare successivamente. Ad esempio, creando un Deployment con un'immagine il cui tag _non_ è `:latest`, e successivamente aggiornando il tag di quell'immagine a `:latest`, il campo `imagePullPolicy` _non_ cambierà su `Always`. È necessario modificare manualmente la policy di pull di ogni oggetto dopo la sua creazione. Quando `imagePullPolicy` è definito senza un valore specifico, esso è impostato su `Always`. Multi-architecture support nelle immagini ----------------------------------------- Oltre a fornire immagini binarie, un _container registry_ può fornire un [indice delle immagini disponibili per un container](https://github.com/opencontainers/image-spec/blob/master/image-index.md) . L'indice di un'immagine può puntare a più [file manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md) ciascuno per una versione specifica dell'architettura di un container. L'idea è che si può avere un unico nome per una stessa immagine (ad esempio: `pause`, `example/mycontainer`, `kube-apiserver`) e permettere a diversi sistemi di recuperare l'immagine binaria corretta a seconda dell'architettura della macchina che la sta utilizzando. Kubernetes stesso tipicamente nomina le immagini dei container tramite il suffisso `-$(ARCH)`. Per la garantire la retrocompatibilità è meglio generare le vecchie immagini con dei suffissi. L'idea è quella di generare, ad esempio, l'immagine `pause` con un manifest che include tutte le architetture supportate, affiancata, ad esempio, da `pause-amd64` che è retrocompatibile per le vecchie configurazioni o per quei file YAML in cui sono specificate le immagini con i suffissi. Utilizzare un private registry ------------------------------ I private registry possono richiedere l'utilizzo di chiavi per accedere alle immagini in essi contenute. Le credenziali possono essere fornite in molti modi: * configurando i nodi in modo tale da autenticarsi al private registry * tutti i pod possono acquisire informazioni da qualsiasi private registry configurato * è necessario che l'amministratore del cluster configuri i nodi in tal senso * tramite pre-pulled images (immagini pre-caricate sui nodi) * tutti i pod possono accedere alle immagini salvate sulla cache del nodo a cui si riferiscono * è necessario effettuare l'accesso come root di sistema su ogni nodo per inserire questa impostazione * specificando _ImagePullSecrets_ su un determinato pod * solo i pod che forniscono le proprie chiavi hanno la possibilità di accedere al private registry * tramite estensioni locali o specifiche di un _Vendor_ * se si sta utilizzando una configurazione personalizzata del nodo oppure se manualmente, o tramite il _cloud provider_, si implementa un meccanismo di autenticazione del nodo presso il _container registry_. Di seguito la spiegazione dettagliata di queste opzioni. ### Configurazione dei nodi per l'autenticazione ad un private registry Se si sta utilizzando Docker sui nodi, si può configurare il _Docker container runtime_ per autenticare il nodo presso un private container registry. Questo è un approccio possibile se si ha il controllo sulle configurazioni del nodo. #### Nota: Kubernetes di default supporta solo le sezioni `auths` e `HttpHeaders` nelle configurazioni relative a Docker. Eventuali _helper_ per le credenziali di Docker (`credHelpers` o `credsStore`) non sono supportati. Docker salva le chiavi per i registri privati in `$HOME/.dockercfg` oppure nel file `$HOME/.docker/config.json`. Inserendo lo stesso file nella lista seguente, kubelet lo utilizzerà per recuperare le credenziali quando deve fare il _pull_ delle immagini. * `{--root-dir:-/var/lib/kubelet}/config.json` * `{cwd of kubelet}/config.json` * `${HOME}/.docker/config.json` * `/.docker/config.json` * `{--root-dir:-/var/lib/kubelet}/.dockercfg` * `{cwd of kubelet}/.dockercfg` * `${HOME}/.dockercfg` * `/.dockercfg` #### Nota: Potrebbe essere necessario impostare `HOME=/root` esplicitamente come variabile d'ambiente del processo _kubelet_. Di seguito i passi consigliati per configurare l'utilizzo di un private registry da parte dei nodi del _cluster_. In questo esempio, eseguire i seguenti comandi sul proprio desktop/laptop: 1. Esegui `docker login [server]` per ogni _set_ di credenziali che vuoi utilizzare. Questo comando aggiornerà `$HOME/.docker/config.json` sul tuo PC. 2. Controlla il file `$HOME/.docker/config.json` in un editor di testo per assicurarti che contenga le credenziali che tu voglia utilizzare. 3. Recupera la lista dei tuoi nodi; ad esempio: * se vuoi utilizzare i nomi: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` * se vuoi recuperare gli indirizzi IP: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 4. Copia il tuo file locale `.docker/config.json` in uno dei path sopra riportati nella lista di ricerca. * ad esempio, per testare il tutto: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` #### Nota: Per i cluster di produzione, utilizza un configuration management tool per poter applicare le impostazioni su tutti i nodi laddove necessario. Puoi fare una verifica creando un Pod che faccia uso di un'immagine privata; ad esempio: kubectl apply -f - < --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL Se possiedi il file delle credenziali per Docker, anziché utilizzare il comando quì sopra puoi importare il file di credenziali come un Kubernetes [Secrets](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-secret "Contiene informazioni sensibili, come passwords, token OAuth, e chiavi ssh.") . [Creare un Secret a partire da credenziali Docker](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) fornisce la spiegazione dettagliata su come fare. Ciò è particolarmente utile se si utilizzano più _container registry_ privati, in quanto il comando `kubectl create secret docker-registry` genera un Secret che funziona con un solo private registry. #### Nota: I Pod possono fare riferimento ai Secret per il pull delle immagini soltanto nel proprio _namespace_, quindi questo procedimento deve essere svolto per ogni _namespace_. #### Fare riferimento ad imagePullSecrets in un Pod È possibile creare pod che referenzino quel Secret aggiungendo la sezione `imagePullSecrets` alla definizione del Pod. Ad esempio: cat < pod.yaml apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey EOF cat <> ./kustomization.yaml resources: - pod.yaml EOF Questo deve esser fatto per ogni Pod che utilizzi un private registry. Comunque, le impostazioni relative a questo campo possono essere automatizzate inserendo la sezione _imagePullSecrets_ nella definizione della risorsa [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) . Visitare la pagina [Aggiungere ImagePullSecrets ad un Service Account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) per istruzioni più dettagliate. Puoi utilizzarlo in congiunzione al file `.docker/config.json` configurato per ogni nodo. In questo caso, si applicherà un _merge_ delle credenziali. Casi d'uso ---------- Ci sono varie soluzioni per configurare i private registry. Di seguito, alcuni casi d'uso comuni e le soluzioni suggerite. 1. Cluster in cui sono utilizzate soltanto immagini non proprietarie (ovvero _open-source_). In questo caso non sussiste il bisogno di nascondere le immagini. * Utilizza immagini pubbliche da Docker hub. * Nessuna configurazione richiesta. * Alcuni _cloud provider_ mettono in _cache_ o effettuano il _mirror_ di immagini pubbliche, il che migliora la disponibilità delle immagini e ne riduce il tempo di _pull_. 2. Cluster con container avviati a partire da immagini proprietarie che dovrebbero essere nascoste a chi è esterno all'organizzazione, ma visibili a tutti gli utenti abilitati nel cluster. * Utilizza un private [Docker registry](https://docs.docker.com/registry/) . * Esso può essere ospitato da [Docker Hub](https://hub.docker.com/signup) , o da qualche altra piattaforma. * Configura manualmente il file .docker/config.json su ogni nodo come descritto sopra. * Oppure, avvia un private registry dietro il tuo firewall con accesso in lettura libero. * Non è necessaria alcuna configurazione di Kubernetes. * Utilizza un servizio di _container registry_ che controlli l'accesso alle immagini * Esso funzionerà meglio con una configurazione del cluster basata su _autoscaling_ che con una configurazione manuale del nodo. * Oppure, su un cluster dove la modifica delle configurazioni del nodo non è conveniente, utilizza `imagePullSecrets`. 3. Cluster con immagini proprietarie, alcune delle quali richiedono un controllo sugli accessi. * Assicurati che l'_admission controller_ [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod potenzialmente possono avere accesso a tutte le immagini. * Sposta i dati sensibili un un _Secret_, invece di inserirli in un'immagine. 4. Un cluster multi-tenant dove ogni tenant necessiti di un private registry. * Assicurati che l'_admission controller_ [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod di tutti i tenant potrebbero potenzialmente avere accesso a tutte le immagini. * Avvia un private registry che richieda un'autorizzazione all'accesso. * Genera delle credenziali di registry per ogni tenant, inseriscile in dei _Secret_, e popola i _Secret_ per ogni _namespace_ relativo ad ognuno dei tenant. * Il singolo tenant aggiunge così quel _Secret_ all'impostazione _imagePullSecrets_ di ogni _namespace_. Se si ha la necessità di accedere a più registri, si può generare un _Secret_ per ognuno di essi. Kubelet farà il _merge_ di ogni `imagePullSecrets` in un singolo file virtuale `.docker/config.json`. Voci correlate -------------- * Leggi [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 3.3.2 - Container Environment ============================= Questa pagina descrive le risorse disponibili nei Container eseguiti in Kubernetes. Container environment --------------------- Quando si esegue un Container in Kubernetes, le seguenti risorse sono rese disponibili: * Un filesystem, composto dal file system dell'[image](https://kubernetes.io/it/docs/concepts/containers/images/) e da uno o più [volumes](https://kubernetes.io/docs/concepts/storage/volumes/) . * Una serie di informazioni sul Container stesso. * Una serie di informazioni sugli oggetti nel cluster. ### Informazioni sul Container L' _hostname_ di un Container è il nome del Pod all'interno del quale è eseguito il Container. È consultabile tramite il comando `hostname` o tramite la funzione [`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) disponibile in libc. Il nome del Pod e il namespace possono essere resi disponibili come environment variables attraverso l'uso delle [downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) . Gli utenti possono aggiungere altre environment variables nella definizione del Pod; anche queste saranno disponibili nel Container come tutte le altre environment variables definite staticamente nella Docker image. ### Informazioni sul cluster Al momento della creazione del Container è generata una serie di environment variables con la lista di servizi in esecuzione nel cluster. Queste environment variables rispettano la sintassi dei Docker links. Per un servizio chiamato _foo_ che è in esecuzione in un Container di nome _bar_, le seguenti variabili sono generate: FOO_SERVICE_HOST= FOO_SERVICE_PORT= I servizi hanno un indirizzo IP dedicato e sono disponibili nei Container anche via DNS se il [DNS addon](http://releases.k8s.io/master/cluster/addons/dns/) è installato nel cluster. Voci correlate -------------- * Approfondisci [Container lifecycle hooks](https://kubernetes.io/it/docs/concepts/containers/container-lifecycle-hooks/) . * Esegui un tutorial su come [definire degli handlers per i Container lifecycle events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . 3.3.3 - Container Lifecycle Hooks ================================= Questa pagina descrive come i Container gestiti con kubelet possono utilizzare il lifecycle hook framework dei Container per l'esecuzione di codice eseguito in corrispondenza di alcuni eventi durante il loro ciclo di vita. Overview -------- Analogamente a molti framework di linguaggi di programmazione che hanno degli hooks legati al ciclo di vita dei componenti, come ad esempio Angular, Kubernetes fornisce ai Container degli hook legati al loro ciclo di vita dei Container. Gli hook consentono ai Container di essere consapevoli degli eventi durante il loro ciclo di gestione ed eseguire del codice implementato in un handler quando il corrispondente hook viene eseguito. Container hooks --------------- Esistono due tipi di hook che vengono esposti ai Container: `PostStart` Questo hook viene eseguito successivamente alla creazione del container. Tuttavia, non vi è garanzia che questo hook venga eseguito prima dell'ENTRYPOINT del container. Non vengono passati parametri all'handler. `PreStop` Questo hook viene eseguito prima della terminazione di un container a causa di una richiesta API o di un evento di gestione, come ad esempio un fallimento delle sonde di liveness/startup, preemption, risorse contese e altro. Una chiamata all'hook di `PreStop` fallisce se il container è in stato terminated o completed e l'hook deve finire prima che possa essere inviato il segnale di TERM per fermare il container. Il conto alla rovescia per la terminazione del Pod (grace period) inizia prima dell'esecuzione dell'hook `PreStop`, quindi indipendentemente dall'esito dell'handler, il container terminerà entro il grace period impostato. Non vengono passati parametri all'handler. Una descrizione più dettagliata riguardante al processo di terminazione dei Pod può essere trovata in [Terminazione dei Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) . ### Implementazione degli hook handler I Container possono accedere a un hook implementando e registrando un handler per tale hook. Ci sono due tipi di handler che possono essere implementati per i Container: * Exec - Esegue un comando specifico, tipo `pre-stop.sh`, all'interno dei cgroup e namespace del Container. Le risorse consumate dal comando vengono contate sul Container. * HTTP - Esegue una richiesta HTTP verso un endpoint specifico del Container. ### Esecuzione dell'hook handler Quando viene richiamato l'hook legato al lifecycle del Container, il sistema di gestione di Kubernetes esegue l'handler secondo l'azione dell'hook, `httpGet` e `tcpSocket` vengono eseguiti dal processo kubelet, mentre `exec` è eseguito nel Container. Le chiamate agli handler degli hook sono sincrone rispetto al contesto del Pod che contiene il Container. Questo significa che per un hook `PostStart`, l'ENTRYPOINT e l'hook si attivano in modo asincrono. Tuttavia, se l'hook impiega troppo tempo per essere eseguito o si blocca, il container non può raggiungere lo stato di `running`. Gli hook di `PreStop` non vengono eseguiti in modo asincrono dall'evento di stop del container; l'hook deve completare la sua esecuzione prima che l'evento TERM possa essere inviato. Se un hook di `PreStop` si blocca durante la sua esecuzione, la fase del Pod rimarrà `Terminating` finchè il Pod non sarà rimosso forzatamente dopo la scadenza del suo `terminationGracePeriodSeconds`. Questo grace period si applica al tempo totale necessario per effettuare sia l'esecuzione dell'hook di `PreStop` che per l'arresto normale del container. Se, per esempio, il `terminationGracePeriodSeconds` è di 60, e l'hook impiega 55 secondi per essere completato, e il container impiega 10 secondi per fermarsi normalmente dopo aver ricevuto il segnale, allora il container verrà terminato prima di poter completare il suo arresto, poiché `terminationGracePeriodSeconds` è inferiore al tempo totale (55+10) necessario perché queste due cose accadano. Se un hook `PostStart` o `PreStop` fallisce, allora il container viene terminato. Gli utenti dovrebbero mantenere i loro handler degli hook i più leggeri possibili. Ci sono casi, tuttavia, in cui i comandi di lunga durata hanno senso, come il salvataggio dello stato del container prima della sua fine. ### Garanzia della chiamata dell'hook La chiamata degli hook avviene _almeno una volta_, il che significa che un hook può essere chiamato più volte da un dato evento, come per `PostStart` o `PreStop`. Sta all'implementazione dell'hook gestire correttamente questo aspetto. Generalmente, vengono effettuate singole chiamate agli hook. Se, per esempio, la destinazione di hook HTTP non è momentaneamente in grado di ricevere traffico, non c'è alcun tentativo di re invio. In alcuni rari casi, tuttavia, può verificarsi una doppia chiamata. Per esempio, se un kubelet si riavvia nel mentre dell'invio di un hook, questo potrebbe essere chiamato per una seconda volta dopo che il kubelet è tornato in funzione. ### Debugging Hook handlers I log di un handler di hook non sono esposti negli eventi del Pod. Se un handler fallisce per qualche ragione, trasmette un evento. Per il `PostStart`, questo è l'evento di `FailedPostStartHook`, e per il `PreStop`, questo è l'evento di `FailedPreStopHook`. Puoi vedere questi eventi eseguendo `kubectl describe pod `. Ecco alcuni esempi di output di eventi dall'esecuzione di questo comando: Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook Voci correlate -------------- * Approfondisci [Container environment](https://kubernetes.io/it/docs/concepts/containers/container-environment/) . * Esegui un tutorial su come [definire degli handlers per i Container lifecycle events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . 3.4 - Configurazione ==================== Risorse che fornisce Kubernetes per configurare i Pods. 3.4.1 - ConfigMaps ================== La ConfigMap è un oggetto API usato per memorizzare dati non riservati in coppie chiave-valore. I [Pods](https://kubernetes.io/it/docs/concepts/workloads/pods/pod-overview/ "Un Pod rappresenta un gruppo di container nel tuo cluster.") possono utilizzare le ConfigMaps come variabili d'ambiente, argomenti da riga di comando, o come files di configurazione all'interno di un [Volume](https://kubernetes.io/it/docs/concepts/storage/volumes/ "Una cartella contenente dati, accessibile dai containers all'interno del pod.") . La ConfigMap ti permette di disaccoppiare le configurazioni specifiche per ambiente dalle [immagini del container](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-image "Istanza archiviata di un cointainer che contiene un insieme di software e librerie necessarie per eseguire l'applicazione.") , cosicchè le tue applicazioni siano facilmente portabili. #### Attenzione: La ConfigMap non fornisce riservatezza o cifratura dei dati. Se i dati che vuoi salvare sono confidenziali, usa un [Secret](https://kubernetes.io/it/docs/reference/glossary/?all=true#term-secret "Contiene informazioni sensibili, come passwords, token OAuth, e chiavi ssh.") piuttosto che una ConfigMap, o usa uno strumento di terze parti per tenere privati i tuoi dati. Utilizzo -------- Usa una ConfigMap per tenere separati i dati di configurazione dal codice applicativo. Per esempio, immagina che stai sviluppando un'applicazione che puoi eseguire sul tuo computer (per lo sviluppo) e sul cloud (per gestire il traffico reale). Puoi scrivere il codice puntando a una variabile d'ambiente chiamata `DATABASE_HOST`. Localmente, puoi settare quella variabile a `localhost`. Nel cloud, la puoi settare referenziando il [Service](https://kubernetes.io/it/docs/concepts/services-networking/service/ "A way to expose an application running on a set of Pods as a network service.") di Kubernetes che espone la componente del database sul tuo cluster. Ciò ti permette di andare a recuperare l'immagine del container eseguita nel cloud e fare il debug dello stesso codice localmente se necessario. La ConfigMap non è pensata per sostenere una gran mole di dati. I dati memorizzati su una ConfigMap non possono superare 1 MiB. Se hai bisogno di memorizzare delle configurazioni che superano questo limite, puoi considerare di montare un volume oppure usare un database o un file service separato. Oggetto ConfigMap ----------------- La ConfigMap è un [oggetto](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/) API che ti permette di salvare configurazioni per poi poter essere riutilizzate da altri oggetti. A differenza di molti oggetti di Kubernetes che hanno una `spec`, la ConfigMap ha i campi `data` e `binaryData`. Questi campi accettano le coppie chiave-valore come valori. Entrambi i campi `data` e `binaryData` sono opzionali. Il campo `data` è pensato per contenere le stringhe UTF-8 mentre il campo `binaryData` è pensato per contenere dati binari come le stringhe codificate in base64. Il nome di una ConfigMap deve essere un nome valido per un sottodominio DNS. Ogni chiave sotto il campo `data` o `binaryData` deve consistere di caratteri alfanumerici, `-`, `_` o `.`. Le chiavi salvate sotto `data` non devono coincidere con le chiavi nel campo `binaryData`. Partendo dalla versione 1.19, puoi aggiungere il campo `immutable` alla definizione di ConfigMap per creare una [ConfigMap immutabile](https://kubernetes.io/it/docs/_print/#configmap-immutable) . ConfigMaps e Pods ----------------- Puoi scrivere una `spec` del Pod che si riferisce a una ConfigMap e configurare il o i containers in quel Pod sulla base dei dati presenti nella ConfigMap. Il Pod e la ConfigMap devono essere nello stesso Namespace. #### Nota: La `spec` di un [Pod statico](https://kubernetes.io/it/docs/tasks/configure-pod-container/static-pod/ "A pod managed directly by the kubelet daemon on a specific node.") non può riferirsi a una ConfigMap o ad altri oggetti API. Questo è un esempio di una ConfigMap che ha alcune chiavi con valori semplici, e altre chiavi dove il valore ha il formato di un frammento di configurazione. apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: # chiavi simili a proprietà; ogni chiave mappa un valore semplice player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # chiavi simili a files game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true Ci sono quattro modi differenti con cui puoi usare una ConfigMap per configurare un container all'interno di un Pod: 1. Argomento da riga di comando come entrypoint di un container 2. Variabile d'ambiente di un container 3. Aggiungere un file in un volume di sola lettura, per fare in modo che l'applicazione lo legga 4. Scrivere il codice da eseguire all'interno del Pod che utilizza l'API di Kubernetes per leggere la ConfigMap Questi metodologie differenti permettono di utilizzare diversi metodi per modellare i dati che saranno consumati. Per i primi tre metodi, il [kubelet](https://kubernetes.io/it/docs/reference/generated/kubelet "Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.") utilizza i dati della ConfigMap quando lancia il container (o più) in un Pod. Per il quarto metodo dovrai scrivere il codice per leggere la ConfigMap e i suoi dati. Comunque, poiché stai utilizzando l'API di Kubernetes direttamente, la tua applicazione può sottoscriversi per ottenere aggiornamenti ogniqualvolta la ConfigMap cambia, e reagire quando ciò accade. Accedendo direttamente all'API di Kubernetes, questa tecnica ti permette anche di accedere a una ConfigMap in namespace differenti. Ecco un esempio di Pod che usa i valori da `game-demo` per configurare il container: apiVersion: v1 kind: Pod metadata: name: configmap-demo-pod spec: containers: - name: demo image: alpine command: ["sleep", "3600"] env: # Definire la variabile d'ambiente - name: PLAYER_INITIAL_LIVES # Notare che il case qui è differente # dal nome della key nella ConfigMap. valueFrom: configMapKeyRef: name: game-demo # La ConfigMap da cui proviene il valore. key: player_initial_lives # La chiave da recuperare. - name: UI_PROPERTIES_FILE_NAME valueFrom: configMapKeyRef: name: game-demo key: ui_properties_file_name volumeMounts: - name: config mountPath: "/config" readOnly: true volumes: # Settare i volumi al livello del Pod, in seguito montarli nei containers all'interno del Pod - name: config configMap: # Fornire il nome della ConfigMap che vuoi montare. name: game-demo # Una lista di chiavi dalla ConfigMap per essere creata come file items: - key: "game.properties" path: "game.properties" - key: "user-interface.properties" path: "user-interface.properties" Una ConfigMap non differenzia tra le proprietà di una singola linea e un file con più linee e valori. L'importante è il modo in cui i Pods e gli altri oggetti consumano questi valori. Per questo esempio, definire un volume e montarlo all'interno del container `demo` come `/config` crea due files, `/config/game.properties` e `/config/user-interface.properties`, sebbene ci siano quattro chiavi nella ConfigMap. Ciò avviene perché la definizione del Pod specifica una lista di `items` nella sezione dei `volumes`. Se ometti del tutto la lista degli `items`, ogni chiave nella ConfigMap diventerà un file con lo stesso nome della chiave, e otterrai 4 files. Usare le ConfigMaps ------------------- Le ConfigMaps possono essere montate come volumi. Le ConfigMaps possono anche essere utilizzate da altre parti del sistema, senza essere direttamente esposte al Pod. Per esempio, le ConfigMaps possono contenere l'informazione che altre parti del sistema utilizzeranno per la loro configurazione. La maniera più comune per usare le ConfigMaps è di configurare i containers che sono in esecuzione in un Pod nello stesso namespace. Puoi anche utilizzare una ConfigMap separatamente. Per esempio, potresti incontrare [addons](https://kubernetes.io/it/docs/concepts/cluster-administration/addons/ "Resources that extend the functionality of Kubernetes.") o [operators](https://kubernetes.io/it/docs/concepts/extend-kubernetes/operator/ "A specialized controller used to manage a custom resource") che adattano il loro comportamento in base a una ConfigMap. ### Usare le ConfigMaps come files in un Pod Per utilizzare una ConfigMap in un volume all'interno di un Pod: 1. Creare una ConfigMap o usarne una che già esiste. Più Pods possono utilizzare la stessa ConfigMap. 2. Modificare la definizione del Pod per aggiungere un volume sotto `.spec.volumes[]`. Nominare il volume in qualsiasi modo, e avere un campo `.spec.volumes[].configMap.name` configurato per referenziare il tuo oggetto ConfigMap. 3. Aggiungere un `.spec.containers[].volumeMounts[]` a ogni container che necessiti di una ConfigMap. Nello specifico `.spec.containers[].volumeMounts[].readOnly = true` e `.spec.containers[].volumeMounts[].mountPath` in una cartella inutilizzata dove vorresti che apparisse la ConfigMap. 4. Modificare l'immagine o il comando utilizzato così che il programma cerchi i files in quella cartella. Ogni chiave nella sezione `data` della ConfigMap si converte in un file sotto `mountPath`. Questo è un esempio di un Pod che monta una ConfigMap in un volume: apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true volumes: - name: foo configMap: name: myconfigmap Ogni ConfigMap che desideri utilizzare deve essere referenziata in `.spec.volumes`. Se c'è più di un container nel Pod, allora ogni container necessita del suo blocco `volumeMounts`, ma solamente un `.spec.volumes` è necessario ConfigMap. #### Le ConfigMaps montate sono aggiornate automaticamente Quando una ConfigMap è utilizzata in un volume ed è aggiornata, anche le chiavi vengono aggiornate. Il kubelet controlla se la ConfigMap montata è aggiornata ad ogni periodo di sincronizzazione. Ad ogni modo, il kubelet usa la sua cache locale per ottenere il valore attuale della ConfigMap. Il tipo di cache è configurabile usando il campo `ConfigMapAndSecretChangeDetectionStrategy` nel [KubeletConfiguration struct](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/) . Una ConfigMap può essere propagata per vista (default), ttl-based, o redirigendo tutte le richieste direttamente all'API server. Come risultato, il ritardo totale dal momento in cui la ConfigMap è aggiornata al momento in cui nuove chiavi sono propagate al Pod può essere tanto lungo quanto il periodo della sincronizzazione del kubelet + il ritardo della propagazione della cache, dove il ritardo della propagazione della cache dipende dal tipo di cache scelta (è uguale rispettivamente al ritardo della propagazione, ttl della cache, o zero). Le ConfigMaps consumate come variabili d'ambiente non sono aggiornate automaticamente e necessitano di un riavvio del pod. #### Nota: Un container utilizzando una ConfigMap come un [subPath](https://kubernetes.io/docs/concepts/storage/volumes#using-subpath) volume mount non riceverà gli aggiornamenti della ConfigMap. ConfigMaps Immutabili --------------------- FEATURE STATE: `Kubernetes v1.21 [stable]` La funzionalità di Kubernetes _Immutable Secrets and ConfigMaps_ fornisce un'opzione per configurare Secrets individuali e ConfigMaps come immutabili. Per clusters che usano le ConfigMaps come estensione (almeno decine o centinaia di ConfigMap uniche montate nel Pod), prevenire i cambiamenti nei loro dati ha i seguenti vantaggi: * protezione da aggiornamenti accidentali (o non voluti) che potrebbero causare l'interruzione di applicazioni * miglioramento della performance del tuo cluster riducendo significativamente il carico sul kube-apiserver, chiudendo l'ascolto sulle ConfigMaps che sono segnate come immutabili. Questa funzionalità è controllata dal `ImmutableEphemeralVolumes` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) . Puoi creare una ConfigMap immutabile settando il campo `immutable` a `true`. Per esempio: apiVersion: v1 kind: ConfigMap metadata: ... data: ... immutable: true Una volta che una ConfigMap è segnata come immutabile, _non_ è possibile invertire questo cambiamento né cambiare il contenuto del campo `data` o `binaryData` field. Puoi solamente cancellare e ricreare la ConfigMap. Poiché i Pods hanno un puntamento verso la ConfigMap eliminata, è raccomandato di ricreare quei Pods. Voci correlate -------------- * Leggi in merito [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) . * Leggi [Configura un Pod per utilizzare una ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) . * Leggi in merito [Modificare una ConfigMap (o qualsiasi altro oggetto di Kubernetes)](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) * Leggi [The Twelve-Factor App](https://12factor.net/) per comprendere il motivo di separare il codice dalla configurazione. 3.5 - Amministrazione del Cluster ================================= 3.5.1 - Proxy in Kubernetes =========================== Questa pagina spiega i proxy utilizzati con Kubernetes. Proxy ----- Esistono diversi proxy che puoi incontrare quando usi Kubernetes: 1. Il [kubectl proxy](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#direct-accessing-the-rest-api) :     - viene eseguito sul computer di un utente o in un pod     - collega un localhost address all'apiserver di Kubernetes     - il client comunica con il proxy in HTTP     - il proxy comunica con l'apiserver in HTTPS     - individua l'apiserver     - aggiunge gli header di autenticazione 1. L'[apiserver proxy](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services) :     - è un proxy presente nell'apiserver     - collega un utente al di fuori del cluster agli IP del cluster che altrimenti potrebbero non essere raggiungibili     - è uno dei processi dell'apiserver     - il client comunica con il proxy in HTTPS (o HTTP se l'apiserver è configurato in tal modo)     - il proxy comunica con il target via HTTP o HTTPS come scelto dal proxy utilizzando le informazioni disponibili     - può essere utilizzato per raggiungere un nodo, un pod o un servizio     - esegue il bilanciamento del carico quando viene utilizzato per raggiungere un servizio 1. Il [kube proxy](https://kubernetes.io/docs/concepts/services-networking/service/#ips-and-vips) :     - è eseguito su ciascun nodo     - fa da proxy per comunicazioni UDP, TCP e SCTP     - non gestisce il protocollo HTTP     - esegue il bilanciamento del carico     - è usato solo per raggiungere i servizi 1. Un proxy/bilanciatore di carico di fronte agli apiserver:     - la sua esistenza e implementazione variano da cluster a cluster (ad esempio nginx)     - si trova tra i client e uno o più apiserver     - funge da bilanciatore di carico se ci sono più di un apiserver. 1. Cloud Load Balancer su servizi esterni:     - sono forniti da alcuni fornitori di servizi cloud (ad es. AWS ELB, Google Cloud Load Balancer)     - vengono creati automaticamente quando il servizio Kubernetes ha tipo `LoadBalancer`     - solitamente supporta solo UDP / TCP     - il supporto SCTP dipende dall'implementazione del bilanciatore di carico del provider cloud     - l'implementazione varia a seconda del provider cloud. Gli utenti di Kubernetes in genere non devono preoccuparsi alcun proxy, se non i primi due tipi. L'amministratore del cluster in genere assicurerà che gli altri tipi di proxy siano impostati correttamente. Richiedere reindirizzamenti --------------------------- I proxy hanno sostituito le funzioni di reindirizzamento. I reindirizzamenti sono stati deprecati. 3.6 - Esempio di modello di concetto ==================================== #### Nota: Assicurati anche di [creare una voce nel sommario](https://kubernetes.io/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) per il tuo nuovo documento. Questa pagina spiega ... Comprendendo ... ---------------- Kubernetes fornisce ... Usando ... ---------- Usare Voci correlate -------------- **\[Sezione opzionale\]** * Ulteriori informazioni su [Scrivere un nuovo argomento](https://kubernetes.io/docs/home/contribuisci/scrivi-nuovo-argomento/) . * Vedi [Uso dei modelli di pagina - Modello di concetto](https://kubernetes.io/docs/home/contribuis/page-templates/#concept_template) su come utilizzare questo modello. 4 - Tutorials ============= Questa sezione della documentazione di Kubernetes contiene i tutorials. Un tutorial mostra come raggiungere un obiettivo più complesso di un singolo [task](https://kubernetes.io/docs/tasks/) . Solitamente un tutorial ha diverse sezioni, ognuna delle quali consiste in una sequenza di più task. Prima di procedere con vari tutorial, raccomandiamo di aggiungere il [Glossario](https://kubernetes.io/it/docs/reference/glossary/) ai tuoi bookmark per riferimenti successivi. Per cominciare -------------- * [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) è un approfondito tutorial che aiuta a capire cosa è Kubernetes e che permette di testare in modo interattivo alcune semplici funzionalità di Kubernetes. * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) * [Hello Minikube](https://kubernetes.io/it/docs/tutorials/hello-minikube/) Configurazione -------------- * [Configurare Redis utilizzando una ConfigMap](https://kubernetes.io/docs/tutorials/configuration/configure-redis-using-configmap/) Stateless Applications ---------------------- * [Esporre un External IP Address per permettere l'accesso alle applicazioni nel Cluster](https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address/) * [Esempio: Rilasciare l'applicazione PHP Guestbook con Redis](https://kubernetes.io/docs/tutorials/stateless-application/guestbook/) Stateful Applications --------------------- * [StatefulSet Basics](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/) * [Esempio: WordPress e MySQL con i PersistentVolumes](https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) * [Esempio: Rilasciare Cassandra con i StatefulSets](https://kubernetes.io/docs/tutorials/stateful-application/cassandra/) * [Eseguire ZooKeeper, un sistema distribuito CP](https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/) Clusters -------- * [AppArmor](https://kubernetes.io/docs/tutorials/clusters/apparmor/) * [Seccomp](https://kubernetes.io/docs/tutorials/clusters/seccomp/) Servizi ------- * [Utilizzare Source IP](https://kubernetes.io/docs/tutorials/services/source-ip/) Voci correlate -------------- Se sei interessato a scrivere un tutorial, vedi [Utilizzare i Page Templates](https://kubernetes.io/docs/home/contribute/page-templates/) per informazioni su come creare una tutorial page e sul tutorial template. 4.1 - Hello Minikube ==================== Questo tutorial mostra come eseguire una semplice applicazione in Kubernetes utilizzando [Minikube](https://kubernetes.io/docs/setup/learning-environment/minikube) e Katacoda. Katacoda permette di operare su un'installazione di Kubernetes dal tuo browser. #### Nota: Come alternativa, è possibile eseguire questo tutorial [installando minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) localmente. Obbiettivi ---------- * Rilasciare una semplice applicazione su Minikube. * Eseguire l'applicazione. * Visualizzare i log dell'applicazione. Prima di cominciare ------------------- Questo tutorial fornisce una container image che utilizza NGINX per risponde a tutte le richieste con un echo che visualizza i dati della richiesta stessa. Crea un Minikube cluster ------------------------ 1. Click **Launch Terminal** #### Nota: Se hai installato Minikube localmente, esegui `minikube start`. 2. Apri la console di Kubernetes nel browser: minikube dashboard 3. Katacoda environment only: In alto alla finestra del terminale, fai click segno più, e a seguire click su **Select port to view on Host 1**. 4. Katacoda environment only: Inserisci `30000`, a seguire click su **Display Port**. Crea un Deployment ------------------ Un Kubernetes [_Pod_](https://kubernetes.io/docs/concepts/workloads/pods/pod/) è un gruppo di uno o più Containers, che sono uniti tra loro dal punto di vista amministrativo e che condividono lo stesso network. Il Pod in questo tutorial ha un solo Container. Un Kubernetes [_Deployment_](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) monitora lo stato del Pod ed eventualmente provvedere a farlo ripartire nel caso questo termini. L'uso dei Deployments è la modalità raccomandata per gestire la creazione e lo scaling dei Pods. 1. Usa il comando `kubectl create` per creare un Deployment che gestisce un singolo Pod. Il Pod eseguirà un Container basato sulla Docker image specificata. kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080 2. Visualizza il Deployment: kubectl get deployments L'output del comando è simile a: NAME READY UP-TO-DATE AVAILABLE AGE hello-node 1/1 1 1 1m 3. Visualizza il Pod creato dal Deployment: kubectl get pods L'output del comando è simile a: NAME READY STATUS RESTARTS AGE hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m 4. Visualizza gli eventi del cluster Kubernetes: kubectl get events 5. Visualizza la configurazione di `kubectl`: kubectl config view #### Nota: Per maggiori informazioni sui comandi di `kubectl`, vedi [kubectl overview](https://kubernetes.io/docs/user-guide/kubectl-overview/) . Crea un Service --------------- Con le impostazioni di default, un Pod è accessibile solamente dagli indirizzi IP interni al Kubernetes cluster. Per far si che il Container `hello-node` sia accessibile dall'esterno del Kubernetes virtual network, è necessario esporre il Pod utilizzando un Kubernetes [_Service_](https://kubernetes.io/docs/concepts/services-networking/service/) . 1. Esponi il Pod su internet untilizzando il comando `kubectl expose`: kubectl expose deployment hello-node --type=LoadBalancer --port=8080 Il flag `--type=LoadBalancer` indica la volontà di esporre il Service all'esterno del Kubernetes cluster. 2. Visualizza il Servizio appena creato: kubectl get services L'output del comando è simile a: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s kubernetes ClusterIP 10.96.0.1 443/TCP 23m Nei cloud providers che supportano i servizi di tipo load balancers, viene fornito un indirizzo IP pubblico per permettere l'acesso al Service. Su Minikube, il service type `LoadBalancer` rende il Service accessibile attraverso il comando `minikube service`. 3. Esegui il comando: minikube service hello-node 4. Katacoda environment only: Fai click segno più, e a seguire click su **Select port to view on Host 1**. 5. Katacoda environment only: Fai attenzione al numero di 5 cifre visualizzato a fianco di `8080` nell'output del comando. Questo port number è generato casualmente e può essere diverso nel tuo caso. Inserisci il tuo port number nella textbox, e a seguire fai click su Display Port. Nell'esempio precedente, avresti scritto `30369`. Questo apre un finestra nel browser dove l'applicazione visuallizza l'echo delle richieste ricevute. Attiva gli addons ----------------- Minikube include un set [addons](https://kubernetes.io/it/docs/concepts/cluster-administration/addons/ "Resources that extend the functionality of Kubernetes.") che possono essere attivati, disattivati o eseguti nel ambiente Kubernetes locale. 1. Elenca gli addons disponibili: minikube addons list L'output del comando è simile a: addon-manager: enabled dashboard: enabled default-storageclass: enabled efk: disabled freshpod: disabled gvisor: disabled helm-tiller: disabled ingress: disabled ingress-dns: disabled logviewer: disabled metrics-server: disabled nvidia-driver-installer: disabled nvidia-gpu-device-plugin: disabled registry: disabled registry-creds: disabled storage-provisioner: enabled storage-provisioner-gluster: disabled 2. Attiva un addon, per esempio, `metrics-server`: minikube addons enable metrics-server L'output del comando è simile a: metrics-server was successfully enabled 3. Visualizza i Pods ed i Service creati in precedenza: kubectl get pod,svc -n kube-system L'output del comando è simile a: NAME READY STATUS RESTARTS AGE pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m pod/metrics-server-67fb648c5 1/1 Running 0 26s pod/etcd-minikube 1/1 Running 0 34m pod/influxdb-grafana-b29w8 2/2 Running 0 26s pod/kube-addon-manager-minikube 1/1 Running 0 34m pod/kube-apiserver-minikube 1/1 Running 0 34m pod/kube-controller-manager-minikube 1/1 Running 0 34m pod/kube-proxy-rnlps 1/1 Running 0 34m pod/kube-scheduler-minikube 1/1 Running 0 34m pod/storage-provisioner 1/1 Running 0 34m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s 4. Disabilita `metrics-server`: minikube addons disable metrics-server L'output del comando è simile a: metrics-server was successfully disabled Clean up -------- Adesso puoi procedere a fare clean up delle risorse che hai creato nel tuo cluster: kubectl delete service hello-node kubectl delete deployment hello-node Eventualmente, puoi stoppare la Minikube virtual machine (VM): minikube stop Eventualmente, puoi cancellare la Minikube VM: minikube delete Voci correlate -------------- * Approfondisci la tua conoscenza dei [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) . * Approfondisci la tua conoscenza di [Rilasciare applicazioni](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/) . * Approfondisci la tua conoscenza dei [Services](https://kubernetes.io/docs/concepts/services-networking/service/) . --- # शेडुलिंग | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/reference/scheduling/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/reference/scheduling/) . शेडुलिंग ======== --- # Współtworzenie nowych treści | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/contribute/new-content/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/contribute/new-content/) . Współtworzenie nowych treści ============================ * 1: [Dokumentowanie funkcji nowego wydania](https://kubernetes.io/pl/docs/contribute/new-content/_print/#pg-10ed45584b496b99003f299b4614ff78) Ta sekcja zawiera informacje, które powinieneś znać przed dodaniem nowej treści. Istnieją również dedykowane strony dotyczące pisania [studiów przypadków](https://kubernetes.io/docs/contribute/new-content/case-studies) oraz [artykułów na bloga](https://kubernetes.io/docs/contribute/blog/) . Proces tworzenia nowej treści ----------------------------- flowchart LR subgraph second\[Zanim zaczniesz\] direction TB S\[ \] -.- A\[Podpisz CNCF CLA\] --> B\[Wybierz gałąź Git\] B --> C\[Jeden język na PR\] C --> F\[Sprawdź \ narzędzia dla współtwórców\] end subgraph first\[Podstawy współtworzenia\] direction TB T\[ \] -.- D\[Pisz dokumentację w Markdown \ i buduj stronę za pomocą Hugo\] --- E\[Kod źródłowy w GitHub\] E --- G\[Folder '/content/../docs' zawiera dokumentację \ w wielu językach\] G --- H\[Zapoznaj się z typami stron \ i shortcode'ami w Hugo\] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H grey class S,T spacewhite class first,second white _**Rysunek - Przygotowanie nowej treści**_ Powyższy rysunek przedstawia informacje, które powinieneś znać przed przesłaniem nowej treści. Szczegóły znajdują się poniżej. Podstawy kontrybucji -------------------- * Napisz dokumentację Kubernetesa w formacie Markdown i zbuduj stronę Kubernetesa za pomocą [Hugo](https://gohugo.io/) . * Dokumentacja Kubernetesa używa [CommonMark](https://commonmark.org/) jako swojej wersji Markdown. * Źródło znajduje się na [GitHub](https://github.com/kubernetes/website) . Dokumentację Kubernetesa można znaleźć w `/content/en/docs/`. Część dokumentacji referencyjnej jest automatycznie generowana ze skryptów w katalogu `update-imported-docs/`. * [Typy zawartości strony](https://kubernetes.io/pl/docs/contribute/style/page-content-types/) opisują sposób prezentacji treści dokumentacji w Hugo. * Możesz użyć [kodów Docsy](https://www.docsy.dev/docs/adding-content/shortcodes/) lub [niestandardowych skrótów Hugo](https://kubernetes.io/docs/contribute/style/hugo-shortcodes/) , aby wspierać dokumentację Kubernetes. * Oprócz standardowych kodów Hugo, w naszej dokumentacji używamy wielu [niestandardowych kodów Hugo](https://kubernetes.io/docs/contribute/style/hugo-shortcodes/) , aby kontrolować prezentację treści. * Dokumentacja jest dostępna w wielu językach w katalogu `/content/`. Każdy język ma własny folder z dwuliterowym kodem określonym przez [standard ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php) . Na przykład, źródło dokumentacji angielskiej jest przechowywane w `/content/en/docs/`. * Aby uzyskać więcej informacji na temat wnoszenia wkładu do dokumentacji w wielu językach lub rozpoczęcia nowego tłumaczenia, zobacz [Lokalizowanie](https://kubernetes.io/pl/docs/contribute/localization/) . Zanim zaczniesz --------------- ### Podpisz CNCF CLA Wszyscy współtwórcy Kubernetesa **muszą** przeczytać [Przewodnik dla Współtwórców](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) i [podpisać Umowę Licencyjną Współtwórcy (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md) . Pull requesty od autorów, którzy nie podpisali umowy CLA, nie przechodzą testów automatycznych. Imię i adres e-mail, które podasz, muszą zgadzać się z tymi ustawionymi w twoim `git config`, a twoje imię i adres e-mail w git muszą być takie same jak te używane dla CNCF CLA. ### Wybierz gałąź w Git Podczas otwierania pull requesta musisz wiedzieć z góry, na której gałęzi oprzeć swoją pracę. | Scenariusz | Gałąź | | --- | --- | | Istniejąca lub nowa treść w języku angielskim dla bieżącego wydania | `main` | | Treść dla wydania zmiany funkcji | Gałąź, która odpowiada głównej i mniejszej wersji, w której znajduje się zmiana funkcji, używając wzorca `dev-`. Na przykład, jeśli funkcja zmienia się w wydaniu `v1.36`, należy dodać zmiany w dokumentacji do gałęzi `dev-1.36`. | | Treść w innych językach (lokalizacje) | Użyj konwencji danej lokalizacji. Zobacz [Strategia rozgałęzień lokalizacji](https://kubernetes.io/pl/docs/contribute/localization/#branch-strategy)
po więcej informacji. | Jeśli nadal nie masz pewności, którą gałąź wybrać, zapytaj na `#sig-docs` na Slacku. #### Informacja: Jeśli już zgłosiłeś swoj pull request i wiesz, że była to niepoprawna gałąź bazowa, możesz ją zmienić (ty i tylko ty, zgłaszający). ### Języki na PR Ogranicz żądania pull request do jednego języka na PR. Jeśli musisz wprowadzić identyczną zmianę w tym samym fragmencie kodu w wielu językach, otwórz osobne PR dla każdego języka. Narzędzia dla współtwórców -------------------------- Katalog [narzędzi dla współtwórców dokumentacji](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) w repozytorium `kubernetes/website` zawiera narzędzia, wspierające proces współtworzenia dokumentacji. Co dalej? --------- * Przeczytaj jak zgłaszać [artykuły na bloga](https://kubernetes.io/docs/contribute/blog/article-submission/) . 1 - Dokumentowanie funkcji nowego wydania ========================================= Każda główna wersja Kubernetesa wprowadza nowe funkcje, które wymagają dokumentacji. Nowe wersje przynoszą również aktualizacje do istniejących funkcji i dokumentacji (na przykład awansowanie funkcji z wersji alpha do beta). Zazwyczaj SIG odpowiedzialny za funkcję przesyła szkic dokumentacji funkcji jako pull request do odpowiedniego gałęzi rozwojowej w repozytorium `kubernetes/website`, a ktoś z zespołu SIG Docs dostarcza uwagi redakcyjne lub edytuje szkic bezpośrednio. Ta sekcja opisuje konwencje dotyczące rozgałęzień (ang. branching) oraz proces stosowany podczas wydania przez obie grupy. Więcej o publikowaniu nowych funkcji na blogu przeczytasz w sekcji [komunikaty po wydaniu](https://kubernetes.io/docs/contribute/blog/release-comms/) . Dla współtwórców dokumentacji ----------------------------- Ogólnie rzecz biorąc, współtwórcy dokumentacji nie piszą treści od podstaw na potrzeby wydania. Zamiast tego współpracują z SIG tworzącym nową funkcję, aby dopracować szkic dokumentacji i przygotować go do wydania. Po wybraniu fukncji do udokumentowania lub wsparcia, zapytaj o nią na kanale Slack `#sig-docs`, podczas cotygodniowego spotkania SIG Docs lub bezpośrednio w zgłoszeniu PR wystawionym przez SIG odpowiedzialny za funkcje. Jeśli otrzymasz zgodę, możesz edytować PR za pomocą jednej z technik opisanych w [Wprowadź zmiany do PR innej osoby](https://kubernetes.io/docs/contribute/review/for-approvers/#commit-into-another-person-s-pr) . ### Dowiedz się o nadchodzących funkcjach Aby dowiedzieć się o nadchodzących funkcjach, weź udział w cotygodniowym spotkaniu SIG Release (zobacz stronę [społeczności](https://kubernetes.io/community/) w celu uzyskania informacji o nadchodzących spotkaniach) i monitoruj dokumentację dotyczącą wydania w repozytorium [kubernetes/sig-release](https://github.com/kubernetes/sig-release/) . Każde wydanie ma podkatalog w katalogu [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases) . Podkatalog zawiera harmonogram wydania, szkic notatek do wydania oraz dokument z listą każdej osoby w zespole wydania. Harmonogram wersji zawiera linki do wszystkich innych dokumentów, spotkań, protokołów spotkań i kamieni milowych związanych z wydaniem. Zawiera również informacje o celach i harmonogramie wydania oraz wszelkich specjalnych procesach wdrożonych dla tego wydania. Pod koniec dokumentu zdefiniowano kilka terminów związanych z wydaniem. Ten dokument zawiera również link do **Arkusza śledzenia funkcji**, który jest oficjalnym sposobem na poznanie wszystkich nowych funkcji planowanych do wprowadzenia w wydaniu. Dokumentacja zespołu odpowiadającego za kolejne wydanie zawiera listę osób do przypisanych do różnych ról. Jeśli nie jest jasne, do kogo się zwrócić w sprawie konkretnej funkcji lub pytania, które masz, możesz skorzystać z jednego z dwóch rozwiązań: weź udział w spotkaniu zespołu, aby zadać swoje pytanie, lub skontaktuj się z liderem wydania, aby mógł Cię odpowiednio skierować. Szkic notatek z wydania to dobre miejsce, aby dowiedzieć się o specyficznych funkcjach, zmianach, przestarzałych elementach i innych kwestiach dotyczących wydania. Ponieważ treść nie jest ostateczna aż do późnego etapu, warto zachować ostrożność. ### Arkusz śledzenia funkcji Arkusz śledzenia funkcji [dla danej wersji Kubernetesa](https://github.com/kubernetes/sig-release/tree/master/releases) wymienia każdą funkcję, która jest planowana do wydania. Każdy element zawiera nazwę funkcji, link do głównego problemu na GitHubie, poziom stabilności (Alpha, Beta lub Stable), SIG i osobę odpowiedzialną za jej wdrożenie, czy wymaga dokumentacji, projekt notatki o wydaniu dla funkcji oraz czy została zintegrowana. Pamiętaj o następujących zasadach: * Funkcje w wersji Beta i Stable są zazwyczaj priorytetowane wyżej w dokumentacji niż funkcje w wersji Alfa. * Trudno jest przetestować (a tym samym udokumentować) funkcję, która nie została zmergowana, lub przynajmniej jest uważana za kompletną w swoim PR. * Określenie, czy funkcja wymaga dokumentacji, jest procesem manualnym. Nawet jeśli funkcja nie jest oznaczona jako wymagająca dokumentacji, może być konieczne jej udokumentowanie. Dla developerów lub innych członków SIG --------------------------------------- Ta sekcja zawiera informacje dla członków innych SIG Kubernetesów dokumentujących nowe funkcje na potrzeby wydania. Jeśli jesteś członkiem SIG, który rozwija nową funkcję dla Kubernetesa, musisz współpracować z SIG Docs, aby mieć pewność, że Twoja funkcja zostanie udokumentowana na czas przed wydaniem. Sprawdź [arkusz śledzenia funkcji](https://github.com/kubernetes/sig-release/tree/master/releases) lub sprawdź kanał Slack Kubernetes `#sig-release`, aby zweryfikować szczegóły harmonogramu i terminy. ### Otwórz tymczasowy PR 1. Otwórz **szkic** pull requestu do gałęzi `dev-1.36` w repozytorium `kubernetes/website`, z małym commitem, który później zmienisz. Aby utworzyć szkic pull requestu, użyj rozwijanego menu **Create Pull Request** i wybierz **Create Draft Pull Request**, następnie kliknij **Draft Pull Request**. 2. Edytuj opis pull requesta, aby zawierał linki do PR-ów w [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) oraz zgłoszeń w [kubernetes/enhancements](https://github.com/kubernetes/enhancements) . 3. Zostaw komentarz w powiązanym zgłoszeniu w tym repozytorium [kubernetes/enhancements](https://github.com/kubernetes/enhancements) z linkiem do PR, aby powiadomić osobę zajmującą się dokumentacją tej wersji, że dokumentacja dotycząca funkcji jest w przygotowaniu i powinna być śledzona w tym wydaniu. Jeśli Twoja funkcjonalność nie wymaga żadnych zmian w dokumentacji, upewnij się, że zespół sig-release o tym wie, wspominając o tym na kanale Slack `#sig-release`. Jeśli funkcjonalność wymaga dokumentacji, ale PR nie został utworzony, funkcjonalność może zostać usunięta z kamienia milowego. ### PR gotowy do przeglądu Kiedy będziesz gotowy, wypełnij swój tymczasowy PR dokumentacją funkcji i zmień stan PR z roboczego na **ready for review**. Aby oznaczyć pull request jako gotowy do przeglądu, przejdź do pola scalania (ang. merge box) i kliknij **Ready for review**. Najlepiej jak potrafisz opisz swoją funkcję i sposób jej użycia. Jeśli potrzebujesz pomocy w strukturyzacji swojej dokumentacji, zapytaj na kanale Slack `#sig-docs`. Gdy ukończysz swój materiał, osoba odpowiedzialna za dokumentację przypisana do Twojej funkcji go przegląda. Aby zapewnić dokładność techniczną, treść może również wymagać przeglądu technicznego przez odpowiednie SIG-i. Skorzystaj z ich sugestii, aby dopracować treść do stanu gotowego do wydania. Jeśli twoja funkcja wymaga dokumentacji, a pierwsza wersja treści nie zostanie dostarczona, funkcja może zostać usunięta z kamienia milowego. #### Bramki funkcji (ang. feature gates) Jeśli Twoja funkcja jest funkcją Alfa lub Beta i jest włączana warunkowo bramką funkcji (ang. feature gate), potrzebujesz dla niej pliku bramki funkcji wewnątrz `content/en/docs/reference/command-line-tools-reference/feature-gates/`. Nazwa pliku powinna być nazwą bramki funkcji z sufiksem `.md`. Możesz spojrzeć na inne pliki już znajdujące się w tym samym katalogu, aby uzyskać wskazówkę, jak powinien wyglądać Twój plik. Zwykle wystarczy jeden akapit; dla dłuższych wyjaśnień dodaj dokumentację w innym miejscu i dodaj do niej link. Aby upewnić się, że twój feature gate pojawi się w tabeli [Alpha/Beta Feature gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) , dodaj następujące informacje do sekcji [front matter](https://gohugo.io/content-management/front-matter/) w pliku Markdown z opisem: stages: - stage: # Specify the development stage of the feature gate defaultValue: # Set to true if enabled by default, false otherwise fromVersion: # Version from which the feature gate is available toVersion: # (Optional) The version until which the feature gate is available W przypadku nowych bramek funkcji wymagany jest również osobny opis bramki funkcji; utwórz nowy plik Markdown w `content/en/docs/reference/command-line-tools-reference/feature-gates/` (użyj innych plików jako szablonu). Gdy zmieniasz bramkę funkcji z domyślnie wyłączonej na domyślnie włączoną, może być konieczne zmienienie również innej dokumentacji (nie tylko listy bramek funkcji). Uważaj na zwroty takie jak „Pole `exampleSetting` jest polem beta i jest domyślnie wyłączone. Możesz je włączyć, włączając bramkę funkcji `ProcessExampleThings`.” Jeśli Twoja funkcja osiągnęła status GA lub została oznaczona jako przestarzała, dodaj dodatkowy wpis `stage` w ramach bloku `stages` w pliku opisu. Upewnij się, że etapy Alpha i Beta pozostają nienaruszone. Ten krok przenosi bramkę funkcji z [Feature gates for Alpha/Beta](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) do [Feature gates for graduated or deprecated features](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) . Na przykład: stages: - stage: alpha defaultValue: false fromVersion: "1.12" toVersion: "1.12" - stage: beta defaultValue: true fromVersion: "1.13" # Added a `toVersion` to the previous stage. toVersion: "1.18" # Added 'stable' stage block to existing stages. - stage: stable defaultValue: true fromVersion: "1.19" toVersion: "1.27" Ostatecznie Kubernetes przestanie w ogóle uwzględniać bramę funkcji. Aby zasygnalizować usunięcie bramy funkcji, uwzględnij `removed: true` w przedniej części odpowiedniego pliku opisu. Wprowadzenie tej zmiany oznacza, że informacje o bramie funkcji przenoszą się z [Skróty funkcji dla ukończonych lub przestarzałych funkcji](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates-removed/#feature-gates-that-are-removed) do dedykowanej strony zatytułowanej [Skróty funkcji (usunięte)](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates-removed/) , łącznie z jej opisem. ### Wszystkie PR-y zostały zrecenzowane i są gotowe do scalenia Jeśli Twój PR nie został jeszcze scalony z gałęzią `dev-1.36` przed terminem wydania, współpracuj z osobą odpowiedzialną za dokumentację i zarządzającą wydaniem, aby dodać go przed terminem. Jeśli Twoja funkcja potrzebuje dokumentacji, a dokumentacja nie jest gotowa, funkcja może zostać usunięta z bieżącego planu (**milestone**). --- # उपकरण स्थापित करें | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/tasks/tools/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/tasks/tools/) . उपकरण स्थापित करें ================== अपने कंप्यूटर पर कुबेरनेट्स टूल सेटअप करें। * 1: [Linux पर kubectl इंस्टॉल और सेट अप करें](https://kubernetes.io/hi/docs/tasks/tools/_print/#pg-37b6179f23c8ad977cb9daa6d2da748a) * 2: [macOS पर kubectl इंस्टॉल और सेटअप करें](https://kubernetes.io/hi/docs/tasks/tools/_print/#pg-961fc70b732cb8df4fd11a3463b6545c) * 3: [Windows पर kubectl इंस्टॉल और सेटअप करें](https://kubernetes.io/hi/docs/tasks/tools/_print/#pg-2cc93d3011d707aeb6564bab02048f7a) kubectl ------- कुबेरनेट्स कमांड-लाइन टूल, [kubectl](https://kubernetes.io/docs/reference/kubectl/kubectl/) , आपको कुबेरनेट्स क्लस्टर पर कमांड चलाने की अनुमति देता है। आप एप्लिकेशन को डिप्लॉय करने, क्लस्टर संसाधनों का निरीक्षण और प्रबंधन करने और लॉग देखने के लिए kubectl का उपयोग कर सकते हैं। kubectl संचालन की पूरी सूची सहित अधिक जानकारी के लिए, देखें [`kubectl` संदर्भ प्रलेखन](https://kubernetes.io/docs/reference/kubectl/) . kubectl विभिन्न प्रकार के Linux प्लेटफॉर्म, macOS और Windows पर इंस्टॉल करने योग्य है। नीचे अपना उपयुक्त ऑपरेटिंग सिस्टम खोजें। * [kubectl Linux पर इंस्टॉल करें](https://kubernetes.io/hi/docs/tasks/tools/install-kubectl-linux) * [kubectl macOS पर इंस्टॉल करें](https://kubernetes.io/hi/docs/tasks/tools/install-kubectl-macos) * [kubectl Windows पर इंस्टॉल करें](https://kubernetes.io/hi/docs/tasks/tools/install-kubectl-windows) kind ---- [`kind`](https://kind.sigs.k8s.io/docs/) आपको अपने कंप्यूटर पर कुबेरनेट्स चलाने देता है। इस उपकरण के लिए आवश्यक है कि आपके पास [Docker](https://docs.docker.com/get-docker/) इंस्टॉल और कॉन्फ़िगर किया गया हो। kind [क्विक स्टार्ट](https://kind.sigs.k8s.io/docs/user/quick-start/) पृष्ठ आपको दिखाता है कि kind चलाने के लिए आपको क्या करने की आवश्यकता है। [kind क्विक स्टार्ट गाइड देखें](https://kind.sigs.k8s.io/docs/user/quick-start/) minikube -------- `kind` की तरह, [`minikube`](https://minikube.sigs.k8s.io/) एक उपकरण है जो आपको स्थानीय स्तर पर कुबेरनेट्स चलाने देता है। minikube आपके कंप्यूटर (windows, macOS और linux पीसी सहित) पर सिंगल-नोड कुबेरनेट्स क्लस्टर चलाता है ताकि आप कुबेरनेट्स सीख सकें या डेवलपमेंट कर सकें। यदि आपका ध्यान उपकरण को इंस्टॉल करने पर है तो आप मुख्य [आरंभ करें!](https://minikube.sigs.k8s.io/docs/start/) गाइड का अनुसरण कर सकते हैं। [minikube क्विक स्टार्ट गाइड देखें](https://minikube.sigs.k8s.io/docs/start/) एक बार जब आपके पास minikube काम कर रहा हो, तो आप इसका उपयोग [नमूना एप्लिकेशन](https://kubernetes.io/hi/docs/tutorials/hello-minikube/) चलाने के लिए कर सकते हैं। kubeadm ------- कुबेरनेट्स क्लस्टर बनाने और प्रबंधित करने के लिए आप [kubeadm](https://kubernetes.io/hi/docs/admin/kubeadm/ "कुबेरनेट्स को जल्दी से इंस्टॉल करने और एक सुरक्षित क्लस्टर स्थापित करने के लिए एक उपकरण।") टूल का उपयोग कर सकते हैं। यह उपयोगकर्ता के अनुकूल तरीके से न्यूनतम व्यवहार्य, सुरक्षित क्लस्टर बनाने और चलाने के लिए आवश्यक कार्य करता है। [kubeadm इंस्टॉल](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) करना आपको दिखाता है कि kubeadm को कैसे इंस्टॉल किया जाए। एक बार इंस्टॉल होने के बाद, आप इसका उपयोग [क्लस्टर बनाने](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) के लिए कर सकते हैं। [kubeadm इंस्टॉल गाइड देखें](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 1 - Linux पर kubectl इंस्टॉल और सेट अप करें =========================================== शुरू करने से पहले ----------------- आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण के भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ संवाद कर सकते हैं। kubectl के नवीनतम संस्करण का उपयोग करने से अप्रत्याशित मुद्दों से बचने में मदद मिलती है। Linux पर kubectl इंस्टॉल करें ----------------------------- Linux पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं: * [Linux पर curl के माध्यम से kubectl बाइनरी इंस्टॉल करें](https://kubernetes.io/hi/docs/tasks/tools/_print/#install-kubectl-binary-with-curl-on-linux) * [नेटिव पैकेज मैनेजमेंट के माध्यम से इंस्टॉल करें](https://kubernetes.io/hi/docs/tasks/tools/_print/#install-using-native-package-management) * [अन्य पैकेज मैनेजमेंट के माध्यम से इंस्टॉल करें](https://kubernetes.io/hi/docs/tasks/tools/_print/#install-using-other-package-management) ### Linux पर curl के माध्यम से kubectl बाइनरी इंस्टॉल करें 1. कमांड से नवीनतम रिलीज डाउनलोड करें: curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" #### टिप्पणी: एक विशिष्ट संस्करण डाउनलोड करने के लिए, कमांड के `$(curl -L -s https://dl.k8s.io/release/stable.txt)` हिस्से को विशिष्ट संस्करण से बदलें। उदाहरण के लिए, लिनक्स पर 1.35.0 संस्करण डाउनलोड करने के लिए, टाइप करें: curl -LO https://dl.k8s.io/release/v1.35.0/bin/linux/amd64/kubectl 2. बाइनरी को मान्य करें (वैकल्पिक) kubectl चेकसम फाइल डाउनलोड करें: curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256" चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें: echo "$( /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF yum install -y kubectl ### अन्य पैकेज मैनेजमेंट के माध्यम से इंस्टॉल करें * [Snap](https://kubernetes.io/hi/docs/tasks/tools/_print/#other-kubectl-install-0) * [Homebrew](https://kubernetes.io/hi/docs/tasks/tools/_print/#other-kubectl-install-1) यदि आप Ubuntu या किसी अन्य Linux डिस्ट्रीब्यूशन पर हैं जो [snap](https://snapcraft.io/docs/core/install) पैकेज मैनेजर को सपोर्ट करता है, तो kubectl [snap](https://snapcraft.io/) एप्लिकेशन के रूप में उपलब्ध है। snap install kubectl --classic kubectl version --client यदि आप Linux पर [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) पैकेज मैनेजर का उपयोग कर रहे हैं, तो kubectl [इंस्टालेशन](https://docs.brew.sh/Homebrew-on-Linux#install) के लिए उपलब्ध है। brew install kubectl kubectl version --client kubectl कॉन्फ़िगरेशन सत्यापित करें ---------------------------------- kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसे [क्यूबकॉन्फिग फाइल](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) (kubeconfig) की आवश्यकता होती है, जो स्वचालित रूप से तब बनता है जब आप [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) का उपयोग करके क्लस्टर बनाते हैं या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं। डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन `~/.kube/config` पर स्थित होता है। जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है: kubectl cluster-info यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है। यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है। The connection to the server was refused - did you specify the right host or port? उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा। यदि `kubectl cluster-info` URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें: kubectl cluster-info dump वैकल्पिक kubectl कॉन्फ़िगरेशन और प्लगइन्स ----------------------------------------- ### शेल ऑटोकम्प्लेशन सक्षम करें kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपका काफी समय बचा सकता है। नीचे Bash और Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं। * [Bash](https://kubernetes.io/hi/docs/tasks/tools/_print/#kubectl-autocompletion-0) * [Zsh](https://kubernetes.io/hi/docs/tasks/tools/_print/#kubectl-autocompletion-1) परिचय ----- Bash के लिए kubectl समापन स्क्रिप्ट `kubectl completion bash` कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में समापन स्क्रिप्ट को सोर्स करने से kubectl ऑटोकम्पलीशन सक्षम हो जाती है। हालाँकि, समापन की स्क्रिप्ट [**bash-completion**](https://github.com/scop/bash-completion) पर निर्भर हैं जिसका अर्थ है कि आपको पहले इस सॉफ़्टवेयर को इंस्टॉल करना होगा (आप `type _init_completion` चलाकर परीक्षण कर सकते हैं कि आपने पहले से bash-completion इंस्टॉल की है या नहीं)। Bash-completion को इंस्टॉल करें ------------------------------- कई पैकेज मैनेजर द्वारा bash-completion प्रदान की जाती है ([यहाँ](https://github.com/scop/bash-completion#installation) देखें)। आप इसे `apt-get install bash-completion` या `yum install bash-completion` आदि के साथ इंस्टॉल कर सकते हैं। यह कमांड `/usr/share/bash-completion/bash_completion` उत्त्पन्न करता है, जो bash-completion की मुख्य स्क्रिप्ट है। आपके पैकेज मैनेजर के आधार पर, आपको इस फाइल को अपनी `~/.bashrc` फाइल में मैन्युअल रूप से सोर्स करना होगा। यह पता लगाने के लिए, अपना शेल पुनः लोड करें और `type _init_completion` रन करे। यदि कमांड सफल होता है, तो आप पहले से ही तैयार हैं, अन्यथा अपनी `~/.bashrc` फ़ाइल में निम्नलिखित जोड़ें: source /usr/share/bash-completion/bash_completion अपना शेल पुनः लोड करें और `type _init_completion` टाइप करके सत्यापित करें कि बैश-कम्पलीशन सही ढंग से इंस्टॉल है। kubectl ऑटोकम्पलीशन सक्षम करे ----------------------------- अब आपको यह सुनिश्चित करने की आवश्यकता है कि kubectl समापन स्क्रिप्ट आपके सभी शेल सत्रों (sourced) में प्राप्त हो जाए। आप ऐसा दो तरीकों से कर सकते हैं: * अपनी `~/.bashrc` फ़ाइल में समापन स्क्रिप्ट सॉर्स करें: echo 'source <(kubectl completion bash)' >>~/.bashr * समापन स्क्रिप्ट को `/etc/bash_completion.d` डायरेक्टरी में जोड़ें: `bash kubectl completion bash >/etc/bash_completion.d/kubectl` यदि आप के पास kubectl के लिए एक अन्य नाम (alias) है, तो आप उस अन्य नाम के साथ काम करने के लिए शेल समापन को बढ़ा सकते हैं: echo 'alias k=kubectl' >>~/.bashrc echo 'complete -F __start_kubectl k' >>~/.bashrc #### टिप्पणी: bash-completion सभी समापन स्क्रिप्ट को `/etc/bash_completion.d` में सोर्स करता है। दोनों दृष्टिकोण बराबर हैं। आपके शेल को पुनः लोड करने के बाद, Kubectl ऑटोकम्पलीशन कार्य करना शुरू कर देगा। Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट `kubectl completion zsh` कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है। अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी `~/.zshrc` फ़ाइल में जोड़ें: source <(kubectl completion zsh) यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं: echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए। यदि आपको कोई त्रुटि मिलती है जैसे `complete:13: command not found: compdef`, तो अपनी `~/.zshrc` फ़ाइल की शुरुआत में निम्नलिखित जोड़ें: autoload -Uz compinit compinit ### `kubectl convert` प्लगइन इंस्टॉल करें कुबेरनेट्स कमांड-लाइन टूल `kubectl` के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है। यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है। अधिक जानकारी के लिए, [गैर पदावनत एपिस में विस्थापित करें](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) पर जाएं। 1. कमांड से नवीनतम रिलीज डाउनलोड करें: curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert 2. बाइनरी को मान्य करें (वैकल्पिक) kubectl-convert चेकसम फ़ाइल डाउनलोड करें: curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256" चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें: echo "$( was refused - did you specify the right host or port? उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा। यदि `kubectl cluster-info` URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें: kubectl cluster-info dump वैकल्पिक Kubectl कॉन्फ़िगरेशन और प्लगइन्स ----------------------------------------- ### शेल ऑटोकम्प्लेशन सक्षम करें kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपका काफी समय बचा सकता है। नीचे Bash और Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं। * [Bash](https://kubernetes.io/hi/docs/tasks/tools/_print/#kubectl-autocompletion-0) * [Zsh](https://kubernetes.io/hi/docs/tasks/tools/_print/#kubectl-autocompletion-1) ### परिचय Bash के लिए kubectl समापन स्क्रिप्ट `kubectl completion bash` कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में समापन स्क्रिप्ट को सोर्स करने से kubectl ऑटोकम्पलीशन सक्षम हो जाती है।\`\`\` हालाँकि, समापन की स्क्रिप्ट [**bash-completion**](https://github.com/scop/bash-completion) पर निर्भर हैं जिसका अर्थ है कि आपको पहले इस सॉफ़्टवेयर को इंस्टॉल करना होगा। #### चेतावनी: Bash-completion के लिये दो संस्करण हैं v1 और v2। v1 bash 3.2 के लिये हैं (जो macOS के लिए डिफ़ॉल्ट है), और v2 bash 4.1+ के लिए है।kubectl कम्पलीशन स्क्रिप्ट Bash-completion v1 और Bash 3.2 के साथ ठीक से **काम नहीं करती है**। इसके लिए **Bash-completion v2** और बैश 4.1+ की आवश्यकता है। इसलिए macOS पर kubectl कम्पलीशन को सही तरीके से इस्तेमाल करने के लिए , आपको bash 4.1+ इनस्टॉल और उपयोग करना होगा ([_निर्देश_](https://apple.stackexchange.com/a/292760) )। निम्नलिखित निर्देश मानते हैं कि आप बैश का उपयोग करते हैं (अर्थात 4.1  का कोई भी बैश संस्करण या इससे नया)। ### अपग्रेड बैश निम्नलिखित निर्देश मानते हैं कि आप बैश 4.1+ का उपयोग करते हैं। आप अपने बैश के संस्करण को यह चलाकर देख सकते हैं: echo $BASH_VERSION यदि यह बहुत पुराना है, तो आप Homebrew का उपयोग करके इसे इनस्टॉल/अपग्रेड कर सकते हैं: brew install bash अपने शेल को पुनः लोड करें और सत्यापित करें कि इच्छित संस्करण का उपयोग किया जा रहा है: echo $BASH_VERSION $SHELL Homebrew आमतौर पर इसे `/usr/local/bin/bash` पर इनस्टॉल करता है। ### इनस्टॉल bash-completion #### टिप्पणी: जैसा कि उल्लेख किया गया है, ये निर्देश मानते हैं कि आप Bash 4.1+ का उपयोग करते हैं, जिसका अर्थ है कि आप bash-completion v2 इनस्टॉल  करेंगे (Bash 3.2 और bash-completion v1 पर kubectl  पूर्णता काम नहीं करेगी)। आप `type_init_completion` से सत्यापित कर सकते हैं कि क्या आपके पास bash-completion v2 पहले से इनस्टॉल है। यदि नहीं, तो आप इसे Homebrew से इनस्टॉल कर सकते हैं brew install bash-completion@2 जैसा कि इस कमांड के आउटपुट में बताया गया है, अपनी `~/.bash_profile` फ़ाइल में निम्नलिखित जोड़ें: export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" अपने शेल को पुनः लोड करें और `type_init_completion` से सत्यापित करें कि bash-completion v2 सही ढंग से इनस्टॉल है। ### kubectl ऑटोकम्पलीशन सक्षम करें अब आपको यह सुनिश्चित करने की आवश्यकता है कि kubectl समापन स्क्रिप्ट आपके सभी शेल सत्रों (sourced) में प्राप्त हो जाए। इसे हासिल करने के कई तरीके हैं: * अपने कम्पलीशन स्क्रिप्ट को `~/.bash_profile` में सोर्स करें: echo 'source <(kubectl completion bash)' >>~/.bash_profile * कम्पलीशन स्क्रिप्ट को `/usr/local/etc/bash_completion.d` डायरेक्टरी में जोड़ें: kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl * यदि आपके पास kubectl के लिए एक नाम (alias) है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं: echo 'alias k=kubectl' >>~/.bash_profile echo 'complete -F __start_kubectl k' >>~/.bash_profile * यदि आपने Homebrew के साथ kubectl इनस्टॉल किया है (जैसा कि यहां बताया गया है), तो kubectl कम्पलीशन स्क्रिप्ट पहले से ही `/usr/local/etc/bash_completion.d/kubectl` में होनी चाहिए। ऐसे में आपको कुछ भी करने की जरूरत नहीं है। #### टिप्पणी: bash-completion Homebrew से इनस्टॉल होने पर, सारे फाइल्स को `BASH_COMPLETION_COMPAT_DIR` डायरेक्टरी में सोर्स कर देता है। इसलिए आखरी दो तरीके काम करते हैं। किसी भी स्थिति में, आपके शेल को पुनः लोड करने के बाद, Kubectl पूर्णता कार्य करना चाहिए। Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट `kubectl completion zsh` कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है। अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी `~/.zshrc` फ़ाइल में जोड़ें: source <(kubectl completion zsh) यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं: echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए। यदि आपको कोई त्रुटि मिलती है जैसे `complete:13: command not found: compdef`, तो अपनी `~/.zshrc` फ़ाइल की शुरुआत में निम्नलिखित जोड़ें: autoload -Uz compinit compinit ### `kubectl convert` प्लगइन इंस्टॉल करें कुबेरनेट्स कमांड-लाइन टूल `kubectl` के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है। यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है। अधिक जानकारी के लिए, [गैर पदावनत एपिस में विस्थापित करें](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) पर जाएं। 1. इस कमांड से नवीनतम रिलीज डाउनलोड करें: * [Intel](https://kubernetes.io/hi/docs/tasks/tools/_print/#download-convert-binary-macos-0) * [Apple Silicon](https://kubernetes.io/hi/docs/tasks/tools/_print/#download-convert-binary-macos-1) curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert" curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert" 2. बाइनरी को मान्य करें (वैकल्पिक) kubectl-convert चेकसम फ़ाइल डाउनलोड करें: * [Intel](https://kubernetes.io/hi/docs/tasks/tools/_print/#download-convert-checksum-macos-0) * [Apple Silicon](https://kubernetes.io/hi/docs/tasks/tools/_print/#download-convert-checksum-macos-1) curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256" curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256" चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें: echo "$( was refused - did you specify the right host or port? उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा। यदि `kubectl cluster-info` URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें: kubectl cluster-info dump वैकल्पिक kubectl कॉन्फ़िगरेशन और प्लगइन्स ----------------------------------------- ### शेल ऑटोकम्प्लेशन सक्षम करें kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपको बहुत सारी टाइपिंग बचा सकता है। नीचे Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं, यदि आप इसे Windows पर चला रहे हैं। Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट `kubectl completion zsh` कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है। अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी `~/.zshrc` फ़ाइल में जोड़ें: source <(kubectl completion zsh) यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं: echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए। यदि आपको कोई त्रुटि मिलती है जैसे `complete:13: command not found: compdef`, तो अपनी `~/.zshrc` फ़ाइल की शुरुआत में निम्नलिखित जोड़ें: autoload -Uz compinit compinit ### इंस्टॉल `kubectl convert` प्लगइन कुबेरनेट्स कमांड-लाइन टूल `kubectl` के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है। यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है। अधिक जानकारी के लिए, [गैर पदावनत एपिस में विस्थापित करें](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) पर जाएं। 1. इस कमांड से नवीनतम रिलीज डाउनलोड करें: curl -LO https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl-convert.exe 2. बाइनरी को मान्य करें (वैकल्पिक) kubectl-convert चेकसम फ़ाइल डाउनलोड करें: curl -LO https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl-convert.exe.sha256 चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें: * मैन्युअल रूप से कमांड प्रॉम्प्ट का उपयोग करके `CertUtil` के आउटपुट की तुलना डाउनलोड किये गये चेकसम फ़ाइल से करें: CertUtil -hashfile kubectl-convert.exe SHA256 type kubectl-convert.exe.sha256 * `True` या `False` परिणाम प्राप्त करने और `-eq` ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए Powershell का उपयोग करें: $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) 3. अपने `PATH` में बाइनरी जोड़ें। 4. सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है। kubectl convert --help यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है। आगे क्या है ----------- * [मिनीक्यूब (Minikube) इंस्टॉल करें](https://minikube.sigs.k8s.io/docs/start/) * क्लस्टर बनाने के बारे में अधिक जानकारी के लिए [आरंभ करने की मार्गदर्शिका](https://kubernetes.io/hi/docs/setup/) देखें। * [अपने एप्लिकेशन को लॉन्च और एक्सपोज़ करने का तरीका जानें।](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/) * यदि आपको किसी ऐसे क्लस्टर को उपयोग करने की आवश्यकता है जिसे आपने नहीं बनाया है, तो [क्लस्टर एक्सेस दस्तावेज़ साझा करना](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) देखें। * [kubectl संदर्भ प्रलेखन](https://kubernetes.io/docs/reference/kubectl/kubectl/) पढ़ें। --- # 404 Page not found | Kubernetes Were you looking for: * [Documentation](https://kubernetes.io/docs/home/) * [Kubernetes Blog](https://kubernetes.io/blog/) * [Training](https://kubernetes.io/training/) * [Careers](https://kubernetes.io/careers/) * [Partners](https://kubernetes.io/partners/) * [Community](https://kubernetes.io/community/) --- # Kontenery | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/concepts/containers/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/concepts/containers/) . Kontenery ========= System "pakowania" aplikacji i jej zależności w spójne środowisko uruchomieniowe. Ta strona omawia kontenery i obrazy kontenerów, a także ich zastosowanie w utrzymaniu systemów i tworzeniu rozwiązań. Słowo _kontener (ang. container)_ jest wieloznacznym pojęciem. Zawsze, gdy go używasz, sprawdź, czy Twoi odbiorcy stosują tę samą definicję. Każdy uruchamiany kontener jest powtarzalny; standaryzacja wynikająca z uwzględnienia zależności oznacza, że uzyskujesz to samo zachowanie, gdziekolwiek go uruchomisz. Kontenery oddzielają aplikacje od infrastruktury hosta. To ułatwia wdrażanie w różnych środowiskach chmurowych lub systemach operacyjnych. Każdy [węzeł](https://kubernetes.io/pl/docs/concepts/architecture/nodes/) w klastrze Kubernetesa uruchamia kontenery, które tworzą [Pody](https://kubernetes.io/pl/docs/concepts/workloads/pods/) przypisane do tego węzła. Kontenery należące do jednego Poda są uruchamiane razem na tym samym węźle w ramach wspólnego harmonogramu. Obrazy kontenerów[](https://kubernetes.io/pl/docs/concepts/containers/_print/#container-images) ------------------------------------------------------------------------------------------------ [Obraz kontenera](https://kubernetes.io/docs/concepts/containers/images/) to gotowy do uruchomienia pakiet oprogramowania zawierający wszystko, co jest potrzebne do uruchomienia aplikacji: kod i wszelkie wymagane środowiska uruchomieniowe, biblioteki aplikacji i systemowe, oraz wartości domyślne dla wszelkich niezbędnych ustawień. Kontenery są przeznaczone do bycia bezstanowymi i [niezmiennymi](https://glossary.cncf.io/immutable-infrastructure/) : nie powinieneś zmieniać kodu kontenera, który już działa. Jeśli masz aplikację konteneryzowaną i chcesz dokonać zmian, właściwym procesem jest zbudowanie nowego obrazu zawierającego zmiany, a następnie odtworzenie kontenera w celu uruchomienia go z zaktualizowanego obrazu. Środowiska uruchomieniowe kontenerów[](https://kubernetes.io/pl/docs/concepts/containers/_print/#container-runtimes) --------------------------------------------------------------------------------------------------------------------- Podstawowy komponent umożliwiający efektywne uruchamianie kontenerów w Kubernetesie. Odpowiada za zarządzanie uruchamianiem i cyklem życia kontenerów w środowisku Kubernetes. Kubernetes obsługuje różne _container runtimes_: [containerd](https://containerd.io/docs/) , [CRI-O](https://cri-o.io/#what-is-cri-o) oraz każdą implementację zgodną z [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Zazwyczaj możesz pozwolić swojemu klastrowi na wybranie domyślnego środowiska uruchomieniowego kontenera dla Poda. Jeśli musisz używać więcej niż jednego środowiska uruchomieniowego kontenera w swoim klastrze, możesz określić [RuntimeClass](https://kubernetes.io/docs/concepts/containers/runtime-class/) dla Poda, aby upewnić się, że Kubernetes uruchamia te kontenery przy użyciu konkretnego środowiska uruchomieniowego kontenera. Możesz również użyć RuntimeClass, aby uruchamiać różne Pody z tym samym środowiskiem uruchomieniowym kontenera, ale z różnymi ustawieniami. --- # Aktualizacja materiałów źródłowych | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/) . Aktualizacja materiałów źródłowych ================================== * 1: [Wkład w kod źródłowy Kubernetesa](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-a5eac5b2b794f16aa703a2fa212d7c39) * 2: [Generowanie materiałów źródłowych dla polecenia kubectl](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-03de26b330a5cfdb26672f6bc75dcc04) * 3: [Generowanie materiałów źródłowych dla metryk](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-7cf2686833318bffe2ef1b82e55748e7) * 4: [Generowanie materiałów źródłowych dla komponentów i narzedzi Kubernetesa](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-28fc50a0072b0b2b444aa24e552d2e60) * 5:[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-eabe0c0c6b0046c51d7fdf5e8450a5b5) Tematy w tej sekcji opisują, jak aktualizować (czyli ponownie wygenerować) materiały źródłowe (ang. reference documentation) Kubernetesa. Aby zbudować materiały źródłowe, zapoznaj się z następującym przewodnikiem: * [Szybki start generowania materiałów źródłowych](https://kubernetes.io/docs/contribute/generate-ref-docs/quickstart/) 1 - Wkład w kod źródłowy Kubernetesa[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-a5eac5b2b794f16aa703a2fa212d7c39) =============================================================================================================================================== Ta strona pokazuje, jak wnieść wkład do projektu `kubernetes/kubernetes`. Możesz naprawiać błędy znalezione w dokumentacji API Kubernetesa lub w treściach dla komponentów Kubernetesa, takich jak `kubeadm`, `kube-apiserver` i `kube-controller-manager`. Jeśli zamiast tego chcesz wygenerować ponownie materiały źródłowe dla API Kubernetesa lub komponentów `kube-*` z kodu źródłowego, zapoznaj się z następującymi instrukcjami: * [Generowanie materiałów źródłowych dla API Kubernetesa](https://kubernetes.io/docs/contribute/generate-ref-docs/kubernetes-api/) * [Generowanie materiałów źródłowych dla komponentów i narzędzi Kubernetesa](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/kubernetes-components/) Zanim zaczniesz[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#zanim-zaczniesz) ------------------------------------------------------------------------------------------------------ * Musisz mieć zainstalowane następujące narzędzia: * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) * [Golang](https://go.dev/doc/install) wersja 1.13+ * [Docker](https://docs.docker.com/engine/installation/) * [etcd](https://github.com/coreos/etcd/) * [make](https://www.gnu.org/software/make/) * [kompilator/linker gcc](https://gcc.gnu.org/) * Twoja zmienna środowiskowa `GOPATH` musi być ustawiona, a lokalizacja `etcd` musi znajdować się w zmiennej środowiskowej `PATH`. * Musisz wiedzieć, jak utworzyć pull requesta do repozytorium GitHub. Zwykle obejmuje to utworzenie forka tego repozytorium. Aby uzyskać więcej informacji, zobacz [Tworzenie pull requesta](https://help.github.com/articles/creating-a-pull-request/) oraz [Standardowy proces fork i pull request w GitHub](https://gist.github.com/Chaser324/ce0505fbed06b947d962) . Ogólny zarys[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#the-big-picture) --------------------------------------------------------------------------------------------------- Materiały źródłowe dla API Kubernetesa oraz komponentów `kube-*`, takich jak `kube-apiserver`, `kube-controller-manager`, są automatycznie generowane z kodu źródłowego w [głównym repozytorium Kubernetes](https://github.com/kubernetes/kubernetes/) . Kiedy zauważysz błędy w wygenerowanej dokumentacji, możesz rozważyć stworzenie poprawki, aby naprawić je w projekcie źródłowym. Sklonuj repozytorium Kubernetesa[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#clone-the-kubernetes-repository) --------------------------------------------------------------------------------------------------------------------------------------- Jeśli nie posiadasz jeszcze repozytorium kubernetes/kubernetes, pobierz je teraz: mkdir $GOPATH/src cd $GOPATH/src go get github.com/kubernetes/kubernetes Określ katalog bazowy swojej kopii repozytorium [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) . Na przykład, jeśli wykonywano wcześniejszy krok w celu pobrania tego repozytorium, to twój katalog bazowy to `$GOPATH/src/github.com/kubernetes/kubernetes`. Pozostałe kroki odnoszą się do twojego katalogu bazowego jako ``. Określ katalog główny swojego klonu repozytorium [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) . Na przykład, jeśli wykonałeś wcześniejszy krok, aby pobrać repozytorium, twój katalog główny to `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`. Pozostałe kroki odnoszą się do twojego katalogu głównego jako ``. Edytowanie kodu źródłowego Kubernetesa[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#edit-the-kubernetes-source-code) --------------------------------------------------------------------------------------------------------------------------------------------- Dokumentacja materiałów źródłowych API Kubernetesa jest automatycznie generowana z specyfikacji OpenAPI, która jest tworzona na podstawie kodu źródłowego Kubernetesa. Jeśli chcesz zmienić dokumentację materiałów źródłowych API, pierwszym krokiem jest zmiana w kodzie źródłowym Kubernetesa. Dokumentacja dla komponentów `kube-*` jest także generowana z oryginalnego kodu źródłowego. Musisz zmienić kod związany z komponentem, który chcesz naprawić, aby naprawić generowaną dokumentację. ### Wprowadź zmiany do kodu źródłowego w repozytorium głównym[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#make-changes-to-the-upstream-source-code) #### Informacja: Poniższe kroki są przykładowe, nie stanowią ogólnej procedury. Szczegóły w Twojej sytuacji będą się różnić. Oto przykład edytowania komentarza w kodzie źródłowym Kubernetesa. W swoim lokalnym repozytorium kubernetes/kubernetes, przełącz się na domyślną gałąź i upewnij się, że jest aktualna: cd git checkout master git pull https://github.com/kubernetes/kubernetes master Przypuśćmy, że ten plik źródłowy w tej domyślnej gałęzi zawiera literówkę "atmost": [kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/apps/v1/types.go) W swoim lokalnym środowisku otwórz plik `types.go` i zmień "atmost" na "at most". Zweryfikuj, czy zmieniłeś plik: git status Wynik pokazuje, że znajdujesz się na gałęzi głównej, a plik źródłowy `types.go` został zmodyfikowany: On branch master ... modified: staging/src/k8s.io/api/apps/v1/types.go ### Zatwierdź swój edytowany plik[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#commit-your-edited-file) Uruchom `git add` i `git commit`, aby zatwierdzić zmiany, które do tej pory wprowadziłeś. W kolejnym kroku wykonasz drugi commit. Ważne jest, aby utrzymać zmiany rozdzielone na dwa commity. ### Generowanie specyfikacji OpenAPI i powiązanych plików[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#generate-the-openapi-spec-and-related-files) Przejdź do `` i uruchom te skrypty: ./hack/update-codegen.sh ./hack/update-openapi-spec.sh Uruchom `git status`, aby zobaczyć, co zostało wygenerowane. On branch master ... modified: api/openapi-spec/swagger.json modified: api/openapi-spec/v3/apis__apps__v1_openapi.json modified: pkg/generated/openapi/zz_generated.openapi.go modified: staging/src/k8s.io/api/apps/v1/generated.proto modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go Sprawdź zawartość pliku `api/openapi-spec/swagger.json`, aby upewnić się, że literówka została poprawiona. Na przykład, możesz uruchomić `git diff -a api/openapi-spec/swagger.json`. Jest to ważne, ponieważ `swagger.json` jest wejściem do drugiego etapu procesu generowania materiałów źródłowych. Uruchom `git add` i `git commit`, aby zatwierdzić swoje zmiany. Teraz masz dwa commity: jeden, który zawiera edytowany plik `types.go`, oraz drugi, który zawiera wygenerowaną specyfikację OpenAPI i powiązane pliki. Zachowaj te dwa commity oddzielnie. To znaczy, nie łącz tych commitów. Prześlij swoje zmiany jako [pull request](https://help.github.com/articles/creating-a-pull-request/) do gałęzi master w repozytorium [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) . Monitoruj swój pull request (PR) i odpowiadaj na uwagi recenzentów w miarę potrzeby. Kontynuuj monitorowanie swojego PR, aż zostanie ono scalone. [PR 57758](https://github.com/kubernetes/kubernetes/pull/57758) jest przykładem pull requesta, który naprawia literówkę w kodzie źródłowym Kubernetesa. #### Informacja: Określenie właściwego pliku źródłowego do zmiany może być skomplikowane. W podanym przykładzie, główny plik źródłowy znajduje się w katalogu `staging` w repozytorium `kubernetes/kubernetes`. Jednak w Twojej sytuacji katalog `staging` może nie być właściwym miejscem do jego znalezienia. Aby uzyskać wskazówki, sprawdź pliki `README` w repozytorium [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/tree/master/staging) oraz w powiązanych repozytoriach, takich jak [kubernetes/apiserver](https://github.com/kubernetes/apiserver/blob/master/README.md) . ### Zrób cherry pick swojego commita do gałęzi wydania[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#cherry-pick-your-commit-into-a-release-branch) W poprzednim rozdziale edytowałeś plik w głównej gałęzi (master branch) i uruchomiłeś skrypty, aby wygenerować specyfikację OpenAPI oraz powiązane pliki. Następnie przesłałeś swoje zmiany w PR (ang. pull request) do głównej gałęzi repozytorium kubernetes/kubernetes. Teraz załóżmy, że chcesz wprowadzić swoją zmianę także do gałęzi wydania (release branch). Na przykład, załóżmy, że główna gałąź jest używana do opracowywania wersji Kubernetesa 1.35, a Ty chcesz wprowadzić swoją zmianę również do gałęzi release-1.34. Przypomnij sobie, że twój pull request zawiera dwa commity: jeden dla edycji `types.go` i jeden dla plików wygenerowanych przez skrypty. Następnym krokiem jest zaproponowanie cherry pick twojego pierwszego commita do gałęzi release-1.34. Chodzi o to, aby cherry pickować commit, który edytował `types.go`, ale nie commit, który zawiera wyniki uruchomienia skryptów. Instrukcje znajdziesz w [Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md) . #### Informacja: Propozycja cherry pick wymaga posiadania uprawnienia do ustawienia etykiety i kamienia milowego w swoim PR (ang. pull request). Jeśli nie masz tych uprawnień, będziesz musiał współpracować z kimś, kto może ustawić etykietę i kamień milowy za Ciebie. Kiedy masz w toku swój pull request dla zastosowania cherry picka ze swoim jednym commitem do gałęzi release-1.34, kolejnym krokiem jest uruchomienie tych skryptów w gałęzi release-1.34 w swoim lokalnym środowisku. ./hack/update-codegen.sh ./hack/update-openapi-spec.sh Teraz dodaj commit do swojego pull requesta związanego z cherry pickiem, który zawiera niedawno wygenerowaną specyfikację OpenAPI i powiązane pliki. Monitoruj swojego pull requesta, aż zostanie scalony z gałęzią release-1.34. W tym momencie zarówno gałąź master, jak i gałąź release-1.34 mają zaktualizowany plik `types.go` oraz zestaw wygenerowanych plików, które odzwierciedlają zmiany wprowadzone do `types.go`. Należy zauważyć, że wygenerowana specyfikacja OpenAPI i inne wygenerowane pliki w gałęzi release-1.34 niekoniecznie są takie same jak wygenerowane pliki w gałęzi master. Wygenerowane pliki w gałęzi release-1.34 zawierają elementy API wyłącznie z Kubernetesa 1.34. Wygenerowane pliki w gałęzi master mogą zawierać elementy API, które nie znajdują się w 1.34, ale są w trakcie rozwoju dla 1.35. Generowanie opublikowanych materiałów źródłowych[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#generate-the-published-reference-docs) ------------------------------------------------------------------------------------------------------------------------------------------------------------- Poprzednia sekcja pokazała, jak edytować plik źródłowy, a następnie generować kilka plików, w tym `api/openapi-spec/swagger.json` w repozytorium `kubernetes/kubernetes`. Plik `swagger.json` to plik definicji OpenAPI używany do generowania materiałów źródłowych API. Jesteś teraz gotowy do zapoznania się z przewodnikiem [generowania materiałów źródłowych dla API Kubernetesa](https://kubernetes.io/docs/contribute/generate-ref-docs/kubernetes-api/) , aby wygenerować [opublikowane materiały źródłowe API Kubernetesa](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/) . Co dalej?[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#co-dalej) ----------------------------------------------------------------------------------------- * [Generowanie materiałów źródłowych dla API Kubernetesa](https://kubernetes.io/docs/contribute/generate-ref-docs/kubernetes-api/) * [Generowanie materiałów źródłowych dla komponentów i narzędzi Kubernetesa](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generowanie materiałów źródłowych dla poleceń `kubectl`](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/kubectl/) 2 - Generowanie materiałów źródłowych dla polecenia kubectl[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-03de26b330a5cfdb26672f6bc75dcc04) ====================================================================================================================================================================== Ta strona pokazuje, jak wygenerować materiały źródłowe polecenia `kubectl`. #### Informacja: Ten temat pokazuje, jak wygenerować materiały źródłowe dla [poleceń kubectl](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands) takich jak [kubectl apply](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) i [kubectl taint](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#taint) . Ten temat nie pokazuje, jak wygenerować stronę materiałów źródłowych opcji [kubectl](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/) . Aby uzyskać instrukcje dotyczące generowania strony materiałów źródłowych opcji kubectl, zobacz [Generowanie stron materiałów źródłowych dla komponentów i narzędzi Kubernetesa](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/kubernetes-components/) . Zanim zaczniesz[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#zanim-zaczniesz) ------------------------------------------------------------------------------------------------------ ### Wymagania:[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#requirements) * Potrzebujesz maszyny z systemem operacyjnym Linux lub macOS. * Musisz mieć zainstalowane następujące narzędzia: * [Python](https://www.python.org/downloads/) w wersji 3.7.x+ * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - Dokumentacja opisuje, jak zainstalować i rozpocząć pracę z systemem kontroli wersji `Git`. * [Golang](https://go.dev/dl/) wersja 1.13+ * [Pip](https://pypi.org/project/pip/) używany do instalacji PyYAML * [PyYAML](https://pyyaml.org/) w wersji 5.1.2 * [make](https://www.gnu.org/software/make/) * [gcc compiler/linker](https://gcc.gnu.org/) * [Docker](https://docs.docker.com/engine/installation/) (Wymagany tylko do odniesień do poleceń `kubectl`) * Twoja zmienna środowiskowa `PATH` musi zawierać wymagane narzędzia do budowania, takie jak binaria `Go` i `python`. * Musisz wiedzieć, jak utworzyć pull requesta do repozytorium na GitHubie. Wymaga to utworzenia własnego forka repozytorium. Aby uzyskać więcej informacji, zobacz [Praca z lokalnej kopii](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#fork-the-repo) . Skonfiguruj lokalne repozytoria[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#set-up-the-local-repositories) ------------------------------------------------------------------------------------------------------------------------------------ Utwórz lokalną przestrzeń roboczą i ustaw swoje `GOPATH`: mkdir -p $HOME/ export GOPATH=$HOME/ Utwórz lokalną kopię następujących repozytoriów: go get -u github.com/spf13/pflag go get -u github.com/spf13/cobra go get -u gopkg.in/yaml.v2 go get -u github.com/kubernetes-sigs/reference-docs Jeśli nie masz jeszcze repozytorium kubernetes/website, pobierz je teraz: git clone https://github.com//website $GOPATH/src/github.com//website Zrób klon repozytorium kubernetes/kubernetes jako k8s.io/kubernetes: git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes Usuń pakiet spf13 z `$GOPATH/src/k8s.io/kubernetes/vendor/github.com`: rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13 Repozytorium kubernetes/kubernetes dostarcza kod źródłowy `kubectl` oraz `kustomize`. * Określ katalog bazowy twojej kopii repozytorium [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) . Na przykład, jeśli postępowałeś zgodnie z poprzednim krokiem, aby pobrać repozytorium, twój katalog bazowy to `$GOPATH/src/k8s.io/kubernetes`. Kolejne kroki odwołują się do twojego katalogu bazowego jako ``. * Określ katalog bazowy klonu Twojego repozytorium [kubernetes/website](https://github.com/kubernetes/website) . Na przykład, jeśli wykonałeś poprzedni krok, aby pobrać repozytorium, Twoim katalogiem bazowym jest `$GOPATH/src/github.com//website`. Kolejne kroki odnoszą się do Twojego katalogu bazowego jako ``. * Określ katalog główny dla Twojej kopii repozytorium [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) . Na przykład, jeśli postępowałeś zgodnie z poprzednim krokiem, aby uzyskać repozytorium, Twoim katalogiem głównym będzie `$GOPATH/src/github.com/kubernetes-sigs/reference-docs`. Dalsze kroki odnoszą się do Twojego katalogu głównego jako ``. W swoim lokalnym repozytorium k8s.io/kubernetes przejdź do interesującej Cię gałęzi i upewnij się, że jest ona aktualna. Na przykład, jeśli chcesz wygenerować dokumentację dla Kubernetesa 1.34.0, możesz użyć tych poleceń: cd git checkout v1.34.0 git pull https://github.com/kubernetes/kubernetes 1.34.0 Jeśli nie musisz edytować kodu źródłowego `kubectl`, postępuj zgodnie z instrukcjami dotyczącymi [Ustawiania zmiennych kompilacji](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#set-build-variables) . Edytowanie kodu źródłowego kubectl[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#edit-the-kubectl-source-code) -------------------------------------------------------------------------------------------------------------------------------------- Materiały źródłowe polecenia kubectl są automatycznie generowana z kodu źródłowego kubectl. Jeśli chcesz zmienić materiały źródłowe, pierwszym krokiem jest zmiana jednego lub więcej komentarzy w kodzie źródłowym kubectl. Wprowadź zmianę w swoim lokalnym repozytorium kubernetes/kubernetes, a następnie zgłoś pull requesta do gałęzi master na [github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) . [PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) jest przykładem pull requesta, który poprawia literówkę w kodzie źródłowym kubectl. Monitoruj swój pull request (PR) i odpowiadaj na komentarze recenzentów. Kontynuuj monitorowanie swojego PR, aż zostanie scalony z docelową gałęzią w repozytorium kubernetes/kubernetes. Zrób cherry pick do gałęzi wydania[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#cherry-pick-your-change-into-a-release-branch) ------------------------------------------------------------------------------------------------------------------------------------------------------- Twoja zmiana znajduje się teraz w głównej gałęzi, która jest używana do rozwoju następnego wydania Kubernetesa. Jeśli chcesz, aby twoja zmiana pojawiła się w wersji dokumentacji Kubernetesa, która została już wydana, musisz zaproponować włączenie twojej zmiany do gałęzi wydania. Na przykład, załóżmy, że gałąź master jest używana do rozwijania Kubernetes 1.35 i chcesz przenieść swoją zmianę do gałęzi release-1.34. Aby uzyskać instrukcje, jak to zrobić, zobacz [Proponowanie Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md) . Monitoruj swój cherry pick pull request, aż zostanie scalone z gałęzią wydania. #### Informacja: Proponowanie cherry pick wymaga posiadania uprawnień do ustawiania etykiety oraz kamienia milowego w swoim pull requeście. Jeśli nie posiadasz tych uprawnień, będziesz musiał współpracować z kimś, kto może ustawić etykietę i kamień milowy za Ciebie. Ustaw zmienne budowania[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#set-build-variables) ------------------------------------------------------------------------------------------------------------------ Przejdź do ``. W swoim wierszu poleceń ustaw następujące zmienne środowiskowe. * Ustaw `K8S_ROOT` na ``. * Ustaw `K8S_WEBROOT` na ``. * Ustaw `K8S_RELEASE` na wersję dokumentacji, którą chcesz zbudować. Na przykład, jeśli chcesz zbudować dokumentację dla Kubernetesa 1.34, ustaw `K8S_RELEASE` na 1.34. Na przykład: export K8S_WEBROOT=$GOPATH/src/github.com//website export K8S_ROOT=$GOPATH/src/k8s.io/kubernetes export K8S_RELEASE=1.34 Tworzenie katalogu wersjonowanego[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#creating-a-versioned-directory) --------------------------------------------------------------------------------------------------------------------------------------- Uruchomienie budowania (ang. build target) `createversiondirs` tworzy katalog z wersjonowaniem i kopiuje pliki konfiguracyjne kubectl dotyczące materiałów źródłowych do tego katalogu. Nazwa katalogu z wersjonowaniem jest zgodna z wzorcem `v_`. W katalogu ``, uruchom następujący cel budowania: cd make createversiondirs Sprawdź tag wydania w k8s.io/kubernetes[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#check-out-a-release-tag-in-k8siokubernetes) --------------------------------------------------------------------------------------------------------------------------------------------------------- W swoim lokalnym repozytorium ``, przejdź do gałęzi, która zawiera wersję Kubernetesa, którą chcesz udokumentować. Na przykład, jeśli chcesz wygenerować dokumentację dla Kubernetesa 1.34.0, przejdź do tagu `v1.34`. Upewnij się, że Twoja lokalna gałąź jest aktualna. cd git checkout v1.34.0 git pull https://github.com/kubernetes/kubernetes v1.34.0 Uruchom kod generowania dokumentacji[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#run-the-doc-generation-code) --------------------------------------------------------------------------------------------------------------------------------------- W lokalnym katalogu ``, uruchom cel budowania (ang. build target) `copycli`. Komenda działa z uprawnieniami `root`: cd make copycli Polecenie `copycli` czyści tymczasowy katalog kompilacji, generuje pliki poleceń kubectl i kopiuje zbiorczą stronę HTML materiałów źródłowych poleceń kubectl oraz zasoby do ``. Zlokalizuj wygenerowane pliki[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#locate-the-generated-files) ------------------------------------------------------------------------------------------------------------------------------- Zweryfikuj, czy te dwa pliki zostały wygenerowane: [ -e "/gen-kubectldocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html" [ -e "/gen-kubectldocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" Zlokalizuj skopiowane pliki[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#locate-the-copied-files) -------------------------------------------------------------------------------------------------------------------------- Zweryfikuj, czy wszystkie wygenerowane pliki zostały skopiowane do Twojego ``: cd git status Wynik powinien zawierać zmodyfikowane pliki: static/docs/reference/generated/kubectl/kubectl-commands.html static/docs/reference/generated/kubectl/navData.js Wynik może również zawierać: static/docs/reference/generated/kubectl/scroll.js static/docs/reference/generated/kubectl/stylesheet.css static/docs/reference/generated/kubectl/tabvisibility.js static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-awesome.min.css Lokalne testowanie dokumentacji[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#locally-test-the-documentation) ------------------------------------------------------------------------------------------------------------------------------------- Zbuduj dokumentację Kubernetes w lokalnym ``. cd git submodule update --init --recursive --depth 1 # if not already done make container-serve Zobacz [podgląd lokalny](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/) . Dodaj i zatwierdź zmiany w kubernetes/website[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#add-and-commit-changes-in-kuberneteswebsite) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Uruchom `git add` i `git commit`, aby zatwierdzić pliki. Utwórz pull requesta[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#create-a-pull-request) ----------------------------------------------------------------------------------------------------------------- Utwórz pull requesta do repozytorium `kubernetes/website`. Monitoruj swój pull request i odpowiadaj na komentarze z przeglądu. Kontynuuj monitorowanie swojego pull requesta aż do momentu jego włączenia do głównej gałęzi kodu. Kilka minut po włączeniu twojego pull requesta, zaktualizowane tematy materiałów źródłowych będą widoczne w [opublikowanej dokumentacji](https://kubernetes.io/pl/docs/home/) . Co dalej?[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#co-dalej) ----------------------------------------------------------------------------------------- * [Szybki start generowania materiałów źródłowych](https://kubernetes.io/docs/contribute/generate-ref-docs/quickstart/) * [Generowanie materiałów źródłowych dla komponentów i narzędzi Kubernetesa](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generowanie materiałów źródłowych dla Kubernetes API](https://kubernetes.io/docs/contribute/generate-ref-docs/kubernetes-api/) 3 - Generowanie materiałów źródłowych dla metryk[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-7cf2686833318bffe2ef1b82e55748e7) =========================================================================================================================================================== Ta strona demonstruje generowanie materiałów źródłowych dotyczących metryk. Zanim zaczniesz[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#zanim-zaczniesz) ------------------------------------------------------------------------------------------------------ ### Wymagania:[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#requirements) * Potrzebujesz maszyny z systemem operacyjnym Linux lub macOS. * Musisz mieć zainstalowane następujące narzędzia: * [Python](https://www.python.org/downloads/) w wersji 3.7.x+ * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - Dokumentacja opisuje, jak zainstalować i rozpocząć pracę z systemem kontroli wersji `Git`. * [Golang](https://go.dev/dl/) wersja 1.13+ * [Pip](https://pypi.org/project/pip/) używany do instalacji PyYAML * [PyYAML](https://pyyaml.org/) w wersji 5.1.2 * [make](https://www.gnu.org/software/make/) * [gcc compiler/linker](https://gcc.gnu.org/) * [Docker](https://docs.docker.com/engine/installation/) (Wymagany tylko do odniesień do poleceń `kubectl`) * Twoja zmienna środowiskowa `PATH` musi zawierać wymagane narzędzia do budowania, takie jak binaria `Go` i `python`. * Musisz wiedzieć, jak utworzyć pull requesta do repozytorium na GitHubie. Wymaga to utworzenia własnego forka repozytorium. Aby uzyskać więcej informacji, zobacz [Praca z lokalnej kopii](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#fork-the-repo) . Sklonuj repozytorium Kubernetesa[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#clone-the-kubernetes-repository) --------------------------------------------------------------------------------------------------------------------------------------- Generowanie metryk odbywa się w repozytorium Kubernetesa. Aby sklonować repozytorium, przejdź do katalogu, w którym chcesz, aby klon istniał. Następnie wykonaj następujące polecenie: git clone https://www.github.com/kubernetes/kubernetes To tworzy folder `kubernetes` w bieżącym katalogu roboczym. Generowanie metryk[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#generate-the-metrics) -------------------------------------------------------------------------------------------------------------- W sklonowanym repozytorium Kubernetesa zlokalizuj katalog `test/instrumentation/documentation`. Dokumentacja metryk jest generowana w tym katalogu. Przy każdej wersji dodawane są nowe metryki. Po uruchomieniu skryptu generatora dokumentacji metryk, skopiuj dokumentację metryk na stronę internetową Kubernetesa i opublikuj zaktualizowaną dokumentację metryk. Aby wygenerować najnowsze metryki, upewnij się, że znajdujesz się w katalogu głównym sklonowanego katalogu Kubernetesa. Następnie wykonaj następujące polecenie: ./test/instrumentation/update-documentation.sh Aby sprawdzić zmiany, wykonaj: git status Wynik jest podobny do: ./test/instrumentation/documentation/documentation.md ./test/instrumentation/documentation/documentation-list.yaml Skopiuj wygenerowany plik dokumentacji metryk do repozytorium strony internetowej Kubernetesa[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#copy-the-generated-metrics-documentation-file-to-the-kubernetes-website-repository) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1. Ustaw zmienną środowiskową głównego katalogu strony Kubernetesa. Wykonaj następujące polecenie, aby ustawić główny katalog witryny: export WEBSITE_ROOT= 2. Skopiuj wygenerowany plik metryk do repozytorium witryny Kubernetesa. cp ./test/instrumentation/documentation/documentation.md "${WEBSITE_ROOT}/content/en/docs/reference/instrumentation/metrics.md" #### Informacja: Jeśli pojawi się błąd, sprawdź, czy masz uprawnienia do skopiowania pliku. Możesz użyć `chown`, aby zmienić własność pliku na swojego użytkownika. Utwórz pull requesta[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#create-a-pull-request) ----------------------------------------------------------------------------------------------------------------- Aby utworzyć pull request, postępuj zgodnie z instrukcjami w [Otwarcie pull requesta](https://kubernetes.io/docs/contribute/new-content/open-a-pr/) . Co dalej?[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#co-dalej) ----------------------------------------------------------------------------------------- * [Współpraca z głównym projektem](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/contribute-upstream/) * [Generowanie materiałów źródłowych dla komponentów i narzędzi Kubernetesa](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generowanie materiałów źródłowych dla poleceń kubectl](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/kubectl/) 4 - Generowanie materiałów źródłowych dla komponentów i narzedzi Kubernetesa[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-28fc50a0072b0b2b444aa24e552d2e60) ======================================================================================================================================================================================= Ta strona pokazuje, jak zbudować strony materiałów źródłowych komponentów i narzędzi Kubernetesa. Zanim zaczniesz[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#zanim-zaczniesz) ------------------------------------------------------------------------------------------------------ Rozpocznij od sekcji [wymagania wstępne](https://kubernetes.io/docs/contribute/generate-ref-docs/quickstart/#before-you-begin) w przewodniku "szybki start materiałów źródłowych" Postępuj zgodnie z [Szybki start](https://kubernetes.io/docs/contribute/generate-ref-docs/quickstart/) , aby wygenerować strony materiałów źródłowych dla komponentów i narzędzi Kubernetesa. Co dalej?[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#co-dalej) ----------------------------------------------------------------------------------------- * [Szybki start](https://kubernetes.io/docs/contribute/generate-ref-docs/quickstart/) * [Generowanie materiałów źródłowych dla poleceń kubectl](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/kubectl/) * [Generowanie materiałów źródłowych dla API Kubernetesa](https://kubernetes.io/docs/contribute/generate-ref-docs/kubernetes-api/) * [Wkład w kod źródłowy Kubernetesa](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/contribute-upstream/) 5 -[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#pg-eabe0c0c6b0046c51d7fdf5e8450a5b5) ============================================================================================================== ### Wymagania:[](https://kubernetes.io/pl/docs/contribute/generate-ref-docs/_print/#requirements) * Potrzebujesz maszyny z systemem operacyjnym Linux lub macOS. * Musisz mieć zainstalowane następujące narzędzia: * [Python](https://www.python.org/downloads/) w wersji 3.7.x+ * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - Dokumentacja opisuje, jak zainstalować i rozpocząć pracę z systemem kontroli wersji `Git`. * [Golang](https://go.dev/dl/) wersja 1.13+ * [Pip](https://pypi.org/project/pip/) używany do instalacji PyYAML * [PyYAML](https://pyyaml.org/) w wersji 5.1.2 * [make](https://www.gnu.org/software/make/) * [gcc compiler/linker](https://gcc.gnu.org/) * [Docker](https://docs.docker.com/engine/installation/) (Wymagany tylko do odniesień do poleceń `kubectl`) * Twoja zmienna środowiskowa `PATH` musi zawierać wymagane narzędzia do budowania, takie jak binaria `Go` i `python`. * Musisz wiedzieć, jak utworzyć pull requesta do repozytorium na GitHubie. Wymaga to utworzenia własnego forka repozytorium. Aby uzyskać więcej informacji, zobacz [Praca z lokalnej kopii](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#fork-the-repo) . --- # अन्य उपकरण | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/hi/docs/reference/tools/_print/#) . [Return to the regular view of this page](https://kubernetes.io/hi/docs/reference/tools/) . अन्य उपकरण ========== कुबेरनेट्स सिस्टम के साथ काम करने में आपकी सहायता के लिए कुबेरनेट्स में कई उपकरण शामिल हैं। crictl[](https://kubernetes.io/hi/docs/reference/tools/_print/#crictl) ----------------------------------------------------------------------- [`crictl`](https://github.com/kubernetes-sigs/cri-tools) [CRI](https://kubernetes.io/hi/docs/concepts/overview/components/#container-runtime) \-संगत कंटेनर रनटाइम के निरीक्षण और डिबगिंग के लिए एक कमांड-लाइन इंटरफ़ेस है। Dashboard[](https://kubernetes.io/hi/docs/reference/tools/_print/#dashboard) ----------------------------------------------------------------------------- कुबेरनेट्स का वेब [`डैशबोर्ड`](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) आपको क्लस्टर में कंटेनरीकृत अनुप्रयोगों को तैनात करने, उनकी समस्या का निवारण करने और क्लस्टर के संसाधनों को प्रबंधित करने की अनुमति देता है। Helm[](https://kubernetes.io/hi/docs/reference/tools/_print/#helm) ------------------------------------------------------------------- 🛇 यह वस्तु कोई अन्य पक्ष की परियोजना या उत्पाद से जुड़ा है जो कुबेरनेट्स का हिस्सा नहीं हैं। [अधिक जानकारी के लिए पढ़ें](https://kubernetes.io/hi/docs/reference/tools/_print/#third-party-content-disclaimer) [हेल्म](https://helm.sh/) पूर्व-कॉन्फ़िगर कुबेरनेट्स संसाधनों के पैकेजों के प्रबंधन के लिए एक उपकरण है। इन पैकेजों को _हेल्म चार्ट_ के रूप में जाना जाता है। हेल्म का उपयोग करें: * कुबेरनेट्स चार्ट के रूप में पैक किए गए लोकप्रिय सॉफ़्टवेयर को ढूंढें और उपयोग करें। * अपने ख़ुद के एप्लिकेशन को कुबेरनेट्स चार्ट के रूप में साझा करें। * बुद्धिमत्ता से अपने कुबेरनेट्स मैनिफ़ेस्ट फ़ाइलों को प्रबंधित करें। * हेल्म पैकेजों के रिलीज़ प्रबंधित करें। Kompose[](https://kubernetes.io/hi/docs/reference/tools/_print/#kompose) ------------------------------------------------------------------------- [`कॉम्पोज़`](https://github.com/kubernetes/kompose) एक उपकरण है, जो डॉकर कंपोज़ उपयोगकर्ताओं को कुबेरनेट्स पर जाने में मदद करता है। कॉम्पोज़ का उपयोग करें: * डॉकर कंपोज़ फ़ाइल को कुबेरनेट्स ऑब्जेक्ट्स में अनुवाद करें। * स्थानीय डॉकर डेवलपमेंट से कुबेरनेट्स एप्लीकेशनों को प्रबंधित करें। * v1 या v2 डॉकर कंपोज़, `yaml` फ़ाइलों या [डिस्ट्रीब्यूटेड एप्लिकेशनो के बंडलों](https://docs.docker.com/compose/bundles/) के माध्यम से अपने एप्लिकेशन को प्रबंधित कऱे। Kui[](https://kubernetes.io/hi/docs/reference/tools/_print/#kui) ----------------------------------------------------------------- [`Kui`](https://github.com/kubernetes-sigs/kui) एक GUI उपकरण है, जो आपके सामान्य `kubectl` कमांड लाइन अनुरोधों को लेकर ग्राफिक्स के साथ प्रतिक्रिया देता है। Kui सामान्य `kubectl` कमांड लाइन अनुरोधों को लेकर ग्राफिक्स के साथ प्रतिक्रिया देता है। ASCII टेबल्स के बजाय, Kui उन टेबल्स के साथ एक GUI प्रदान करता है, जिन्हें आप सॉर्ट कर सकते हैं। Kui आपको देता है: * कॉपी और पेस्ट करने के बजाय सीधे लंबे स्वचालित रूप से जेनरेटेड किए गए संसाधनों के नामों पर क्लिक करें। * `Kubectl` कमांड टाइप करें और उन्हें निष्पादन होते हुए देखें, यहां तक कि कभी-कभी `Kubectl` से भी तेज। * एक [जॉब](https://kubernetes.io/hi/docs/concepts/workloads/controllers/job/) क्वेरी करें और इसके निष्पादन को वॉटरफॉल के डायग्राम के रूप में देखें। * एक टैब्ड UI का उपयोग करके अपने क्लस्टर में संसाधनों पर क्लिक करें। Minikube[](https://kubernetes.io/hi/docs/reference/tools/_print/#minikube) --------------------------------------------------------------------------- [`मिनीक्यूब`](https://minikube.sigs.k8s.io/docs/) एक उपकरण है, जो डेवलपमेंट और परीक्षण जैसे उद्देश्यों के लिए आपके वर्कस्टेशन पर स्थानीय रूप से एक-नोड वाले कुबेरनेट्स क्लस्टर को चलाता है। --- # Pojęcia | Kubernetes To wielostronicowy widok tej sekcji do wydrukowania. [Kliknij aby wydrukować](https://kubernetes.io/pl/docs/concepts/_print/#) . [Wróć do zwykłego widoku tej strony](https://kubernetes.io/pl/docs/concepts/) . Pojęcia ======= * 1: [Przegląd](https://kubernetes.io/pl/docs/concepts/_print/#pg-0554ac387412eaf4e6e89b2f847dacde) * 1.1: [Składniki Kubernetesa](https://kubernetes.io/pl/docs/concepts/_print/#pg-13b0f1dbe89228e3d76d2ac231e245f1) * 1.2: [Objekty w Kubernetesie](https://kubernetes.io/pl/docs/concepts/_print/#pg-110f33530cf761140cb1dab536baef04) * 1.2.1: [Nazwy i identyfikatory objektów](https://kubernetes.io/pl/docs/concepts/_print/#pg-f37749a83c2916b63279ea60f3cfe53e) * 1.2.2: [Etykiety i selektory](https://kubernetes.io/pl/docs/concepts/_print/#pg-f1dec4557fb8ffbac9f11390aaaf9fa4) * 1.2.3: [Przestrzenie nazw (ang. Namespaces)](https://kubernetes.io/pl/docs/concepts/_print/#pg-1127165f472b7181b9c1d5a0b187d620) * 1.2.4: [Adnotatcje](https://kubernetes.io/pl/docs/concepts/_print/#pg-93cd7a1d4e1623e2bf01afc49a5af69c) * 1.2.5: [Selektory pól](https://kubernetes.io/pl/docs/concepts/_print/#pg-046c03090d47bc4b89b818dc645c3865) * 1.2.6: [Zalecane etykiety](https://kubernetes.io/pl/docs/concepts/_print/#pg-5dd62c6a4a481b4cf1ac50f6799eb581) * 1.3: [API Kubernetesa](https://kubernetes.io/pl/docs/concepts/_print/#pg-0c745f42e623d2b70a53bc0e6db73d95) * 2: [Architektura klastra](https://kubernetes.io/pl/docs/concepts/_print/#pg-2bf36ccd6b3dbeafecf87c39761b07c7) * 3: [Kontenery](https://kubernetes.io/pl/docs/concepts/_print/#pg-a5f7383c83ab9eb9cd0e3c4c020b3ae6) * 4: [Workload](https://kubernetes.io/pl/docs/concepts/_print/#pg-d52aadda80edd9f8c514cfe2321363c2) * 4.1: [Pod](https://kubernetes.io/pl/docs/concepts/_print/#pg-4d68b0ccf9c683e6368ffdcc40c838d4) * 4.2: [Zarządzanie Workloadem](https://kubernetes.io/pl/docs/concepts/_print/#pg-89637410cacae45a36ab1cc278c482eb) * 5: [Usługi, równoważenie obciążenia i sieci w Kubernetesie](https://kubernetes.io/pl/docs/concepts/_print/#pg-0a0a7eca3e302a3c08f8c85e15d337fd) * 6: [Przechowywanie danych](https://kubernetes.io/pl/docs/concepts/_print/#pg-f018f568c6723865753f150c3c59bdda) * 7: [Konfiguracja](https://kubernetes.io/pl/docs/concepts/_print/#pg-275bea454e1cf4c5adeca4058b5af988) * 8: [Bezpieczeństwo](https://kubernetes.io/pl/docs/concepts/_print/#pg-712cb3c03ff14a39e5a83a6d9b71d203) * 9: [Polityki](https://kubernetes.io/pl/docs/concepts/_print/#pg-ac9161c6d952925b083ad9602b4e8e7f) * 10: [Harmonogramowanie, pierszeństwo i eksmisja](https://kubernetes.io/pl/docs/concepts/_print/#pg-c21d05f31057c5bcd2ebdd01f4e62a0e) * 11: [Administracja klastrem](https://kubernetes.io/pl/docs/concepts/_print/#pg-285a3785fd3d20f437c28d87ca4dadca) * 12: [Windows w Kubernetesie](https://kubernetes.io/pl/docs/concepts/_print/#pg-05a1231ecbfe48ec554e6d078818aca4) * 13: [Rozszerzanie Kubernetesa](https://kubernetes.io/pl/docs/concepts/_print/#pg-7e0d97616b15e2c383c6a0a96ec442cb) * 13.1: [Rozszerzanie API Kubernetesa](https://kubernetes.io/pl/docs/concepts/_print/#pg-0af41d3bd7c785621b58b7564793396a) * 13.2: [Rozszerzenia obliczeniowe, przechowywania danych i sieciowe](https://kubernetes.io/pl/docs/concepts/_print/#pg-c8937cdc9df96f3328becf04f8211292) Rozdział dotyczący pojęć ma za zadanie pomóc w zrozumieniu poszczególnych składowych systemu oraz obiektów abstrakcyjnych, których Kubernetes używa do reprezentacji [klastra](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-cluster) , a także posłużyć do lepszego poznania działania całego systemu. 1 - Przegląd[](https://kubernetes.io/pl/docs/concepts/_print/#pg-0554ac387412eaf4e6e89b2f847dacde) =================================================================================================== Kubernetes to przenośna, rozszerzalna platforma oprogramowania _open source_ służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach. Umożliwia ich deklaratywną konfigurację i automatyzację. Kubernetes posiada duży i dynamicznie rozwijający się ekosystem. Szeroko dostępne są usługi, wsparcie i dodatkowe narzędzia. Na tej stronie znajdziesz ogólne informacje o Kubernetesie. Nazwa Kubernetes pochodzi z języka greckiego i oznacza sternika albo pilota. Skrót K8s powstał poprzez zastąpienie ośmiu liter pomiędzy "K" i "s". Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność. Do czego potrzebujesz Kubernetesa i jakie są jego możliwości[](https://kubernetes.io/pl/docs/concepts/_print/#why-you-need-kubernetes-and-what-can-it-do) ---------------------------------------------------------------------------------------------------------------------------------------------------------- Kontenery są dobrą metodą na opakowywanie i uruchamianie aplikacji. W środowisku produkcyjnym musisz zarządzać kontenerami, w których działają aplikacje i pilnować, aby nie było żadnych przerw w ich dostępności. Przykładowo, kiedy jeden z kontenerów przestaje działać, musi zostać wymieniony. Nie byłoby prościej, aby takimi działaniami zajmował się jakiś system? I tu właśnie przychodzi z pomocą Kubernetes! Kubernetes zapewnia środowisko do uruchamiania systemów rozproszonych o wysokiej niezawodności. Kubernetes obsługuje skalowanie aplikacji, przełączanie w sytuacjach awaryjnych, różne scenariusze wdrożeń itp. Przykładowo, Kubernetes w łatwy sposób może zarządzać wdrożeniem nowej wersji oprogramowania zgodnie z metodyką _canary deployments_. Kubernetes zapewnia: * **Detekcję nowych serwisów i balansowanie ruchu** Kubernetes może udostępnić kontener używając nazwy DNS lub swojego własnego adresu IP. Jeśli ruch przychodzący do kontenera jest duży, Kubernetes może balansować obciążenie i przekierować ruch sieciowy, aby zapewnić stabilność całej instalacji. * **Zarządzanie obsługą składowania danych** Kubernetes umożliwia automatyczne montowanie systemów składowania danych dowolnego typu - lokalnych, od dostawców chmurowych i innych. * **Automatyczne wdrożenia i wycofywanie zmian** Możesz opisać oczekiwany stan instalacji za pomocą Kubernetesa, który zajmie się doprowadzeniem w sposób kontrolowany stanu faktycznego do stanu oczekiwanego. Przykładowo, przy pomocy Kubernetesa możesz zautomatyzować proces tworzenia nowych kontenerów na potrzeby swojego wdrożenia, usuwania istniejących i przejęcia zasobów przez nowe kontenery. * **Automatyczne zarządzanie dostępnymi zasobami** Twoim zadaniem jest dostarczenie klastra maszyn, które Kubernetes może wykorzystać do uruchamiania zadań w kontenerach. Określasz zapotrzebowanie na moc procesora i pamięć RAM dla każdego z kontenerów. Kubernetes rozmieszcza kontenery na maszynach w taki sposób, aby jak najlepiej wykorzystać dostarczone zasoby. * **Samoczynne naprawianie** Kubernetes restartuje kontenery, które przestały działać, wymienia je na nowe, wymusza wyłączenie kontenerów, które nie odpowiadają na określone zapytania o stan i nie rozgłasza powiadomień o ich dostępności tak długo, dopóki nie są gotowe do działania. * **Zarządzanie informacjami poufnymi i konfiguracją** Kubernetes pozwala składować i zarządzać informacjami poufnymi, takimi jak hasła, tokeny OAuth czy klucze SSH. Informacje poufne i zawierające konfigurację aplikacji mogą być dostarczane i zmieniane bez konieczności ponownego budowania obrazu kontenerów i bez ujawniania poufnych danych w ogólnej konfiguracji oprogramowania. * **Wykonywanie wsadowe** Oprócz usług Kubernetes może zarządzać zadaniami wsadowymi i obciążeniami CI, automatycznie wymieniając kontenery, które ulegną awarii. * **Skalowanie poziome** Skaluj swoją aplikację w górę i w dół za pomocą prostego polecenia, poprzez interfejs użytkownika lub automatycznie na podstawie zużycia CPU. * **Podwójny stos IPv4/IPv6** Przydzielanie adresów IPv4 i IPv6 do podów i usług * **Możliwość rozbudowy** Dodawaj funkcje do swojego klastra Kubernetesa bez konieczności zmiany kodu źródłowego w głównym repozytorium. Czym Kubernetes nie jest[](https://kubernetes.io/pl/docs/concepts/_print/#what-kubernetes-is-not) -------------------------------------------------------------------------------------------------- Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS _(Platform as a Service)_. Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania, wspólne dla innych rozwiązań PaaS, takie jak: instalacje _(deployments)_, skalowanie i balansowanie ruchu, umożliwiając użytkownikom integrację rozwiązań służących do logowania, monitoringu i ostrzegania. Co ważne, Kubernetes nie jest monolitem i domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki. Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska, ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne. Kubernetes: * Nie ogranicza typów aplikacji, które są obsługiwane. Celem Kubernetesa jest możliwość obsługi bardzo różnorodnego typu zadań, włączając w to aplikacje bezstanowe (_stateless_), aplikacje ze stanem (_stateful_) i ogólne przetwarzanie danych. Jeśli jakaś aplikacja może działać w kontenerze, będzie doskonale sobie radzić w środowisku Kubernetesa. * Nie oferuje wdrażania aplikacji wprost z kodu źródłowego i nie buduje aplikacji. Procesy Continuous Integration, Delivery, and Deployment (CI/CD) są zależne od kultury pracy organizacji, jej preferencji oraz wymagań technicznych. * Nie dostarcza serwisów z warstwy aplikacyjnej, takich jak warstwy pośrednie _middleware_ (np. broker wiadomości), środowiska analizy danych (np. Spark), bazy danych (np. MySQL), cache ani klastrowych systemów składowania danych (np. Ceph) jako usług wbudowanych. Te składniki mogą być uruchamiane na klastrze Kubernetes i udostępniane innym aplikacjom przez przenośne rozwiązania, takie jak [Open Service Broker](https://openservicebrokerapi.org/) . * Nie wymusza użycia konkretnych systemów zbierania logów, monitorowania ani ostrzegania. Niektóre z tych rozwiązań są udostępnione jako przykłady. Dostępne są też mechanizmy do gromadzenia i eksportowania różnych metryk. * Nie dostarcza, ani nie wymusza języka/systemu używanego do konfiguracji (np. Jsonnet). Udostępnia API typu deklaratywnego, z którego można korzystać za pomocą różnych metod wykorzystujących deklaratywne specyfikacje. * Nie zapewnia, ani nie wykorzystuje żadnego ogólnego systemu do zarządzania konfiguracją, utrzymaniem i samo-naprawianiem maszyn. * Co więcej, nie jest zwykłym systemem planowania _(orchestration)_. W rzeczywistości, eliminuje konieczność orkiestracji. Zgodnie z definicją techniczną, orkiestracja to wykonywanie określonego ciągu zadań: najpierw A, potem B i następnie C. Dla kontrastu, Kubernetes składa się z wielu niezależnych, możliwych do złożenia procesów sterujących, których zadaniem jest doprowadzenie stanu faktycznego do stanu oczekiwanego. Nie ma znaczenia, w jaki sposób przechodzi się od A do C. Nie ma konieczności scentralizowanego zarządzania. Dzięki temu otrzymujemy system, który jest potężniejszy, bardziej odporny i niezawodny i dający więcej możliwości rozbudowy. Trochę historii[](https://kubernetes.io/pl/docs/concepts/_print/#going-back-in-time) ------------------------------------------------------------------------------------- Aby zrozumieć, dlaczego Kubernetes stał się taki przydatny, cofnijmy sie trochę w czasie. ![Jak zmieniały sie metody wdrożeń](https://kubernetes.io/images/docs/Container_Evolution.svg) **Era wdrożeń tradycyjnych:** Na początku aplikacje uruchamiane były na fizycznych serwerach. Nie było możliwości separowania zasobów poszczególnych aplikacji, co prowadziło do problemów z alokacją zasobów. Przykładowo, kiedy wiele aplikacji jest uruchomionych na jednym fizycznym serwerze, część tych aplikacji może zużyć większość dostępnych zasobów, powodując spowolnienie działania innych. Rozwiązaniem tego problemu mogło być uruchamianie każdej aplikacji na osobnej maszynie. Niestety, takie podejście ograniczało skalowanie, ponieważ większość zasobów nie była w pełni wykorzystywana, a utrzymanie wielu fizycznych maszyn było kosztowne. **Era wdrożeń w środowiskach wirtualnych:** Jako rozwiązanie zaproponowano wirtualizację, która umożliwia uruchamianie wielu maszyn wirtualnych (VM) na jednym procesorze fizycznego serwera. Wirtualizacja pozwala izolować aplikacje pomiędzy maszynami wirtualnymi, zwiększając w ten sposób bezpieczeństwo, jako że informacje związane z jedną aplikacją nie są w łatwy sposób dostępne dla pozostałych. Wirtualizacja pozwala lepiej wykorzystywać zasoby fizycznego serwera i lepiej skalować, ponieważ aplikacje mogą być łatwo dodawane oraz aktualizowane, pozwala ograniczyć koszty sprzętu oraz ma wiele innych zalet. Za pomocą wirtualizacji można udostępnić wybrane zasoby fizyczne jako klaster maszyn wirtualnych "wielokrotnego użytku". Każda maszyna wirtualna jest pełną maszyną zawierającą własny system operacyjny pracujący na zwirtualizowanej warstwie sprzętowej. **Era wdrożeń w kontenerach:** Kontenery działają w sposób zbliżony do maszyn wirtualnych, ale mają mniejszy stopnień wzajemnej izolacji, współdzieląc ten sam system operacyjny. Kontenery określane są mianem "lekkich". Podobnie, jak maszyna wirtualna, kontener posiada własny system plików, udział w zasobach procesora, pamięć, przestrzeń procesów itd. Ponieważ kontenery są definiowane rozłącznie od leżących poniżej warstw infrastruktury, mogą być łatwiej przenoszone pomiędzy chmurami i różnymi dystrybucjami systemu operacyjnego. Kontenery zyskały popularność ze względu na swoje zalety, takie jak: * Szybkość i elastyczność w tworzeniu i instalacji aplikacji: obraz kontenera buduje się łatwiej niż obraz VM. * Ułatwienie ciągłego rozwoju, integracji oraz wdrażania aplikacji ( _Continuous development, integration, and deployment_): obrazy kontenerów mogą być budowane w sposób wiarygodny i częsty. W razie potrzeby, przywrócenie poprzedniej wersji aplikacji jest stosunkowo łatwie (ponieważ obrazy są niezmienne). * Rozdzielenie zadań _Dev_ i _Ops_: obrazy kontenerów powstają w fazie _build/release_, a nie w trakcie procesu instalacji, oddzielając w ten sposób aplikacje od infrastruktury. * Obserwowalność obejmuje nie tylko informacje i metryki z poziomu systemu operacyjnego, ale także poprawność działania samej aplikacji i inne sygnały. * Spójność środowiska na etapach rozwoju oprogramowania, testowania i działania w trybie produkcyjnym: działa w ten sam sposób na laptopie i w chmurze. * Możliwość przenoszenia pomiędzy systemami operacyjnymi i platformami chmurowymi: Ubuntu, RHEL, CoreOS, prywatnymi centrami danych, największymi dostawcami usług chmurowych czy gdziekolwiek indziej. * Zarządzanie, które w centrum uwagi ma aplikacje: Poziom abstrakcji przeniesiony jest z warstwy systemu operacyjnego działającego na maszynie wirtualnej na poziom działania aplikacji, która działa na systemie operacyjnym używając zasobów logicznych. * Luźno powiązane, rozproszone i elastyczne "swobodne" mikro serwisy: Aplikacje podzielone są na mniejsze, niezależne komponenty, które mogą być dynamicznie uruchamiane i zarządzane - nie jest to monolityczny system działający na jednej, dużej maszynie dedykowanej na wyłączność. * Izolacja zasobów: wydajność aplikacji możliwa do przewidzenia * Wykorzystanie zasobów: wysoka wydajność i upakowanie. Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej) --------------------------------------------------------------------- * Poczytaj o [komponentach Kubernetesa](https://kubernetes.io/pl/docs/concepts/overview/components/) * Poczytaj o [API Kubernetesa](https://kubernetes.io/pl/docs/concepts/overview/kubernetes-api/) * Poczytaj o [kubectl](https://kubernetes.io/docs/concepts/overview/kubectl/) - podstawowym narzędziu CLI dla Kubernetesa * Poczytaj o [architekturze klastra](https://kubernetes.io/pl/docs/concepts/architecture/) * Jesteś gotowy [zacząć pracę](https://kubernetes.io/pl/docs/setup/) ? 1.1 - Składniki Kubernetesa[](https://kubernetes.io/pl/docs/concepts/_print/#pg-13b0f1dbe89228e3d76d2ac231e245f1) ================================================================================================================== Omówienie głównych elementów tworzących klaster Kubernetesa. Ta strona zawiera wysokopoziomy przegląd niezbędnych komponentów, które tworzą klaster Kubernetesa. ![Komponenty Kubernetesa](https://kubernetes.io/images/docs/components-of-kubernetes.svg) Komponenty klastra Kubernetesa Składniki Kubernetesa[](https://kubernetes.io/pl/docs/concepts/_print/#core-components) ---------------------------------------------------------------------------------------- Klaster Kubernetesa składa się z warstwy sterowania oraz jednego lub więcej węzłów roboczych. Oto krótki przegląd głównych komponentów: ### Części składowe warstwy sterowania[](https://kubernetes.io/pl/docs/concepts/_print/#control-plane-components) Zarządzanie ogólnym stanem klastra: [kube-apiserver](https://kubernetes.io/pl/docs/concepts/architecture/#kube-apiserver) Podstawowy komponent udostępniający interfejs API Kubernetesa przez HTTP. [etcd](https://kubernetes.io/pl/docs/concepts/architecture/#etcd) Stabilna i wysoko dostępna baza danych typu klucz-wartość, wykorzystywana do przechowywania stanu całego klastra Kubernetesa. [kube-scheduler](https://kubernetes.io/pl/docs/concepts/architecture/#kube-scheduler) Wyszukuje Pody, które nie zostały jeszcze przypisane do węzła, i przydziela każdy Pod do odpowiedniego węzła. [kube-controller-manager](https://kubernetes.io/pl/docs/concepts/architecture/#kube-controller-manager) Uruchamia [kontrolery](https://kubernetes.io/pl/docs/concepts/architecture/controller/) realizujące logikę działania API Kubernetesa. [cloud-controller-manager](https://kubernetes.io/pl/docs/concepts/architecture/#cloud-controller-manager) (opcjonalne) Zapewnia integrację klastra Kubernetesa z infrastrukturą dostarczaną przez zewnętrznych dostawców chmurowych. ### Składniki węzłów[](https://kubernetes.io/pl/docs/concepts/_print/#node-components) Działa na każdym węźle klastra, odpowiada za utrzymanie aktywnych podów oraz zapewnienie środowiska uruchomieniowego Kubernetesa: [kubelet](https://kubernetes.io/pl/docs/concepts/architecture/#kubelet) Odpowiada za nadzorowanie, czy pody oraz ich kontenery są uruchomione i działają zgodnie z oczekiwaniami. [kube-proxy](https://kubernetes.io/pl/docs/concepts/architecture/#kube-proxy) (opcjonalne) Utrzymuje reguły sieciowe na węzłach w celu obsługi komunikacji z [usługami (ang. Service)](https://kubernetes.io/pl/docs/concepts/services-networking/service/) . [Środowisko uruchomieniowe kontenerów](https://kubernetes.io/pl/docs/concepts/architecture/#container-runtime) Oprogramowanie odpowiedzialne za uruchamianie kontenerów. Przeczytaj [Środowiska uruchomieniowe kontenerów](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) , aby dowiedzieć się więcej. 🛇 Ta pozycja przekierowuje do projektu lub produktu, który nie jest częścią projektu Kubernetes. [Więcej informacji](https://kubernetes.io/pl/docs/concepts/_print/#third-party-content-disclaimer) Klaster może wymagać dodatkowego oprogramowania na każdym węźle; możesz na przykład uruchomić [systemd](https://systemd.io/) na węzłach z systemem Linux do monitorowania i zarządzania lokalnymi usługami. Dodatki (Addons)[](https://kubernetes.io/pl/docs/concepts/_print/#addons) -------------------------------------------------------------------------- Dodatki rozszerzają funkcjonalność Kubernetesa. Oto kilka ważnych przykładów: [DNS](https://kubernetes.io/pl/docs/concepts/architecture/#dns) Umożliwia rozpoznawanie nazw DNS dla usług i komponentów działających w całym klastrze. [Web UI](https://kubernetes.io/pl/docs/concepts/architecture/#web-ui-dashboard) (Dashboard) Umożliwia zarządzanie klastrem Kubernetesa poprzez webowy interfejs. [Monitorowanie zasobów kontenera](https://kubernetes.io/pl/docs/concepts/architecture/#container-resource-monitoring) Służy do monitorowania zasobów kontenerów poprzez gromadzenie i zapisywanie danych o ich wydajności. [Logowanie na poziomie klastra](https://kubernetes.io/pl/docs/concepts/architecture/#cluster-level-logging) Umożliwia zbieranie i przechowywanie logów z kontenerów w centralnym systemie logowania dostępnym na poziomie całego klastra. Elastyczność architektury[](https://kubernetes.io/pl/docs/concepts/_print/#flexibility-in-architecture) -------------------------------------------------------------------------------------------------------- Dzięki elastycznej architekturze Kubernetesa można dostosować sposób wdrażania i zarządzania poszczególnymi komponentami do konkretnych wymagań - od prostych klastrów deweloperskich po złożone systemy produkcyjne na dużą skalę. Szczegółowe informacje o każdym komponencie oraz różnych sposobach konfiguracji architektury klastra znajdziesz na stronie [Architektura klastra](https://kubernetes.io/pl/docs/concepts/architecture/) . 1.2 - Objekty w Kubernetesie[](https://kubernetes.io/pl/docs/concepts/_print/#pg-110f33530cf761140cb1dab536baef04) =================================================================================================================== Obiekty Kubernetesa to trwałe jednostki w systemie Kubernetes. Służą one do odwzorowania stanu klastra. Poznaj, czym jest model obiektów Kubernetesa i jak z nimi pracować. Ta strona wyjaśnia, jak obiekty Kubernetesa są reprezentowane w API Kubernetesa oraz jak można je wyrazić w formacie `.yaml`. Czym są obiekty Kubernetesa[](https://kubernetes.io/pl/docs/concepts/_print/#kubernetes-objects) ------------------------------------------------------------------------------------------------- _Obiekty Kubernetesa_ to trwałe byty w systemie Kubernetes. Kubernetes wykorzystuje te byty do reprezentowania stanu klastra. Konkretne zastosowania to m.in.: * Jakie aplikacje kontenerowe są uruchomione (i na których węzłach) * Zasoby dostępne dla tych aplikacji * Polityki dotyczące zachowania tych aplikacji, takie jak polityki restartu, aktualizacje i tolerancja na błędy Obiekt Kubernetesa to "zapis zamiaru" - gdy go utworzysz, Kubernetes będzie stale pilnować, aby taki obiekt faktycznie istniał. Tworząc obiekt, efektywnie informujesz Kubernetesa, jak ma wyglądać workload klastra; to jest _pożądany stan_ twojego klastra. Aby pracować z obiektami Kubernetesa-czy to w celu ich tworzenia, modyfikacji, czy usuwania—musisz użyć [API Kubernetesa](https://kubernetes.io/pl/docs/concepts/overview/kubernetes-api/) . Na przykład, kiedy używasz interfejsu wiersza poleceń `kubectl`, CLI wykonuje dla ciebie niezbędne wywołania do API Kubernetesa. Możesz także używać API Kubernetesa bezpośrednio w swoich własnych programach, korzystając z jednej z [bibliotek klienckich](https://kubernetes.io/docs/reference/using-api/client-libraries/) . ### Specyfikacja i status obiektu[](https://kubernetes.io/pl/docs/concepts/_print/#object-spec-and-status) Prawie każdy obiekt Kubernetesa zawiera dwa zagnieżdżone pola obiektowe, które zarządzają konfiguracją obiektu: obiekt _`spec`_ i obiekt _`status`_. W przypadku obiektów, które mają `spec`, musisz go ustawić podczas tworzenia obiektu, dostarczając opis cech, jakie chcesz, aby zasób posiadał: jego _pożądany stan_. `Status` opisuje _aktualny stan_ obiektu, dostarczany i aktualizowany przez system Kubernetes i jego komponenty. Kubernetes [warstwa sterowania](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-control-plane) stale i aktywnie zarządza rzeczywistym stanem każdego obiektu, aby dopasować go do pożądanego stanu, który dostarczyłeś. Na przykład: w Kubernetesie, Deployment jest obiektem, który może reprezentować aplikację działającą na twoim klastrze. Kiedy tworzysz Deployment, możesz ustawić `spec` Deploymentu, aby określić, że chcesz, aby uruchomione były trzy repliki aplikacji. System Kubernetes odczytuje spec Deploymentu i uruchamia trzy instancje twojej pożądanej aplikacji—aktualizując status, aby dopasować go do twojego spec. Jeśli któraś z instancji ulegnie awarii (czyli zmieni się status), Kubernetes zareaguje na różnicę między spec a status - w tym przypadku, uruchamiając nową instancję. Aby uzyskać więcej informacji na temat specyfikacji obiektu, statusu i metadanych, zobacz [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) . ### Opis obiektu w Kubernetesie[](https://kubernetes.io/pl/docs/concepts/_print/#describing-a-kubernetes-object) Kiedy tworzysz obiekt w Kubernetesie, musisz dostarczyć specyfikację obiektu, która opisuje jego pożądany stan, a także podstawowe informacje o obiekcie (takie jak nazwa). Gdy używasz API Kubernetesa do tworzenia obiektu (bezpośrednio lub za pośrednictwem `kubectl`), żądanie API musi zawierać te informacje w formacie JSON w treści żądania. Najczęściej dostarczasz informacje do `kubectl` w pliku znanym jako _manifest_. Zgodnie z konwencją, manifesty są w formacie YAML (możesz również użyć formatu JSON). Narzędzia takie jak `kubectl` konwertują informacje z manifestu na JSON lub inny obsługiwany format serializacji podczas wysyłania żądania API przez HTTP. Oto przykład manifestu pokazujący wymagane pola oraz specyfikację obiektu dla Deployment w Kubernetesie: [`application/deployment.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/pl/examples/application/deployment.yaml) ![](https://kubernetes.io/images/copycode.svg "Skopiuj application/deployment.yaml do schowka") apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 # tells deployment to run 2 pods matching the template template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 Jednym ze sposobów utworzenia Deploymentu przy użyciu pliku manifestu, takiego jak powyżej, jest użycie polecenia [`kubectl apply`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) w interfejsie wiersza poleceń `kubectl`, przekazując plik `.yaml` jako argument. Oto przykład: kubectl apply -f https://k8s.io/examples/application/deployment.yaml Wynik jest podobny do tego: deployment.apps/nginx-deployment created ### Wymagane pola[](https://kubernetes.io/pl/docs/concepts/_print/#required-fields) W manifeście (pliku YAML lub JSON) dla obiektu Kubernetesa, który chcesz utworzyć, musisz ustawić wartości dla następujących pól: * `apiVersion` - Której wersji API Kubernetesa używasz do utworzenia tego obiektu * `kind` - Jakiego rodzaju obiekt chcesz utworzyć * `metadata` - Dane pomagające jednoznacznie zidentyfikować obiekt, w tym łańcuch znaków `name`, `UID` oraz opcjonalnie `namespace`. * `spec` - Jaki stan jest pożądany dla obiektu Dokładny format obiektu `spec` jest inny dla każdego obiektu Kubernetesa i zawiera zagnieżdżone pola specyficzne dla tego obiektu. [Kubernetes API Reference](https://kubernetes.io/docs/reference/kubernetes-api/) może pomóc ci znaleźć format spec dla wszystkich obiektów, które możesz utworzyć przy użyciu Kubernetesa. Na przykład, zobacz [pole `spec`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) w odniesieniu do API Poda. Dla każdego Poda, pole `.spec` określa pod i jego pożądany stan (taki jak nazwa obrazu kontenera dla każdego kontenera w ramach tego poda). Innym przykładem specyfikacji obiektu jest [pole `spec`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec) dla API StatefulSet. Dla StatefulSet, pole `.spec` określa StatefulSet i jego pożądany stan. W ramach `.spec` dla StatefulSet znajduje się [szablon](https://kubernetes.io/pl/docs/concepts/workloads/pods/#pod-templates) dla obiektów Pod. Ten szablon opisuje Pody, które kontroler StatefulSet utworzy w celu spełnienia specyfikacji StatefulSet. Różne rodzaje obiektów mogą również mieć różne `.status`; ponownie, strony referencyjne API szczegółowo opisują strukturę tego pola `.status` i jego zawartość dla każdego rodzaju obiektu. Zobacz [Najlepsze Praktyki Konfiguracji](https://kubernetes.io/blog/2025/11/25/configuration-good-practices/) aby uzyskać dodatkowe informacje na temat pisania plików konfiguracyjnych YAML. Walidacja pól po stronie serwera[](https://kubernetes.io/pl/docs/concepts/_print/#server-side-field-validation) ---------------------------------------------------------------------------------------------------------------- Począwszy od wersji Kubernetesa v1.25, serwer API oferuje [walidację pól](https://kubernetes.io/docs/reference/using-api/api-concepts/#field-validation) po stronie serwera, która wykrywa nierozpoznane lub zduplikowane pola w obiekcie. Zapewnia ona całą funkcjonalność `kubectl --validate` po stronie serwera. Narzędzie `kubectl` używa flagi `--validate` do ustawiania poziomu walidacji pól. Akceptuje wartości `ignore`, `warn` oraz `strict`, a także akceptuje wartości `true` (równoważne `strict`) i `false` (równoważne `ignore`). Domyślne ustawienie walidacji dla `kubectl` to `--validate=true`. `Strict` : Ścisła walidacja pól, błędy w przypadku niepowodzenia walidacji `Warn` : Walidacja pola jest przeprowadzana, ale błędy są zgłaszane jako ostrzeżenia zamiast powodować niepowodzenie żądania. `Ignore` : Nie jest wykonywana żadna walidacja pola po stronie serwera Kiedy `kubectl` nie może połączyć się z serwerem API, który obsługuje walidację pól, przełączy się na użycie walidacji po stronie klienta. Kubernetes 1.27 i nowsze wersje zawsze oferują walidację pól; starsze wydania Kubernetesa mogą tego nie robić. Jeśli twój klaster jest starszy niż v1.27, sprawdź dokumentację dla swojej wersji Kubernetesa. Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej) --------------------------------------------------------------------- Jeśli dopiero zaczynasz swoją przygodę z Kubernetesem, przeczytaj więcej na temat: * [Pody](https://kubernetes.io/pl/docs/concepts/workloads/pods/) , które są najważniejszymi podstawowymi obiektami Kubernetesa. * Obiekty [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) . * [Kontrolery](https://kubernetes.io/docs/concepts/architecture/controller/) w Kubernetesie. * [kubectl](https://kubernetes.io/docs/reference/kubectl/) i [kubectl commands](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands) . [Zarządzanie obiektami Kubernetesa](https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/) wyjaśnia, jak używać `kubectl` do zarządzania obiektami. Możesz potrzebować [zainstalować kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) , jeśli jeszcze go nie masz. Aby dowiedzieć się więcej ogólnie o API Kubernetesa, odwiedź: * [Kubernetes API overview](https://kubernetes.io/docs/reference/using-api/) Aby dowiedzieć się więcej o obiektach w Kubernetesie, przeczytaj inne strony w tej sekcji: 1.2.1 - Nazwy i identyfikatory objektów[](https://kubernetes.io/pl/docs/concepts/_print/#pg-f37749a83c2916b63279ea60f3cfe53e) ============================================================================================================================== Każdy [obiekt](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/#kubernetes-objects) w Twoim klastrze ma [_Nazwę_](https://kubernetes.io/pl/docs/concepts/_print/#names) , która jest unikalna dla tego typu zasobu. Każdy obiekt Kubernetesa posiada również [_UID_](https://kubernetes.io/pl/docs/concepts/_print/#uids) , który jest unikalny w całym Twoim klastrze. Na przykład, w jednym [namespace](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/namespaces/) można mieć tylko jeden Pod o nazwie `myapp-1234`, ale można mieć jeden Pod i jeden Deployment, które są nazwane `myapp-1234`. Dla nieunikalnych atrybutów dostarczonych przez użytkownika, Kubernetes udostępnia [etykiety](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/labels/) oraz [adnotacje](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/annotations/) . Nazwy[](https://kubernetes.io/pl/docs/concepts/_print/#names) -------------------------------------------------------------- Ciąg znaków dostarczony przez klienta, który odnosi się do obiektu w adresie URL [zasobu](https://kubernetes.io/pl/docs/reference/using-api/api-concepts/#standard-api-terminology) , na przykład `/api/v1/pods/some-name`. W danym momencie tylko jeden obiekt danego typu może mieć określoną nazwę. Jednak po usunięciu tego obiektu można utworzyć nowy o tej samej nazwie. **Nazwy muszą być unikalne we wszystkich [wersjach API](https://kubernetes.io/pl/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) dla tego samego zasobu. Zasoby API są rozróżniane na podstawie grupy API, typu zasobu, przestrzeni nazw (dla zasobów przestrzeniozależnych) oraz nazwy. Innymi słowy, wersja API jest nieistotna w tym kontekście.** #### Informacja: W przypadkach, gdy obiekty reprezentują fizyczną jednostkę, jak Node reprezentujący fizycznego hosta, jeśli host jest odtworzony pod tą samą nazwą bez usuwania i ponownego tworzenia Node, Kubernetes traktuje nowy host jako stary, co może prowadzić do niespójności. Serwer może wygenerować nazwę, gdy zamiast `name` w żądaniu utworzenia zasobu podano `generateName`. Gdy używane jest `generateName`, podana wartość służy jako prefiks nazwy, do którego serwer dodaje wygenerowany sufiks. Nawet jeśli nazwa jest generowana, może wystąpić konflikt z istniejącymi nazwami, co skutkuje odpowiedzią HTTP 409. W Kubernetes v1.31 i nowszych wersjach jest to znacznie mniej prawdopodobne, ponieważ serwer podejmuje do 8 prób wygenerowania unikalnej nazwy przed zwróceniem odpowiedzi HTTP 409. Poniżej znajdują się cztery typy często używanych ograniczeń nazw dla zasobów. ### Nazwy subdomen DNS[](https://kubernetes.io/pl/docs/concepts/_print/#dns-subdomain-names) Większość typów zasobów wymaga nazwy, która może być używana jako nazwa poddomeny DNS, zgodnie z definicją w [RFC 1123](https://tools.ietf.org/html/rfc1123) . Oznacza to, że nazwa musi: * zawierać nie więcej niż 253 znaki * zawierać tylko małe litery alfanumeryczne, '-' lub '.' * zaczynać się od znaku alfanumerycznego * kończyć się znakiem alfanumerycznym ### Nazwy etykiet zgodnie z RFC 1123[](https://kubernetes.io/pl/docs/concepts/_print/#dns-label-names) Niektóre typy zasobów wymagają, aby ich nazwy były zgodne ze standardem etykiet DNS, jak zdefiniowano w [RFC 1123](https://tools.ietf.org/html/rfc1123) . Oznacza to, że nazwa musi: * zawierać maksymalnie 63 znaków * zawierać tylko małe litery alfanumeryczne lub '-' * zaczynać się od litery alfabetu * kończyć się znakiem alfanumerycznym #### Informacja: Gdy bramka funkcji `RelaxedServiceNameValidation` jest włączona, nazwy obiektów usługi (ang. Service) mogą rozpoczynać się od cyfry. ### Nazwy etykiet zgodne z RFC 1035[](https://kubernetes.io/pl/docs/concepts/_print/#rfc-1035-label-names) Niektóre typy zasobów wymagają, aby ich nazwy spełniały standardy etykiet DNS zgodnie z definicją w [RFC 1035](https://tools.ietf.org/html/rfc1035) . Oznacza to, że nazwa musi: * zawierać maksymalnie 63 znaków * zawierać tylko małe litery alfanumeryczne lub '-' * zaczynać się od litery alfabetu * kończyć się znakiem alfanumerycznym #### Informacja: Chociaż RFC 1123 technicznie pozwala, aby etykiety zaczynały się od cyfr, obecna implementacja Kubernetesa wymaga, aby zarówno etykiety (ang. label) zgodne z RFC 1035, jak i RFC 1123 zaczynały się od znaku alfabetycznego. Wyjątkiem jest sytuacja, gdy dla obiektów typu Service jest włączona brama funkcji `RelaxedServiceNameValidation`, co pozwala na to, aby nazwy usług zaczynały się od cyfr. ### Nazwy segmentów ścieżki[](https://kubernetes.io/pl/docs/concepts/_print/#path-segment-names) Niektóre typy zasobów wymagają, aby ich nazwy mogły być bezpiecznie kodowane jako segment ścieżki. Innymi słowy, nazwa nie może być "." ani ".." oraz nie może zawierać "/" ani "%". Oto przykładowy manifest dla Poda o nazwie `nginx-demo`. apiVersion: v1 kind: Pod metadata: name: nginx-demo spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 #### Informacja: Niektóre typy zasobów mają dodatkowe ograniczenia dotyczące ich nazw. UIDy[](https://kubernetes.io/pl/docs/concepts/_print/#uids) ------------------------------------------------------------ Unikalny identyfikator obiektu generowany automatycznie przez system Kubernetes. Każdy obiekt utworzony w trakcie całego cyklu życia klastra Kubernetesa posiada unikalny UID. Jego celem jest rozróżnianie historycznych wystąpień podobnych jednostek. UID-y Kubernetesa to uniwersalne unikalne identyfikatory (znane również jako UUID). UUID są ustandaryzowane jako ISO/IEC 9834-8 oraz jako ITU-T X.667. Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej) --------------------------------------------------------------------- * Przeczytaj o [etykietach](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/labels/) i [adnotacjach](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/annotations/) w Kubernetesie. * Zobacz [Identyfikatory i nazwy w Kubernetesie](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) . 1.2.2 - Etykiety i selektory[](https://kubernetes.io/pl/docs/concepts/_print/#pg-f1dec4557fb8ffbac9f11390aaaf9fa4) =================================================================================================================== _Etykiety_ to pary klucz/wartość, które są dołączane do [obiektów](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/#kubernetes-objects) takich jak Pody. Etykiety służą do określania identyfikacyjnych atrybutów obiektów, które są istotne i ważne dla użytkowników, ale bezpośrednio nie wpływają na semantykę głównego systemu. Etykiety mogą być używane do organizowania i wybierania podzbiorów obiektów. Etykiety mogą być dołączane do obiektów w momencie ich tworzenia, a następnie mogą być dodawane i modyfikowane w dowolnym momencie. Każdy obiekt może mieć zdefiniowany zestaw etykiet w postaci par klucz/wartość. Każdy klucz musi być unikalny dla konkretnego obiektu. "metadata": { "labels": { "key1" : "value1", "key2" : "value2" } } Etykiety umożliwiają wydajne zapytania i obserwacje, co czyni je idealnym rozwiązaniem do użycia w interfejsach użytkownika (UI) i interfejsach wiersza poleceń (CLI). Informacje nieidentyfikujące powinny być rejestrowane przy użyciu [adnotacji](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/annotations/) . Motywacja[](https://kubernetes.io/pl/docs/concepts/_print/#motivation) ----------------------------------------------------------------------- Etykiety umożliwiają użytkownikom odwzorowanie własnych struktur organizacyjnych na obiekty systemowe w sposób luźno powiązany, bez konieczności przechowywania tych odwzorowań przez klientów. Rozmieszczanie usług i przetwarzanie wsadowe to często byty wielowymiarowe (np. wiele partycji lub wdrożeń, wiele ścieżek wydania, wiele poziomów, wiele mikrousług na poziom). Zarządzanie często wymaga operacji przekrojowych, co łamie enkapsulację ściśle hierarchicznych reprezentacji, zwłaszcza sztywnych hierarchii określanych przez infrastrukturę, a nie przez użytkowników. Przykłady etykiet: * `"release" : "stable"`, `"release" : "canary"` * `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` * `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` * `"partition" : "customerA"`, `"partition" : "customerB"` * `"track" : "daily"`, `"track" : "weekly"` Oto przykłady [zalecanych etykiet](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/common-labels/) ; możesz swobodnie opracowywać własne konwencje. Pamiętaj, że klucz etykiety musi być unikalny dla danego obiektu. Składnia i zestaw znaków[](https://kubernetes.io/pl/docs/concepts/_print/#syntax-and-character-set) ---------------------------------------------------------------------------------------------------- _Etykiety_ to pary klucz/wartość. Prawidłowe klucze etykiet mają dwa segmenty: opcjonalny prefiks i nazwę, oddzielone ukośnikiem (`/`). Segment nazwy jest wymagany i musi mieć maksymalnie 63 znaki, zaczynając i kończąc się znakiem alfanumerycznym (`[a-z0-9A-Z]`), z myślnikami (`-`), podkreśleniami (`_`), kropkami (`.`) i znakami alfanumerycznymi pomiędzy. Prefiks jest opcjonalny. Jeśli jest podany, prefiks musi być subdomeną DNS: serią etykiet DNS oddzielonych kropkami (`.`), o długości nieprzekraczającej łącznie 253 znaków, zakończoną ukośnikiem (`/`). Jeśli prefiks zostanie pominięty, uważa się, że klucz etykiety jest prywatny dla użytkownika. Zautomatyzowane komponenty systemowe (np. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` lub inne zewnętrzne automatyzacje), które dodają etykiety do obiektów końcowego użytkownika, muszą określać prefiks. Prefiksy `kubernetes.io/` i `k8s.io/` są [zarezerwowane](https://kubernetes.io/docs/reference/labels-annotations-taints/) dla podstawowych komponentów Kubernetesa. Prawidłowa wartość etykiety: * musi mieć 63 znaki lub mniej (może być puste), * o ile ciąg nie jest pusty, musi zaczynać się i kończyć znakiem alfanumerycznym (`[a-z0-9A-Z]`), * może zawierać myślniki (`-`), podkreślenia (`_`), kropki (`.`) oraz znaki alfanumeryczne pomiędzy. Na przykład, oto manifest dla Poda, który ma dwie etykiety `environment: production` oraz `app: nginx`: apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 Selektory etykiet[](https://kubernetes.io/pl/docs/concepts/_print/#label-selectors) ------------------------------------------------------------------------------------ W przeciwieństwie do [nazw i identyfikatorów UID](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/names/) , etykiety nie zapewniają unikalności. To oznacza, że wiele obiektów może mieć te same etykiety. Za pomocą _selektora etykiet_ klient/użytkownik może zidentyfikować zestaw obiektów. Selektor etykiet jest podstawowym mechanizmem grupującym w Kubernetesie. API obecnie obsługuje dwa typy selektorów: _oparte na równości_ i _oparte na zbiorach_. Selektor etykiet może składać się z wielu _wymagań_, które są oddzielone przecinkami. W przypadku wielu wymagań, wszystkie muszą być spełnione, więc separator przecinka działa jako logiczny operator _AND_ (`&&`). Interpretacja pustych lub niepodanych selektorów zależy od kontekstu. Każdy typ API, który je wykorzystuje, powinien jasno udokumentować ich dopuszczalność i sposób działania. #### Informacja: Dla niektórych typów API, takich jak ReplicaSets, selektory etykiet dwóch instancji nie mogą się nakładać w obrębie jednej przestrzeni nazw, ponieważ kontroler może to uznać za sprzeczne polecenia i nie będzie w stanie określić, ile replik powinno być obecnych. #### Uwaga: Zarówno dla warunków opartych na równości, jak i warunków opartych na zbiorach nie istnieje operator logiczny _OR_ (`||`). Upewnij się, że twoje instrukcje filtrujące są odpowiednio skonstruowane. ### _Wymóg oparty na równości_[](https://kubernetes.io/pl/docs/concepts/_print/#equality-based-requirement) _Wymagania_ oparte na _równości_ lub _nierówności_ umożliwiają filtrowanie według kluczy i wartości etykiet. Pasujące obiekty muszą spełniać wszystkie określone ograniczenia etykiet, chociaż mogą mieć również dodatkowe etykiety. Dopuszczalne są trzy rodzaje operatorów: `=`,`==`,`!=`. Pierwsze dwa reprezentują _równość_ (i są synonimami), podczas gdy ostatni reprezentuje _nierówność_. Na przykład: environment = production tier != frontend Poprzedni wybiera wszystkie zasoby, których klucz jest równy `environment`, a wartość równa się `production`. Drugi wybiera wszystkie zasoby, których klucz jest równy `tier`, a wartość różni się od `frontend`, oraz wszystkie zasoby bez etykiet z kluczem `tier`. Można filtrować zasoby w `production` wyłączając `frontend` przy użyciu operatora przecinka: `environment=production,tier!=frontend` Jednym ze scenariuszy użycia dla wymagań etykiet opartych na równości jest specyfikacja kryteriów wyboru węzła przez Pody. Na przykład, poniższy przykładowy Pod wybiera węzły, na których etykieta `accelerator` istnieje i jest ustawiona na `nvidia-tesla-p100`. apiVersion: v1 kind: Pod metadata: name: cuda-test spec: containers: - name: cuda-test image: "registry.k8s.io/cuda-vector-add:v0.1" resources: limits: nvidia.com/gpu: 1 nodeSelector: accelerator: nvidia-tesla-p100 ### _Wymagania oparte na zbiorach_[](https://kubernetes.io/pl/docs/concepts/_print/#set-based-requirement) Wymagania dotyczące etykiet bazujących na zbiorach (_Set-based_) umożliwiają filtrowanie kluczy według zbioru wartości. Obsługiwane są trzy rodzaje operatorów: `in`, `notin` oraz `exists` (tylko identyfikator klucza). Na przykład: environment in (production, qa) tier notin (frontend, backend) partition !partition * Pierwszy przykład wybiera wszystkie zasoby z kluczem równym `environment` i wartością równą `production` lub `qa`. * Drugi przykład wybiera wszystkie zasoby z kluczem równym `tier` i wartościami innymi niż `frontend` i `backend`, oraz wszystkie zasoby bez etykiet z kluczem `tier`. * Trzeci przykład wybiera wszystkie zasoby zawierające etykietę z kluczem `partition`; wartości nie są sprawdzane. * Czwarty przykład wybiera wszystkie zasoby bez etykiety z kluczem `partition`; wartości nie są sprawdzane. Podobnie separator przecinka działa jako operator _AND_. Filtrowanie zasobów z kluczem `partition` (bez względu na wartość) i z `environment` innym niż `qa` można osiągnąć używając `partition,environment notin (qa)`. _Selekcja etykiet oparta na zbiorach_ jest ogólną formą równości, ponieważ `environment=production` jest równoważne `environment in (production)`; podobnie dla `!=` i `notin`. Wymagania oparte na _zbiorach_ mogą być mieszane z wymaganiami opartymi na _równości_. Na przykład: `partition in (customerA, customerB),environment!=qa`. API[](https://kubernetes.io/pl/docs/concepts/_print/#api) ---------------------------------------------------------- ### Filtrowanie LIST i WATCH[](https://kubernetes.io/pl/docs/concepts/_print/#list-and-watch-filtering) Dla operacji **list** i **watch** można określić selektory etykiet, aby filtrować zestawy zwracanych obiektów; filtr określasz za pomocą parametru zapytania. (Aby dowiedzieć się więcej o mechanizmie watch w Kubernetesie, przeczytaj o [wydajnym wykrywaniu zmian](https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes) ). Oba wymagania są dozwolone (przedstawione tutaj tak, jak mogą się pojawić w ciągu zapytania URL): * _wymagania oparte na równości_: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` * \_wymagania oparte na zbiorach: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` Oba style selektorów etykiet mogą być używane do wylistowania lub obserwacji zasobów za pomocą klienta REST. Na przykład, kierując się na `apiserver` z `kubectl` i używając selekcji opartej na równości, można napisać: kubectl get pods -l environment=production,tier=frontend lub używając wymagań opartych na _zbiorach_: kubectl get pods -l 'environment in (production),tier in (frontend)' Jak już wspomniano, wymagania oparte na _zbiorach_ są bardziej wyraziste. Na przykład mogą implementować operator _LUB_ na wartościach: kubectl get pods -l 'environment in (production, qa)' lub ograniczenie dopasowywania negatywnego za pomocą operatora _notin_: kubectl get pods -l 'environment,environment notin (frontend)' ### Ustaw referencje w obiektach API[](https://kubernetes.io/pl/docs/concepts/_print/#set-references-in-api-objects) Niektóre obiekty Kubernetesa, takie jak [`services`](https://kubernetes.io/docs/concepts/services-networking/service/) i [`replicationcontrollers`](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/) , również używają selektorów etykiet do określania zbiorów innych zasobów, takich jak [pods](https://kubernetes.io/pl/docs/concepts/workloads/pods/) . #### Usługa i Kontroler Replikacji[](https://kubernetes.io/pl/docs/concepts/_print/#service-and-replicationcontroller) Zestaw podów, na które skierowana jest usługa (`service`), jest określany za pomocą selektora etykiet. Podobnie, populacja podów, którą powinien zarządzać kontroler replikacji (`replicationcontroller`), jest również określana za pomocą selektora etykiet. Selektory etykiet dla obu obiektów są definiowane w plikach `json` lub `yaml` za pomocą map, i obsługiwane są tylko selektory wymagań oparte na _równości_: "selector": { "component" : "redis", } lub selector: component: redis Ten selektor (odpowiednio w formacie `json` lub `yaml`) jest równoważny z `component=redis` lub `component in (redis)`. #### Zasoby, które obsługują wymagania oparte na zbiorach[](https://kubernetes.io/pl/docs/concepts/_print/#resources-that-support-set-based-requirements) Nowsze zasoby, takie jak [`Job`](https://kubernetes.io/docs/concepts/workloads/controllers/job/) , [`Deployment`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) , [`ReplicaSet`](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) oraz [`DaemonSet`](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) , obsługują również wymagania _oparte na zbiorach_. selector: matchLabels: component: redis matchExpressions: - { key: tier, operator: In, values: [cache] } - { key: environment, operator: NotIn, values: [dev] } `matchLabels` to mapa par `{klucz,wartość}`. Pojedyncza para `{klucz,wartość}` w mapie `matchLabels` jest równoważna elementowi `matchExpressions`, którego pole `key` to "klucz", `operator` to "In", a tablica `values` zawiera wyłącznie "wartość". `matchExpressions` to lista wymagań selektora podów. Prawidłowe operatory to In, NotIn, Exists i DoesNotExist. Zbiór wartości musi być niepusty w przypadku In i NotIn. Wszystkie wymagania zarówno z `matchLabels`, jak i `matchExpressions` są łączone za pomocą operatora AND - muszą być wszystkie spełnione, aby dopasowanie było możliwe. #### Wybieranie zestawów węzłów[](https://kubernetes.io/pl/docs/concepts/_print/#selecting-sets-of-nodes) Jednym z przypadków użycia wybierania w oparciu o etykiety jest ograniczenie zestawu węzłów, na które można umieścić pod. Więcej informacji można znaleźć w dokumentacji na temat [wyboru węzła](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) . Skuteczne wykorzystywanie etykiet[](https://kubernetes.io/pl/docs/concepts/_print/#using-labels-effectively) ------------------------------------------------------------------------------------------------------------- Możesz zastosować pojedynczą etykietę do dowolnych zasobów, ale nie zawsze jest to najlepsza praktyka. Istnieje wiele scenariuszy, w których należy użyć wielu etykiet, aby odróżnić zestawy zasobów od siebie nawzajem. Na przykład różne aplikacje mogą używać różnych wartości dla etykiety `app`, ale aplikacja wielowarstwowa, taka jak [przykład książki gości](https://github.com/kubernetes/examples/tree/master/web/guestbook/) , będzie dodatkowo musiała rozróżniać każdą warstwę. Frontend mógłby nosić następujące etykiety: labels: app: guestbook tier: frontend podczas gdy instancje master i replica Redis miałyby różne etykiety `tier`, a być może nawet dodatkową etykietę `role`: labels: app: guestbook tier: backend role: master i labels: app: guestbook tier: backend role: replica Etykiety umożliwiają sortowanie i filtrowanie zasobów według dowolnego wymiaru określonego przez etykietę: kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml kubectl get pods -Lapp -Ltier -Lrole NAME READY STATUS RESTARTS AGE APP TIER ROLE guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master guestbook-redis-replica-2q2yf 1/1 Running 0 1m guestbook backend replica guestbook-redis-replica-qgazl 1/1 Running 0 1m guestbook backend replica my-nginx-divi2 1/1 Running 0 29m nginx my-nginx-o0ef1 1/1 Running 0 29m nginx kubectl get pods -lapp=guestbook,role=replica NAME READY STATUS RESTARTS AGE guestbook-redis-replica-2q2yf 1/1 Running 0 3m guestbook-redis-replica-qgazl 1/1 Running 0 3m Aktualizacja etykiet[](https://kubernetes.io/pl/docs/concepts/_print/#updating-labels) --------------------------------------------------------------------------------------- Czasami możesz chcieć zmienić etykiety istniejących podów i innych zasobów przed utworzeniem nowych zasobów. Można to zrobić za pomocą `kubectl label`. Na przykład, jeśli chcesz oznaczyć wszystkie swoje pody NGINX jako warstwę frontendową, wykonaj: kubectl label pods -l app=nginx tier=fe pod/my-nginx-2035384211-j5fhi labeled pod/my-nginx-2035384211-u2c7e labeled pod/my-nginx-2035384211-u3t6x labeled Najpierw filtruje wszystkie pody z etykietą "app=nginx", a następnie nadaje im etykietę "tier=fe". Aby zobaczyć pody, które zostały oznaczone etykietą, uruchom: kubectl get pods -l app=nginx -L tier NAME READY STATUS RESTARTS AGE TIER my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe To wyświetla wszystkie pody z etykietą "app=nginx", z dodatkową kolumną etykiet reprezentującą warstwę podów (określoną za pomocą `-L` lub `--label-columns`). Aby uzyskać więcej informacji, zobacz [kubectl label](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#label) . Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej) --------------------------------------------------------------------- * Dowiedz się, jak [dodać etykietę do węzła](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node) * Zobacz [Well-known labels, Annotations and Taints](https://kubernetes.io/docs/reference/labels-annotations-taints/) * Zobacz [Zalecane etykiety](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/common-labels/) * [Enforce Pod Security Standards with Namespace Labels](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) * Przeczytaj blog [Writing a Controller for Pod Labels](https://kubernetes.io/blog/2021/06/21/writing-a-controller-for-pod-labels/) 1.2.3 - Przestrzenie nazw (ang. Namespaces)[](https://kubernetes.io/pl/docs/concepts/_print/#pg-1127165f472b7181b9c1d5a0b187d620) ================================================================================================================================== W Kubernetesie _przestrzenie nazw_ zapewniają mechanizm izolowania grup zasobów w ramach jednego klastra. Nazwy zasobów muszą być unikalne w obrębie danej przestrzeni nazw, ale nie muszą być unikalne w całym klastrze. Zakres oparty na przestrzeniach nazw dotyczy tylko [obiektów](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/#kubernetes-objects) _(np. Deploymentów, Service'ów, itp.)_, a nie dla obiektów dotyczących całego klastra _(np. StorageClass, Nodes, PersistentVolumes, itp.)_. Kiedy używać wielu przestrzeni nazw[](https://kubernetes.io/pl/docs/concepts/_print/#when-to-use-multiple-namespaces) ---------------------------------------------------------------------------------------------------------------------- Przestrzenie nazw są przeznaczone do użycia w środowiskach z wieloma użytkownikami rozproszonymi w różnych zespołach lub projektach. Dla klastrów z użytkownikami w ilości od kilku do kilkunastu nie powinieneś potrzebować tworzyć ani myśleć o przestrzeniach nazw. Zacznij używać przestrzeni nazw, gdy potrzebujesz funkcji, które one oferują. Namespace'y zapewniają zakres dla nazw. Nazwy zasobów muszą być unikalne w obrębie jednego namespace'u, ale nie muszą być unikalne w różnych namespace'ach. Namespace'y nie mogą być zagnieżdżane w sobie wzajemnie, a każdy zasób Kubernetesa może znajdować się tylko w jednym namespace'ie. Namespacey są sposobem na podział zasobów klastra pomiędzy wielu użytkowników (przez [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) ). Nie ma potrzeby używania wielu przestrzeni nazw do oddzielania nieznacznie różniących się zasobów, takich jak różne wersje tego samego oprogramowania: zamiast tego wykorzystaj [etykiety](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/labels) , aby rozróżnić zasoby w obrębie jednej przestrzeni nazw. #### Informacja: Dla klastra produkcyjnego, rozważ _nie_ używanie przestrzeni nazw `default`. Zamiast tego stwórz inne przestrzenie nazw i używaj ich. Początkowe przestrzenie nazw[](https://kubernetes.io/pl/docs/concepts/_print/#initial-namespaces) -------------------------------------------------------------------------------------------------- Kubernetes rozpoczyna z czterema początkowymi przestrzeniami nazw: `default` : Kubernetes zawiera tę przestrzeń nazw, aby umożliwić rozpoczęcie korzystania z nowego klastra bez konieczności wcześniejszego tworzenia przestrzeni nazw. `kube-node-lease` : Ta przestrzeń nazw przechowuje obiekty [Lease](https://kubernetes.io/docs/concepts/architecture/leases/) powiązane z każdym węzłem. Pozwalają one kubeletowi na wysyłanie [sygnałów życia (ang. heartbeats)](https://kubernetes.io/docs/concepts/architecture/nodes/#node-heartbeats) , dzięki czemu warstwa sterowania może wykryć awarię węzła. `kube-public` : Ta przestrzeń nazw jest możliwa do odczytu przez _wszystkich_ klientów (w tym tych, którzy nie są uwierzytelnieni). Ta przestrzeń nazw jest głównie zarezerwowana do użytku klastra, na wypadek gdyby niektóre zasoby miały być widoczne i czytelne publicznie w całym klastrze. Publiczny aspekt tej przestrzeni nazw jest jedynie konwencją, a nie wymogiem. `kube-system` : Przestrzeń nazw dla obiektów tworzonych przez system Kubernetesa. Praca z przestrzeniami nazw[](https://kubernetes.io/pl/docs/concepts/_print/#working-with-namespaces) ------------------------------------------------------------------------------------------------------ Tworzenie i usuwanie przestrzeni nazw zostało opisane w [dokumentacji Przewodnika Administratora dotyczącej przestrzeni nazw](https://kubernetes.io/docs/tasks/administer-cluster/namespaces) . #### Informacja: Unikaj tworzenia przestrzeni nazw z prefiksem `kube-`, ponieważ jest on zarezerwowany dla przestrzeni nazw systemu Kubernetes. ### Przeglądanie przestrzeni nazw[](https://kubernetes.io/pl/docs/concepts/_print/#viewing-namespaces) Możesz wyświetlić listę bieżących przestrzeni nazw w klastrze za pomocą: kubectl get namespace NAME STATUS AGE default Active 1d kube-node-lease Active 1d kube-public Active 1d kube-system Active 1d ### Ustawianie przestrzeni nazw dla żądania[](https://kubernetes.io/pl/docs/concepts/_print/#setting-the-namespace-for-a-request) Aby ustawić przestrzeń nazw dla bieżącego żądania, użyj flagi `--namespace`. Na przykład: kubectl run nginx --image=nginx --namespace= kubectl get pods --namespace= ### Ustawianie preferencji przestrzeni nazw[](https://kubernetes.io/pl/docs/concepts/_print/#setting-the-namespace-preference) Możesz na stałe zapisać przestrzeń nazw dla wszystkich kolejnych poleceń kubectl w tym kontekście. kubectl config set-context --current --namespace= # Validate it kubectl config view --minify | grep namespace: Przestrzenie nazw i DNS[](https://kubernetes.io/pl/docs/concepts/_print/#namespaces-and-dns) --------------------------------------------------------------------------------------------- Kiedy tworzysz [Service](https://kubernetes.io/docs/concepts/services-networking/service/) , tworzy on odpowiadający mu [rekord DNS](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) . Ten wpis ma postać `..svc.cluster.local`, co oznacza, że jeśli kontener używa tylko ``, odwołuje się on do usługi lokalnej dla danego namespace'a. Jest to przydatne do używania tej samej konfiguracji w wielu namespace'ach, takich jak Development, Staging i Production. Jeśli chcesz uzyskać dostęp do zasobów między namespace'ami, musisz użyć w pełni kwalifikowanej nazwy domeny (FQDN). W związku z tym, wszystkie nazwy przestrzeni nazw muszą być zgodne z [etykietami DNS RFC 1123](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/names/#dns-label-names) . #### Ostrzeżenie: Poprzez tworzenie przestrzeni nazw o takiej samej nazwie jak [publiczne domeny najwyższego poziomu](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) , usługi w tych przestrzeniach nazw mogą mieć krótkie nazwy DNS, które pokrywają się z publicznymi rekordami DNS. Zapytania DNS wykonywane przez workloady z dowolnej przestrzeni nazw, bez [kończącej kropki](https://datatracker.ietf.org/doc/html/rfc1034#page-8) , będą przekierowane do tych usług, mając pierwszeństwo przed publicznym wpisem DNS. Aby temu zapobiec, ogranicz uprawnienia do tworzenia przestrzeni nazw dla zaufanych użytkowników. Jeśli to konieczne, możesz dodatkowo skonfigurować zewnętrzne mechanizmy kontroli bezpieczeństwa, takie jak [admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) , aby zablokować tworzenie jakiejkolwiek przestrzeni nazw o nazwie z listy [domen najwyższego poziomu (ang. TLD - Top-Level Domain)](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) . Nie wszystkie obiekty znajdują się w przestrzeni nazw.[](https://kubernetes.io/pl/docs/concepts/_print/#not-all-objects-are-in-a-namespace) -------------------------------------------------------------------------------------------------------------------------------------------- Większość zasobów Kubernetesa (np. pody, usługi, kontrolery replikacji i inne) znajduje się w jakiś przestrzeniach nazw. Jednak zasoby przestrzeni nazw nie są same w sobie w przestrzeni nazw. Zasoby niskiego poziomu, takie jak [węzły](https://kubernetes.io/docs/concepts/architecture/nodes/) i [persistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) , nie znajdują się w żadnej przestrzeni nazw. Aby zobaczyć, które zasoby Kubernetesa znajdują się w przestrzeni nazw, a które nie: # In a namespace kubectl api-resources --namespaced=true # Not in a namespace kubectl api-resources --namespaced=false Automatyczne etykietowanie[](https://kubernetes.io/pl/docs/concepts/_print/#automatic-labelling) ------------------------------------------------------------------------------------------------- STATUS FUNKCJONALNOŚCI: `Kubernetes 1.22 [stable]` Warstwa sterowania Kubernetesa ustawia niezmienną [etykietę](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/labels) `kubernetes.io/metadata.name` na wszystkich przestrzeniach nazw. Wartością etykiety jest nazwa przestrzeni nazw. Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej) --------------------------------------------------------------------- * Dowiedz się więcej o [tworzeniu przestrzeni nazw](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace) . * Dowiedz się więcej o [usuwaniu przestrzeni nazw](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace) . 1.2.4 - Adnotatcje[](https://kubernetes.io/pl/docs/concepts/_print/#pg-93cd7a1d4e1623e2bf01afc49a5af69c) ========================================================================================================= Możesz używać Kubernetesowych adnotacji do dołączania dodatkowych (czyli takich, które nie są wykorzystywane przy identyfikacji) metadanych do [obiektów](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/#kubernetes-objects) . Narzędzia i biblioteki mogą odczytywać te metadane. Dołączanie metadanych do obiektów[](https://kubernetes.io/pl/docs/concepts/_print/#attaching-metadata-to-objects) ------------------------------------------------------------------------------------------------------------------ Możesz używać etykiet (ang. labels) lub adnotacji (ang. annotations), aby dołączać metadane do obiektów Kubernetesa. Etykiety pomagają w wybieraniu obiektów i wyszukiwaniu ich zbiorów na podstawie określonych warunków. Z kolei adnotacje nie są używane do identyfikacji ani selekcji obiektów. Metadane w adnotacjach mogą mieć dowolny rozmiar i strukturę - mogą być małe lub duże, uporządkowane lub nie, i zawierać znaki niedozwolone w etykietach. Dopuszczalne jest jednoczesne użycie etykiet i adnotacji w tym samym obiekcie. Adnotacje, podobnie jak etykiety, są mapami klucz/wartość: "metadata": { "annotations": { "key1" : "value1", "key2" : "value2" } } #### Informacja: Klucze i wartości w mapie muszą być ciągami znaków. Innymi słowy, nie można używać wartości numerycznych, logicznych, list ani innych typów ani dla kluczy, ani dla wartości. Oto przykłady informacji, które mogą być zapisane w adnotacjach: * Pola zarządzane przez warstwę konfiguracji deklaratywnej. Dołączanie tych pól jako adnotacji odróżnia je od wartości domyślnych ustawianych przez klientów lub serwery, oraz od pól generowanych automatycznie i pól ustawianych przez systemy automatycznego skalowania lub automatycznego dopasowywania rozmiaru. * Informacje dotyczące kompilacji, wersji lub obrazów, takie jak znaczniki czasu, identyfikatory wersji, gałąź git, numery PR, skróty obrazów i adres rejestru. * Referencje do zewnętrznych źródeł danych takich jak logi, metryki monitorujące, wyniki analiz czy dane audytowe. * Informacje o bibliotece klienckiej lub narzędziu, które mogą być wykorzystane do debugowania - na przykład nazwa, wersja i dane o kompilacji. * Informacje o pochodzeniu użytkownika, narzędzia lub systemu, takie jak adresy URL powiązanych obiektów z innych komponentów ekosystemu. * Metadane wykorzystywane przez proste narzędzia do wdrażania zmian (rollout), takie jak zapis stanu konfiguracji lub punktów kontrolnych służących do śledzenia postępu wdrożenia. * Numery telefonów lub pagerów osób odpowiedzialnych, lub wpisy do katalogu określające, gdzie można znaleźć te informacje, takie jak strona internetowa zespołu. * Instrukcje od użytkownika końcowego kierowane do implementacji, mające na celu zmianę zachowania systemu lub uruchomienie niestandardowych funkcji. Zamiast używać adnotacji, można przechowywać tego typu informacje w zewnętrznej bazie danych lub katalogu, ale to znacznie utrudniłoby tworzenie wspólnych bibliotek klienckich i narzędzi do wdrażania, zarządzania, introspekcji i tym podobnych działań. Składnia i zestaw znaków[](https://kubernetes.io/pl/docs/concepts/_print/#syntax-and-character-set) ---------------------------------------------------------------------------------------------------- _Adnotacje_ są parami klucz/wartość. Prawidłowe klucze adnotacji mają dwa segmenty: opcjonalny prefiks oraz nazwę, oddzielone ukośnikiem (`/`). Segment nazwy jest wymagany i musi mieć maksymalnie 63 znaki, zaczynać się i kończyć znakiem alfanumerycznym (`[a-z0-9A-Z]`) oraz może zawierać myślniki (`-`), podkreślenia (`_`), kropki (`.`) i znaki alfanumeryczne pomiędzy nimi. Prefiks jest opcjonalny. Jeśli zostanie określony, prefiks musi być subdomeną DNS: serią etykiet DNS oddzielonych kropkami (`.`), nie dłuższą w sumie niż 253 znaki, zakończoną ukośnikiem (`/`). Jeśli prefiks jest pominięty, zakłada się, że klucz adnotacji należy wyłącznie do użytkownika. Zautomatyzowane komponenty systemowe (np. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` lub inna automatyzacja firm trzecich), które dodają adnotacje do obiektów końcowego użytkownika, muszą określić prefiks. Prefiksy `kubernetes.io/` i `k8s.io/` są zarezerwowane dla podstawowych komponentów Kubernetesa. Na przykład, oto manifest dla Poda, który posiada adnotację `imageregistry: https://hub.docker.com/` : apiVersion: v1 kind: Pod metadata: name: annotations-demo annotations: imageregistry: "https://hub.docker.com/" spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej) --------------------------------------------------------------------- * Dowiedz się więcej o [Etykietach i Selektorach](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/labels/) . * Znajdź [Typowe etykiety, Adnotacje i Tainty (ang. Taints)](https://kubernetes.io/docs/reference/labels-annotations-taints/) 1.2.5 - Selektory pól[](https://kubernetes.io/pl/docs/concepts/_print/#pg-046c03090d47bc4b89b818dc645c3865) ============================================================================================================ Selektory pól (_Field selectors_) pozwalają na wybór [obiektów](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/#kubernetes-objects) Kubernetesa na podstawie wartości jednego lub kilku pól zasobów. Oto kilka przykładów zapytań z użyciem selektora pól: * `metadata.name=my-service` * `metadata.namespace!=default` * `status.phase=Pending` Polecenie `kubectl` wybiera wszystkie Pody, dla których wartość pola [`status.phase`](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) to `Running`: kubectl get pods --field-selector status.phase=Running #### Informacja: Selektory pól to zasadniczo _filtry_ zasobów. Domyślnie nie stosuje się żadnych selektorów/filtrów, co oznacza, że wszystkie zasoby określonego typu są wybierane. Dzięki temu zapytania `kubectl` `kubectl get pods` i `kubectl get pods --field-selector ""` są równoważne. Obsługiwane pola[](https://kubernetes.io/pl/docs/concepts/_print/#supported-fields) ------------------------------------------------------------------------------------ Obsługiwane selektory pól różnią się w zależności od typu zasobu Kubernetesa. Wszystkie typy zasobów obsługują pola `metadata.name` oraz `metadata.namespace`. Użycie nieobsługiwanych selektorów pól skutkuje błędem. Na przykład: kubectl get ingress --field-selector foo.bar=baz Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" ### Lista obsługiwanych pól[](https://kubernetes.io/pl/docs/concepts/_print/#list-of-supported-fields) | Rodzaj | Pola | | --- | --- | | Pod | `spec.nodeName`
`spec.restartPolicy`
`spec.schedulerName`
`spec.serviceAccountName`
`spec.hostNetwork`
`status.phase`
`status.podIP`
`status.podIPs`
`status.nominatedNodeName` | | Event | `involvedObject.kind`
`involvedObject.namespace`
`involvedObject.name`
`involvedObject.uid`
`involvedObject.apiVersion`
`involvedObject.resourceVersion`
`involvedObject.fieldPath`
`reason`
`reportingComponent`
`source`
`type` | | Secret | `type` | | Namespace | `status.phase` | | ReplicaSet | `status.replicas` | | ReplicationController | `status.replicas` | | Job | `status.successful` | | Node | `spec.unschedulable` | | CertificateSigningRequest | `spec.signerName` | ### Pola zasobów niestandardowych[](https://kubernetes.io/pl/docs/concepts/_print/#custom-resources-fields) Wszystkie niestandardowe typy zasobów obsługują pola `metadata.name` oraz `metadata.namespace`. Dodatkowo, pole `spec.versions[*].selectableFields` w [CustomResourceDefinition](https://kubernetes.io/pl/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) określa, które inne pola w zasobie niestandardowym mogą być używane w selektorach pól. Zobacz [selectable fields for custom resources](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#crd-selectable-fields) aby uzyskać więcej informacji o tym, jak używać selektorów pól z CustomResourceDefinitions. Obsługiwane operatory[](https://kubernetes.io/pl/docs/concepts/_print/#supported-operators) -------------------------------------------------------------------------------------------- Możesz używać operatorów `=`, `==` i `!=` z selektorami pól (`=` and `==` oznaczają to samo). Na przykład ta komenda `kubectl` wybiera wszystkie usługi Kubernetesa, które nie znajdują się w przestrzeni nazw `default`: kubectl get services --all-namespaces --field-selector metadata.namespace!=default #### Informacja: Operatory dla zbiorów ([Set-based operators](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) ) (`in`, `notin`, `exists`) nie są obsługiwane dla selektorów pól. Złożone selektory[](https://kubernetes.io/pl/docs/concepts/_print/#chained-selectors) -------------------------------------------------------------------------------------- Podobnie jak [etykieta](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/labels/) i inne selektory, selektory pól mogą być łączone w postaci listy rozdzielanej przecinkami. To polecenie `kubectl` wybiera wszystkie Pody, dla których `status.phase` nie jest równe `Running`, a pole `spec.restartPolicy` jest równe `Always`: kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always Wiele typów zasobów[](https://kubernetes.io/pl/docs/concepts/_print/#multiple-resource-types) ---------------------------------------------------------------------------------------------- Możesz używać selektorów pól w różnych typach zasobów. To polecenie `kubectl` wybiera wszystkie obiekty typu Statefulset i Service, które nie znajdują się w przestrzeni nazw `default`: kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default 1.2.6 - Zalecane etykiety[](https://kubernetes.io/pl/docs/concepts/_print/#pg-5dd62c6a4a481b4cf1ac50f6799eb581) ================================================================================================================ Możesz wizualizować i zarządzać obiektami Kubernetesa za pomocą większej liczby narzędzi niż tylko kubectl i dashboard. Wspólny zestaw etykiet umożliwia narzędziom współpracę, opisując obiekty w ujednolicony sposób, który wszystkie narzędzia mogą zrozumieć. Poza wsparciem dla narzędzi, rekomendowane etykiety opisują aplikacje tak, aby można było je łatwo wyszukiwać za pomocą zapytań. Metadane są zorganizowane wokół pojęcia _aplikacji_. Kubernetes nie jest platformą typu PaaS i nie posiada ani nie wymusza formalnej definicji aplikacji. Zamiast tego aplikacje mają charakter nieformalny i są opisywane za pomocą metadanych. Definicja tego, co wchodzi w skład aplikacji, jest dość luźna. #### Informacja: Są to zalecane etykiety. Ułatwiają zarządzanie aplikacjami, ale nie są wymagane do działania podstawowych narzędzi. Współdzielone etykiety i adnotacje mają prefiks: `app.kubernetes.io`. Etykiety bez prefiksu są traktowane jako prywatne. Dzięki temu prefiksowi etykiety współdzielone nie kolidują z etykietami definiowanymi przez użytkownika. Etykiety[](https://kubernetes.io/pl/docs/concepts/_print/#labels) ------------------------------------------------------------------ Aby w pełni wykorzystać zalety etykiet, warto dodawać je do każdego obiektu w systemie. | Klucz | Opis | Przykład | Typ | | --- | --- | --- | --- | | `app.kubernetes.io/name` | Nazwa aplikacji | `mysql` | string | | `app.kubernetes.io/instance` | Unikalna nazwa identyfikująca instancję aplikacji | `mysql-abcxyz` | string | | `app.kubernetes.io/version` | Aktualna wersja aplikacji (np. [SemVer 1.0](https://semver.org/spec/v1.0.0.html)
, hash rewizji, itp.) | `5.7.21` | ciąg znaków | | `app.kubernetes.io/component` | Komponent w ramach architektury | `baza danych` | string | | `app.kubernetes.io/part-of` | Nazwa nadrzędnej aplikacji, do której należy ten element | `wordpress` | string | | `app.kubernetes.io/managed-by` | Narzędzie używane do zarządzania operacjami aplikacji | `Helm` | string | Aby zilustrować działanie tych etykiet, rozważ następujący obiekt [StatefulSet](https://kubernetes.io/pl/docs/concepts/workloads/controllers/statefulset/) : # This is an excerpt apiVersion: apps/v1 kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql app.kubernetes.io/instance: mysql-abcxyz app.kubernetes.io/version: "5.7.21" app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress app.kubernetes.io/managed-by: Helm Aplikacje i instancje aplikacji[](https://kubernetes.io/pl/docs/concepts/_print/#applications-and-instances-of-applications) ----------------------------------------------------------------------------------------------------------------------------- Aplikacja może być zainstalowana jeden lub więcej razy w klastrze Kubernetesa, a w niektórych przypadkach w tej samej przestrzeni nazw. Na przykład WordPress może być zainstalowany więcej niż raz, gdzie różne strony internetowe to różne instalacje WordPressa. Nazwa aplikacji i nazwa instancji są rejestrowane oddzielnie. Na przykład, WordPress ma `app.kubernetes.io/name` o wartości `wordpress`, natomiast nazwa instancji jest reprezentowana jako `app.kubernetes.io/instance` z wartością `wordpress-abcxyz`. Umożliwia to identyfikację aplikacji oraz jej instancji. Każda instancja aplikacji musi mieć unikalną nazwę. Przykłady[](https://kubernetes.io/pl/docs/concepts/_print/#examples) --------------------------------------------------------------------- Aby zilustrować różne sposoby wykorzystania tych etykiet, poniższe przykłady mają różny stopień złożoności. ### Prosta usługa bezstanowa (ang. Stateless Service)[](https://kubernetes.io/pl/docs/concepts/_print/#a-simple-stateless-service) Rozważmy przypadek prostego serwisu bezstanowego wdrożonego przy użyciu obiektów `Deployment` i `Service`. Poniższe dwa fragmenty przedstawiają, jak etykiety mogą być używane w najprostszej formie. `Deployment` jest używany do nadzorowania podów uruchamiających samą aplikację. apiVersion: apps/v1 kind: Deployment metadata: labels: app.kubernetes.io/name: myservice app.kubernetes.io/instance: myservice-abcxyz ... `Service` służy do udostępniania aplikacji. apiVersion: v1 kind: Service metadata: labels: app.kubernetes.io/name: myservice app.kubernetes.io/instance: myservice-abcxyz ... ### Aplikacja webowa z bazą danych[](https://kubernetes.io/pl/docs/concepts/_print/#web-application-with-a-database) Rozważmy nieco bardziej skomplikowaną aplikację: aplikację webową (WordPress) korzystającą z bazy danych (MySQL), zainstalowaną za pomocą Helm. Poniższe fragmenty ilustrują początek obiektów użytych do wdrożenia tej aplikacji. Początek następującego `Deployment` jest używany dla WordPressa: apiVersion: apps/v1 kind: Deployment metadata: labels: app.kubernetes.io/name: wordpress app.kubernetes.io/instance: wordpress-abcxyz app.kubernetes.io/version: "4.9.4" app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: server app.kubernetes.io/part-of: wordpress ... `Service` jest używany do udostępniania WordPressa: apiVersion: v1 kind: Service metadata: labels: app.kubernetes.io/name: wordpress app.kubernetes.io/instance: wordpress-abcxyz app.kubernetes.io/version: "4.9.4" app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: server app.kubernetes.io/part-of: wordpress ... MySQL jest udostępniany jako `StatefulSet` z metadanymi zarówno dla niego, jak i dla nadrzędnej aplikacji, do której należy: apiVersion: apps/v1 kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql app.kubernetes.io/instance: mysql-abcxyz app.kubernetes.io/version: "5.7.21" app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress ... `Serwis` jest używany do udostępniania MySQL jako część WordPressa: apiVersion: v1 kind: Service metadata: labels: app.kubernetes.io/name: mysql app.kubernetes.io/instance: mysql-abcxyz app.kubernetes.io/version: "5.7.21" app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress ... W `StatefulSet` i `Service` dla MySQL zawarte są informacje zarówno o MySQL, jak i o WordPressie, czyli nadrzędnej aplikacji. 1.3 - API Kubernetesa[](https://kubernetes.io/pl/docs/concepts/_print/#pg-0c745f42e623d2b70a53bc0e6db73d95) ============================================================================================================ API Kubernetesa służy do odpytywania i zmiany stanu obiektów Kubernetesa. Sercem warstwy sterowania Kubernetesa jest serwer API i udostępniane po HTTP API. Przez ten serwer odbywa się komunikacja pomiędzy użytkownikami, różnymi częściami składowymi klastra oraz komponentami zewnętrznymi. Sercem [warstwy sterowania](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-control-plane) Kubernetesa jest [serwer API](https://kubernetes.io/pl/docs/concepts/architecture/#kube-apiserver) . Serwer udostępnia API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra i komponentami zewnętrznymi. API Kubernetesa pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_). Większość operacji może zostać wykonana poprzez interfejs linii komend (CLI) [kubectl](https://kubernetes.io/docs/reference/kubectl/) lub inne programy, takie jak [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/) , które używają API. Możesz też korzystać z API bezpośrednio przez wywołania typu REST. Jeśli piszesz aplikację używającą API Kubernetesa, warto rozważyć użycie jednej z [bibliotek klienckich](https://kubernetes.io/docs/reference/using-api/client-libraries/) . Każdy klaster Kubernetesa publikuje specyfikację dostępnych interfejsów API. Dostępne są dwa mechanizmy udostępniania tych specyfikacji, które umożliwiają automatyczną integrację i interoperacyjność z narzędziami zewnętrznymi. Na przykład narzędzie `kubectl` pobiera i buforuje specyfikację API w celu umożliwienia autouzupełniania wiersza poleceń i innych funkcji. Te dwa mechanizmy to: * [Discovery API](https://kubernetes.io/pl/docs/concepts/_print/#discovery-api) dostarcza informacji o interfejsach API Kubernetesa: nazwach API, zasobach, wersjach i obsługiwanych operacjach. W Kubernetesie ten termin ma szczególne znaczenie, ponieważ to odrębny interfejs od OpenAPI i jest traktowany jako osobna część systemu. Jest to zwięzłe podsumowanie dostępnych zasobów i nie obejmuje szczegółowych definicji schematów. Szczegółowe informacje o strukturze zasobów można znaleźć w dokumencie OpenAPI. * [Kubernetes OpenAPI Document](https://kubernetes.io/pl/docs/concepts/_print/#openapi-interface-definition) dostarcza (pełne) [schematy OpenAPI v2.0 i 3.0](https://www.openapis.org/) dla wszystkich endpointów API Kubernetesa. OpenAPI v3 to zalecany sposób uzyskiwania dostępu do specyfikacji API, ponieważ zapewnia pełniejszy i dokładniejszy obraz. Zawiera wszystkie ścieżki API oraz komplet danych wejściowych i wyjściowych dla każdej operacji na wszystkich endpointach. Specyfikacja obejmuje także wszystkie rozszerzenia wspierane przez klaster. Jest to pełna definicja API, która znacząco przewyższa pod względem szczegółowości dane z Discovery API. Discovery API[](https://kubernetes.io/pl/docs/concepts/_print/#discovery-api) ------------------------------------------------------------------------------ Kubernetes przez Discovery API udostępnia pełną listę obsługiwanych grup API, ich wersji oraz zasobów. Dla każdego zasobu można uzyskać następujące dane: * Nazwa * Klaster lub zasięg w przestrzeni nazw * URL endpointu oraz obsługiwane metody HTTP * Alternatywne nazwy * Grupa, wersja, typ API jest dostępne zarówno w formie zagregowanej, jak i niezagregowanej. W trybie zagregowanym Discovery API udostępnia dwa endpointy, natomiast w trybie niezagregowanym jest to oddzielny endpoint dla każdej wersji grupy. ### Zagregowane Discovery API[](https://kubernetes.io/pl/docs/concepts/_print/#aggregated-discovery) STATUS FUNKCJONALNOŚCI: `Kubernetes v1.30 [stable]`(domyślnie włączone) Kubernetes zapewnia stabilne wsparcie dla zagregowanego Discovery API, publikując wszystkie zasoby obsługiwane przez klaster za pośrednictwem dwóch endpointów (`/api` i `/apis`). Korzystanie z tych endpointów znacząco ogranicza liczbę zapytań potrzebnych do pobrania danych z klastra. Dostęp do tych danych uzyskuje się, wysyłając żądanie na odpowiedni endpoint z nagłówkiem `Accept`, który wskazuje na zagregowany zasób Discovery: `Accept: application/json;v=v2;g=apidiscovery.k8s.io;as=APIGroupDiscoveryList`. W przypadku braku nagłówka `Accept` wskazującego typ zasobu, zapytania do endpointów `/api` i `/apis` zwracają domyślnie dane w formacie niezagregowanym. [Discovery document](https://github.com/kubernetes/kubernetes/blob/release-1.35/api/discovery/aggregated_v2.json) znajduje się w oficjalnym repozytorium GitHub Kubernetesa. Może on służyć jako odniesienie do podstawowego zestawu zasobów dostępnych w Kubernetesie, gdy nie masz możliwości wykonania zapytania do rzeczywistego klastra. Endpoint obsługuje także mechanizm ETag oraz możliwość przesyłania danych w formacie protobuf. ### Niezagregowane Discovery API[](https://kubernetes.io/pl/docs/concepts/_print/#unaggregated-discovery) W przypadku braku agregacji Discovery API, dane udostępniane są w strukturze wielopoziomowej, w której główne endpointy publikują informacje prowadzące do podrzędnych dokumentów. Wszystkie wersje grup API dostępnych w klastrze są udostępniane pod endpointami /api i /apis. Oto przykład: { "kind": "APIGroupList", "apiVersion": "v1", "groups": [\ {\ "name": "apiregistration.k8s.io",\ "versions": [\ {\ "groupVersion": "apiregistration.k8s.io/v1",\ "version": "v1"\ }\ ],\ "preferredVersion": {\ "groupVersion": "apiregistration.k8s.io/v1",\ "version": "v1"\ }\ },\ {\ "name": "apps",\ "versions": [\ {\ "groupVersion": "apps/v1",\ "version": "v1"\ }\ ],\ "preferredVersion": {\ "groupVersion": "apps/v1",\ "version": "v1"\ }\ },\ ...\ }\ \ \ Żeby pobrać informacje o zasobach dostępnych w konkretnej wersji API, trzeba wysłać osobne zapytanie pod `/apis//` - np. `/apis/rbac.authorization.k8s.io/v1alpha1`. Ten endpoint zawiera listę typów zasobów w danej grupie. Używa go polecenie kubectl, żeby dowiedzieć się, jakie zasoby są dostępne w klastrze.\ \ Interfejs OpenAPI[](https://kubernetes.io/pl/docs/concepts/_print/#openapi-interface-definition)\ \ -------------------------------------------------------------------------------------------------\ \ Pełną specyfikację API udokumentowano za pomocą [OpenAPI](https://www.openapis.org/)\ .\ \ Kubernetes obsługuje zarówno OpenAPI 2.0, jak i 3.0. Wersja 3 jest preferowana, ponieważ umożliwia dokładniejszy i kompletny opis zasobów (bez utraty informacji). W OpenAPI 2 niektóre pola, np. `default`, `nullable`, `oneOf`, są pomijane z powodu ograniczeń formatu.\ \ ### OpenAPI V2[](https://kubernetes.io/pl/docs/concepts/_print/#openapi-v2)\ \ Serwer API Kubernetesa udostępnia specyfikację OpenAPI poprzez ścieżkę `/openapi/v2`. Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z tabelą:\ \ | | | |\ | --- | --- | --- |Dopuszczalne wartości nagłówka żądania dla zapytań OpenAPI v2\ | Nagłówek | Dopuszczalne wartości | Uwagi |\ | --- | --- | --- |\ | `Accept-Encoding` | `gzip` | _pominięcie tego nagłówka jest dozwolone_ |\ | `Accept` | `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` | _głównie do celu komunikacji wewnątrz klastra_ |\ | `application/json` | _domyślne_ |\ | `*` | _udostępnia_ `application/json` |\ \ #### Ostrzeżenie:\ \ Reguły walidacyjne publikowane w ramach schematów OpenAPI mogą być niekompletne – i zazwyczaj nie zawierają wszystkich warunków. Dodatkowa walidacja realizowana jest przez serwer API. Aby uzyskać pełną i precyzyjną weryfikację, zaleca się użycie polecenia `kubectl apply --dry-run=server`, które uruchamia wszystkie mechanizmy walidacji, również te wykonujące się podczas przyjmowania zasobów do klastra (ang. admission checks).\ \ ### OpenAPI V3[](https://kubernetes.io/pl/docs/concepts/_print/#openapi-v3)\ \ STATUS FUNKCJONALNOŚCI: `Kubernetes v1.27 [stable]`(domyślnie włączone)\ \ Kubernetes publikuje własne API zgodnie ze specyfikacją OpenAPI v3.\ \ Pod adresem `/openapi/v3` można znaleźć listę wszystkich dostępnych grup/wersji. Zwracane wartości są dostępne tylko w formacie JSON. Grupy/wersje opisane są następującym schematem:\ \ {\ "paths": {\ ...,\ "api/v1": {\ "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF"\ },\ "apis/admissionregistration.k8s.io/v1": {\ "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597"\ },\ ....\ }\ }\ \ \ Względne adresy URL wskazują na niezmieniające się opisy OpenAPI, aby umożliwić trzymanie cache po stronie klienta. Serwer API zwraca również odpowiednie nagłówki HTTP dla cache (`Expires` ustawione na 1 rok wprzód, `Cache-Control` jako `immutable`). Wysłanie zapytania do nieaktualnego URL spowoduje przekierowanie przez serwer API do wersji najnowszej.\ \ Serwer API Kubernetesa udostępnia specyfikację OpenAPI v3 pod adresem `/openapi/v3/apis//?hash=`, zgodnie z podziałem na grupy i wersje.\ \ Tabela poniżej podaje dopuszczalne wartości nagłówków żądania.\ \ | | | |\ | --- | --- | --- |Dopuszczalne wartości nagłówka żądania dla zapytań OpenAPI v3\ | Nagłówek | Dopuszczalne wartości | Uwagi |\ | --- | --- | --- |\ | `Accept-Encoding` | `gzip` | _pominięcie tego nagłówka jest dozwolone_ |\ | `Accept` | `application/com.github.proto-openapi.spec.v3@v1.0+protobuf` | _głównie do celu komunikacji wewnątrz klastra_ |\ | `application/json` | _domyślne_ |\ | `*` | _udostępnia_ `application/json` |\ \ W pakiecie [`k8s.io/client-go/openapi3`](https://pkg.go.dev/k8s.io/client-go/openapi3)\ znajduje się implementacja w Golang do pobierania OpenAPI V3.\ \ Kubernetes 1.35 publikuje OpenAPI w wersji 2.0 i 3.0; nie ma planów wsparcia wersji 3.1 w najbliższej przyszłości.\ \ ### Serializacja Protobuf[](https://kubernetes.io/pl/docs/concepts/_print/#protobuf-serialization)\ \ Kubernetes implementuje alternatywny format serializacji oparty na Protobuf, który jest głównie przeznaczony do komunikacji w obrębie klastra. Aby uzyskać więcej informacji na temat tego formatu, zobacz [Kubernetes Protobuf serialization](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md)\ propozycję projektową oraz pliki Interface Definition Language (IDL) dla każdego schematu znajdujące się w pakietach Go, które definiują obiekty API.\ \ Przechowywanie stanu[](https://kubernetes.io/pl/docs/concepts/_print/#persistence)\ \ -----------------------------------------------------------------------------------\ \ Kubernetes przechowuje serializowany stan swoich obiektów w [etcd](https://kubernetes.io/pl/docs/tasks/administer-cluster/configure-upgrade-etcd/)\ .\ \ Grupy i wersje API[](https://kubernetes.io/pl/docs/concepts/_print/#api-groups-and-versioning)\ \ -----------------------------------------------------------------------------------------------\ \ Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub `/apis/rbac.authorization.k8s.io/v1alpha1`.\ \ Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach poszczególnych zasobów lub pól, aby być pewnym, że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania oraz pozwala na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej.\ \ Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy [_grupy API_](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)\ , które mogą być [włączane i wyłączane](https://kubernetes.io/docs/reference/using-api/#enabling-or-disabling)\ .\ \ Zasoby API są rozróżniane poprzez przynależność do grupy API, typ zasobu, przestrzeń nazw (_namespace_, o ile ma zastosowanie) oraz nazwę. Serwer API może przeprowadzać konwersję między różnymi wersjami API w sposób niewidoczny dla użytkownika: wszystkie te różne wersje reprezentują w rzeczywistości ten sam zasób. Serwer API może udostępniać te same dane poprzez kilka różnych wersji API.\ \ Załóżmy przykładowo, że istnieją dwie wersje `v1` i `v1beta1` tego samego zasobu. Obiekt utworzony przez wersję `v1beta1` może być odczytany, zaktualizowany i skasowany zarówno przez wersję `v1beta1`, jak i `v1`, do czasu aż wersja `v1beta1` będzie przestarzała i usunięta. Wtedy możesz dalej korzystać i modyfikować obiekt poprzez wersję `v1`.\ \ ### Zmiany w API[](https://kubernetes.io/pl/docs/concepts/_print/#api-changes)\ \ Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb. Dlatego Kubernetes został tak zaprojektowany, aby API mogło się zmieniać i rozrastać. Projekt Kubernetes dąży do tego, aby nie wprowadzać zmian niezgodnych z istniejącymi aplikacjami klienckimi i utrzymywać zgodność przez wystarczająco długi czas, aby inne projekty zdążyły się dostosować do zmian.\ \ W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól jest regulowane przez [API deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ .\ \ Po osiągnięciu przez API statusu ogólnej dostępności (_general availability_ - GA), oznaczanej zazwyczaj jako wersja API `v1`, bardzo zależy nam na utrzymaniu jej zgodności w kolejnych wydaniach. Dodatkowo, Kubernetes zachowuje kompatybilność z danymi zapisanymi za pomocą wersji _beta_. Gdy dana funkcja osiąga stabilność (GA), dane te mogą być automatycznie konwertowane i dostępne w docelowej wersji API.\ \ Jeśli korzystasz z wersji beta API, musisz przejść na kolejną wersję beta lub stabilną, gdy dana wersja zostanie wycofana. Najlepszy moment na migrację to okres wycofywania wersji beta - wtedy obiekty są dostępne równocześnie w obu wersjach API. Po zakończeniu tego okresu wersja beta przestaje być obsługiwana i konieczne jest użycie wersji docelowej.\ \ #### Informacja:\ \ Mimo, że Kubernetes stara się także zachować zgodność dla API w wersji _alpha_, zdarzają się przypadki, kiedy nie jest to możliwe. Jeśli korzystasz z API w wersji alfa, przed aktualizacją klastra do nowej wersji zalecamy sprawdzenie w informacjach o wydaniu, czy nie nastąpiła jakaś zmiana w tej części API. Może się okazać, że API uległo niekompatybilnym zmianom, co wymaga usunięcia wszystkich istniejących obiektów alfa przed wykonaniem aktualizacji.\ \ Zajrzyj do [API versions reference](https://kubernetes.io/docs/reference/using-api/#api-versioning)\ po szczegółowe definicje różnych poziomów wersji API.\ \ Rozbudowa API[](https://kubernetes.io/pl/docs/concepts/_print/#api-extension)\ \ ------------------------------------------------------------------------------\ \ API Kubernetesa można rozszerzać na dwa sposoby:\ \ 1. [Definicje zasobów własnych (_custom resources_)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)\ pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane przez Ciebie zasoby API.\ 2. Można także rozszerzać API Kubernetesa implementując [warstwę agregacji](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)\ .\ \ Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej)\ \ ---------------------------------------------------------------------\ \ * Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych [CustomResourceDefinition](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)\ .\ * [Controlling Access To The Kubernetes API](https://kubernetes.io/docs/concepts/security/controlling-access/)\ opisuje sposoby, jakimi klaster zarządza dostępem do API.\ * Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](https://kubernetes.io/docs/reference/kubernetes-api/)\ .\ * Aby dowiedzieć się, jaki rodzaj zmian można określić jako zgodne i jak zmieniać API, zajrzyj do [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)\ .\ \ 2 - Architektura klastra[](https://kubernetes.io/pl/docs/concepts/_print/#pg-2bf36ccd6b3dbeafecf87c39761b07c7)\ \ ===============================================================================================================\ \ Podstawowe założenia architektury Kubernetesa.\ \ Klaster Kubernetesa składa się z warstwy sterowania oraz zestawu maszyn roboczych, zwanych węzłami, które uruchamiają konteneryzowane aplikacje. Każdy klaster potrzebuje co najmniej jednego węzła roboczego, aby obsługiwać Pody.\ \ Węzeł roboczy hostuje Pody, które są komponentami _workload_ aplikacji. Warstwa sterowania zarządza węzłami roboczymi oraz Podami w klastrze. W środowiskach produkcyjnych, warstwa sterowania zazwyczaj działa na wielu komputerach, a klaster zazwyczaj działa na wielu węzłach, zapewniając odporność na awarie i wysoką dostępność.\ \ Ten dokument opisuje różne komponenty, które musisz posiadać, aby mieć kompletny i działający klaster Kubernetesa.\ \ ![Warstwa sterowania (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) oraz kilka węzłów. Każdy węzeł uruchamia kubelet i kube-proxy.](https://kubernetes.io/images/docs/kubernetes-cluster-architecture.svg)\ \ Rysunek 1. Komponenty klastra Kubernetesa.\ \ About this architecture\ \ Diagram na Rysunku 1 przedstawia przykładową referencyjną architekturę klastra Kubernetesa. Rzeczywisty rozkład komponentów może różnić się w zależności od specyficznych konfiguracji klastra i wymagań.\ \ Na schemacie każdy węzeł uruchamia komponent [`kube-proxy`](https://kubernetes.io/pl/docs/concepts/_print/#kube-proxy)\ . Potrzebujesz komponentu sieciowego proxy na każdym węźle, aby zapewnić, że API [Service](https://kubernetes.io/pl/docs/concepts/services-networking/service/)\ i związane z nim zachowania są dostępne w sieci klastra. Niektóre wtyczki sieciowe jednak dostarczają własne, zewnętrzne implementacje proxy. Kiedy korzystasz z tego rodzaju wtyczki sieciowej, węzeł nie musi uruchamiać `kube-proxy`.\ \ Komponenty warstwy sterowania[](https://kubernetes.io/pl/docs/concepts/_print/#control-plane-components)\ \ ---------------------------------------------------------------------------------------------------------\ \ Komponenty warstwy sterowania podejmują globalne decyzje dotyczące klastra (na przykład harmonogramowanie), a także wykrywają i reagują na zdarzenia klastra (na przykład uruchamianie nowego [poda](https://kubernetes.io/pl/docs/concepts/workloads/pods/)\ gdy nie zgadza się liczba `[replik](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-replica) ` Deploymentu.\ \ Elementy warstwy sterowania mogą być uruchamiane na dowolnej maszynie w klastrze. Jednakże, dla uproszczenia, skrypty instalacyjne zazwyczaj uruchamiają wszystkie elementy warstwy sterowania na tej samej maszynie i nie uruchamiają kontenerów użytkownika na tej maszynie. Zobacz [Tworzenie klastrów o wysokiej dostępności za pomocą kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/)\ dla przykładowej konfiguracji warstwy sterowania, która działa na wielu maszynach.\ \ ### kube-apiserver[](https://kubernetes.io/pl/docs/concepts/_print/#kube-apiserver)\ \ Serwer API jest składnikiem [warstwy sterowania](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-control-plane)\ Kubernetesa, który udostępnia API. Server API służy jako front-end warstwy sterowania Kubernetesa.\ \ Podstawową implementacją serwera API Kubernetesa jest [kube-apiserver](https://kubernetes.io/docs/reference/generated/kube-apiserver/)\ . kube-apiserver został zaprojektowany w taki sposób, aby móc skalować się horyzontalnie — to oznacza, że zwiększa swoją wydajność poprzez dodawanie kolejnych instancji. Można uruchomić kilka instancji kube-apiserver i rozkładać między nimi ruch od klientów.\ \ ### etcd[](https://kubernetes.io/pl/docs/concepts/_print/#etcd)\ \ Magazyn typu klucz-wartość _(key/value store)_, zapewniający spójność i wysoką dostępność, używany do przechowywania wszystkich danych o klastrze Kubernetesa.\ \ Jeśli Twój klaster Kubernetesa używa etcd do przechowywania swoich danych, upewnij się, że masz opracowany plan tworzenia [kopii zapasowych](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)\ tych danych.\ \ Szczegółowe informacje na temat etcd można znaleźć w oficjalnej [dokumentacji](https://etcd.io/docs/)\ .\ \ ### kube-scheduler[](https://kubernetes.io/pl/docs/concepts/_print/#kube-scheduler)\ \ Składnik warstwy sterowania, który śledzi tworzenie nowych [podów](https://kubernetes.io/pl/docs/concepts/workloads/pods/)\ i przypisuje im [węzły](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ , na których powinny zostać uruchomione.\ \ Przy podejmowaniu decyzji o wyborze węzła brane pod uwagę są wymagania indywidualne i zbiorcze odnośnie [zasobów](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-infrastructure-resource)\ , ograniczenia wynikające z polityk sprzętu i oprogramowania, wymagania _affinity_ i _anty-affinity_, lokalizacja danych, zależności między zadaniami i wymagania czasowe.\ \ ### kube-controller-manager[](https://kubernetes.io/pl/docs/concepts/_print/#kube-controller-manager)\ \ Składnik warstwy sterowania odpowiedzialny za uruchamianie [kontrolerów](https://kubernetes.io/pl/docs/concepts/architecture/controller/)\ .\ \ Z poziomu podziału logicznego, każdy [kontroler](https://kubernetes.io/pl/docs/concepts/architecture/controller/)\ jest oddzielnym procesem, ale w celu zmniejszenia złożoności, wszystkie kontrolery są skompilowane do jednego programu binarnego i uruchamiane jako jeden proces.\ \ Istnieje wiele różnych typów kontrolerów. Niektóre z nich to:\ \ * Kontroler węzłów (ang. Node controller): Odpowiada za zauważanie i reagowanie, gdy węzły przestają działać.\ * Kontroler zadania (ang. Job controller): Monitoruje obiekty zadania (Job), które reprezentują jednorazowe zadania, a następnie tworzy Pody, aby wykonały te zadania do końca.\ * Kontroler EndpointSlice: Uzupełnia obiekty EndpointSlice (aby zapewnić połączenie między Services a Pods).\ * Kontroler ServiceAccount: Tworzenie domyślnych obiektów ServiceAccount dla nowych przestrzeni nazw.\ \ Powyższa lista nie jest wyczerpującą.\ \ ### cloud-controller-manager[](https://kubernetes.io/pl/docs/concepts/_print/#cloud-controller-manager)\ \ Element składowy [warstwy sterowania](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-control-plane)\ Kubernetesa, który zarządza usługami realizowanymi po stronie chmur obliczeniowych. Cloud controller manager umożliwia połączenie Twojego klastra z API operatora usług chmurowych i rozdziela składniki operujące na platformie chmurowej od tych, które dotyczą wyłącznie samego klastra.\ \ Manager 'cloud-controller' uruchamia tylko kontrolery specyficzne dla dostawcy chmury. Jeśli uruchamiasz Kubernetesa w swojej siedzibie lub w środowisku do nauki na swoim komputerze osobistym, klaster nie posiada managera 'cloud-controller'.\ \ Podobnie jak kube-controller-manager, cloud-controller-manager łączy kilka logicznie niezależnych pętli kontrolnych w jedną binarkę, którą uruchamiasz jako pojedynczy proces. Możesz go skalować horyzontalnie (uruchamiając więcej niż jedną kopię), aby poprawić wydajność lub pomóc w tolerowaniu awarii.\ \ Następujące kontrolery mogą mieć zależności od dostawcy chmury:\ \ * Kontroler węzłów (ang. Node controller): Do sprawdzania dostawcy chmury w celu ustalenia, czy węzeł został usunięty w chmurze po tym, jak przestaje odpowiadać.\ * Kontroler tras (ang. Route controller): Do konfiguracji tras w podstawowej infrastrukturze chmurowej.\ * Kontroler usługi (ang. Service controller): Do tworzenia, aktualizowania i usuwania load balancerów dostawcy chmury.\ \ * * *\ \ Komponenty węzła[](https://kubernetes.io/pl/docs/concepts/_print/#node-components)\ \ -----------------------------------------------------------------------------------\ \ Komponenty węzła działają na każdym węźle, utrzymując działające pody i zapewniając środowisko wykonawcze Kubernetesa.\ \ ### kubelet[](https://kubernetes.io/pl/docs/concepts/_print/#kubelet)\ \ Agent, który działa na każdym [węźle](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ klastra. Odpowiada za uruchamianie [kontenerów](https://kubernetes.io/pl/docs/concepts/containers/)\ w ramach [poda](https://kubernetes.io/pl/docs/concepts/workloads/pods/)\ .\ \ [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)\ korzysta z dostarczanych (różnymi metodami) _PodSpecs_ i gwarantuje, że kontenery opisane przez te PodSpecs są uruchomione i działają poprawnie. Kubelet nie zarządza kontenerami, które nie zostały utworzone przez Kubernetesa.\ \ ### `kube-proxy` (opcjonalne)[](https://kubernetes.io/pl/docs/concepts/_print/#kube-proxy)\ \ kube-proxy to _proxy_ sieciowe, które uruchomione jest na każdym [węźle](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ klastra i uczestniczy w tworzeniu [serwisu](https://kubernetes.io/pl/docs/concepts/services-networking/service/)\ .\ \ [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)\ utrzymuje reguły sieciowe na węźle. Dzięki tym regułom sieci na zewnątrz i wewnątrz klastra mogą komunikować się z podami.\ \ kube-proxy używa warstwy filtrowania pakietów dostarczanych przez system operacyjny, o ile taka jest dostępna. W przeciwnym przypadku, kube-proxy samo zajmuje sie przekazywaniem ruchu sieciowego.\ \ Jeśli używasz [wtyczki sieciowej](https://kubernetes.io/pl/docs/concepts/_print/#network-plugins)\ , która samodzielnie implementuje przekazywanie pakietów dla Usług i zapewnia równoważne działanie do kube-proxy, to nie musisz uruchamiać kube-proxy na węzłach w swoim klastrze.\ \ ### Środowisko uruchomieniowe kontenera[](https://kubernetes.io/pl/docs/concepts/_print/#container-runtime)\ \ Podstawowy komponent umożliwiający efektywne uruchamianie kontenerów w Kubernetesie. Odpowiada za zarządzanie uruchamianiem i cyklem życia kontenerów w środowisku Kubernetes.\ \ Kubernetes obsługuje różne _container runtimes_: [containerd](https://containerd.io/docs/)\ , [CRI-O](https://cri-o.io/#what-is-cri-o)\ oraz każdą implementację zgodną z [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)\ .\ \ Dodatki[](https://kubernetes.io/pl/docs/concepts/_print/#addons)\ \ -----------------------------------------------------------------\ \ Dodatki (ang. Addons) wykorzystują zasoby Kubernetesa ([DaemonSet](https://kubernetes.io/pl/docs/concepts/workloads/controllers/daemonset)\ , [Deployment](https://kubernetes.io/pl/docs/concepts/workloads/controllers/deployment/)\ , itp.) do wdrażania funkcji klastra. Ponieważ zapewniają one funkcje na poziomie klastra, zasoby te należą do przestrzeni nazw `kube-system`.\ \ Wybrane dodatki są opisane poniżej; aby uzyskać rozszerzoną listę dostępnych dodatków, zobacz [Dodatki](https://kubernetes.io/docs/concepts/cluster-administration/addons/)\ .\ \ ### DNS[](https://kubernetes.io/pl/docs/concepts/_print/#dns)\ \ Podczas gdy inne dodatki nie są ściśle wymagane, wszystkie klastry Kubernetes powinny mieć [DNS klastra](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)\ , ponieważ wiele elementów na nim polega.\ \ Cluster DNS to serwer DNS, będący uzupełnieniem dla innych serwerów DNS w Twoim środowisku, który obsługuje rekordy DNS dla usług Kubernetes.\ \ Kontenery uruchamiane przez Kubernetesa automatycznie uwzględniają ten serwer DNS w swoich wyszukiwaniach DNS.\ \ ### Interfejs Web UI (Dashboard)[](https://kubernetes.io/pl/docs/concepts/_print/#web-ui-dashboard)\ \ [Dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/)\ to uniwersalny interfejs internetowy dla klastrów Kubernetesa. Umożliwia użytkownikom zarządzanie i rozwiązywanie problemów z aplikacjami działającymi w klastrze, a także samym klastrem.\ \ ### Monitorowanie zasobów kontenerów[](https://kubernetes.io/pl/docs/concepts/_print/#container-resource-monitoring)\ \ [Monitorowanie Zasobów Kontenera](https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)\ rejestruje ogólne metryki dotyczące kontenerów w centralnej bazie danych i udostępnia interfejs użytkownika do przeglądania tych danych.\ \ ### Rejestrowanie na poziomie klastra[](https://kubernetes.io/pl/docs/concepts/_print/#cluster-level-logging)\ \ Mechanizm [logowania na poziomie klastra](https://kubernetes.io/docs/concepts/cluster-administration/logging/)\ jest odpowiedzialny za zapisywanie logów z kontenerów w centralnym magazynie logów z interfejsem do przeszukiwania/przeglądania.\ \ ### Wtyczki sieciowe[](https://kubernetes.io/pl/docs/concepts/_print/#network-plugins)\ \ [Wtyczki sieciowe](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins)\ są komponentami oprogramowania, które implementują specyfikację interfejsu sieciowego kontenera (CNI). Są odpowiedzialne za przydzielanie adresów IP do podów i umożliwianie im komunikacji między sobą w klastrze.\ \ Warianty architektury[](https://kubernetes.io/pl/docs/concepts/_print/#architecture-variations)\ \ ------------------------------------------------------------------------------------------------\ \ Podczas gdy podstawowe komponenty Kubernetesa pozostają niezmienne, sposób ich wdrażania i zarządzania może się różnić. Zrozumienie tych wariacji jest kluczowe dla projektowania i utrzymania klastrów Kubernetesa, które spełniają określone potrzeby operacyjne.\ \ ### Opcje wdrażania warstwy sterowania[](https://kubernetes.io/pl/docs/concepts/_print/#control-plane-deployment-options)\ \ Komponenty warstwy sterowania mogą być wdrażane na kilka sposobów:\ \ Tradycyjna implementacja: : Komponenty warstwy sterowania działają bezpośrednio na dedykowanych maszynach lub maszynach wirtualnych (VM), często zarządzane jako usługi systemd.\ \ Statyczne Pody: : Komponenty warstwy sterowania są wdrażane jako statyczne Pody, zarządzane przez kubelet na określonych węzłach. Jest to powszechne podejście stosowane przez narzędzia takie jak kubeadm.\ \ Samodzielnie hostowane : Warstwa sterowania działa jako Pody wewnątrz samego klastra Kubernetes, zarządzane przez Deploymenty i StatefulSety lub inne obiekty Kubernetesa.\ \ Zarządzane usługi Kubernetesa: Dostawcy usług chmurowych zazwyczaj ukrywają warstwę kontrolną, zarządzając jej elementami w ramach swoich usług.\ \ ### Rozważania dotyczące umieszczania workloadów[](https://kubernetes.io/pl/docs/concepts/_print/#workload-placement-considerations)\ \ Umiejscowienie workloadów, w tym komponentów warstwy sterowania, może różnić się w zależności od wielkości klastra, wymagań dotyczących wydajności i polityk operacyjnych:\ \ * W mniejszych klastrach lub klastrach deweloperskich, komponenty warstwy sterowania i workloady użytkowników mogą działać na tych samych węzłach.\ * Większe klastry produkcyjne często dedykują określone węzły dla komponentów warstwy sterowania, oddzielając je od workloadów użytkowników.\ * Niektóre organizacje uruchamiają krytyczne dodatki lub narzędzia monitorujące na węzłach warstwy sterowania.\ \ ### Narzędzia do zarządzania klastrem[](https://kubernetes.io/pl/docs/concepts/_print/#cluster-management-tools)\ \ Narzędzia takie jak kubeadm, kops i Kubespray oferują różne podejścia do wdrażania i zarządzania klastrami, z których każde ma własną metodę rozmieszczenia i zarządzania komponentami.\ \ ### Dostosowywanie i rozszerzalność[](https://kubernetes.io/pl/docs/concepts/_print/#customization-and-extensibility)\ \ Architektura Kubernetesa pozwala na szeroką konfigurację:\ \ * Niestandardowe schedulery mogą być wdrażane do pracy wraz z domyślnym schedulerem Kubernetesa lub aby całkowicie go zastąpić.\ * Serwery API mogą być rozszerzane za pomocą CustomResourceDefinitions i agregacji API.\ * Dostawcy chmury mogą mocno integrować się z Kubernetesem używając `cloud-controller-manager`.\ \ Elastyczność architektury Kubernetesa umożliwia organizacjom dostosowanie ich klastrów do specyficznych potrzeb, balansując czynniki takie jak złożoność operacyjna, wydajność i narzut na zarządzanie.\ \ Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej)\ \ ---------------------------------------------------------------------\ \ Dowiedz się więcej na temat:\ \ * [Węzły](https://kubernetes.io/docs/concepts/architecture/nodes/)\ i [ich komunikacja](https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/)\ z warstwą sterowania.\ * [Kontrolery Kubernetesa](https://kubernetes.io/docs/concepts/architecture/controller/)\ .\ * [kube-scheduler](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/)\ , czyli domyślny scheduler dla Kubernetesa.\ * Oficjalna [dokumentacja](https://etcd.io/docs/)\ Etcd.\ * Wiele [środowisk uruchomieniowych kontenerów](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)\ w Kubernetesie.\ * Integracja z dostawcami chmury za pomocą [cloud-controller-manager](https://kubernetes.io/docs/concepts/architecture/cloud-controller/)\ .\ * Polecenia [kubectl](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands)\ .\ \ 3 - Kontenery[](https://kubernetes.io/pl/docs/concepts/_print/#pg-a5f7383c83ab9eb9cd0e3c4c020b3ae6)\ \ ====================================================================================================\ \ System "pakowania" aplikacji i jej zależności w spójne środowisko uruchomieniowe.\ \ Ta strona omawia kontenery i obrazy kontenerów, a także ich zastosowanie w utrzymaniu systemów i tworzeniu rozwiązań.\ \ Słowo _kontener (ang. container)_ jest wieloznacznym pojęciem. Zawsze, gdy go używasz, sprawdź, czy Twoi odbiorcy stosują tę samą definicję.\ \ Każdy uruchamiany kontener jest powtarzalny; standaryzacja wynikająca z uwzględnienia zależności oznacza, że uzyskujesz to samo zachowanie, gdziekolwiek go uruchomisz.\ \ Kontenery oddzielają aplikacje od infrastruktury hosta. To ułatwia wdrażanie w różnych środowiskach chmurowych lub systemach operacyjnych.\ \ Każdy [węzeł](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ w klastrze Kubernetesa uruchamia kontenery, które tworzą [Pody](https://kubernetes.io/pl/docs/concepts/workloads/pods/)\ przypisane do tego węzła. Kontenery należące do jednego Poda są uruchamiane razem na tym samym węźle w ramach wspólnego harmonogramu.\ \ Obrazy kontenerów[](https://kubernetes.io/pl/docs/concepts/_print/#container-images)\ \ -------------------------------------------------------------------------------------\ \ [Obraz kontenera](https://kubernetes.io/docs/concepts/containers/images/)\ to gotowy do uruchomienia pakiet oprogramowania zawierający wszystko, co jest potrzebne do uruchomienia aplikacji: kod i wszelkie wymagane środowiska uruchomieniowe, biblioteki aplikacji i systemowe, oraz wartości domyślne dla wszelkich niezbędnych ustawień.\ \ Kontenery są przeznaczone do bycia bezstanowymi i [niezmiennymi](https://glossary.cncf.io/immutable-infrastructure/)\ : nie powinieneś zmieniać kodu kontenera, który już działa. Jeśli masz aplikację konteneryzowaną i chcesz dokonać zmian, właściwym procesem jest zbudowanie nowego obrazu zawierającego zmiany, a następnie odtworzenie kontenera w celu uruchomienia go z zaktualizowanego obrazu.\ \ Środowiska uruchomieniowe kontenerów[](https://kubernetes.io/pl/docs/concepts/_print/#container-runtimes)\ \ ----------------------------------------------------------------------------------------------------------\ \ Podstawowy komponent umożliwiający efektywne uruchamianie kontenerów w Kubernetesie. Odpowiada za zarządzanie uruchamianiem i cyklem życia kontenerów w środowisku Kubernetes.\ \ Kubernetes obsługuje różne _container runtimes_: [containerd](https://containerd.io/docs/)\ , [CRI-O](https://cri-o.io/#what-is-cri-o)\ oraz każdą implementację zgodną z [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)\ .\ \ Zazwyczaj możesz pozwolić swojemu klastrowi na wybranie domyślnego środowiska uruchomieniowego kontenera dla Poda. Jeśli musisz używać więcej niż jednego środowiska uruchomieniowego kontenera w swoim klastrze, możesz określić [RuntimeClass](https://kubernetes.io/docs/concepts/containers/runtime-class/)\ dla Poda, aby upewnić się, że Kubernetes uruchamia te kontenery przy użyciu konkretnego środowiska uruchomieniowego kontenera.\ \ Możesz również użyć RuntimeClass, aby uruchamiać różne Pody z tym samym środowiskiem uruchomieniowym kontenera, ale z różnymi ustawieniami.\ \ 4 - Workload[](https://kubernetes.io/pl/docs/concepts/_print/#pg-d52aadda80edd9f8c514cfe2321363c2)\ \ ===================================================================================================\ \ Poznaj Pody – podstawowy element obliczeniowy w Kubernetes – oraz mechanizmy ułatwiające ich wdrażanie.\ \ Workload to ogólne określenie aplikacji działającej na Kubernetesie. Niezależnie od tego, czy Twój workload jest pojedynczym komponentem, czy kilkoma współpracującymi ze sobą, na Kubernetes uruchamiasz go wewnątrz zestawu [_podów_](https://kubernetes.io/pl/docs/concepts/workloads/pods/)\ . Pod reprezentuje zestaw uruchomionych [kontenerów](https://kubernetes.io/pl/docs/concepts/containers/)\ na Twoim klastrze.\ \ Pody mają [zdefiniowany cykl życia](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)\ . Na przykład, gdy Pod działa w twoim klastrze, krytyczna awaria na [węźle](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ , na którym ten Pod działa, oznacza, że wszystkie Pody na tym węźle przestają działać. Kubernetes traktuje ten typ awarii jako ostateczny: przywrócenie działania wymaga utworzenia nowego Poda, nawet jeśli węzeł później zostanie przywrócony do pełnej sprawności.\ \ Jednak, aby znacznie ułatwić sobie życie, nie musisz zarządzać każdym Podem bezpośrednio. Zamiast tego, możesz użyć obiektów dedykowanych do obsługi _workload-ów_, które zarządzają zestawem Podów w Twoim imieniu. Te zasoby konfigurują [kontrolery](https://kubernetes.io/pl/docs/concepts/architecture/controller/)\ , które zapewniają, że odpowiednia liczba Podów działa, zgodnie z tym, co zdefiniowałeś.\ \ Kubernetes udostępnia kilka wbudowanych typów obiektów przeznaczonych do obsługi _workload-ów_:\ \ * [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\ i [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)\ (zastępując przestarzały zasób [ReplicationController](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-replication-controller)\ ). Deployment jest odpowiedni do zarządzania bezstanowym workloadem aplikacji w klastrze, gdzie każdy Pod w Deployment jest wymienny i może być zastąpiony, jeśli to konieczne.\ * [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)\ pozwala na uruchomienie jednego lub więcej powiązanych Podów, które przechowują stan i potrafią go odtwarzać. Na przykład, jeśli Twój workload zapisuje dane w sposób trwały, możesz uruchomić StatefulSet, który wiąże każdy Pod z [PersistentVolume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)\ . Twój kod, działający w ramach Podów dla tego StatefulSet, może replikować dane do innych Podów w tym samym StatefulSet, aby poprawić ogólną odporność na awarie.\ * [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)\ definiuje Pody, które zapewniają funkcje lokalne dla węzłów. Za każdym razem, gdy dodajesz węzeł do swojego klastra, który pasuje do specyfikacji w DaemonSet, warstwa sterowania zleca uruchomienie Poda dla tego DaemonSet na nowym węźle. Każdy Pod w DaemonSet wykonuje zadanie podobne do demona systemowego na klasycznym serwerze Unix / POSIX. DaemonSet może być fundamentalny dla działania twojego klastra, na przykład jako wtyczka do uruchamiania [infrastuktury sieciowej klastra](https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model)\ , może pomóc w zarządzaniu węzłem, lub może zapewniać opcjonalne funkcje, które ulepszają platformę kontenerową.\ * [Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/)\ i [CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)\ oferują różne sposoby definiowania zadań, które uruchamiają się do zakończenia, a następnie zatrzymują. Możesz użyć [Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/)\ , aby zdefiniować zadanie, które uruchamia się do zakończenia, tylko raz. Możesz użyć [CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)\ , aby uruchomić to samo zadanie (Job) wielokrotnie według harmonogramu.\ \ W szerszym ekosystemie Kubernetesa można znaleźć definicje zadań od firm trzecich, które zapewniają dodatkowe zachowania. Korzystając z [Custom Resource Definition](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)\ , można dodać definicję zadania od firmy trzeciej, jeśli chcesz uzyskać określone działanie, które nie jest częścią podstawowej wersji Kubernetesa. Na przykład, jeśli chcesz uruchomić grupę Podów dla swojej aplikacji, ale zatrzymać pracę, jeśli _wszystkie_ Pody nie są dostępne (może dla jakiegoś zadania wysokoprzepustowego rozproszonego), to można zaimplementować lub zainstalować rozszerzenie, które oferuje tę funkcję.\ \ Rozmieszczanie workloadów[](https://kubernetes.io/pl/docs/concepts/_print/#workload-placement)\ \ -----------------------------------------------------------------------------------------------\ \ STATUS FUNKCJONALNOŚCI: `Kubernetes v1.35 [alpha]`(domyślnie wyłączone)\ \ Podczas gdy standardowe zasoby workloadów (takie jak Deploymenty czy Joby) zarządzają cyklem życia Podów, w niektórych przypadkach możesz mieć złożone wymagania dotyczące harmonogramowania, w których grupy Podów muszą być traktowane jako jedna całość.\ \ [Workload API](https://kubernetes.io/docs/concepts/workloads/workload-api/)\ umożliwia zdefiniowanie grupy Podów oraz zastosowanie do niej zaawansowanych polityk planowania, takich jak [gang scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/gang-scheduling/)\ . Jest to szczególnie przydatne dla workloadów związanych z przetwarzaniem wsadowym i uczeniem maszynowym, gdzie wymagane jest rozmieszczenie "wszystko albo nic".\ \ Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej)\ \ ---------------------------------------------------------------------\ \ Oprócz przeczytania informacji o każdym rodzaju API do zarządzania workloadami, możesz dowiedzieć się, jak wykonywać konkretne zadania:\ \ * [Uruchom aplikację bezstanową za pomocą Deployment](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/)\ \ * Uruchom aplikację stanową jako [pojedynczą instancję](https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/)\ lub jako [zestaw zreplikowany](https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/)\ \ * [Uruchamianie zadań automatycznych za pomocą CronJob](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/)\ \ \ Aby dowiedzieć się więcej o mechanizmach Kubernetesa służących do oddzielania kodu od konfiguracji, odwiedź [Konfiguracja](https://kubernetes.io/pl/docs/concepts/configuration/)\ .\ \ Istnieją dwie wspomagające koncepcje, które dostarczają informacji o tym, jak Kubernetes zarządza Podami dla aplikacji:\ \ * [Mechanizm usuwania zbędnych obiektów (ang. Garbage collection)](https://kubernetes.io/docs/concepts/architecture/garbage-collection/)\ porządkuje obiekty z klastra po usunięciu ich _zasobu właściciela_.\ * [_Kontroler czasu życia po zakończeniu_ (time-to-live after finished)](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)\ usuwa zadania (Jobs) po upływie określonego czasu od ich zakończenia.\ \ Gdy Twoja aplikacja jest uruchomiona, możesz chcieć udostępnić ją w internecie jako [Service](https://kubernetes.io/docs/concepts/services-networking/service/)\ lub, tylko dla aplikacji webowych, używając [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress)\ .\ \ 4.1 - Pod[](https://kubernetes.io/pl/docs/concepts/_print/#pg-4d68b0ccf9c683e6368ffdcc40c838d4)\ \ ================================================================================================\ \ _Pod_ jest najmniejszą jednostką obliczeniową, którą można utworzyć i zarządzać nią w Kubernetesie.\ \ _Pod_ (w języku angielskim: jak w odniesieniu do grupy wielorybów lub strąka grochu) to grupa jednego lub więcej [kontenerów](https://kubernetes.io/pl/docs/concepts/containers/)\ , z współdzielonymi zasobami pamięci i sieci, oraz specyfikacją dotyczącą sposobu uruchamiania kontenerów. Wszystkie komponenty Poda są uruchamiane razem, współdzielą ten sam kontekst i są planowane do uruchomienia na tym samym węźle. Pod modeluje specyficznego dla aplikacji "logicznego hosta": zawiera jeden lub więcej kontenerów aplikacji, które są stosunkowo ściśle ze sobą powiązane. W kontekstach niechmurowych, aplikacje wykonane na tej samej maszynie fizycznej lub wirtualnej są analogiczne do aplikacji chmurowych wykonanych na tym samym logicznym hoście.\ \ Oprócz kontenerów aplikacyjnych, Pod może zawierać [kontenery inicjalizujące](https://kubernetes.io/pl/docs/concepts/workloads/pods/init-containers/)\ uruchamiane podczas startu Pod. Możesz również wstrzyknąć [kontenery efemeryczne](https://kubernetes.io/pl/docs/concepts/workloads/pods/ephemeral-containers/)\ do debugowania działającego Poda.\ \ Czym jest Pod?[](https://kubernetes.io/pl/docs/concepts/_print/#what-is-a-pod)\ \ -------------------------------------------------------------------------------\ \ #### Informacja:\ \ Musisz zainstalować [środowisko uruchomieniowe kontenerów](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)\ na każdym węźle w klastrze, aby mogły tam działać Pody.\ \ Wspólny kontekst Poda to zestaw przestrzeni nazw Linux, cgroups i potencjalnie innych aspektów izolacji - te same elementy, które izolują [kontener (ang. container)](https://kubernetes.io/pl/docs/concepts/containers/)\ . W obrębie kontekstu Poda, poszczególne aplikacje mogą mieć dodatkowo zastosowane dalsze sub-izolacje.\ \ Pod jest podobny do zestawu kontenerów z współdzielonymi przestrzeniami nazw i współdzielonymi woluminami systemu plików.\ \ Pody w klastrze Kubernetesa są używane na dwa główne sposoby:\ \ * **Pody, które uruchamiają pojedynczy kontener**. Model "jeden-kontener-na-Poda" jest najczęstszym przypadkiem użycia; w tym przypadku możesz myśleć o Podzie jako o obudowie wokół pojedynczego kontenera; Kubernetes zarządza Podami, zamiast zarządzać kontenerami bezpośrednio.\ \ * **Pody, które uruchamiają wiele kontenerów, które muszą współdziałać**. Pod może zawierać aplikację składającą się z [wielu współlokalizowanych kontenerów](https://kubernetes.io/pl/docs/concepts/_print/#how-pods-manage-multiple-containers)\ , które są ściśle powiązane i muszą współdzielić zasoby. Te współlokalizowane kontenery tworzą jedną spójną jednostkę.\ \ Grupowanie wielu współlokalizowanych i współzarządzanych kontenerów w jednym Podzie jest stosunkowo zaawansowanym przypadkiem użycia. Ten wzorzec powinieneś używać tylko w określonych przypadkach, gdy twoje kontenery są ściśle powiązane.\ \ Nie musisz uruchamiać wielu kontenerów, aby zapewnić replikację (dla odporności lub pojemności); jeśli potrzebujesz wielu replik, zobacz [zarządzanie workloadami](https://kubernetes.io/pl/docs/concepts/workloads/controllers/)\ .\ \ \ Używanie Podów[](https://kubernetes.io/pl/docs/concepts/_print/#using-pods)\ \ ----------------------------------------------------------------------------\ \ Poniżej znajduje się przykład Poda, który składa się z kontenera uruchamiającego obraz `nginx:1.14.2`.\ \ [`pods/simple-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/pl/examples/pods/simple-pod.yaml)\ ![](https://kubernetes.io/images/copycode.svg "Skopiuj pods/simple-pod.yaml do schowka")\ \ apiVersion: v1\ kind: Pod\ metadata:\ name: nginx\ spec:\ containers:\ - name: nginx\ image: nginx:1.14.2\ ports:\ - containerPort: 80\ \ \ Aby utworzyć Pod pokazany powyżej, uruchom następujące polecenie:\ \ kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml\ \ \ Pody zazwyczaj nie są tworzone bezpośrednio tylko przy użyciu specjalnych zadań (workload). Zobacz [Praca z Podami](https://kubernetes.io/pl/docs/concepts/_print/#working-with-pods)\ aby uzyskać więcej informacji na temat tego, jak Pody są używane z zasobami workload.\ \ ### Zasoby workload do zarządzania podami[](https://kubernetes.io/pl/docs/concepts/_print/#workload-resources-for-managing-pods)\ \ Zazwyczaj nie musisz tworzyć Podów bezpośrednio, nawet pojedynczych Podów. Zamiast tego, twórz je używając zasobów workload, takich jak [Deployment](https://kubernetes.io/pl/docs/concepts/workloads/controllers/deployment/)\ lub [Job](https://kubernetes.io/pl/docs/concepts/workloads/controllers/job/)\ . Jeśli Twoje Pody muszą śledzić stan, rozważ użycie zasobu [StatefulSet](https://kubernetes.io/pl/docs/concepts/workloads/controllers/statefulset/)\ .\ \ Każdy Pod ma na celu uruchomienie pojedynczej instancji danej aplikacji. Jeśli chcesz skalować swoją aplikację horyzontalnie (aby zapewnić więcej zasobów ogółem poprzez uruchomienie większej liczby instancji), powinieneś użyć wielu Podów, jednego dla każdej instancji. W Kubernetesie, operację tę zazwyczaj określa się mianem _replikacji_. Replikowane Pody są zazwyczaj tworzone i zarządzane jako grupa przez zasób workload i jego [kontroler](https://kubernetes.io/pl/docs/concepts/architecture/controller/)\ .\ \ Zobacz [Pody i kontrolery](https://kubernetes.io/pl/docs/concepts/_print/#pods-and-controllers)\ , aby uzyskać więcej informacji na temat tego, jak Kubernetes wykorzystuje zasoby workload oraz ich kontrolery do implementacji skalowania aplikacji i automatycznego naprawiania.\ \ Pody natywnie zapewniają dwa rodzaje zasobów współdzielonych dla ich składowych kontenerów: [sieć](https://kubernetes.io/pl/docs/concepts/_print/#pod-networking)\ i [przechowywanie](https://kubernetes.io/pl/docs/concepts/_print/#pod-storage)\ .\ \ Praca z Podami[](https://kubernetes.io/pl/docs/concepts/_print/#working-with-pods)\ \ -----------------------------------------------------------------------------------\ \ Rzadko będziesz tworzyć indywidualne Pody bezpośrednio w Kubernetesie - nawet pojedyncze Pody. Dzieje się tak, ponieważ Pody są zaprojektowane jako stosunkowo efemeryczne, jednorazowe obiekty. Kiedy Pod zostaje utworzony (bezpośrednio przez Ciebie lub pośrednio przez [kontroller](https://kubernetes.io/pl/docs/concepts/architecture/controller/)\ ), nowy Pod jest planowany do uruchomienia na [węźle](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ w Twoim klastrze. Pod pozostaje na tym węźle, dopóki nie zakończy wykonywania, obiekt Poda nie zostanie usunięty, Pod nie zostanie _usunięty_ z powodu braku zasobów lub węzeł ulegnie awarii.\ \ #### Informacja:\ \ Restartowanie kontenera w Podzie nie powinno być mylone z restartowaniem Poda. Pod nie jest procesem, ale środowiskiem do uruchamiania kontenera(-ów). Pod trwa, dopóki nie zostanie usunięty.\ \ Nazwa Poda musi być prawidłową wartością [poddomeny DNS](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)\ , ale może to powodować nieoczekiwane skutki w odniesieniu do jego nazwy hosta. Dla najlepszej kompatybilności, nazwa powinna spełniać bardziej restrykcyjne zasady dla [etykiety DNS](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/names/#dns-label-names)\ .\ \ ### System operacyjny Poda[](https://kubernetes.io/pl/docs/concepts/_print/#pod-os)\ \ STATUS FUNKCJONALNOŚCI: `Kubernetes v1.25 [stable]`\ \ Powinieneś ustawić pole `.spec.os.name` na `windows` lub `linux`, aby wskazać system operacyjny, na którym chcesz uruchomić swojego Poda. Są to jedyne obsługiwane systemy operacyjne przez Kubernetesa w chwili obecnej. W przyszłości lista ta może zostać rozszerzona.\ \ W Kubernetesie v1.35, wartość `.spec.os.name` nie wpływa na to, w jaki sposób [kube-scheduler](https://kubernetes.io/pl/docs/reference/command-line-tools-reference/kube-scheduler/)\ wybiera węzeł do uruchomienia Poda. W każdym klastrze, w którym istnieje więcej niż jeden system operacyjny dla działających węzłów, powinieneś poprawnie ustawić etykietę [kubernetes.io/os](https://kubernetes.io/docs/reference/labels-annotations-taints/#kubernetes-io-os)\ na każdym węźle i zdefiniować Pody z `nodeSelector` opartym na etykiecie systemu operacyjnego. Kube-scheduler przypisuje Pody do węzłów na podstawie określonych kryteriów, ale nie zawsze gwarantuje wybór węzła z właściwym systemem operacyjnym dla uruchamianych kontenerów. [Standardy bezpieczeństwa Pod](https://kubernetes.io/docs/concepts/security/pod-security-standards/)\ również używają tego pola, aby uniknąć wymuszania polityk, które nie mają zastosowania dla danego systemu operacyjnego.\ \ ### Pody i kontrolery[](https://kubernetes.io/pl/docs/concepts/_print/#pods-and-controllers)\ \ Możesz użyć zasobów workload do tworzenia i zarządzania wieloma Podami. Kontroler dla zasobu obsługuje replikację, wdrażanie oraz automatyczne naprawianie w przypadku awarii Poda. Na przykład, jeśli węzeł ulegnie awarii, kontroler zauważa, że Pody na tym węźle przestały działać i tworzy zastępczego Poda. Scheduler umieszcza zastępczego Poda na zdrowym węźle.\ \ Oto kilka przykładów zasobów workload, które zarządzają Podami:\ \ * [Deployment](https://kubernetes.io/pl/docs/concepts/workloads/controllers/deployment/)\ \ * [StatefulSet](https://kubernetes.io/pl/docs/concepts/workloads/controllers/statefulset/)\ - komponent Kubernetesa służący do zarządzania aplikacjami stateful. StatefulSet zapewnia zachowanie kolejności i spójności danych w ramach aplikacji, co jest kluczowe dla usług wymagających takiego funkcjonowania. StatefulSet śledzi, które identyfikatory Podów są skojarzone z określonymi zasobami pamięci masowej i w jakiej kolejności powinny być tworzone oraz usuwane.\ * [DaemonSet](https://kubernetes.io/pl/docs/concepts/workloads/controllers/daemonset)\ \ \ ### Określanie referencji do Workloadu[](https://kubernetes.io/pl/docs/concepts/_print/#specifying-a-workload-reference)\ \ STATUS FUNKCJONALNOŚCI: `Kubernetes v1.35 [alpha]`(domyślnie wyłączone)\ \ Standardowo Kubernetes uruchamia (ang. schedule) każdy Pod osobno. W przypadku niektórych silnie sprzężonych aplikacji konieczne jest jednoczesne zaplanowanie całej grupy Podów, aby mogły działać poprawnie.\ \ Możesz powiązać Poda z obiektem [Workload](https://kubernetes.io/docs/concepts/workloads/workload-api/)\ , używając specjalnej [referencji do Workloadu](https://kubernetes.io/docs/concepts/workloads/pods/workload-reference/)\ . Informuje to `kube-scheduler`, że Pod należy do określonej grupy, co umożliwia mu podejmowanie skoordynowanych decyzji dotyczących rozmieszczenia całej grupy jednocześnie.\ \ ### Szablony Poda[](https://kubernetes.io/pl/docs/concepts/_print/#pod-templates)\ \ Kontrolery zasobów [workload](https://kubernetes.io/pl/docs/concepts/workloads/)\ tworzą Pody z _szablonu poda_ i zarządzają tymi Podami w Twoim imieniu.\ \ PodTemplates to specyfikacje do tworzenia Podów, które są uwzględniane w zasobach workload, takich jak [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\ , [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/job/)\ i [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)\ .\ \ Każdy kontroler dla zasobu workload używa `PodTemplate` wewnątrz obiektu workload do tworzenia rzeczywistych Podów. `PodTemplate` jest częścią pożądanego stanu dowolnego zasobu workload, którego użyłeś do uruchomienia swojej aplikacji.\ \ Gdy tworzysz Pod, możesz uwzględnić [zmienne środowiskowe](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/)\ w szablonie Poda dla kontenerów, które działają w Podzie.\ \ Poniższy przykład to manifest dla prostego zadania (Job) z `szablonem (template)`, który uruchamia jeden kontener. Kontener w tym Podzie wyświetla komunikat, a następnie się zatrzymuje.\ \ apiVersion: batch/v1\ kind: Job\ metadata:\ name: hello\ spec:\ template:\ # This is the pod template\ spec:\ containers:\ - name: hello\ image: busybox:1.28\ command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']\ restartPolicy: OnFailure\ # The pod template ends here\ \ \ Modyfikacja szablonu poda lub przejście na nowy szablon poda nie ma bezpośredniego wpływu na już istniejące Pody. Jeśli zmienisz szablon poda dla zasobu workload, ten zasób musi utworzyć nowe, zamienne Pody, które korzystają ze zaktualizowanego szablonu.\ \ Na przykład kontroler StatefulSet zapewnia, że uruchomione Pody odpowiadają bieżącemu szablonowi Poda dla każdego obiektu StatefulSet. Jeśli edytujesz StatefulSet, aby zmienić jego szablon, StatefulSet zaczyna tworzyć nowe Pody na podstawie zaktualizowanego szablonu. Ostatecznie, wszystkie stare Pody zostają zastąpione nowymi Podami, a aktualizacja jest zakończona.\ \ Każdy zasób workload implementuje własne zasady dotyczące obsługi zmian w szablonie Pod. Jeśli chcesz dowiedzieć się więcej o StatefulSet, zapoznaj się z [strategią aktualizacji](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets)\ w samouczku podstawy StatefulSet.\ \ Na poziomie węzłów [kubelet](https://kubernetes.io/pl/docs/reference/command-line-tools-reference/kubelet)\ nie kontroluje bezpośrednio szczegółów dotyczących szablonów Podów ani ich aktualizacji – są one zarządzane na wyższym poziomie abstrakcji. Taka separacja upraszcza działanie systemu i pozwala na rozszerzanie funkcjonalności klastra bez ingerencji w istniejący kod.\ \ Aktualizacja i wymiana Poda[](https://kubernetes.io/pl/docs/concepts/_print/#pod-update-and-replacement)\ \ ---------------------------------------------------------------------------------------------------------\ \ Jak wspomniano w poprzedniej sekcji, gdy szablon Poda dla zasobu workload zostaje zmieniony, kontroler tworzy nowe Pody na podstawie zaktualizowanego szablonu zamiast aktualizować lub łatać istniejące Pody.\ \ Kubernetes nie uniemożliwia bezpośredniego zarządzania Podami. Możliwe jest aktualizowanie niektórych pól działającego Poda, na miejscu. Jednak operacje aktualizacji Poda, takie jak [`patch`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#patch-pod-v1-core)\ , oraz [`replace`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#replace-pod-v1-core)\ mają pewne ograniczenia:\ \ * Większość metadanych o Podzie jest niezmienna. Na przykład, nie można zmienić pól `namespace`, `name`, `uid` ani `creationTimestamp`.\ \ * Jeśli parametr `metadata.deletionTimestamp` jest ustawiony, nie można dodać nowego wpisu do listy `metadata.finalizers`.\ \ * Aktualizacje Podów nie mogą zmieniać pól innych niż `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds`, `spec.terminationGracePeriodSeconds`, `spec.tolerations` lub `spec.schedulingGates`. Dla `spec.tolerations` można jedynie dodawać nowe wpisy.\ \ * Podczas aktualizacji pola `spec.activeDeadlineSeconds` dozwolone są dwa typy aktualizacji:\ \ 1. ustawienie nieprzypisanego pola na liczbę dodatnią;\ 2. aktualizacja pola z liczby dodatniej do mniejszej, nieujemnej liczby.\ \ ### Podzasoby Poda[](https://kubernetes.io/pl/docs/concepts/_print/#pod-subresources)\ \ Powyższe zasady aktualizacji dotyczą standardowych zmian w Podach, jednak niektóre pola Poda mogą być aktualizowane za pomocą _podzasobów_.\ \ * **Zmiana rozmiaru:** Podzasób `resize` umożliwia aktualizację zasobów kontenera (`spec.containers [*].resources`). Szczegółowe informacje znajdują się w sekcji [Zmiana rozmiaru zasobów kontenera](https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/)\ .\ * **Kontenery efemeryczne:** Podzasób `ephemeralContainers` umożliwia dodanie do Poda [kontenera efemerycznego](https://kubernetes.io/pl/docs/concepts/workloads/pods/ephemeral-containers/)\ . Aby uzyskać więcej szczegółów zobacz [Kontenery efemeryczne](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/)\ .\ * **Status:** Podzasób `status` umożliwia aktualizację statusu poda. Zazwyczaj jest to używane tylko przez Kubelet i kontrolery systemowe.\ * **Przypisanie Poda do węzła:** Podzasób `binding` umożliwia ustawienie `spec.nodeName` poda za pomocą żądania typu `Binding`. Zazwyczaj jest to używane tylko przez [kube-scheduler](https://kubernetes.io/pl/docs/reference/command-line-tools-reference/kube-scheduler/)\ .\ \ ### Generacja poda[](https://kubernetes.io/pl/docs/concepts/_print/#pod-generation)\ \ * Pole `metadata.generation` jest unikatowe. Zostanie automatycznie ustawione przez system w taki sposób, że nowe pody będą miały ustawioną wartość `metadata.generation` na 1, a każda aktualizacja pól zmiennych w specyfikacji poda zwiększy `metadata.generation` o 1.\ \ STATUS FUNKCJONALNOŚCI: `Kubernetes v1.35 [stable]`(domyślnie włączone)\ \ * Pole `observedGeneration` znajduje się w sekcji `status` obiektu typu Pod. Kubelet aktualizuje `status.observedGeneration`, aby odzwierciedlało ono numer generacji (`metadata.generation`) poda w chwili raportowania jego statusu. Dzięki temu możliwe jest powiązanie aktualnego stanu poda z wersją jego specyfikacji.\ \ #### Informacja:\ \ Pole `status.observedGeneration` jest zarządzane przez kubelet i zewnętrzne kontrolery **nie powinny modyfikować** tego pola.\ \ Różne pola statusu mogą być powiązane z `metadata.generation` bieżącej pętli synchronizacji lub z `metadata.generation` poprzedniej pętli synchronizacji. Kluczowa różnica polega na tym, czy zmiana w `spec` jest bezpośrednio odzwierciedlona w `status`, czy jest pośrednim wynikiem działającego procesu.\ \ #### Bezpośrednie aktualizacje statusu[](https://kubernetes.io/pl/docs/concepts/_print/#direct-status-updates)\ \ Dla pól statusu, gdzie przydzielona specyfikacja jest odzwierciedlona bezpośrednio, `observedGeneration` będzie powiązane z bieżącym `metadata.generation` (Generacja N).\ \ To zachowanie dotyczy:\ \ * **Statusu zmiany przydzielonych zasobów**: Status operacji zmiany rozmiaru zasobu.\ * **Przydzielonych zasobów**: Zasoby przydzielone do Poda po zmianie rozmiaru.\ * **Kontenerów efemerycznych**: Gdy nowy tymczasowy kontener zostaje dodany i znajduje się w stanie `Waiting`.\ \ #### Pośrednie aktualizacje statusu[](https://kubernetes.io/pl/docs/concepts/_print/#indirect-status-updates)\ \ Dla pól statusu, które są pośrednim wynikiem wykonania specyfikacji, pole `observedGeneration` będzie powiązane z wartością z `metadata.generation` z poprzedniej pętli synchronizacji (Generacja N-1).\ \ To zachowanie dotyczy:\ \ * **Obrazu Kontenera**: pole `ContainerStatus.ImageID` odzwierciedla obraz z poprzedniej generacji do momentu pobrania nowego obrazu i zaktualizowania kontenera.\ * **Rzeczywiście używanych zasobów**: Podczas trwającej zmiany rozmiaru, faktycznie wykorzystywane zasoby nadal odpowiadają żądaniu z poprzedniej generacji.\ * **Stanu kontenera**: Podczas trwającej zmiany rozmiaru z wymaganą polityką restartu, stan kontenera odzwierciedla żądanie z poprzedniej generacji.\ * **activeDeadlineSeconds** i **terminationGracePeriodSeconds** oraz **deletionTimestamp**: Zmiany w statusie poda wynikające z tych pól odnoszą się do specyfikacji z poprzedniej generacji.\ \ Udostępnianie zasobów i komunikacja[](https://kubernetes.io/pl/docs/concepts/_print/#resource-sharing-and-communication)\ \ -------------------------------------------------------------------------------------------------------------------------\ \ Pody umożliwiają udostępnianie danych i komunikację pomiędzy swoimi składowymi kontenerami.\ \ ### Pamięć masowa w Podach[](https://kubernetes.io/pl/docs/concepts/_print/#pod-storage)\ \ Pod może określić zestaw współdzielonych zasobów pamięci masowej ([woluminów](https://kubernetes.io/pl/docs/concepts/storage/volumes/)\ ). Wszystkie kontenery w Podzie mają dostęp do tych woluminów, co umożliwia im współdzielenie danych. Woluminy pozwalają również na utrzymanie danych w Podzie, nawet jeśli jeden z jego kontenerów wymaga ponownego uruchomienia. Zobacz sekcję [Storage](https://kubernetes.io/pl/docs/concepts/storage/)\ , aby dowiedzieć się więcej o tym, jak Kubernetes implementuje współdzieloną pamięć masową i udostępnia ją Podom.\ \ ### Sieci Poda[](https://kubernetes.io/pl/docs/concepts/_print/#pod-networking)\ \ Każdy Pod ma przypisany unikalny adres IP dla każdej rodziny adresów. Każdy kontener w Podzie dzieli przestrzeń nazw sieci, w tym adres IP i porty sieciowe. Wewnątrz Poda (i **tylko** wtedy) kontenery, które należą do Poda mogą komunikować się ze sobą za pomocą `localhost`. Kiedy kontenery w Podzie komunikują się z jednostkami _poza Podem_, muszą koordynować sposób korzystania ze wspólnych zasobów sieciowych (takich jak porty). W ramach Poda, kontenery dzielą adres IP i przestrzeń portów, i mogą znaleźć się nawzajem za pośrednictwem `localhost`. Kontenery w Podzie mogą również komunikować się między sobą za pomocą standardowych komunikatów międzyprocesowych, takich jak semafory SystemV lub współdzielona pamięć POSIX. Kontenery w różnych Podach mają różne adresy IP i nie mogą komunikować się poprzez IPC na poziomie systemu operacyjnego bez specjalnej konfiguracji. Kontenery, które chcą nawiązać interakcję z kontenerem działającym w innym Podzie, mogą używać sieci IP do komunikacji.\ \ Kontenery w ramach Pod mają tę samą nazwę hosta systemowego, co skonfigurowane `name` dla Pod. Więcej na ten temat znajduje się w sekcji [sieci](https://kubernetes.io/docs/concepts/cluster-administration/networking/)\ .\ \ Ustawienia zabezpieczeń Poda[](https://kubernetes.io/pl/docs/concepts/_print/#pod-security)\ \ --------------------------------------------------------------------------------------------\ \ Aby ustawić ograniczenia bezpieczeństwa na Podach i kontenerach, używasz pola `securityContext` w specyfikacji Poda. To pole umożliwia szczegółową kontrolę nad tym, co może robić Pod lub poszczególne kontenery. Więcej informacji znajdziesz w sekcji [Zaawansowana konfiguracja Podów](https://kubernetes.io/docs/concepts/workloads/pods/advanced-pod-config/)\ .\ \ W ramach podstawowej konfiguracji bezpieczeństwa należy zapewnić zgodność ze standardem bezpieczeństwa podów _Baseline_ oraz uruchamiać kontenery jako użytkownik niebędący rootem. Możliwe jest skonfigurowanie podstawowych kontekstów bezpieczeństwa:\ \ apiVersion: v1\ kind: Pod\ metadata:\ name: security-context-demo\ spec:\ securityContext:\ runAsUser: 1000\ runAsGroup: 3000\ fsGroup: 2000\ containers:\ - name: sec-ctx-demo\ image: busybox\ command: ["sh", "-c", "sleep 1h"]\ \ \ W celu skonfigurowania zaawansowanych ustawień bezpieczeństwa, takich jak capabilities, profile seccomp czy inne szczegółowe opcje, zobacz rozdział [koncepcje bezpieczeństwa](https://kubernetes.io/pl/docs/concepts/security/)\ .\ \ * Aby dowiedzieć się o ograniczeniach bezpieczeństwa na poziomie jądra, które można użyć, zobacz [Ograniczenia bezpieczeństwa jądra Linux dla Podów i kontenerów](https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints)\ .\ * Aby dowiedzieć się więcej na temat kontekstu bezpieczeństwa Poda, zobacz [Konfigurowanie kontekstu bezpieczeństwa dla Poda lub kontenera](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)\ .\ \ Statyczne Pody[](https://kubernetes.io/pl/docs/concepts/_print/#static-pods)\ \ -----------------------------------------------------------------------------\ \ _Statyczne Pody_ są zarządzane bezpośrednio przez demona kubelet na określonym węźle, bez nadzoru przez [serwer API](https://kubernetes.io/pl/docs/concepts/architecture/#kube-apiserver)\ . Podczas gdy większość Podów jest zarządzana przez warstwę sterowania (na przykład przez [Deployment](https://kubernetes.io/pl/docs/concepts/workloads/controllers/deployment/)\ ), w przypadku statycznych Podów to kubelet bezpośrednio nadzoruje każdy statyczny Pod (i restartuje go, jeśli ulegnie awarii).\ \ Statyczne Pody są zawsze powiązane z jednym komponentem [Kubelet](https://kubernetes.io/pl/docs/reference/command-line-tools-reference/kubelet)\ na konkretnym węźle. Głównym zastosowaniem statycznych Podów jest uruchamianie samodzielnie hostowanej warstwy sterowania: innymi słowy, użycie kubeleta do nadzorowania poszczególnych [komponentów warstwy sterowania](https://kubernetes.io/pl/docs/concepts/architecture/#control-plane-components)\ .\ \ Kubelet automatycznie próbuje utworzyć [Pod lustrzany](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-mirror-pod)\ na serwerze API Kubernetesa dla każdego statycznego Poda. Oznacza to, że Pody działające na węźle są widoczne na serwerze API, ale nie mogą być z niego kontrolowane. Więcej informacji znajdziesz w przewodniku [Tworzenie statycznych Podów](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod)\ .\ \ #### Informacja:\ \ `spec` statycznego Poda nie może odwoływać się do innych obiektów API (np. [ServiceAccount](https://kubernetes.io/pl/docs/tasks/configure-pod-container/configure-service-account/)\ , [ConfigMap](https://kubernetes.io/pl/docs/concepts/configuration/configmap/)\ , [Secret](https://kubernetes.io/pl/docs/concepts/configuration/secret/)\ , itp.).\ \ Pody z wieloma kontenerami[](https://kubernetes.io/pl/docs/concepts/_print/#how-pods-manage-multiple-containers)\ \ -----------------------------------------------------------------------------------------------------------------\ \ Pody są zaprojektowane do obsługi wielu współpracujących procesów (jako kontenery), które tworzą spójną jednostkę usługi. Kontenery w Podzie są automatycznie współlokowane i współharmonogramowane na tej samej fizycznej lub wirtualnej maszynie w klastrze. Kontenery mogą współdzielić zasoby i zależności, komunikować się ze sobą oraz koordynować, kiedy i jak są zakończane.\ \ Pody w klastrze Kubernetesa są używane na dwa główne sposoby:\ \ * **Pody, które uruchamiają pojedynczy kontener**. Model "jeden-kontener-na-Poda" jest najczęstszym przypadkiem użycia; w tym przypadku możesz myśleć o Podzie jako o obudowie wokół pojedynczego kontenera; Kubernetes zarządza Podami, zamiast zarządzać kontenerami bezpośrednio.\ * **Pody, które uruchamiają wiele kontenerów, które muszą współpracować**. Pod może zawierać aplikację składającą się z wielu współlokalizowanych kontenerów, które są ściśle powiązane i muszą współdzielić zasoby. Te współlokalizowane kontenery tworzą jedną spójną jednostkę usługi - na przykład, jeden kontener udostępniający dane przechowywane we współdzielonym wolumenie publicznym, podczas gdy osobny [kontener sidecar](https://kubernetes.io/pl/docs/concepts/workloads/pods/sidecar-containers/)\ odświeża lub aktualizuje te pliki. Pod łączy te kontenery, zasoby pamięci, oraz efemeryczną tożsamość sieciową razem jako jedną jednostkę.\ \ Na przykład, możesz mieć kontener, który działa jako serwer webowy dla plików we współdzielonym wolumenie oraz oddzielny [kontener pomocniczy (ang. sidecar container)](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)\ , który aktualizuje te pliki z zewnętrznego źródła, jak pokazano na poniższym diagramie:\ \ ![Diagram tworzenia Pod](https://kubernetes.io/images/docs/pod.svg)\ \ Niektóre Pody mają [kontenery inicjujące](https://kubernetes.io/pl/docs/concepts/workloads/pods/init-containers/)\ oraz [kontenery aplikacji](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-app-container)\ . Domyślnie, kontenery inicjujące uruchamiają się i kończą przed startem kontenerów aplikacji.\ \ Możesz również mieć [kontenery pomocnicze](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)\ , które świadczą usługi pomocnicze dla głównej aplikacji w Podzie.\ \ STATUS FUNKCJONALNOŚCI: `Kubernetes v1.33 [stable]`(domyślnie włączone)\ \ Domyślnie włączona bramka funkcji `SidecarContainers` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)\ pozwala na określenie `restartPolicy: Always` dla kontenerów inicjalizacyjnych. Ustawienie polityki restartu `Always` zapewnia, że kontenery, dla których ją ustawisz, są traktowane jako _sidecar_ i są utrzymywane w działaniu przez cały czas życia Poda. Kontenery, które określisz jako kontenery sidecar, uruchamiają się przed główną aplikacją w Podzie i pozostają uruchomione do momentu, gdy Pod zostanie zamknięty.\ \ Kontenerowe sondy (ang. Container probes)[](https://kubernetes.io/pl/docs/concepts/_print/#container-probes)\ \ -------------------------------------------------------------------------------------------------------------\ \ _Sonda (ang. probe)_ to diagnostyka wykonywana okresowo przez kubelet na kontenerze. Aby przeprowadzić diagnostykę, kubelet może wywoływać różne akcje:\ \ * `ExecAction` (wykonywane za pomocą środowiska uruchomieniowego kontenera)\ * `TCPSocketAction` (sprawdzane bezpośrednio przez kubelet)\ * `HTTPGetAction` (sprawdzane bezpośrednio przez kubelet)\ \ Możesz przeczytać więcej o [sondach](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)\ w dokumentacji dotyczącej cyklu życia Podów.\ \ Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej)\ \ ---------------------------------------------------------------------\ \ * Dowiedz się więcej o [cyklu życia Poda](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)\ .\ * Przeczytaj o [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/)\ i dowiedz się, jak możesz go używać do zarządzania dostępnością aplikacji podczas zakłóceń.\ * Pod jest zasobem najwyższego poziomu w REST API Kubernetesa. Definicja obiektu [Pod](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/)\ opisuje szczegółowo ten obiekt.\ * [Toolkit systemu rozproszonego: Wzorce dla kontenerów złożonych](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/)\ wyjaśnia typowe układy dla Podów z więcej niż jednym kontenerem.\ * Przeczytaj o [ograniczeniach topologii Podów](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)\ \ * Przeczytaj [Zaawansowaną Konfigurację Podów](https://kubernetes.io/docs/concepts/workloads/pods/advanced-pod-config/)\ , aby szczegółowo poznać ten temat. Ta strona obejmuje aspekty konfiguracji Podów wykraczające poza podstawy, w tym:\ * PriorityClasses\ * RuntimeClasses\ * zaawansowane metody konfigurowania _planowania uruchamiania Podów (ang. scheduling)_: czyli sposobu, w jaki Kubernetes wybiera węzeł dla Poda.\ \ Aby zrozumieć kontekst, dlaczego Kubernetes opakowuje wspólne API Poda w inne zasoby (takie jak [StatefulSets](https://kubernetes.io/pl/docs/concepts/workloads/controllers/statefulset/)\ lub [Deployments](https://kubernetes.io/pl/docs/concepts/workloads/controllers/deployment/)\ ), możesz przeczytać o wcześniejszych rozwiązaniach, w tym:\ \ * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)\ \ * [Borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/)\ \ * [Marathon](https://github.com/d2iq-archive/marathon)\ \ * [Omega](https://research.google/pubs/pub41684/)\ \ * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/)\ .\ \ 4.2 - Zarządzanie Workloadem[](https://kubernetes.io/pl/docs/concepts/_print/#pg-89637410cacae45a36ab1cc278c482eb)\ \ ===================================================================================================================\ \ Kubernetes udostępnia kilka wbudowanych interfejsów API do deklaratywnego zarządzania Twoim [workloadem](https://kubernetes.io/pl/docs/concepts/workloads/)\ oraz jego komponentami.\ \ Twoje aplikacje działają jako kontenery wewnątrz [Podów](https://kubernetes.io/pl/docs/concepts/workloads/pods/)\ ; jednakże zarządzanie pojedynczymi Podami wiąże się z dużym wysiłkiem. Na przykład, jeśli jeden Pod ulegnie awarii, prawdopodobnie będziesz chciał uruchomić nowy Pod, aby go zastąpić. Kubernetes może to zrobić za Ciebie.\ \ Używasz API Kubernetesa aby utworzyć [obiekt](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/#kubernetes-objects)\ zadania (workload), który reprezentuje wyższy poziom abstrakcji niż Pod, a następnie [warstwa sterowania](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-control-plane)\ Kubernetesa automatycznie zarządza obiektami Pod w Twoim imieniu, na podstawie specyfikacji zdefiniowanego przez Ciebie obiektu tego workloadu.\ \ Wbudowane interfejsy API do zarządzania workloadami to:\ \ [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\ (oraz pośrednio [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)\ ), to najczęstszy sposób uruchamiania aplikacji w klastrze. Deployment jest odpowiedni do zarządzania aplikacją bezstanową w klastrze, gdzie każdy Pod w Deployment jest wymienny i może być zastąpiony w razie potrzeby. (Deploymenty zastępują przestarzałe [ReplicationController](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-replication-controller)\ API).\ \ [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)\ pozwala na zarządzanie jednym lub wieloma Podami – wszystkie uruchamiają ten sam kod aplikacji – gdzie Pody opierają się na posiadaniu unikalnej tożsamości. Jest to inne niż w przypadku Deployment, gdzie oczekuje się, że Pody są wymienne. Najczęstszym zastosowaniem StatefulSet jest możliwość powiązania jego Podów z ich trwałą pamięcią masową. Na przykład, można uruchomić StatefulSet, który kojarzy każdy Pod z [PersistentVolume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)\ . Jeśli jeden z Podów w StatefulSet ulegnie awarii, Kubernetes tworzy zastępczy Pod, który jest połączony z tym samym PersistentVolume.\ \ [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)\ definiuje Pody, które zapewniają funkcje lokalne dla określonego [węzła](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ ; na przykład sterownik, który umożliwia kontenerom na tym węźle dostęp do systemu przechowywania danych. DaemonSet jest wykorzystywany w sytuacjach, gdy sterownik lub inna usługa na poziomie węzła musi działać na konkretnym węźle. Każdy Pod w DaemonSet pełni rolę podobną do demona systemowego na klasycznym serwerze Unix / POSIX. DaemonSet może być kluczowy dla działania twojego klastra, na przykład jako wtyczka, która pozwala temu węzłowi uzyskać dostęp do [sieci klastrowej](https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model)\ , może pomóc w zarządzaniu węzłem albo zapewnia mniej istotne funkcje, które wzbogacają używaną platformę kontenerową. Możesz uruchamiać DaemonSety (i ich pody) na każdym węźle w twoim klastrze, lub tylko na podzbiorze (na przykład instalując sterownik GPU tylko na węzłach, które mają zainstalowany GPU).\ \ Możesz użyć [Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/)\ i/lub [CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)\ do zdefiniowania zadań, które działają do momentu ukończenia, a następnie się zatrzymują. `Job` reprezentuje jednorazowe zadanie, podczas gdy każdy `CronJob` powtarza się zgodnie z harmonogramem.\ \ Inne tematy w tej sekcji:\ \ 5 - Usługi, równoważenie obciążenia i sieci w Kubernetesie[](https://kubernetes.io/pl/docs/concepts/_print/#pg-0a0a7eca3e302a3c08f8c85e15d337fd)\ \ =================================================================================================================================================\ \ Pojęcia i zasoby związane z siecią w Kubernetesie.\ \ Model sieciowy Kubernetesa[](https://kubernetes.io/pl/docs/concepts/_print/#the-kubernetes-network-model)\ \ ----------------------------------------------------------------------------------------------------------\ \ Model sieci Kubernetesa składa się z kilku części:\ \ * Każdy [pod](https://kubernetes.io/pl/docs/concepts/workloads/pods/)\ otrzymuje swój własny unikalny adres IP w całym klastrze.\ \ * Pod ma swoją własną, prywatną przestrzeń nazw sieci, która jest współdzielona przez wszystkie kontenery w ramach tego poda. Procesy działające w różnych kontenerach w tym samym podzie mogą komunikować się ze sobą za pośrednictwem `localhost`.\ * _Sieć podów_ (znana również jako sieć klastra) obsługuje komunikację między podami. Zapewnia, że (z zastrzeżeniem celowego segmentowania sieci):\ \ * Wszystkie pody mogą komunikować się ze wszystkimi innymi podami, niezależnie od tego, czy znajdują się na tym samym [węźle](https://kubernetes.io/docs/concepts/architecture/nodes/)\ , czy na różnych węzłach. Pody mogą komunikować się ze sobą bezpośrednio, bez użycia proxy ani translacji adresów (NAT).\ \ W systemie Windows ta reguła nie dotyczy podów z siecią hosta.\ \ * Agenci na węźle (takie jak demony systemowe czy kubelet) mogą komunikować się ze wszystkimi podami na tym węźle.\ \ * Obiekt API [Service](https://kubernetes.io/docs/concepts/services-networking/service/)\ pozwala na udostępnienie stabilnego (długoterminowego) adresu IP lub nazwy hosta dla usługi zrealizowanej przez jeden lub więcej backendowych podów, gdzie poszczególne pody składające się na usługę mogą zmieniać się w czasie.\ \ * Kubernetes automatycznie zarządza obiektami [EndpointSlice](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)\ aby dostarczać informacje o Podach obsługujących daną usługę.\ \ * Implementacja proxy serwisu monitoruje zestaw obiektów Service i EndpointSlice, a także konfiguruje warstwę danych w celu kierowania ruchu serwisowego do jego backendów, używając API systemu operacyjnego lub dostawcy chmury do przechwytywania lub przepisania pakietów.\ \ * Obiekt API [Gateway](https://kubernetes.io/docs/concepts/services-networking/gateway/)\ (lub jego poprzednik, [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)\ ) umożliwia udostępnienie usług klientom znajdującym się poza klastrem.\ \ * Prostszy, ale mniej konfigurowalny mechanizm dostępu do klastra (Ingress) jest dostępny za pośrednictwem API usług (Service) z wykorzystaniem opcji [`type: LoadBalancer`](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer)\ , pod warunkiem korzystania z obsługiwanego dostawcy chmury ([Cloud Provider](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-cloud-provider)\ ).\ * [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies)\ to wbudowane API Kubernetesa, które pozwala na kontrolowanie ruchu pomiędzy podami, lub pomiędzy podami a światem zewnętrznym.\ \ \ W starszych systemach kontenerowych nie było automatycznej łączności pomiędzy kontenerami na różnych hostach, więc często konieczne było jawne tworzenie połączeń między kontenerami lub mapowanie portów kontenerów na porty hostów, aby były osiągalne przez kontenery na innych hostach. W Kubernetesie nie jest to potrzebne; model Kubernetesa polega na tym, że pody mogą być traktowane podobnie jak maszyny wirtualne lub fizyczne hosty z perspektyw alokacji portów, nazewnictwa, wykrywania usług, równoważenia obciążenia, konfiguracji aplikacji i migracji.\ \ Tylko kilka części tego modelu jest implementowanych przez Kubernetesa samodzielnie. Dla pozostałych części Kubernetes definiuje API, ale odpowiadającą funkcjonalność zapewniają zewnętrzne komponenty, z których niektóre są opcjonalne:\ \ * Konfiguracja przestrzeni nazw sieci poda jest obsługiwana przez oprogramowanie systemowe implementujące [Interfejs Uruchomieniowy Kontenera (ang. Container Runtime Interface)](https://kubernetes.io/docs/concepts/containers/cri/)\ .\ \ * Sama sieć podów jest zarządzana przez [implementację sieci podów](https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy)\ . W systemie Linux, większość środowisk uruchomieniowych kontenerów używa [Container Networking Interface (CNI)](https://kubernetes.io/pl/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)\ do interakcji z implementacją sieci podów, dlatego te implementacje często nazywane są _wtyczkami CNI_.\ \ * Kubernetes dostarcza domyślną implementację proxy usług, nazywaną [kube-proxy](https://kubernetes.io/pl/docs/reference/command-line-tools-reference/kube-proxy/)\ , ale niektóre implementacje sieciowe poda używają zamiast tego własnego proxy usług, które jest ściślej zintegrowane z resztą implementacji.\ \ * NetworkPolicy jest zazwyczaj również implementowane przez implementację sieci poda. (Niektóre prostsze implementacje sieci poda nie implementują NetworkPolicy, lub administrator może zdecydować się na skonfigurowanie sieci poda bez wsparcia dla NetworkPolicy. W takich przypadkach API będzie nadal obecne, ale nie będzie miało żadnego efektu.)\ \ * Istnieje wiele [implementacji Gateway API](https://gateway-api.sigs.k8s.io/implementations/)\ , z których niektóre są specyficzne dla określonych środowisk chmurowych, inne bardziej skupione na środowiskach "bare metal", a jeszcze inne bardziej ogólne.\ \ \ Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej)\ \ ---------------------------------------------------------------------\ \ Samouczek [Łączenie aplikacji z usługami](https://kubernetes.io/docs/tutorials/services/connect-applications-service/)\ pozwala na naukę o Usługach i sieciach Kubernetesa poprzez praktyczne przykłady.\ \ Dokumentacja [Sieci Klastra](https://kubernetes.io/docs/concepts/cluster-administration/networking/)\ wyjaśnia, jak skonfigurować sieć dla twojego klastra, a także dostarcza przegląd użytych technologii.\ \ 6 - Przechowywanie danych[](https://kubernetes.io/pl/docs/concepts/_print/#pg-f018f568c6723865753f150c3c59bdda)\ \ ================================================================================================================\ \ Trwałe i tymczasowe mechanizmy przechowywania danych dla Podów w klastrze.\ \ 7 - Konfiguracja[](https://kubernetes.io/pl/docs/concepts/_print/#pg-275bea454e1cf4c5adeca4058b5af988)\ \ =======================================================================================================\ \ Zasoby Kubernetesa wykorzystywane do konfiguracji Podów.\ \ 8 - Bezpieczeństwo[](https://kubernetes.io/pl/docs/concepts/_print/#pg-712cb3c03ff14a39e5a83a6d9b71d203)\ \ =========================================================================================================\ \ Zasady ochrony aplikacji cloud-native.\ \ Ta sekcja dokumentacji Kubernetesa ma na celu pomoc w nauce bezpiecznego uruchamiania workloadów oraz zapoznanie z podstawowymi aspektami utrzymania bezpieczeństwa klastra Kubernetes.\ \ Kubernetes opiera się na architekturze cloud-native i korzysta z porad [CNCF](https://cncf.io/)\ dotyczących dobrych praktyk w zakresie bezpieczeństwa informacji cloud-native.\ \ Przeczytaj [Cloud Native Security and Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/)\ , aby zrozumieć szerszy kontekst zabezpieczania klastrów i uruchamianych na nich aplikacji.\ \ Mechanizmy bezpieczeństwa Kubernetesa[](https://kubernetes.io/pl/docs/concepts/_print/#security-mechanisms)\ \ ------------------------------------------------------------------------------------------------------------\ \ Kubernetes zawiera kilka interfejsów API i mechanizmów bezpieczeństwa, a także sposoby na definiowanie [polityk (ang. policies)](https://kubernetes.io/pl/docs/concepts/_print/#policies)\ , które mogą stanowić część tego, jak zarządzasz bezpieczeństwem informacji.\ \ ### Ochrona warstwy sterowania[](https://kubernetes.io/pl/docs/concepts/_print/#control-plane-protection)\ \ Kluczowym mechanizmem bezpieczeństwa dla każdego klastra Kubernetes jest [kontrolowanie dostępu do API Kubernetesa](https://kubernetes.io/docs/concepts/security/controlling-access)\ .\ \ Kubernetes oczekuje, że skonfigurujesz i użyjesz TLS do zapewnienia [szyfrowania przesyłanych danych](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)\ w obrębie warstwy sterowania oraz pomiędzy warstwą sterowania a jej klientami. Możesz także włączyć [szyfrowanie danych spoczynkowych](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)\ dla danych przechowywanych w obrębie warstwy sterowania Kubernetesa; Nie należy mylić tego z szyfrowaniem danych w stanie spoczynku dla własnych workloadów, co również może być dobrą praktyką.\ \ ### Sekrety (ang. Secret)[](https://kubernetes.io/pl/docs/concepts/_print/#secrets)\ \ Obiekt API [Secret](https://kubernetes.io/docs/concepts/configuration/secret/)\ zapewnia podstawową ochronę dla wartości konfiguracyjnych, które wymagają poufności.\ \ ### Ochrona workloadów[](https://kubernetes.io/pl/docs/concepts/_print/#workload-protection)\ \ Egzekwowanie [standardów bezpieczeństwa poda](https://kubernetes.io/docs/concepts/security/pod-security-standards/)\ zapewnia, że Pody i ich kontenery są odpowiednio izolowane. Możesz również użyć [RuntimeClasses](https://kubernetes.io/docs/concepts/containers/runtime-class)\ do zdefiniowania niestandardowej izolacji, jeśli tego potrzebujesz.\ \ [Polityki sieciowe](https://kubernetes.io/docs/concepts/services-networking/network-policies/)\ pozwalają kontrolować ruch sieciowy pomiędzy Podami lub pomiędzy Podami a siecią poza klastrem.\ \ Możesz wdrażać mechanizmy zabezpieczeń z szerszego ekosystemu, aby wprowadzać środki zapobiegawcze lub detekcyjne wokół Podów, ich kontenerów oraz obrazów, które w nich działają.\ \ ### Kontrola przychodzących żądań[](https://kubernetes.io/pl/docs/concepts/_print/#admission-control)\ \ Kontrolery przychodzących żądań ([Admission controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)\ ) to wtyczki, które przechwytują żądania do API Kubernetesa i mogą weryfikować lub modyfikować te żądania w oparciu o konkretne pola w żądaniu. Przemyślane projektowanie tych kontrolerów pomaga unikać niezamierzonych zakłóceń, szczególnie gdy API Kubernetesa zmienia się wraz z aktualizacjami. Aby dowiedzieć się więcej, zobacz [Dobre Praktyki dla Admission Webhooks](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/)\ .\ \ ### Audytowanie[](https://kubernetes.io/pl/docs/concepts/_print/#auditing)\ \ Dziennik audytu Kubernetesa [audit logging](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)\ dostarcza istotnego z punktu widzenia bezpieczeństwa, chronologicznego zbioru zapisów dokumentujących sekwencję działań w klastrze. Klastr audytuje aktywności generowane przez użytkowników, przez aplikacje korzystające z API Kubernetesa oraz przez samą warstwę sterowania.\ \ Zabezpieczenia dostawcy chmury[](https://kubernetes.io/pl/docs/concepts/_print/#cloud-provider-security)\ \ ---------------------------------------------------------------------------------------------------------\ \ **Informacja:** Elementy na tej stronie dotyczą dostawców zewnętrznych wobec Kubernetesa. Autorzy projektu Kubernetesa nie ponoszą odpowiedzialności za produkty ani projekty stron trzecich. Aby dodać dostawcę, produkt lub projekt do tej listy, przed zgłoszeniem zmiany przeczytaj [przewodnik po treści](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content)\ . [Więcej informacji.](https://kubernetes.io/pl/docs/concepts/_print/#third-party-content-disclaimer)\ \ Jeśli uruchamiasz klaster Kubernetes na własnym sprzęcie lub sprzęcie dostawcy chmury, zapoznaj się z dokumentacją dotyczącą najlepszych praktyk w zakresie bezpieczeństwa. Oto linki do dokumentacji bezpieczeństwa niektórych popularnych dostawców chmury:\ \ | | |\ | --- | --- |Zabezpieczenia dostawcy chmury\ | Dostawca IaaS | Link |\ | --- | --- |\ | Alibaba Cloud | [https://www.alibabacloud.com/trust-center](https://www.alibabacloud.com/trust-center) |\ | Amazon Web Services | [https://aws.amazon.com/security](https://aws.amazon.com/security) |\ | Google Cloud Platform | [https://cloud.google.com/security](https://cloud.google.com/security) |\ | Huawei Cloud | [https://www.huaweicloud.com/intl/en-us/securecenter/overallsafety](https://www.huaweicloud.com/intl/en-us/securecenter/overallsafety) |\ | IBM Cloud | [https://www.ibm.com/cloud/security](https://www.ibm.com/cloud/security) |\ | Microsoft Azure | [https://docs.microsoft.com/en-us/azure/security/azure-security](https://docs.microsoft.com/en-us/azure/security/azure-security) |\ | Oracle Cloud Infrastructure | [https://www.oracle.com/security](https://www.oracle.com/security) |\ | Tencent Cloud | [https://www.tencentcloud.com/solutions/data-security-and-information-protection](https://www.tencentcloud.com/solutions/data-security-and-information-protection) |\ | VMware vSphere | [https://www.vmware.com/solutions/security/hardening-guides](https://www.vmware.com/solutions/security/hardening-guides) |\ \ Polityki[](https://kubernetes.io/pl/docs/concepts/_print/#policies)\ \ --------------------------------------------------------------------\ \ Możesz definiować zasady bezpieczeństwa, używając mechanizmów natywnych dla Kubernetesa, takich jak [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)\ (deklaratywna kontrola nad filtrowaniem pakietów sieciowych) lub [ValidatingAdmissionPolicy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)\ (deklaratywne ograniczenia dotyczące tego, jakie zmiany ktoś może wprowadzać za pomocą API Kubernetesa).\ \ Możesz również polegać na implementacjach polityk z szerszego ekosystemu wokół Kubernetesa. Kubernetes zapewnia mechanizmy rozszerzeń, aby umożliwić projektom ekosystemowym wdrażanie własnych kontroli polityk dotyczących przeglądu kodu źródłowego, zatwierdzania obrazów kontenerów, kontroli dostępu do API, sieci i innych.\ \ Aby uzyskać więcej informacji na temat mechanizmów polityki i Kubernetesa, przeczytaj [Polityki](https://kubernetes.io/pl/docs/concepts/policy/)\ .\ \ Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej)\ \ ---------------------------------------------------------------------\ \ Dowiedz się więcej na temat powiązanych zagadnień bezpieczeństwa Kubernetesa:\ \ * [Zabezpieczanie klastra](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/)\ \ * [Znane podatności](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/)\ w Kubernetesie (i linki do dalszych informacji)\ * [Szyfrowanie danych podczas przesyłania](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)\ dla warstwy sterowania\ * [Szyfrowanie danych w spoczynku](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)\ \ * [Kontrola dostępu do API Kubernetesa](https://kubernetes.io/docs/concepts/security/controlling-access)\ \ * [Zasady sieciowe](https://kubernetes.io/docs/concepts/services-networking/network-policies/)\ dla Podów\ * [Sekrety w Kubernetesie](https://kubernetes.io/docs/concepts/configuration/secret/)\ \ * [Standardy bezpieczeństwa podów](https://kubernetes.io/docs/concepts/security/pod-security-standards/)\ \ * [Klasy środowisk uruchomieniowych](https://kubernetes.io/docs/concepts/containers/runtime-class)\ \ \ Poznaj kontekst:\ \ * [Bezpieczeństwo natywne dla chmury i Kubernetesa](https://kubernetes.io/docs/concepts/security/cloud-native-security/)\ \ \ Zdobądź certyfikat:\ \ * Certyfikacja [Certified Kubernetes Security Specialist](https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/)\ oraz oficjalny kurs szkoleniowy.\ \ Przeczytaj więcej w tej sekcji:\ \ 9 - Polityki[](https://kubernetes.io/pl/docs/concepts/_print/#pg-ac9161c6d952925b083ad9602b4e8e7f)\ \ ===================================================================================================\ \ Stosuj polityki do zarządzania bezpieczeństwem i wdrażania najlepszych praktyk.\ \ Polityki Kubernetesa to ustawienia kontrolujące inne konfiguracje lub sposób działania aplikacji w trakcie ich działania. Kubernetes oferuje różne formy polityk, opisane poniżej:\ \ Stosowanie polityk za pomocą obiektów API[](https://kubernetes.io/pl/docs/concepts/_print/#apply-policies-using-api-objects)\ \ -----------------------------------------------------------------------------------------------------------------------------\ \ Niektóre obiekty API spełniają rolę polityk. Oto kilka przykładów:\ \ * [NetworkPolicies](https://kubernetes.io/docs/concepts/services-networking/network-policies/)\ mogą być używane do ograniczania ruchu przychodzącego i wychodzącego dla workload.\ * [LimitRanges](https://kubernetes.io/docs/concepts/policy/limit-range/)\ zarządzają ograniczeniami alokacji zasobów w różnych typach obiektów.\ * [ResourceQuotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/)\ ogranicza zużycie zasobów dla [namespace](https://kubernetes.io/pl/docs/concepts/overview/working-with-objects/namespaces)\ .\ \ Stosowanie polityk za pomocą kontrolerów dopuszczania (ang. Admission Controllers)[](https://kubernetes.io/pl/docs/concepts/_print/#apply-policies-using-admission-controllers)\ \ --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\ \ Kontroler dopuszczania (ang. Admission Controller - [admission controller](https://kubernetes.io/pl/docs/reference/access-authn-authz/admission-controllers/)\ ) działa na serwerze API i może weryfikować lub modyfikować żądania API. Niektóre takie kontrolery działają w celu zastosowania polityk. Na przykład kontroler [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)\ modyfikuje nowy Pod, aby ustawić politykę pobierania obrazów na `Always`.\ \ Kubernetes ma kilka wbudowanych kontrolerów dostępu, które można konfigurować za pomocą flagi `--enable-admission-plugins` serwera API.\ \ Szczegóły dotyczące kontrolerów dopuszczania są udokumentowane w dedykowanej sekcji:\ \ * [Kontrolery dopuszczania (ang. Admission Controllers)](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)\ \ \ Stosowanie polityk używając ValidatingAdmissionPolicy[](https://kubernetes.io/pl/docs/concepts/_print/#apply-policies-using-validatingadmissionpolicy)\ \ -------------------------------------------------------------------------------------------------------------------------------------------------------\ \ Polityki walidacji przyjmowania (ang. Validating admission policies) umożliwiają wykonywanie konfigurowalnych kontroli walidacji na serwerze API przy użyciu wspólnego języka wyrażeń (CEL). Na przykład, `ValidatingAdmissionPolicy` może być używana do zakazania użycia tagu obrazu `latest`.\ \ Polityka `ValidatingAdmissionPolicy` działa na żądaniach API i może być używana do blokowania, audytowania oraz ostrzegania użytkowników o niezgodnych konfiguracjach.\ \ Szczegóły dotyczące API `ValidatingAdmissionPolicy`, wraz z przykładami, są udokumentowane w dedykowanej sekcji:\ \ * [Walidacja Polityki Dopuszczania (ang. Validating Admission Policy)](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)\ \ \ Stosowanie polityk przy użyciu dynamicznej kontroli dostępu[](https://kubernetes.io/pl/docs/concepts/_print/#apply-policies-using-dynamic-admission-control)\ \ -------------------------------------------------------------------------------------------------------------------------------------------------------------\ \ Dynamiczne kontrolery dostępu (lub webhooki dostępu) działają poza serwerem API jako oddzielne aplikacje, które rejestrują się do odbierania żądań webhooków w celu przeprowadzania weryfikacji lub modyfikacji żądań API.\ \ Dynamiczne kontrolery dopuszczeń mogą być używane do stosowania polityk na żądaniach API i uruchamiania innych procesów opartych na politykach. Dynamiczny kontroler dopuszczeń może przeprowadzać skomplikowane kontrole, w tym te, które wymagają pobierania innych zasobów klastra i danych zewnętrznych. Na przykład, kontrola weryfikacji obrazu może wyszukiwać dane z rejestrów OCI, aby zatwierdzić podpisy i atestacje obrazów kontenerów.\ \ Szczegóły dotyczące dynamicznej kontroli dostępu są udokumentowane w dedykowanej sekcji:\ \ * [Dynamiczne Sterowanie Dostępem](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)\ \ \ ### Implementacje[](https://kubernetes.io/pl/docs/concepts/_print/#implementations-admission-control)\ \ **Informacja:** Ta sekcja przekierowuje do projektów zewnętrznych (niżej ich lista alfabetyczna), które udostępniają funkcjonalności wymagane przez Kubernetesa. Autorzy Kubernetesa nie odpowiadają za te projekty. Jeśli chcesz dodać projekt do tego wykazu, zanim wprowadzisz zmiany, przeczytaj [nasz przewodnik](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content)\ .\ \ Dynamiczne kontrolery dopuszczeń (Admission Controllers), które działają jako elastyczne silniki polityki, są rozwijane w ekosystemie Kubernetesa:\ \ * [Kubewarden](https://github.com/kubewarden)\ \ * [Kyverno](https://kyverno.io/)\ \ * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)\ \ * [Polaris](https://polaris.docs.fairwinds.com/admission-controller/)\ \ \ Stosowanie zasad za pomocą konfiguracji Kubelet[](https://kubernetes.io/pl/docs/concepts/_print/#apply-policies-using-kubelet-configurations)\ \ ----------------------------------------------------------------------------------------------------------------------------------------------\ \ Kubernetes pozwala na konfigurowanie Kubelet na każdym węźle roboczym. Niektóre konfiguracje Kubelet działają jako polityki:\ \ * [Limity i rezerwacje identyfikatorów procesów](https://kubernetes.io/docs/concepts/policy/pid-limiting/)\ są używane do ograniczania i rezerwacji dostępnych PID-ów.\ * [Menedżery zasobów węzła](https://kubernetes.io/docs/concepts/policy/node-resource-managers/)\ mogą zarządzać zasobami obliczeniowymi, pamięci oraz urządzeniami dla workloadów krytycznych pod względem opóźnień i o wysokiej przepustowości.\ \ 10 - Harmonogramowanie, pierszeństwo i eksmisja[](https://kubernetes.io/pl/docs/concepts/_print/#pg-c21d05f31057c5bcd2ebdd01f4e62a0e)\ \ ======================================================================================================================================\ \ W Kubernetesie, planowanie odnosi się do zapewnienia, że [Pody](https://kubernetes.io/pl/docs/concepts/workloads/pods/)\ są dopasowane do [Węzłów](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ , aby [kubelet](https://kubernetes.io/pl/docs/reference/command-line-tools-reference/kubelet)\ mógł je uruchomić. Pierszeństwo (ang. preemption) to proces zakończania Podów z niższym [Priorytetem](https://kubernetes.io/pl/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)\ po to, aby Pody z wyższym Priorytetem mogły być zaplanowane na Węzłach. Eksmisja (ang. eviction) to proces zakończania jednego lub więcej Podów na Węzłach.\ \ Harmonogramowanie[](https://kubernetes.io/pl/docs/concepts/_print/#scheduling)\ \ -------------------------------------------------------------------------------\ \ * [Scheduler Kubernetesa](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/)\ \ * [Przypisywanie Podów do Węzłów](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)\ \ * [Narzut na utrzymanie poda (ang. Pod overhead)](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-overhead/)\ \ * [Reguły rozmieszczenia Podów w klastrze](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)\ \ * [Reguły wykluczania i dopuszczania podów](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)\ \ * [Scheduling Framework](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework)\ \ * [Dynamiczne przydzielanie zasobów](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation)\ \ * [Tuning wydajności schedulera](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)\ \ * [Pakowanie zasobów (Bin Packing) dla niestandardowych zasobów klastra](https://kubernetes.io/docs/concepts/scheduling-eviction/resource-bin-packing/)\ \ * [Gotowość do planowania Podów](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)\ \ * [Planowanie grupowe (ang. Gang Scheduling)](https://kubernetes.io/docs/concepts/scheduling-eviction/gang-scheduling/)\ \ * [Descheduler](https://github.com/kubernetes-sigs/descheduler#descheduler-for-kubernetes)\ \ * [Deklarowane funkcje węzłów](https://kubernetes.io/docs/concepts/scheduling-eviction/node-declared-features/)\ \ \ Zakłócenia w działaniu Podów[](https://kubernetes.io/pl/docs/concepts/_print/#pod-disruption)\ \ ----------------------------------------------------------------------------------------------\ \ [Zakłócenie działania Poda](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/)\ to proces, w ramach którego Pody na węzłach są zakończone dobrowolnie lub mimowolnie.\ \ Dobrowolne zakłócenia są inicjowane celowo przez właścicieli aplikacji lub administratorów klastra. Mimowolne zakłócenia są niezamierzone i mogą być spowodowane nieuniknionymi problemami, takimi jak wyczerpanie [zasobów](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-infrastructure-resource)\ na węzłach, lub przypadkowymi usunięciami.\ \ * [Priorytet poda i wywłaszczenie](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)\ \ * [Usuwanie z powodu presji na węzeł](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/)\ \ * [Usunięcie zainicjowane przez API](https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/)\ \ \ 11 - Administracja klastrem[](https://kubernetes.io/pl/docs/concepts/_print/#pg-285a3785fd3d20f437c28d87ca4dadca)\ \ ==================================================================================================================\ \ Niskopoziomowe szczegóły istotne dla tworzenia i administracji klastrem Kubernetesa.\ \ Rozdział dotyczący administracji klastrem jest przeznaczony dla każdego, kto tworzy lub zarządza klastrem Kubernetesa. Zakłada się pewną znajomość podstawowych [pojęć](https://kubernetes.io/pl/docs/concepts/)\ Kubernetesa.\ \ Planowanie klastra[](https://kubernetes.io/pl/docs/concepts/_print/#planning-a-cluster)\ \ ----------------------------------------------------------------------------------------\ \ Zobacz przewodniki w [Od czego zacząć](https://kubernetes.io/pl/docs/setup/)\ zawierające przykłady planowania, konfiguracji i uruchamiania klastrów Kubernetes. Rozwiązania wymienione w tym artykule nazywane są _dystrybucjami_.\ \ #### Informacja:\ \ Nie wszystkie dystrybucje są aktywnie utrzymywane. Wybierz dystrybucje, które zostały przetestowane z aktualną wersją Kubernetesa.\ \ Rozważ:\ \ * Czy chcesz wypróbować Kubernetesa na swoim komputerze, czy może chcesz zbudować klaster o wysokiej dostępności, złożony z wielu węzłów? Wybierz dystrybucję najlepiej dostosowaną do Twoich potrzeb.\ * Czy będziesz korzystać z **hostowanego klastra Kubernetesa**, takiego jak [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)\ , czy też **hostować własny klaster**?\ * Czy Twój klaster będzie **w lokalnym centrum obliczeniowym (on-premises)**, czy **w chmurze (IaaS)**? Kubernetes nie obsługuje bezpośrednio klastrów hybrydowych. Zamiast tego, możesz skonfigurować wiele klastrów.\ * **Jeśli konfigurujesz Kubernetesa lokalnie**, zastanów się, który [model sieciowy](https://kubernetes.io/docs/concepts/cluster-administration/networking/)\ pasuje najlepiej.\ * Czy będziesz uruchamiać Kubernetesa na sprzęcie typu **"bare metal"** czy na **maszynach wirtualnych (VM)**?\ * Czy **chcesz uruchomić klaster**, czy raczej zamierzasz prowadzić **aktywny rozwój kodu projektu Kubernetes**? Jeśli to drugie, wybierz dystrybucję aktywnie rozwijaną. Niektóre dystrybucje używają tylko wydań binarnych, ale oferują większą różnorodność wyboru.\ * Zapoznaj się z [komponentami](https://kubernetes.io/pl/docs/concepts/overview/components/)\ potrzebnymi do uruchomienia klastra.\ \ Zarządzanie klastrem[](https://kubernetes.io/pl/docs/concepts/_print/#managing-a-cluster)\ \ ------------------------------------------------------------------------------------------\ \ * Dowiedz się, jak [zarządzać węzłami](https://kubernetes.io/docs/concepts/architecture/nodes/)\ .\ \ * Przeczytaj o [automatycznym skalowaniu węzłów](https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/)\ .\ * Dowiedz się, jak skonfigurować i zarządzać [przydziałem zasobów](https://kubernetes.io/docs/concepts/policy/resource-quotas/)\ dla współdzielonych klastrów.\ \ \ Zabezpieczanie klastra[](https://kubernetes.io/pl/docs/concepts/_print/#securing-a-cluster)\ \ --------------------------------------------------------------------------------------------\ \ * [Generowanie Certyfikatów](https://kubernetes.io/docs/tasks/administer-cluster/certificates/)\ opisuje kroki generowania certyfikatów z użyciem różnych zestawów narzędzi.\ \ * [Środowisko Kontenerów Kubernetesa](https://kubernetes.io/docs/concepts/containers/container-environment/)\ opisuje środowisko dla zarządzanych przez Kubelet kontenerów na węźle Kubernetesa.\ \ * [Kontrola dostępu do API Kubernetesa](https://kubernetes.io/docs/concepts/security/controlling-access)\ opisuje, jak Kubernetes implementuje kontrolę dostępu do swojego API.\ \ * [Uwierzytelnianie](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)\ wyjaśnia uwierzytelnianie w Kubernetesie, w tym różne opcje uwierzytelniania.\ \ * [Autoryzacja](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)\ jest oddzielona od uwierzytelniania i kontroluje, w jaki sposób obsługiwane są wywołania HTTP.\ \ * [Korzystanie z kontrolerów dopuszczania (Admission Controllers)](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)\ opisuje wtyczki, które przechwytują żądania do serwera API Kubernetesa po uwierzytelnieniu i autoryzacji.\ \ * Dokument [Dobre Praktyki dla Admission Webhooks](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/)\ opisuje zalecane podejście i ważne aspekty, które należy uwzględnić przy tworzeniu webhooków modyfikujących oraz wehbooków walidujących w Kubernetesie.\ \ * [Używanie Sysctls w klastrach Kubernetesa](https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/)\ opisuje administratorowi, jak używać narzędzia wiersza polecenia `sysctl` do ustawiania parametrów jądra.\ \ * [Audyt](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)\ opisuje, jak współpracować z logami audytowymi Kubernetesa.\ \ \ ### Zabezpieczanie kubeleta[](https://kubernetes.io/pl/docs/concepts/_print/#securing-the-kubelet)\ \ * [Komunikacja warstwy sterowania z węzłem](https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/)\ \ * [TLS bootstrapping](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)\ \ * [Uwierzytelnianie/autoryzacja Kubelet](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)\ \ \ Opcjonalne usługi klastra[](https://kubernetes.io/pl/docs/concepts/_print/#optional-cluster-services)\ \ ------------------------------------------------------------------------------------------------------\ \ * [Integracja DNS](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)\ opisuje, jak rozwiązać nazwę DNS bezpośrednio do usługi Kubernetesa.\ \ * [Logowanie i monitorowanie aktywności klastra](https://kubernetes.io/docs/concepts/cluster-administration/logging/)\ wyjaśnia, jak działa logowanie w Kubernetesie i jak je zaimplementować.\ \ \ 12 - Windows w Kubernetesie[](https://kubernetes.io/pl/docs/concepts/_print/#pg-05a1231ecbfe48ec554e6d078818aca4)\ \ ==================================================================================================================\ \ Kubernetes obsługuje węzły działające na systemie Microsoft Windows.\ \ Kubernetes obsługuje [węzły](https://kubernetes.io/pl/docs/concepts/architecture/nodes/)\ robocze działające zarówno na systemie Linux, jak i Microsoft Windows.\ \ 🛇 Ta pozycja przekierowuje do projektu lub produktu, który nie jest częścią projektu Kubernetes. [Więcej informacji](https://kubernetes.io/pl/docs/concepts/_print/#third-party-content-disclaimer)\ \ CNCF i jej macierzysta organizacja Linux Foundation przyjmują neutralne podejście do kompatybilności w kontekście dostawców. Możliwe jest dołączenie swojego [serwera Windows](https://www.microsoft.com/en-us/windows-server)\ jako węzeł roboczy do klastra Kubernetes.\ \ Możesz [zainstalować i skonfigurować kubectl na Windows](https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/)\ niezależnie od tego, jakiego systemu operacyjnego używasz w ramach swojego klastra.\ \ Jeśli używasz węzłów Windows, możesz przeczytać:\ \ * [Sieci w Windows](https://kubernetes.io/docs/concepts/services-networking/windows-networking/)\ \ * [Windows storage w Kubernetesie](https://kubernetes.io/docs/concepts/storage/windows-storage/)\ \ * [Zarządzanie zasobami dla węzłów Windows](https://kubernetes.io/docs/concepts/configuration/windows-resource-management/)\ \ * [Konfiguracja RunAsUserName dla Podów Windows i kontenerów](https://kubernetes.io/docs/tasks/configure-pod-container/configure-runasusername/)\ \ * [Utwórz Windows HostProcess Pod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/)\ \ * [Konfigurowanie grupowych zarządzanych kont Usług dla Podów i kontenerów Windows](https://kubernetes.io/docs/tasks/configure-pod-container/configure-gmsa/)\ \ * [Bezpieczeństwo dla węzłów Windows](https://kubernetes.io/docs/concepts/security/windows-security/)\ \ * [Wskazówki dotyczące debugowania w systemie Windows](https://kubernetes.io/docs/tasks/debug/debug-cluster/windows/)\ \ * [Przewodnik dotyczący harmonogramowania kontenerów Windows w Kubernetesie](https://kubernetes.io/docs/concepts/windows/user-guide)\ \ \ lub, aby uzyskać przegląd, przeczytaj:\ \ 13 - Rozszerzanie Kubernetesa[](https://kubernetes.io/pl/docs/concepts/_print/#pg-7e0d97616b15e2c383c6a0a96ec442cb)\ \ ====================================================================================================================\ \ Różne sposoby na modyfikację działania klastra Kubernetesa.\ \ Kubernetes jest wysoce konfigurowalny i rozbudowywalny. W rezultacie rzadko istnieje potrzeba robienia forka lub przesyłania poprawek do kodu projektu.\ \ Ten przewodnik opisuje opcje dostosowywania klastra Kubernetesa. Jest skierowany do [operatorów klastrów](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-cluster-operator)\ , którzy chcą zrozumieć, jak dostosować swój klaster Kubernetesa do potrzeb środowiska pracy. Programiści, którzy są potencjalnymi [Deweloperami Platformy](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-platform-developer)\ lub [Współtwórcami](https://kubernetes.io/pl/docs/reference/glossary/?all=true#term-contributor)\ projektu Kubernetes również uznają go za przydatny jako wprowadzenie do istniejących punktów rozszerzeń i wzorców oraz ich kompromisów i ograniczeń.\ \ Podejścia do dostosowywania można ogólnie podzielić na [konfigurację](https://kubernetes.io/pl/docs/concepts/_print/#configuration)\ , która obejmuje tylko zmiany argumentów wiersza poleceń, lokalnych plików konfiguracyjnych lub zasobów API; oraz [rozszerzenia](https://kubernetes.io/pl/docs/concepts/_print/#extensions)\ , które obejmują uruchamianie dodatkowych programów, dodatkowych usług sieciowych lub obu. Ten dokument dotyczy przede wszystkim _rozszerzeń_.\ \ Konfiguracja[](https://kubernetes.io/pl/docs/concepts/_print/#configuration)\ \ -----------------------------------------------------------------------------\ \ _Pliki konfiguracyjne_ i _argumenty poleceń_ są udokumentowane w sekcji [Materiały źródłowe (ang. Reference)](https://kubernetes.io/pl/docs/reference/)\ dokumentacji online, z osobną stroną dla każdego pliku binarnego:\ \ * [`kube-apiserver`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)\ \ * [`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/)\ \ * [`kube-scheduler`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)\ \ * [`kubelet`](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)\ \ * [`kube-proxy`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)\ \ \ Argumenty poleceń i pliki konfiguracyjne mogą nie zawsze być możliwe do zmiany w hostowanej usłudze Kubernetesa lub w dystrybucji z zarządzaną instalacją. Kiedy są możliwe do zmiany, zazwyczaj mogą być zmieniane tylko przez operatora klastra. Dodatkowo, mogą ulegać zmianom w przyszłych wersjach Kubernetesa, a ich ustawienie może wymagać ponownego uruchomienia procesów. Z tych powodów należy je używać tylko wtedy, gdy nie ma innych opcji.\ \ Wbudowane _interfejsy API polityk_, takie jak [ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)\ , [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)\ i Role-based Access Control ( [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\ ), to natywne API Kubernetesa umożliwiające deklaratywną konfigurację polityk. Interfejsy API są zazwyczaj użyteczne nawet w przypadku hostowanych usług Kubernetesa i zarządzanych instalacji Kubernetesa. Wbudowane interfejsy API polityk przestrzegają tych samych konwencji co inne zasoby Kubernetesa, takie jak Pody. Gdy korzystasz z API polityk, które są [stabilne](https://kubernetes.io/docs/reference/using-api/#api-versioning)\ , masz zapewnione [określone wsparcie](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\ , zgodnie z ogólną polityką wsparcia API Kubernetesa. Z tych powodów interfejsy API polityk są zalecane zamiast _plików konfiguracyjnych_ i _argumentów poleceń_, tam gdzie to możliwe.\ \ Rozszerzenia[](https://kubernetes.io/pl/docs/concepts/_print/#extensions)\ \ --------------------------------------------------------------------------\ \ Rozszerzenia to komponenty oprogramowania, które rozszerzają i głęboko integrują się z Kubernetesem. Dostosowują go do obsługi nowych typów i nowych rodzajów sprzętu.\ \ Wielu administratorów klastra korzysta z hostowanej lub dystrybucyjnej instancji Kubernetesa. Te klastry mają zainstalowane rozszerzenia. W rezultacie, większość użytkowników Kubernetesa nie będzie musiała instalować rozszerzeń, a jeszcze mniej użytkowników będzie musiało tworzyć nowe.\ \ ### Wzorce rozszerzeń[](https://kubernetes.io/pl/docs/concepts/_print/#extension-patterns)\ \ Kubernetes jest zaprojektowany tak, aby można go było zautomatyzować poprzez pisanie programów klienckich. Każdy program, który odczytuje i/lub zapisuje do API Kubernetesa, może zapewnić użyteczną automatyzację. _Automatyzacja_ może działać zarówno na klastrze, jak i poza nim. Postępując zgodnie z wytycznymi zawartymi w tym dokumencie, możesz napisać wysoce dostępną i solidną automatyzację. Automatyzacja generalnie działa z dowolnym klastrem Kubernetesa, w tym klastrami hostowanymi i zarządzanymi instalacjami.\ \ Istnieje specyficzny wzorzec pisania programów klienckich, które dobrze współpracują z Kubernetesem, zwany wzorcem [kontrolera](https://kubernetes.io/pl/docs/concepts/architecture/controller/)\ . Kontrolery zazwyczaj odczytują `.spec` obiektu, ewentualnie wykonują pewne czynności, a następnie aktualizują `.status` obiektu.\ \ Kontroler jest klientem API Kubernetesa. Gdy Kubernetes działa jako klient i wywołuje zdalną usługę, nazywa to _webhookiem_. Zdalna usługa nazywana jest _backendem webhooka_. Podobnie jak w przypadku niestandardowych kontrolerów, webhooki stanowią dodatkowy potencjalny punkt awarii.\ \ #### Informacja:\ \ Poza Kubernetesen, termin "webhook" zazwyczaj odnosi się do mechanizmu asynchronicznych powiadomień, gdzie wywołanie webhooka służy jako jednostronne powiadomienie do innego systemu lub komponentu. W ekosystemie Kubernetesa, nawet synchroniczne wywołania HTTP są często opisywane jako "webhooki".\ \ W modelu webhook Kubernetes wykonuje żądanie sieciowe do zdalnej usługi. W alternatywnym modelu _binarnej wtyczki_, Kubernetes wykonuje program binarny. Wtyczki binarne są używane przez kubelet (na przykład, [wtyczki magazynu CSI](https://kubernetes-csi.github.io/docs/)\ i [wtyczki sieciowe CNI](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)\ ), oraz przez kubectl (zobacz [Rozszerz kubectl za pomocą wtyczek](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/)\ ).\ \ ### Punkty rozszerzeń[](https://kubernetes.io/pl/docs/concepts/_print/#extension-points)\ \ Ten diagram pokazuje punkty rozszerzeń w klastrze Kubernetesa oraz klientów, którzy uzyskują do niego dostęp.\ \ ![Symboliczne przedstawienie siedmiu ponumerowanych punktów rozszerzeń dla Kubernetesa](https://kubernetes.io/docs/concepts/extend-kubernetes/extension-points.png)\ \ Punkty rozszerzeń Kubernetesa\ \ #### Klucz do rysunku[](https://kubernetes.io/pl/docs/concepts/_print/#key-to-the-figure)\ \ 1. Użytkownicy często wchodzą w interakcję z API Kubernetesa za pomocą `kubectl`. [Wtyczki](https://kubernetes.io/pl/docs/concepts/_print/#client-extensions)\ dostosowują zachowanie klientów. Istnieją ogólne rozszerzenia, które mogą być stosowane do różnych klientów, a także specyficzne sposoby rozszerzania `kubectl`.\ \ 2. Serwer API obsługuje wszystkie żądania. Kilka typów punktów rozszerzeń w serwerze API umożliwia uwierzytelnianie żądań, blokowanie ich na podstawie ich treści, edytowanie treści oraz obsługę usuwania. Są one opisane w sekcji [Rozszerzenia dostępu do API](https://kubernetes.io/pl/docs/concepts/_print/#api-access-extensions)\ .\ \ 3. Serwer API obsługuje różne rodzaje _zasobów_. _Wbudowane rodzaje zasobów_, takie jak `pods`, są definiowane przez projekt Kubernetesa i nie mogą być modyfikowane. Przeczytaj [Rozszerzenia API](https://kubernetes.io/pl/docs/concepts/_print/#api-extensions)\ , aby dowiedzieć się więcej o rozszerzaniu API Kubernetesa.\ \ 4. Scheduler Kubernetesa [decyduje](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)\ , na których węzłach umieścić pody. Istnieje kilka sposobów na rozszerzenie harmonogramowania, które są opisane w sekcji [Rozszerzenia harmonogramowania](https://kubernetes.io/pl/docs/concepts/_print/#scheduling-extensions)\ .\ \ 5. Duża część zachowań Kubernetesa jest realizowana przez programy zwane [kontrolerami](https://kubernetes.io/pl/docs/concepts/architecture/controller/)\ , które są klientami serwera API. Kontrolery są często używane w połączeniu z niestandardowymi zasobami. Przeczytaj [łączenie nowych API z automatyzacją](https://kubernetes.io/pl/docs/concepts/_print/#combining-new-apis-with-automation)\ oraz [Zmiana wbudowanych zasobów](https://kubernetes.io/pl/docs/concepts/_print/#changing-built-in-resources)\ , aby dowiedzieć się więcej.\ \ 6. Kubelet działa na serwerach (węzłach) i pomaga podom wyglądać jak wirtualne serwery z własnymi adresami IP w sieci klastra. [Wtyczki sieciowe](https://kubernetes.io/pl/docs/concepts/_print/#network-plugins)\ umożliwiają różne implementacje sieciowania podów.\ \ 7. Możesz użyć [Pluginów Urządzeń](https://kubernetes.io/pl/docs/concepts/_print/#device-plugins)\ , aby zintegrować niestandardowy sprzęt lub inne specjalne lokalne dla węzła funkcje i udostępnić je Podom działającym w Twoim klastrze. Kubelet zawiera wsparcie dla pracy z pluginami urządzeń.\ \ Kubelet również montuje i odmontowuje [volume](https://kubernetes.io/pl/docs/concepts/storage/volumes/)\ dla podów i ich kontenerów. Możesz użyć [wtyczek magazynowania](https://kubernetes.io/pl/docs/concepts/_print/#storage-plugins)\ , aby dodać obsługę nowych rodzajów magazynu (ang. storage) i innych typów wolumenów.\ \ \ #### Schemat przepływu wyboru punktu rozszerzenia[](https://kubernetes.io/pl/docs/concepts/_print/#extension-flowchart)\ \ Jeśli nie jesteś pewien, od czego zacząć, ten schemat blokowy może pomóc. Zwróć uwagę, że niektóre rozwiązania mogą obejmować kilka typów rozszerzeń.\ \ ![Schemat blokowy z pytaniami o przypadki użycia i wskazówki dla wdrażających. Zielone koła oznaczają tak; czerwone koła oznaczają nie.](https://kubernetes.io/docs/concepts/extend-kubernetes/flowchart.svg)\ \ Przewodnik do wyboru metody rozszerzenia\ \ * * *\ \ Rozszerzenia klienta[](https://kubernetes.io/pl/docs/concepts/_print/#client-extensions)\ \ -----------------------------------------------------------------------------------------\ \ Wtyczki do `kubectl` to oddzielne pliki binarne, które dodają lub zastępują działanie określonych poleceń. Narzędzie `kubectl` może również integrować się z [wtyczkami uwierzytelniania](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)\ . Te rozszerzenia wpływają tylko na lokalne środowisko danego użytkownika, dlatego nie mogą wymuszać polityk dla całego serwisu.\ \ Jeśli chcesz rozszerzyć narzędzie `kubectl`, przeczytaj [Rozszerzanie kubectl za pomocą wtyczek](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/)\ .\ \ Rozszerzenia API[](https://kubernetes.io/pl/docs/concepts/_print/#api-extensions)\ \ ----------------------------------------------------------------------------------\ \ ### Definicje zasobów niestandardowych (ang. custom resource)[](https://kubernetes.io/pl/docs/concepts/_print/#custom-resource-definitions)\ \ Rozważ dodanie _Custom Resource_ do Kubernetesa, jeśli chcesz zdefiniować nowe kontrolery, obiekty konfiguracji aplikacji lub inne deklaratywne interfejsy API i zarządzać nimi za pomocą narzędzi Kubernetesa, takich jak `kubectl`.\ \ Aby dowiedzieć się więcej o zasobach niestandardowych, zapoznaj się z przewodnikiem po [zasobach niestandardowych](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)\ .\ \ ### Warstwa agregacji API[](https://kubernetes.io/pl/docs/concepts/_print/#api-aggregation-layer)\ \ Możesz użyć [warstwy agregacji API](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)\ Kubernetesa, aby zintegrować API Kubernetesa z dodatkowymi usługami, takimi jak [metryki](https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/)\ .\ \ ### Łączenie nowych interfejsów API z automatyzacją[](https://kubernetes.io/pl/docs/concepts/_print/#combining-new-apis-with-automation)\ \ Kombinacja niestandardowego API zasobu i pętli sterowania nazywana jest wzorcem [controllers](https://kubernetes.io/pl/docs/concepts/architecture/controller/)\ . Jeśli Twój kontroler zastępuje ludzkiego operatora wdrażającego infrastrukturę na podstawie pożądanego stanu, kontroler może również podążać za [wzorcem operatora](https://kubernetes.io/pl/docs/concepts/extend-kubernetes/operator/)\ . Wzorzec operatora jest używany do zarządzania specyficznymi aplikacjami; zazwyczaj są to aplikacje, które utrzymują stan i wymagają uwagi w sposobie zarządzania nimi.\ \ Możesz także tworzyć własne niestandardowe interfejsy API i pętle sterujące, które zarządzają innymi zasobami, takimi jak storage, lub definiować polityki (takie jak ograniczenia kontroli dostępu).\ \ ### Zmiana wbudowanych zasobów[](https://kubernetes.io/pl/docs/concepts/_print/#changing-built-in-resources)\ \ Kiedy rozszerzasz API Kubernetesa poprzez dodanie zasobów niestandardowych, dodane zasoby zawsze trafiają do nowych grup API. Nie możesz zastąpić ani zmienić istniejących grup API. Dodanie API nie pozwala bezpośrednio wpłynąć na zachowanie istniejących API (takich jak Pody), podczas gdy _Rozszerzenia Dostępu do API_ mogą to zrobić.\ \ Rozszerzenia dostępu do API[](https://kubernetes.io/pl/docs/concepts/_print/#api-access-extensions)\ \ ----------------------------------------------------------------------------------------------------\ \ Gdy żądanie trafia do serwera API Kubernetesa, najpierw jest _uwierzytelniane_, następnie _autoryzowane_, i podlega różnym typom _kontroli dostępu_ (niektóre żądania nie są uwierzytelniane i podlegają specjalnemu przetwarzaniu). Zobacz [Kontrolowanie dostępu do API Kubernetesa](https://kubernetes.io/docs/concepts/security/controlling-access/)\ aby dowiedzieć się więcej o tym procesie.\ \ Każdy z kroków w przepływie uwierzytelniania / autoryzacji Kubernetesa oferuje punkty rozszerzeń.\ \ ### Uwierzytelnianie[](https://kubernetes.io/pl/docs/concepts/_print/#authentication)\ \ [Uwierzytelnianie](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)\ mapuje nagłówki lub certyfikaty we wszystkich żądaniach do nazwy użytkownika dla klienta składającego żądanie.\ \ Kubernetes ma kilka wbudowanych metod uwierzytelniania, które obsługuje. Może również działać za proxy uwierzytelniającym, a także może wysyłać token z nagłówka `Authorization:` do zdalnej usługi w celu weryfikacji (przez [authentication webhook](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)\ ), jeśli te metody nie spełniają Twoich potrzeb.\ \ ### Autoryzacja[](https://kubernetes.io/pl/docs/concepts/_print/#authorization)\ \ [Authorization](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)\ określa, czy konkretni użytkownicy mogą odczytywać, zapisywać i wykonywać inne operacje na zasobach API. Działa na poziomie całych zasobów -- nie rozróżnia na podstawie dowolnych pól obiektu.\ \ Jeśli wbudowane opcje autoryzacji nie spełniają Twoich potrzeb, [webhook autoryzacji](https://kubernetes.io/docs/reference/access-authn-authz/webhook/)\ umożliwia wywołanie niestandardowego kodu, który podejmuje decyzję autoryzacyjną.\ \ ### Dynamiczne sterowanie dostępem[](https://kubernetes.io/pl/docs/concepts/_print/#dynamic-admission-control)\ \ Po autoryzacji żądania, jeśli jest to operacja zapisu, przechodzi również przez kroki [Kontroli Przyjęć (ang. Admission Control)](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)\ . Oprócz wbudowanych kroków, istnieje kilka rozszerzeń:\ \ * [Webhook polityki obrazów](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)\ ogranicza, jakie obrazy mogą być uruchamiane w kontenerach.\ * Aby podejmować dowolne decyzje dotyczące kontroli dostępu, można użyć ogólnego [webhooka dopuszczenia (ang. Admission webhook)](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)\ . Webhooki dopuszczenia mogą odrzucać żądania tworzenia lub aktualizacji. Niektóre webhooki modyfikują dane przychodzącego żądania, zanim zostaną one dalej obsłużone przez Kubernetesa.\ \ Rozszerzenia infrastruktury[](https://kubernetes.io/pl/docs/concepts/_print/#infrastructure-extensions)\ \ --------------------------------------------------------------------------------------------------------\ \ ### Wtyczki urządzeń[](https://kubernetes.io/pl/docs/concepts/_print/#device-plugins)\ \ _Device plugins_ pozwalają węzłowi na odkrywanie nowych zasobów Węzła (oprócz wbudowanych, takich jak CPU i pamięć) za pomocą [Device Plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)\ .\ \ ### Wtyczki magazynowe (ang. Storage plugins)[](https://kubernetes.io/pl/docs/concepts/_print/#storage-plugins)\ \ Wtyczki [Container Storage Interface](https://kubernetes.io/pl/docs/concepts/storage/volumes/#csi)\ (CSI) dostarczają sposób na rozszerzenie Kubernetesa o wsparcie dla nowych rodzajów wolumenów. Wolumeny mogą być obsługiwane przez trwałe zewnętrzne magazyny danych, dostarczać pamięć ulotną lub oferować interfejs tylko do odczytu do informacji z wykorzystaniem paradygmatu systemu plików.\ \ Kubernetes zawiera również wsparcie dla wtyczek [FlexVolume](https://kubernetes.io/docs/concepts/storage/volumes/#flexvolume)\ , które są przestarzałe od wersji Kubernetes v1.23 (na rzecz CSI).\ \ Wtyczki FlexVolume umożliwiają użytkownikom podłączanie typów woluminów, które nie są natywnie obsługiwane przez Kubernetesa. Kiedy uruchamiasz Pod, który polega na magazynie FlexVolume, kubelet wywołuje wtyczkę binarną, aby zamontować wolumin. Zarchiwizowany [FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md)\ projekt wstępny zawiera więcej szczegółów na temat tego podejścia.\ \ [FAQ dotyczące Wtyczki Wolumenów Kubernetesa dla Dostawców Pamięci](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)\ zawiera ogólne informacje na temat wtyczek do pamięci.\ \ ### Wtyczki sieciowe[](https://kubernetes.io/pl/docs/concepts/_print/#network-plugins)\ \ Twój klaster Kubernetesa potrzebuje _wtyczki sieciowej_, aby mieć działającą sieć Podów i wspierać inne aspekty modelu sieciowego Kubernetesa.\ \ [Wtyczki sieciowe](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)\ pozwalają Kubernetesowi na współpracę z różnymi topologiami i technologiami sieciowymi.\ \ ### Wtyczki dostawcy poświadczeń obrazu dla Kubeleta[](https://kubernetes.io/pl/docs/concepts/_print/#kubelet-image-credential-provider-plugins)\ \ STATUS FUNKCJONALNOŚCI: `Kubernetes v1.26 [stable]`\ \ Dostawcy poświadczeń obrazów dla kubeleta to wtyczki dla kubeleta, które dynamicznie pobierają poświadczenia rejestru obrazów. Poświadczenia te są następnie używane podczas pobierania obrazów z rejestrów obrazów kontenerów, które odpowiadają konfiguracji.\ \ Wtyczki mogą komunikować się z zewnętrznymi usługami lub korzystać z lokalnych plików w celu uzyskania poświadczeń. W ten sposób kubelet nie musi mieć statycznych poświadczeń dla każdego rejestru i może obsługiwać różne metody i protokoły uwierzytelniania.\ \ Aby uzyskać szczegóły dotyczące konfiguracji wtyczki, zobacz [Konfigurowanie dostawcy poświadczeń obrazu kubelet](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-credential-provider/)\ .\ \ Rozszerzenia harmonogramowania[](https://kubernetes.io/pl/docs/concepts/_print/#scheduling-extensions)\ \ -------------------------------------------------------------------------------------------------------\ \ Scheduler to specjalny typ kontrolera, który obserwuje pody i przypisuje pody do węzłów. Domyślny scheduler może być całkowicie zastąpiony, przy jednoczesnym dalszym korzystaniu z innych komponentów Kubernetesa, lub [wielokrotne schedulery](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)\ mogą działać jednocześnie.\ \ Jest to duże przedsięwzięcie i prawie wszyscy użytkownicy Kubernetesa stwierdzają, że nie muszą modyfikować schedulera.\ \ Możesz kontrolować, które [wtyczki planowania](https://kubernetes.io/docs/reference/scheduling/config/#scheduling-plugins)\ są aktywne, lub kojarzyć zestawy wtyczek z różnymi nazwanymi [profilami schedulera](https://kubernetes.io/docs/reference/scheduling/config/#multiple-profiles)\ . Możesz również napisać własną wtyczkę, która integruje się z jednym lub więcej [punktami rozszerzeń](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/#extension-points)\ kube-schedulera.\ \ Wreszcie, wbudowany komponent `kube-scheduler` obsługuje [webhook](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)\ , który pozwala zdalnemu backendowi HTTP (rozszerzenie schedulera) na filtrowanie i/lub priorytetyzowanie węzłów, które kube-scheduler wybiera dla poda.\ \ #### Informacja:\ \ Za pomocą webhooka rozszerzającego harmonogram można wpływać jedynie na filtrowanie węzłów i priorytetyzację węzłów; inne punkty rozszerzenia nie są dostępne poprzez integrację webhooków.\ \ Co dalej?[](https://kubernetes.io/pl/docs/concepts/_print/#co-dalej)\ \ ---------------------------------------------------------------------\ \ * Dowiedz się więcej o rozszerzeniach infrastruktury\ * [Wtyczki Urządzeń](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)\ \ * [Wtyczki sieciowe](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)\ \ * Wtyczki do przechowywania CSI [storage plugins](https://kubernetes-csi.github.io/docs/)\ \ * Dowiedz się więcej o [wtyczkach kubectl](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/)\ \ * Dowiedz się więcej o [zasobach niestandardowych (ang. Custom Resources)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)\ \ * Dowiedz się więcej o [serwerach API rozszerzeń](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)\ \ * Dowiedz się więcej o [dynamicznym kontrolowaniu dostępu](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)\ \ * Dowiedz się więcej o [wzorcu Operatora](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/)\ \ \ 13.1 - Rozszerzanie API Kubernetesa[](https://kubernetes.io/pl/docs/concepts/_print/#pg-0af41d3bd7c785621b58b7564793396a)\ \ ==========================================================================================================================\ \ Niestandardowe zasoby Kubernetesa (ang. Custom Resources) stanowią rozszerzenie API. Kubernetes udostępnia dwie metody ich integracji z klastrem:\ \ * Mechanizm [CustomResourceDefinition](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)\ (CRD) pozwala deklaratywnie zdefiniować nowe niestandardowe API z grupą API, rodzajem i schematem, który określisz. Warstwa sterowania Kubernetesa obsługuje i zarządza przechowywaniem twojego niestandardowego zasobu. CRD pozwalają tworzyć nowe typy zasobów dla twojego klastra bez pisania i uruchamiania niestandardowego serwera API.\ * [Warstwa agregacji](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)\ znajduje się za głównym serwerem API, który działa jako proxy. To rozwiązanie nazywa się Agregacją API (AA), które umożliwia dostarczanie implementacji dla własnych niestandardowych zasobów poprzez napisanie i wdrożenie własnego serwera API. Główny serwer API deleguje żądania do twojego serwera API, udostępniając je wszystkim jego klientom.\ \ 13.2 - Rozszerzenia obliczeniowe, przechowywania danych i sieciowe[](https://kubernetes.io/pl/docs/concepts/_print/#pg-c8937cdc9df96f3328becf04f8211292)\ \ =========================================================================================================================================================\ \ Ta sekcja obejmuje rozszerzenia do Twojego klastra, które nie są częścią samego Kubernetesa. Możesz użyć tych rozszerzeń, aby ulepszyć węzły w Twoim klastrze lub zapewnić sieć łączącą Pody.\ \ * Wtyczki pamięci masowej [CSI](https://kubernetes.io/docs/concepts/storage/volumes/#csi)\ i [FlexVolume](https://kubernetes.io/docs/concepts/storage/volumes/#flexvolume)\ \ Wtyczki [Container Storage Interface](https://kubernetes.io/pl/docs/concepts/storage/volumes/#csi)\ (CSI) dostarczają sposób na rozszerzenie Kubernetesa o wsparcie dla nowych rodzajów wolumenów. Wolumeny mogą być wspierane przez trwałe zewnętrzne systemy przechowywania, mogą dostarczać pamięć ulotną, lub mogą oferować interfejs tylko do odczytu dla informacji przy użyciu paradygmatu systemu plików.\ \ Kubernetes zawiera również wsparcie dla wtyczek [FlexVolume](https://kubernetes.io/docs/concepts/storage/volumes/#flexvolume)\ , które są przestarzałe od Kubernetesa v1.23 (na rzecz CSI).\ \ Wtyczki FlexVolume pozwalają użytkownikom montować typy woluminów, które nie są natywnie obsługiwane przez Kubernetesa. Gdy uruchamiasz Pod, który polega na przechowywaniu FlexVolume, "kubelet" wywołuje binarną wtyczkę, aby zamontować wolumin. Zarchiwizowany [FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md)\ dokument projektowy zawiera więcej szczegółów na temat tego podejścia.\ \ [FAQ dotyczące wtyczek wolumenów Kubernetesa dla dostawców pamięci masowej](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)\ zawiera ogólne informacje na temat wtyczek pamięci masowej.\ \ * [Wtyczki urządzeń](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)\ \ Wtyczki urządzeń umożliwiają węzłowi odkrywanie nowych funkcji węzła (dodatkowo do wbudowanych zasobów węzła, takich jak `cpu` i `memory`), oraz udostępniają te niestandardowe funkcje lokalne węzła dla Podów, które ich żądają.\ \ * [Wtyczki sieciowe](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)\ \ Wtyczki sieciowe (ang. network plugins) umożliwiają Kubernetesowi obsługę różnych topologii i technologii sieciowych. Aby klaster Kubernetesa miał działającą sieć Podów i wspierał różne elementy modelu sieciowego Kubernetesa, konieczne jest zainstalowanie odpowiedniej _wtyczki sieciowej_.\ \ Kubernetes 1.35 jest kompatybilny z wtyczkami sieciowymi [CNI](https://kubernetes.io/pl/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)\ . --- # Event Rate Limit Configuration (v1alpha1) | Kubernetes Event Rate Limit Configuration (v1alpha1) ========================================= 资源类型[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#resource-types) ---------------------------------------------------------------------------------------------------------------- * [Configuration](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#eventratelimit-admission-k8s-io-v1alpha1-Configuration) `Configuration`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#eventratelimit-admission-k8s-io-v1alpha1-Configuration) ------------------------------------------------------------------------------------------------------------------------------------------------------------------- Configuration 为 EventRateLimit 准入控制器提供配置数据。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `eventratelimit.admission.k8s.io/v1alpha1` | | `kind`
string | `Configuration` | | `limits` **\[必需\]**
[`[]Limit`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#eventratelimit-admission-k8s-io-v1alpha1-Limit) | `limits` 是为所接收到的事件查询设置的限制。可以针对服务器端接收到的事件设置限制， 按逐个名字空间、逐个用户、或逐个来源+对象组合的方式均可以。 至少需要设置一种限制。 | `Limit`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#eventratelimit-admission-k8s-io-v1alpha1-Limit) --------------------------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [Configuration](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#eventratelimit-admission-k8s-io-v1alpha1-Configuration) `Limit` 是为特定限制类型提供的配置数据。 | 字段 | 描述 | | --- | --- | | `type` **\[必需\]**
[`LimitType`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#eventratelimit-admission-k8s-io-v1alpha1-LimitType) | `type` 是此配置所适用的限制的类型。 | | `qps` **\[必需\]**
`int32` | `qps` 是针对此类型的限制每秒钟所允许的事件查询次数。qps 和 burst 字段一起用来确定是否特定的事件查询会被接受。qps 确定的是当超出查询数量的 burst 值时可以接受的查询个数。 | | `burst` **\[必需\]**
`int32` | burst 是针对此类型限制的突发事件查询数量。qps 和 burst 字段一起使用可用来确定特定的事件查询是否被接受。 burst 字段确定针对特定的事件桶（bucket）可以接受的规模上限。 例如，如果 burst 是 10，qps 是 3，那么准入控制器会在接收 10 个查询之后阻塞所有查询。 每秒钟可以额外允许 3 个查询。如果这一限额未被用尽，则剩余的限额会被顺延到下一秒钟， 直到再次达到 10 个限额的上限。 | | `cacheSize`
`int32` | `cacheSize` 是此类型限制的 LRU 缓存的规模。如果某个事件桶（bucket）被从缓存中剔除， 该事件桶所对应的限额也会被重置。如果后来再次收到针对某个已被剔除的事件桶的查询， 则该事件桶会重新以干净的状态进入缓存，因而获得全量的突发查询配额。

默认的缓存大小是 4096。

如果 limitType 是 “server”，则 cacheSize 设置会被忽略。 | `LimitType`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#eventratelimit-admission-k8s-io-v1alpha1-LimitType) ----------------------------------------------------------------------------------------------------------------------------------------------------------- （`string` 类型的别名） **出现在：** * [Limit](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#eventratelimit-admission-k8s-io-v1alpha1-Limit) `LimitType` 是限制类型（例如：per-namespace，即按命名空间限制）。 反馈[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/#feedback) -------------------------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/) . 最后修改 June 25, 2025 at 8:17 PM PST: [\[zh-cn\]sync cri (4813a4f241)](https://github.com/kubernetes/website/commit/4813a4f241b5b2d302572ee98aab48ce69317b04) --- # IPv4/IPv6 双协议栈 | Kubernetes IPv4/IPv6 双协议栈 ============== Kubernetes 允许你配置单协议栈 IPv4 网络、单协议栈 IPv6 网络或同时激活这两种网络的双协议栈网络。本页说明具体配置方法。 特性状态： `Kubernetes v1.23 [stable]` IPv4/IPv6 双协议栈网络能够将 IPv4 和 IPv6 地址分配给 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/) 和 [Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 。 从 1.21 版本开始，Kubernetes 集群默认启用 IPv4/IPv6 双协议栈网络， 以支持同时分配 IPv4 和 IPv6 地址。 支持的功能[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#supported-features) ------------------------------------------------------------------------------------------------------ Kubernetes 集群的 IPv4/IPv6 双协议栈可提供下面的功能： * 双协议栈 Pod 网络（每个 Pod 分配一个 IPv4 和 IPv6 地址） * IPv4 和 IPv6 启用的 Service * Pod 的集群外出口通过 IPv4 和 IPv6 路由 先决条件[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#prerequisites) ------------------------------------------------------------------------------------------------ 为了使用 IPv4/IPv6 双栈的 Kubernetes 集群，需要满足以下先决条件： * Kubernetes 1.20 版本或更高版本，有关更早 Kubernetes 版本的使用双栈 Service 的信息， 请参考对应版本的 Kubernetes 文档。 * 提供商支持双协议栈网络（云提供商或其他提供商必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口）。 * 支持双协议栈的[网络插件](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 。 配置 IPv4/IPv6 双协议栈[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#%E9%85%8D%E7%BD%AE-ipv4-ipv6-%E5%8F%8C%E5%8D%8F%E8%AE%AE%E6%A0%88) ----------------------------------------------------------------------------------------------------------------------------------------------------------------- 如果配置 IPv4/IPv6 双栈，请分配双栈集群网络： * kube-apiserver： * `--service-cluster-ip-range=,` * kube-controller-manager： * `--cluster-cidr=,` * `--service-cluster-ip-range=,` * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` 对于 IPv4 默认为 /24， 对于 IPv6 默认为 /64 * kube-proxy： * `--cluster-cidr=,` * kubelet： * `--node-ip=,` * 裸机双栈节点（未使用 `--cloud-provider` 标志定义云平台的节点）需要此选项。 如果你使用了某个云平台并选择覆盖云平台所选择的节点 IP，请设置 `--node-ip` 选项。 * （传统的内置云平台实现不支持双栈 `--node-ip`。） #### 说明： IPv4 CIDR 的一个例子：`10.244.0.0/16`（尽管你会提供你自己的地址范围）。 IPv6 CIDR 的一个例子：`fdXY:IJKL:MNOP:15::/64` （这里演示的是格式而非有效地址 - 请看 [RFC 4193](https://tools.ietf.org/html/rfc4193) ）。 Service[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#services) ---------------------------------------------------------------------------------------------- 你可以使用 IPv4 或 IPv6 地址来创建 [Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 。 Service 的地址族默认为第一个服务集群 IP 范围的地址族（通过 kube-apiserver 的 `--service-cluster-ip-range` 参数配置）。 当你定义 Service 时，可以选择将其配置为双栈。若要指定所需的行为，你可以设置 `.spec.ipFamilyPolicy` 字段为以下值之一： * `SingleStack`：单栈 Service。控制面使用第一个配置的服务集群 IP 范围为 Service 分配集群 IP。 * `PreferDualStack`：启用双栈时，为 Service 同时分配 IPv4 和 IPv6 集群 IP 地址。 如果双栈未被启用或不被支持，则会返回到单栈行为。 * `RequireDualStack`：启用双栈时，同时从 IPv4 和 IPv6 的地址范围中分配 Service 的 `.spec.clusterIPs`。 如果双栈未被启用或不被支持，则 Service API 对象创建失败。 * 从基于在 `.spec.ipFamilies` 数组中第一个元素的地址族的 `.spec.clusterIPs` 列表中选择 `.spec.clusterIP` 如果你想要定义哪个 IP 族用于单栈或定义双栈 IP 族的顺序，可以通过设置 Service 上的可选字段 `.spec.ipFamilies` 来选择地址族。 #### 说明： `.spec.ipFamilies` 字段修改是有条件的：你可以添加或删除第二个 IP 地址族， 但你不能更改现有 Service 的主要 IP 地址族。 你可以设置 `.spec.ipFamily` 为以下任何数组值： * `["IPv4"]` * `["IPv6"]` * `["IPv4","IPv6"]` （双栈） * `["IPv6","IPv4"]` （双栈） 你所列出的第一个地址族用于原来的 `.spec.clusterIP` 字段。 ### 双栈 Service 配置场景[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios) 以下示例演示多种双栈 Service 配置场景下的行为。 #### 新 Service 的双栈选项[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#dual-stack-options-on-new-services) 1. 此 Service 规约中没有显式设定 `.spec.ipFamilyPolicy`。当你创建此 Service 时，Kubernetes 从所配置的第一个 `service-cluster-ip-range` 中为 Service 分配一个集群 IP，并设置 `.spec.ipFamilyPolicy` 为 `SingleStack`。 （[无选择算符的 Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#services-without-selectors) 和[无头服务（Headless Service）](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services) 的行为方式与此相同。） [`service/networking/dual-stack-default-svc.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/dual-stack-default-svc.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/dual-stack-default-svc.yaml 到剪贴板") apiVersion: v1 kind: Service metadata: name: my-service labels: app.kubernetes.io/name: MyApp spec: selector: app.kubernetes.io/name: MyApp ports: - protocol: TCP port: 80 2. 此 Service 规约显式地将 `.spec.ipFamilyPolicy` 设置为 `PreferDualStack`。 当你在双栈集群上创建此 Service 时，Kubernetes 会为此 Service 分配 IPv4 和 IPv6 地址。 控制平面更新 Service 的 `.spec` 以记录 IP 地址分配。 字段 `.spec.clusterIPs` 是主要字段，包含两个分配的 IP 地址；`.spec.clusterIP` 是次要字段， 其取值从 `.spec.clusterIPs` 计算而来。 * 对于 `.spec.clusterIP` 字段，控制面记录来自第一个服务集群 IP 范围对应的地址族的 IP 地址。 * 对于单协议栈的集群，`.spec.clusterIPs` 和 `.spec.clusterIP` 字段都 仅仅列出一个地址。 * 对于启用了双协议栈的集群，将 `.spec.ipFamilyPolicy` 设置为 `RequireDualStack` 时，其行为与 `PreferDualStack` 相同。 [`service/networking/dual-stack-preferred-svc.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/dual-stack-preferred-svc.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/dual-stack-preferred-svc.yaml 到剪贴板") apiVersion: v1 kind: Service metadata: name: my-service labels: app.kubernetes.io/name: MyApp spec: ipFamilyPolicy: PreferDualStack selector: app.kubernetes.io/name: MyApp ports: - protocol: TCP port: 80 3. 下面的 Service 规约显式地在 `.spec.ipFamilies` 中指定 `IPv6` 和 `IPv4`，并将 `.spec.ipFamilyPolicy` 设定为 `PreferDualStack`。 当 Kubernetes 为 `.spec.clusterIPs` 分配一个 IPv6 和一个 IPv4 地址时， `.spec.clusterIP` 被设置成 IPv6 地址，因为它是 `.spec.clusterIPs` 数组中的第一个元素， 覆盖其默认值。 [`service/networking/dual-stack-preferred-ipfamilies-svc.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/dual-stack-preferred-ipfamilies-svc.yaml 到剪贴板") apiVersion: v1 kind: Service metadata: name: my-service labels: app.kubernetes.io/name: MyApp spec: ipFamilyPolicy: PreferDualStack ipFamilies: - IPv6 - IPv4 selector: app.kubernetes.io/name: MyApp ports: - protocol: TCP port: 80 #### 现有 Service 的双栈默认值[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#dual-stack-defaults-on-existing-services) 下面示例演示了在 Service 已经存在的集群上新启用双栈时的默认行为。 （将现有集群升级到 1.21 或者更高版本会启用双协议栈支持。） 1. 在集群上启用双栈时，控制面会将现有 Service（无论是 `IPv4` 还是 `IPv6`）配置 `.spec.ipFamilyPolicy` 为 `SingleStack` 并设置 `.spec.ipFamilies` 为 Service 的当前地址族。 [`service/networking/dual-stack-default-svc.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/dual-stack-default-svc.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/dual-stack-default-svc.yaml 到剪贴板") apiVersion: v1 kind: Service metadata: name: my-service labels: app.kubernetes.io/name: MyApp spec: selector: app.kubernetes.io/name: MyApp ports: - protocol: TCP port: 80 你可以通过使用 kubectl 检查现有 Service 来验证此行为。 kubectl get svc my-service -o yaml apiVersion: v1 kind: Service metadata: labels: app.kubernetes.io/name: MyApp name: my-service spec: clusterIP: 10.0.197.123 clusterIPs: - 10.0.197.123 ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - port: 80 protocol: TCP targetPort: 80 selector: app.kubernetes.io/name: MyApp type: ClusterIP status: loadBalancer: {} 2. 在集群上启用双栈时，带有选择算符的现有 [无头服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services) 由控制面设置 `.spec.ipFamilyPolicy` 为 `SingleStack` 并设置 `.spec.ipFamilies` 为第一个服务集群 IP 范围的地址族（通过配置 kube-apiserver 的 `--service-cluster-ip-range` 参数），即使 `.spec.clusterIP` 的设置值为 `None` 也如此。 [`service/networking/dual-stack-default-svc.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/dual-stack-default-svc.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/dual-stack-default-svc.yaml 到剪贴板") apiVersion: v1 kind: Service metadata: name: my-service labels: app.kubernetes.io/name: MyApp spec: selector: app.kubernetes.io/name: MyApp ports: - protocol: TCP port: 80 你可以通过使用 kubectl 检查带有选择算符的现有无头服务来验证此行为。 kubectl get svc my-service -o yaml apiVersion: v1 kind: Service metadata: labels: app.kubernetes.io/name: MyApp name: my-service spec: clusterIP: None clusterIPs: - None ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - port: 80 protocol: TCP targetPort: 80 selector: app.kubernetes.io/name: MyApp #### 在单栈和双栈之间切换 Service[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#switching-services-between-single-stack-and-dual-stack) Service 可以从单栈更改为双栈，也可以从双栈更改为单栈。 1. 要将 Service 从单栈更改为双栈，根据需要将 `.spec.ipFamilyPolicy` 从 `SingleStack` 改为 `PreferDualStack` 或 `RequireDualStack`。 当你将此 Service 从单栈更改为双栈时，Kubernetes 将分配缺失的地址族， 以便现在此 Service具有 IPv4 和 IPv6 地址。 编辑 Service 规约将 `.spec.ipFamilyPolicy` 从 `SingleStack` 改为 `PreferDualStack`。 之前： spec: ipFamilyPolicy: SingleStack 之后： spec: ipFamilyPolicy: PreferDualStack 2. 要将 Service 从双栈更改为单栈，请将 `.spec.ipFamilyPolicy` 从 `PreferDualStack` 或 `RequireDualStack` 改为 `SingleStack`。 当你将此 Service 从双栈更改为单栈时，Kubernetes 只保留 `.spec.clusterIPs` 数组中的第一个元素，并设置 `.spec.clusterIP` 为那个 IP 地址， 并设置 `.spec.ipFamilies` 为 `.spec.clusterIPs` 地址族。 ### 无选择算符的无头服务[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#headless-services-without-selector) 对于[不带选择算符的无头服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#without-selectors) ， 若没有显式设置 `.spec.ipFamilyPolicy`，则 `.spec.ipFamilyPolicy` 字段默认设置为 `RequireDualStack`。 ### LoadBalancer 类型 Service[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#service-type-loadbalancer) 要为你的 Service 提供双栈负载均衡器： * 将 `.spec.type` 字段设置为 `LoadBalancer` * 将 `.spec.ipFamilyPolicy` 字段设置为 `PreferDualStack` 或者 `RequireDualStack` #### 说明： 为了使用双栈的负载均衡器类型 Service，你的云驱动必须支持 IPv4 和 IPv6 的负载均衡器。 出站流量[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#egress-traffic) ------------------------------------------------------------------------------------------------- 如果你要启用出站流量，以便使用非公开路由 IPv6 地址的 Pod 到达集群外地址 （例如公网），则需要通过透明代理或 IP 伪装等机制使 Pod 使用公共路由的 IPv6 地址。 [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 项目 支持在双栈集群上进行 IP 伪装。 #### 说明： 确认你的 [CNI](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 驱动支持 IPv6。 Windows 支持[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#windows-support) -------------------------------------------------------------------------------------------------------- Windows 上的 Kubernetes 不支持单栈“仅 IPv6” 网络。 然而， 对于 Pod 和节点而言，仅支持单栈形式 Service 的双栈 IPv4/IPv6 网络是被支持的。 你可以使用 `l2bridge` 网络来实现 IPv4/IPv6 双栈联网。 #### 说明： Windows 上的 Overlay（VXLAN）网络**不**支持双栈网络。 关于 Windows 的不同网络模式，你可以进一步阅读 [Windows 上的网络](https://kubernetes.io/zh-cn/docs/concepts/services-networking/windows-networking#network-modes) 。 接下来[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) ------------------------------------------------------------------------------------------------------------- * [验证 IPv4/IPv6 双协议栈](https://kubernetes.io/zh-cn/docs/tasks/network/validate-dual-stack) 网络 * [使用 kubeadm 启用双协议栈网络](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) 反馈[](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/#feedback) ----------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/services-networking/dual-stack/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/services-networking/dual-stack/) . 最后修改 July 14, 2024 at 11:07 PM PST: [\[zh-cn\] Sync services-networking/\* (9070bf13ee)](https://github.com/kubernetes/website/commit/9070bf13ee20657dd2097cd2da1a570a7ea4915d) --- # 生产环境 | Kubernetes 生产环境 ==== 生产质量的 Kubernetes 集群需要规划和准备。 如果你的 Kubernetes 集群是用来运行关键负载的，该集群必须被配置为弹性的（Resilient）。 本页面阐述你在安装生产就绪的集群或将现有集群升级为生产用途时可以遵循的步骤。 如果你已经熟悉生产环境安装，因此只关注一些链接，则可以跳到[接下来](https://kubernetes.io/zh-cn/docs/setup/production-environment/#what-s-next) 节。 生产环境考量[](https://kubernetes.io/zh-cn/docs/setup/production-environment/#production-considerations) --------------------------------------------------------------------------------------------------- 通常，一个生产用 Kubernetes 集群环境与个人学习、开发或测试环境所使用的 Kubernetes 相比有更多的需求。 生产环境可能需要被很多用户安全地访问，需要提供一致的可用性，以及能够与需求变化相适配的资源。 在你决定在何处运行你的生产用 Kubernetes 环境（在本地或者在云端）， 以及你希望承担或交由他人承担的管理工作量时， 需要考察以下因素如何影响你对 Kubernetes 集群的需求： * **可用性**：一个单机的 Kubernetes [学习环境](https://kubernetes.io/zh-cn/docs/setup/#%E5%AD%A6%E4%B9%A0%E7%8E%AF%E5%A2%83) 具有单点失效特点。创建高可用的集群则意味着需要考虑： * 将控制面与工作节点分开 * 在多个节点上提供控制面组件的副本 * 为针对集群的 [API 服务器](https://kubernetes.io/zh-cn/docs/concepts/architecture/#kube-apiserver) 的流量提供负载均衡 * 随着负载的合理需要，提供足够的可用的（或者能够迅速变为可用的）工作节点 * **规模**：如果你预期你的生产用 Kubernetes 环境要承受固定量的请求， 你可能可以针对所需要的容量来一次性完成安装。 不过，如果你预期服务请求会随着时间增长，或者因为类似季节或者特殊事件的原因而发生剧烈变化， 你就需要规划如何处理请求上升时对控制面和工作节点的压力，或者如何缩减集群规模以减少未使用资源的消耗。 * **安全性与访问管理**：在你自己的学习环境 Kubernetes 集群上，你拥有完全的管理员特权。 但是针对运行着重要工作负载的共享集群，用户账户不止一两个时， 就需要更细粒度的方案来确定谁或者哪些主体可以访问集群资源。 你可以使用基于角色的访问控制（[RBAC](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/) ） 和其他安全机制来确保用户和负载能够访问到所需要的资源， 同时确保工作负载及集群自身仍然是安全的。 你可以通过管理[策略](https://kubernetes.io/zh-cn/docs/concepts/policy/) 和 [容器资源](https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers) 来针对用户和工作负载所可访问的资源设置约束。 在自行构建 Kubernetes 生产环境之前， 请考虑将这一任务的部分或者全部交给[云方案承包服务](https://kubernetes.io/zh-cn/docs/setup/production-environment/turnkey-solutions) 提供商或者其他 [Kubernetes 合作伙伴](https://kubernetes.io/zh-cn/partners/) 。选项有： * **无服务**：仅是在第三方设备上运行负载，完全不必管理集群本身。 你需要为 CPU 用量、内存和磁盘请求等付费。 * **托管控制面**：让供应商决定集群控制面的规模和可用性，并负责打补丁和升级等操作。 * **托管工作节点**：配置一个节点池来满足你的需要，由供应商来确保节点始终可用，并在需要的时候完成升级。 * **集成**：有一些供应商能够将 Kubernetes 与一些你可能需要的其他服务集成， 这类服务包括存储、容器镜像仓库、身份认证方法以及开发工具等。 无论你是自行构造一个生产用 Kubernetes 集群还是与合作伙伴一起协作， 请审阅下面章节以评估你的需求，因为这关系到你的集群的**控制面**、**工作节点**、**用户访问**以及**负载资源**。 生产用集群安装[](https://kubernetes.io/zh-cn/docs/setup/production-environment/#production-cluster-setup) --------------------------------------------------------------------------------------------------- 在生产质量的 Kubernetes 集群中，控制面用不同的方式来管理集群和可以分布到多个计算机上的服务。 每个工作节点则代表的是一个可配置来运行 Kubernetes Pod 的实体。 ### 生产用控制面[](https://kubernetes.io/zh-cn/docs/setup/production-environment/#production-control-plane) 最简单的 Kubernetes 集群中，整个控制面和工作节点服务都运行在同一台机器上。 你可以通过添加工作节点来提升环境运算能力，正如 [Kubernetes 组件](https://kubernetes.io/zh-cn/docs/concepts/overview/components/) 示意图所示。 如果只需要集群在很短的一段时间内可用，或者可以在某些事物出现严重问题时直接丢弃， 这种配置可能符合你的需要。 如果你需要一个更为持久的、高可用的集群，那么就需要考虑扩展控制面的方式。 根据设计，运行在一台机器上的单机控制面服务不是高可用的。 如果你认为保持集群的正常运行并需要确保它在出错时可以被修复是很重要的， 可以考虑以下步骤： * **选择部署工具**：你可以使用类似 kubeadm、kops 和 kubespray 这类工具来部署控制面。 参阅[使用部署工具安装 Kubernetes](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/) 以了解使用这类部署方法来完成生产就绪部署的技巧。 存在不同的[容器运行时](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/) 可供你的部署采用。 * **管理证书**：控制面服务之间的安全通信是通过证书来完成的。 证书是在部署期间自动生成的，或者你也可以使用自己的证书机构来生成它们。 参阅 [PKI 证书和需求](https://kubernetes.io/zh-cn/docs/setup/best-practices/certificates/) 了解细节。 * **为 API 服务器配置负载均衡**：配置负载均衡器来将外部的 API 请求散布给运行在不同节点上的 API 服务实例。 参阅[创建外部负载均衡器](https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/) 了解细节。 * **分离并备份 etcd 服务**：etcd 服务可以运行于其他控制面服务所在的机器上， 也可以运行在不同的机器上以获得更好的安全性和可用性。 因为 etcd 存储着集群的配置数据，应该经常性地对 etcd 数据库进行备份， 以确保在需要的时候你可以修复该数据库。与配置和使用 etcd 相关的细节可参阅 [etcd FAQ](https://etcd.io/docs/v3.5/faq/) 。 更多的细节可参阅[为 Kubernetes 运维 etcd 集群](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/) 和[使用 kubeadm 配置高可用的 etcd 集群](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) 。 * **创建多控制面系统**：为了实现高可用性，控制面不应被限制在一台机器上。 如果控制面服务是使用某 init 服务（例如 systemd）来运行的，每个服务应该至少运行在三台机器上。 不过，将控制面作为服务运行在 Kubernetes Pod 中可以确保你所请求的个数的服务始终保持可用。 调度器应该是可容错的，但不是高可用的。 某些部署工具会安装 [Raft](https://raft.github.io/) 票选算法来对 Kubernetes 服务执行领导者选举。 如果主节点消失，另一个服务会被选中并接手相应服务。 * **跨多个可用区**：如果保持你的集群一直可用这点非常重要，可以考虑创建一个跨多个数据中心的集群； 在云环境中，这些数据中心被视为可用区。若干个可用区在一起可构成地理区域。 通过将集群分散到同一区域中的多个可用区内，即使某个可用区不可用，整个集群能够继续工作的机会也大大增加。 更多的细节可参阅[跨多个可用区运行](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/) 。 * **管理演进中的特性**：如果你计划长时间保留你的集群，就需要执行一些维护其健康和安全的任务。 例如，如果你采用 kubeadm 安装的集群， 则有一些可以帮助你完成 [证书管理](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) 和[升级 kubeadm 集群](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade) 的指令。 参见[管理集群](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster) 了解一个 Kubernetes 管理任务的较长列表。 如要了解运行控制面服务时可使用的选项，可参阅 [kube-apiserver](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) 、 [kube-controller-manager](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 和 [kube-scheduler](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) 组件参考页面。 如要了解高可用控制面的例子，可参阅[高可用拓扑结构选项](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/ha-topology/) 、 [使用 kubeadm 创建高可用集群](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/) 以及[为 Kubernetes 运维 etcd 集群](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/) 。 关于制定 etcd 备份计划，可参阅[对 etcd 集群执行备份](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) 。 ### 生产用工作节点[](https://kubernetes.io/zh-cn/docs/setup/production-environment/#production-worker-nodes) 生产质量的工作负载需要是弹性的；它们所依赖的其他组件（例如 CoreDNS）也需要是弹性的。 无论你是自行管理控制面还是让云供应商来管理，你都需要考虑如何管理工作节点 （有时也简称为**节点**）。 * **配置节点**：节点可以是物理机或者虚拟机。如果你希望自行创建和管理节点， 你可以安装一个受支持的操作系统，之后添加并运行合适的[节点服务](https://kubernetes.io/zh-cn/docs/concepts/architecture/#node-components) 。考虑： * 在安装节点时要通过配置适当的内存、CPU 和磁盘读写速率、存储容量来满足你的负载的需求。 * 是否通用的计算机系统即足够，还是你有负载需要使用 GPU 处理器、Windows 节点或者 VM 隔离。 * **验证节点**：参阅[验证节点配置](https://kubernetes.io/zh-cn/docs/setup/best-practices/node-conformance/) 以了解如何确保节点满足加入到 Kubernetes 集群的需求。 * **添加节点到集群中**：如果你自行管理你的集群，你可以通过安装配置你的机器， 之后或者手动加入集群，或者让它们自动注册到集群的 API 服务器。 参阅[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 节，了解如何配置 Kubernetes 以便以这些方式来添加节点。 * **扩缩节点**：制定一个扩充集群容量的规划，你的集群最终会需要这一能力。 参阅[大规模集群考察事项](https://kubernetes.io/zh-cn/docs/setup/best-practices/cluster-large/) 以确定你所需要的节点数； 这一规模是基于你要运行的 Pod 和容器个数来确定的。 如果你自行管理集群节点，这可能意味着要购买和安装你自己的物理设备。 * **节点自动扩缩容**：查阅[节点自动扩缩容](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/cluster-autoscaling) ， 了解可以自动管理节点的工具及其提供的能力。 * **安装节点健康检查**：对于重要的工作负载，你会希望确保节点以及在节点上运行的 Pod 处于健康状态。 通过使用 [Node Problem Detector](https://kubernetes.io/zh-cn/docs/tasks/debug/debug-cluster/monitor-node-health/) ， 你可以确保你的节点是健康的。 ### 生产级用户环境[](https://kubernetes.io/zh-cn/docs/setup/production-environment/#production-user-management) 在生产环境中，情况可能不再是你或者一小组人在访问集群，而是几十上百人需要访问集群。 在学习环境或者平台原型环境中，你可能具有一个可以执行任何操作的管理账号。 在生产环境中，你会需要对不同名字空间具有不同访问权限级别的很多账号。 建立一个生产级别的集群意味着你需要决定如何有选择地允许其他用户访问集群。 具体而言，你需要选择验证尝试访问集群的人的身份标识（身份认证）， 并确定他们是否被许可执行他们所请求的操作（鉴权）： * **认证（Authentication）**：API 服务器可以使用客户端证书、持有者令牌、 身份认证代理或者 HTTP 基本认证机制来完成身份认证操作。 你可以选择你要使用的认证方法。通过使用插件， API 服务器可以充分利用你所在组织的现有身份认证方法， 例如 LDAP 或者 Kerberos。 关于认证 Kubernetes 用户身份的不同方法的描述， 可参阅[身份认证](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/) 。 * **鉴权（Authorization）**：当你准备为一般用户执行权限判定时， 你可能会需要在 RBAC 和 ABAC 鉴权机制之间做出选择。 参阅[鉴权概述](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authorization/) ， 了解对用户账户（以及访问你的集群的服务账户）执行鉴权的不同模式。 * **基于角色的访问控制**（[RBAC](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/) ）： 让你通过为通过身份认证的用户授权特定的许可集合来控制集群访问。 访问许可可以针对某特定名字空间（Role）或者针对整个集群（ClusterRole）。 通过使用 RoleBinding 和 ClusterRoleBinding 对象，这些访问许可可以被关联到特定的用户身上。 * **基于属性的访问控制**（[ABAC](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/abac/) ）： 让你能够基于集群中资源的属性来创建访问控制策略，基于对应的属性来决定允许还是拒绝访问。 策略文件的每一行都给出版本属性（apiVersion 和 kind）以及一个规约属性的映射， 用来匹配主体（用户或组）、资源属性、非资源属性（/version 或 /apis）和只读属性。 参阅[示例](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/abac/#examples) 以了解细节。 作为在你的生产用 Kubernetes 集群中安装身份认证和鉴权机制的负责人，要考虑的事情如下： * **设置鉴权模式**：当 Kubernetes API 服务器（[kube-apiserver](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) ）启动时， 所支持的鉴权模式必须使用 `*--authorization-config` 文件或 `--authorization-mode` 标志配置。 例如，`kube-apiserver.yaml`（位于 `/etc/kubernetes/manifests` 下）中对应的标志可以设置为 `Node,RBAC`。 这样就会针对已完成身份认证的请求执行 Node 和 RBAC 鉴权。 * **创建用户证书和角色绑定（RBAC）**：如果你在使用 RBAC 鉴权，用户可以创建由集群 CA 签名的 CertificateSigningRequest（CSR）。接下来你就可以将 Role 和 ClusterRole 绑定到每个用户身上。 参阅[证书签名请求](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/) 了解细节。 * **创建组合属性的策略（ABAC）**：如果你在使用 ABAC 鉴权， 你可以设置属性组合以构造策略对所选用户或用户组执行鉴权， 判定他们是否可访问特定的资源（例如 Pod）、名字空间或者 apiGroup。 进一步的详细信息可参阅[示例](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/abac/#examples) 。 * **考虑准入控制器**：针对指向 API 服务器的请求的其他鉴权形式还包括 [Webhook 令牌认证](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 。 Webhook 和其他特殊的鉴权类型需要通过向 API 服务器添加[准入控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 来启用。 为负载资源设置约束[](https://kubernetes.io/zh-cn/docs/setup/production-environment/#set-limits-on-workload-resources) ------------------------------------------------------------------------------------------------------------- 生产环境负载的需求可能对 Kubernetes 的控制面内外造成压力。 在针对你的集群的负载执行配置时，要考虑以下条目： * **设置名字空间限制**：为每个名字空间的内存和 CPU 设置配额。 参阅[管理内存、CPU 和 API 资源](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/manage-resources/) 以了解细节。 * **为 DNS 请求做准备**：如果你希望工作负载能够完成大规模扩展，你的 DNS 服务也必须能够扩大规模。 参阅[自动扩缩集群中 DNS 服务](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) 。 * **创建额外的服务账户**：用户账户决定用户可以在集群上执行的操作，服务账号则定义的是在特定名字空间中 Pod 的访问权限。默认情况下，Pod 使用所在名字空间中的 default 服务账号。 参阅[管理服务账号](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/) 以了解如何创建新的服务账号。 例如，你可能需要： * 为 Pod 添加 Secret，以便 Pod 能够从某特定的容器镜像仓库拉取镜像。 参阅[为 Pod 配置服务账号](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 以获得示例。 * 为服务账号设置 RBAC 访问许可。参阅[服务账号访问许可](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/#service-account-permissions) 了解细节。 接下来[](https://kubernetes.io/zh-cn/docs/setup/production-environment/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) -------------------------------------------------------------------------------------------------- * 决定你是想自行构造自己的生产用 Kubernetes， 还是从某可用的[云服务外包厂商](https://kubernetes.io/zh-cn/docs/setup/production-environment/turnkey-solutions/) 或 [Kubernetes 合作伙伴](https://kubernetes.io/zh-cn/partners/) 获得集群。 * 如果你决定自行构造集群，则需要规划如何处理[证书](https://kubernetes.io/zh-cn/docs/setup/best-practices/certificates/) 并为类似 [etcd](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) 和 [API 服务器](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/ha-topology/) 这些功能组件配置高可用能力。 * 选择使用 [kubeadm](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/) 、 [kops](https://kops.sigs.k8s.io/) 或 [Kubespray](https://kubespray.io/) 作为部署方法。 * 通过决定[身份认证](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/) 和[鉴权](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authorization/) 方法来配置用户管理。 * 通过配置[资源限制](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/manage-resources/) 、 [DNS 自动扩缩](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) 和[服务账号](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/) 来为应用负载作准备。 反馈[](https://kubernetes.io/zh-cn/docs/setup/production-environment/#feedback) ------------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/setup/production-environment/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/setup/production-environment/) . 最后修改 April 20, 2025 at 9:57 PM PST: [\[zh-cn\]sync production-environment/\_index.md (d5b9b53c8d)](https://github.com/kubernetes/website/commit/d5b9b53c8d91fb9111500c523eea6405acdd744e) --- # Kubernetes 问题和安全 | Kubernetes Kubernetes 问题和安全 ================ * * * ##### [Kubernetes 问题追踪](https://kubernetes.io/zh-cn/docs/reference/issues-security/issues/) ##### [Kubernetes 安全和信息披露](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/) ##### [官方 CVE 订阅源](https://kubernetes.io/zh-cn/docs/reference/issues-security/official-cve-feed/) 反馈[](https://kubernetes.io/zh-cn/docs/reference/issues-security/#feedback) --------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/issues-security/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/issues-security/) . 最后修改 March 23, 2023 at 1:28 PM PST: [\[zh-cn\] Reference files to sync task-32 (80c0e7c419)](https://github.com/kubernetes/website/commit/80c0e7c419bef655caf90820730f45246b3a4554) --- # 부트스트랩 토큰을 사용한 인증 | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Authenticating with Bootstrap Tokens](https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/) 부트스트랩 토큰을 사용한 인증 ================ 기능 상태: `Kubernetes v1.18 [stable]` 부트스트랩 토큰은 새 클러스터를 만들거나 새 노드를 기존 클러스터에 결합할 때 사용되는 간단한 전달자 토큰이다. [kubeadm](https://kubernetes.io/ko/docs/reference/setup-tools/kubeadm/) 을 지원하도록 구축되었지만 `kubeadm` 없이 클러스터를 시작하려는 사용자를 위해 다른 컨텍스트에서 사용할 수 있다. 또한 RBAC 정책을 통해 [Kubelet TLS 부트스트래핑](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 시스템과 함께 동작하도록 구축되었다. 부트스트랩 토큰 개요[](https://kubernetes.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/#%EB%B6%80%ED%8A%B8%EC%8A%A4%ED%8A%B8%EB%9E%A9-%ED%86%A0%ED%81%B0-%EA%B0%9C%EC%9A%94) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 부트스트랩 토큰은 `kube-system` 네임스페이스에 있는 특정 유형(`bootstrap.kubernetes.io/token`)의 시크릿(Secret)으로 정의된다. API 서버의 부트스트랩 인증자가 이러한 시크릿을 읽는다. 만료된 토큰은 컨트롤러 관리자가 TokenCleaner 컨트롤러로 제거한다. 토큰은 BootstrapSigner 컨트롤러를 통해 "discovery" 프로세스에 사용되는 특정 컨피그맵(ConfigMap)에 대한 서명을 만드는 데도 사용된다. 토큰 형식[](https://kubernetes.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/#%ED%86%A0%ED%81%B0-%ED%98%95%EC%8B%9D) ---------------------------------------------------------------------------------------------------------------------------- 부트스트랩 토큰은 `abcdef.0123456789abcdef` 형식을 취한다. 더 공식적으로는 정규식 `[a-z0-9]{6}\.[a-z0-9]{16}` 와 일치해야 한다. 토큰의 첫 번째 부분은 "Token ID" 이며 공개 정보로 간주된다. 인증에 사용하는 시크릿의 일부를 노출하지 않고 토큰을 참조할 때 사용한다. 두 번째 부분은 "Token Secret"이며 신뢰할 수 있는 당사자와만 공유해야 한다. 부트스트랩 토큰 인증 활성화[](https://kubernetes.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/#%EB%B6%80%ED%8A%B8%EC%8A%A4%ED%8A%B8%EB%9E%A9-%ED%86%A0%ED%81%B0-%EC%9D%B8%EC%A6%9D-%ED%99%9C%EC%84%B1%ED%99%94) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- API 서버에서 다음 플래그를 사용하여 부트스트랩 토큰 인증자를 활성화할 수 있다. --enable-bootstrap-token-auth 활성화되면 부트스트랩 토큰을 API 서버에 대한 요청을 인증하기 위한 전달자 토큰 자격 증명으로 사용할 수 있다. Authorization: Bearer 07401b.f395accd246ae52d 토큰은 사용자 이름 `system:bootstrap:` 로 인증되며 `system:bootstrappers` 그룹의 구성원이다. 토큰의 시크릿에 추가 그룹을 지정할 수 있다. 만료된 토큰은 컨트롤러 관리자에서 `tokencleaner` 컨트롤러를 활성화하여 자동으로 삭제할 수 있다. --controllers=*,tokencleaner 부트스트랩 토큰 시크릿 형식[](https://kubernetes.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/#%EB%B6%80%ED%8A%B8%EC%8A%A4%ED%8A%B8%EB%9E%A9-%ED%86%A0%ED%81%B0-%EC%8B%9C%ED%81%AC%EB%A6%BF-%ED%98%95%EC%8B%9D) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 각각의 유효한 토큰은 `kube-system` 네임스페이스의 시크릿에 의해 지원된다. 전체 디자인 문서는 [여기](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md) 에서 찾을 수 있다. 시크릿은 다음과 같다. apiVersion: v1 kind: Secret metadata: # Name MUST be of form "bootstrap-token-" name: bootstrap-token-07401b namespace: kube-system # Type MUST be 'bootstrap.kubernetes.io/token' type: bootstrap.kubernetes.io/token stringData: # Human readable description. Optional. description: "The default bootstrap token generated by 'kubeadm init'." # Token ID and secret. Required. token-id: 07401b token-secret: f395accd246ae52d # Expiration. Optional. expiration: 2017-03-10T03:22:11Z # Allowed usages. usage-bootstrap-authentication: "true" usage-bootstrap-signing: "true" # Extra groups to authenticate the token as. Must start with "system:bootstrappers:" auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress 시크릿 유형은 `bootstrap.kubernetes.io/token` 이어야 하고 이름은 `bootstrap-token-`여야 한다. 반드시 `kube-system` 네임스페이스에도 존재해야 한다. `usage-bootstrap-*` 멤버는 이 시크릿의 용도를 나타낸다. 활성화하려면 값을 `true` 로 설정해야 한다. * `usage-bootstrap-authentication` 은 토큰을 API 서버에 베어러 토큰으로 인증하는데 사용할 수 있음을 나타낸다. * `usage-bootstrap-signing` 은 토큰을 사용하여 아래에 설명된 `cluster-info` 컨피그맵에 서명할 수 있음을 나타낸다. `expiration` 필드는 토큰의 만료를 제어한다. 만료된 토큰은 인증에 사용될 때 거부되고 컨피그맵서명 중에 무시된다. 만료된 값은 RFC3339를 사용하여 절대 UTC 시간으로 인코딩된다. 만료된 토큰을 자동으로 삭제하려면 `tokencleaner` 컨트롤러를 활성화한다. kubeadm을 사용한 토큰 관리[](https://kubernetes.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/#kubeadm%EC%9D%84-%EC%82%AC%EC%9A%A9%ED%95%9C-%ED%86%A0%ED%81%B0-%EA%B4%80%EB%A6%AC) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- `kubeadm` 툴을 사용하여 실행중인 클러스터에서 토큰을 관리할 수 있다. 자세한 내용은 [kubeadm token docs](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token/) 에서 찾을 수 있다. 컨피그맵 서명[](https://kubernetes.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/#%EC%BB%A8%ED%94%BC%EA%B7%B8%EB%A7%B5-%EC%84%9C%EB%AA%85) ------------------------------------------------------------------------------------------------------------------------------------------------ 토큰은 인증 외에도 컨피그맵에 서명하는데 사용할 수 있다. 이것은 클라이언트가 API 서버를 신뢰하기 전에 클러스터 부트스트랩 프로세스의 초기에 사용된다. 서명된 컨피그맵은 공유 토큰으로 인증할 수 있다. 컨트롤러 관리자에서 `bootstrapsigner` 컨트롤러를 활성화하여 컨피그맵서명을 활성화 한다. --controllers=*,bootstrapsigner 서명된 컨피그맵은 `kube-public` 네임스페이스에 있는 `cluster-info` 이다. 일반적인 흐름은 클라이언트가 인증되지 않고 TLS 오류를 무시하는 동안 컨피그맵을 읽는 것이다. 그런 다음 컨피그맵에 포함된 서명을 확인하여 컨피그맵의 페이로드를 확인한다. 컨피그맵은 다음과 같을 수 있다. apiVersion: v1 kind: ConfigMap metadata: name: cluster-info namespace: kube-public data: jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U kubeconfig: | apiVersion: v1 clusters: - cluster: certificate-authority-data: server: https://10.138.0.2:6443 name: "" contexts: [] current-context: "" kind: Config preferences: {} users: [] 컨피그맵의 `kubeconfig` 멤버는 클러스터 정보만 입력된 구성 파일이다. 여기서 전달되는 핵심은 `certificate-authority-data` 이다. 이는 향후 확대될 수 있다. 서명은 "detached" 모드를 사용하는 JWS 서명이다. 서명을 검증하려면 사용자는 JWS 규칙(뒤로 오는 `=` 를 삭제하는 동안 인코딩된 base64)에 따라 `kubeconfig` 페이로드를 인코딩해야 한다. 그런 다음 인코딩된 페이로드는 두 개의 점 사이에 삽입하여 전체 JWS를 형성하는 데 사용된다. 전체 토큰(예:`07401b.f395accd246ae52d`)을 공유 시크릿으로 사용하여 `HS256` 방식(HMAC-SHA256)을 사용함으로 JWS를 확인할 수 있다. 사용자는 _반드시_ HS256이 사용되고 있는지 확인해야 한다. #### 경고: 부트스트래핑 토큰을 가진 모든 당사자는 해당 토큰에 대한 유효한 서명을 만들 수 있다. 컨피그맵 서명을 사용할 때 많은 클라이언트와 동일한 토큰을 공유하는 것은 권장되지 않는다. 손상된 클라이언트는 잠재적으로 서명에 의존하여 TLS 트러스트를 부트스트랩하는 다른 클라이언트를 대신할 수 있기 때문이다. 자세한 내용은 [kubeadm implementation details](https://kubernetes.io/docs/reference/setup-tools/kubeadm/implementation-details/) 섹션을 참조하면 된다. 피드백[](https://kubernetes.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/#feedback) --------------------------------------------------------------------------------------------- 이 페이지가 도움이 되었나요? 네 아니요 피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 원한다면 GitHub 리포지터리에 이슈를 열어서 [문제 리포트](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/) 또는 [개선 제안이 가능합니다.](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/) . 최종 수정 August 10, 2022 at 4:33 PM PST: [\[ko\] Update links in dev-1.24-ko.3 (9fe9e1b827)](https://github.com/kubernetes/website/commit/9fe9e1b82781b8ef776f966bea0223e0ea770f7b) --- # Kubernetes 安全和信息披露 | Kubernetes Kubernetes 安全和信息披露 ================== 本页面介绍 Kubernetes 安全和信息披露相关的内容。 安全公告[](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/#security-announcements) ---------------------------------------------------------------------------------------------------- 加入 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 组，以获取关于安全性和主要 API 公告的电子邮件。 报告一个漏洞[](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/#report-a-vulnerability) ------------------------------------------------------------------------------------------------------ 我们非常感谢向 Kubernetes 开源社区报告漏洞的安全研究人员和用户。 所有的报告都由社区志愿者进行彻底调查。 如需报告，请将你的漏洞提交给 [Kubernetes 漏洞赏金计划](https://hackerone.com/kubernetes) 。 这样做可以使得社区能够在标准化的响应时间内对漏洞进行分类和处理。 你还可以通过电子邮件向私有 [security@kubernetes.io](mailto:security@kubernetes.io) 列表发送电子邮件，邮件中应该包含 [所有 Kubernetes 错误报告](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml) 所需的详细信息。 你可以使用[安全响应委员会成员](https://git.k8s.io/security/README.md#product-security-committee-psc) 的 GPG 密钥加密你的发往邮件列表的邮件。揭示问题时不需要使用 GPG 来加密。 ### 我应该在什么时候报告漏洞？[](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/#when-should-i-report-a-vulnerability) * 你认为在 Kubernetes 中发现了一个潜在的安全漏洞 * 你不确定漏洞如何影响 Kubernetes * 你认为你在 Kubernetes 依赖的另一个项目中发现了一个漏洞 * 对于具有漏洞报告和披露流程的项目，请直接在该项目处报告 ### 我什么时候不应该报告漏洞？[](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/#when-should-i-not-report-a-vulnerability) * 你需要调整 Kubernetes 组件安全性的帮助 * 你需要应用与安全相关更新的帮助 * 你的问题与安全无关 安全漏洞响应[](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/#security-vulnerability-response) --------------------------------------------------------------------------------------------------------------- 每个报告在 3 个工作日内由安全响应委员会成员确认和分析， 这将启动[安全发布过程](https://git.k8s.io/security/security-release-process.md#disclosures) 。 与安全响应委员会共享的任何漏洞信息都保留在 Kubernetes 项目中，除非有必要修复该问题，否则不会传播到其他项目。 随着安全问题从分类、识别修复、发布计划等方面的进展，我们将不断更新报告。 公开披露时间[](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/#public-disclosure-timing) -------------------------------------------------------------------------------------------------------- 公开披露日期由 Kubernetes 安全响应委员会和 bug 提交者协商。 我们倾向于在能够为用户提供缓解措施之后尽快完全披露该 bug。 当 bug 或其修复还没有被完全理解，解决方案没有经过良好的测试，或者为了处理供应商协调问题时，延迟披露是合理的。 信息披露的时间范围从即时（尤其是已经公开的）到几周不等。 对于具有直接缓解措施的漏洞，我们希望报告日期到披露日期的间隔是 7 天。 在设置披露日期方面，Kubernetes 安全响应委员会拥有最终决定权。 反馈[](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/#feedback) ------------------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/issues-security/security/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/issues-security/security/) . 最后修改 January 08, 2026 at 2:27 PM PST: [Update security.md (e42c6b186f)](https://github.com/kubernetes/website/commit/e42c6b186f8f09f89131a6ccfea8e6873cfda111) --- # Kubelet CredentialProvider (v1) | Kubernetes **此文档中的信息可能已过时** 此文档的更新日期比原文晚，因此其中的信息可能已过时。如果能阅读英文，请查看英文版本以获取最新信息： [Kubelet CredentialProvider (v1)](https://kubernetes.io/docs/reference/config-api/kubelet-credentialprovider.v1/) Kubelet CredentialProvider (v1) =============================== 资源类型[](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#resource-types) ------------------------------------------------------------------------------------------------------------ * [CredentialProviderRequest](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-CredentialProviderRequest) * [CredentialProviderResponse](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-CredentialProviderResponse) `CredentialProviderRequest`[](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-CredentialProviderRequest) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- `CredentialProviderRequest` 包含 kubelet 需要通过身份验证才能访问的镜像。 kubelet 将此请求对象通过 stdin 传递到插件。 通常，插件应优先使用所收到的 `apiVersion` 作出响应。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `credentialprovider.kubelet.k8s.io/v1` | | `kind`
string | `CredentialProviderRequest` | | `image` **\[必需\]**
`string` | `image` 是作为凭据提供程序插件请求的一部分所拉取的容器镜像。 这些插件可以选择解析镜像以提取获取凭据所需的任何信息。 | | `serviceAccountToken` **\[必需\]**
`string` | `serviceAccountToken` 是与正在拉取镜像的 Pod 绑定的服务帐号令牌。 只有在 kubelet 的凭证提供者配置中设置了 `tokenAttributes.serviceAccountTokenAudience` 字段时， 才会将此令牌发送给插件。 | | `serviceAccountAnnotations` **\[必需\]**
`map[string]string` | `serviceAccountAnnotations`\> 与正在拉取镜像的 Pod 绑定的服务帐号上的注解映射。需要传递给插件的服务帐号中的注解列表在 kubelet 的凭证提供者配置中进行配置。 | `CredentialProviderResponse`[](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-CredentialProviderResponse) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- `CredentialProviderResponse` 中包含 kubelet 应针对原始请求中所给镜像来使用的凭据。 kubelet 将通过 stdout 读取来自插件的响应。 此响应应被设置为与 `CredentialProviderRequest` 相同的 `apiVersion`。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `credentialprovider.kubelet.k8s.io/v1` | | `kind`
string | `CredentialProviderResponse` | | `cacheKeyType` **\[必需\]**
[`PluginCacheKeyType`](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-PluginCacheKeyType) | `cacheKeyType` 标示了基于请求中提供的镜像要使用的缓存键的类型。 缓存键类型有三个有效值：`Image`、`Registry` 和 `Global`。 如果所指定的值无效，则此响应不会被 kubelet 使用。 | | `cacheDuration`
[`meta/v1.Duration`](https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration) | `cacheDuration` 标示所提供的凭据可被缓存的持续期。 kubelet 将使用此字段为 `AuthConfig` 中的凭据设置内存中缓存持续期。 如果为空，kubelet 将使用 CredentialProviderConfig 中提供的 `defaultCacheDuration`。 如果设置为 0，kubelet 将不再缓存提供的 `AuthConfig`。 | | `auth`
[`map[string]AuthConfig`](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-AuthConfig) | `auth` 是一个映射，包含传递给 kubelet 的身份验证信息。 映射中每个键都是一个匹配镜像字符串（更多内容见下文）。 相应的 `authConfig` 值应该对匹配此键的所有镜像有效。 如果无法为请求的镜像返回有效凭据，则插件应将此字段设置为空。

映射中的每个主键都可以包含端口和路径。 域名中可以使用 Glob 通配，但不能在端口或路径中使用 Glob。 Glob 支持类似 `*.k8s.io` 或 `k8s.*.io` 这类子域以及 `k8s.*` 这类顶级域。 也支持匹配的部分子域，例如 `app*.k8s.io`。 每个 Glob 只能匹配一个子域段，因此 `*.io` 与 `*.k8s.io` 不匹配。

当满足以下所有条件时，kubelet 将根据主键来匹配镜像：

* 两者都包含相同数量的域名部分，并且每个部分都匹配。
* imageMatch 的 URL 路径必须是目标镜像 URL 路径的前缀。
* 如果 `imageMatch` 包含端口，则此端口也必须在镜像中匹配。

当返回多个主键时，kubelet 将以相反的顺序遍历所有主键，以便：

* 较长键出现在具有相同前缀的较短键前面。
* 非通配符键出现在具有相同前缀的通配符键之前。

对于任一给定的匹配项，kubelet 将尝试用提供的凭据拉取镜像，并在第一次成功通过身份验证的拉取之后停止。

示例键：

* 123456789.dkr.ecr.us-east-1.amazonaws.com
* \*.azurecr.io
* gcr.io
* \*.\*.registry.io
* registry.io:8080/path | `AuthConfig`[](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-AuthConfig) ----------------------------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [CredentialProviderResponse](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-CredentialProviderResponse) `AuthConfig` 包含针对容器镜像仓库的身份验证信息。 目前仅支持基于用户名/密码的身份验证，但未来可能添加更多的身份验证机制。 | 字段 | 描述 | | --- | --- | | `username` **\[必需\]**
`string` | `username` 是对容器镜像仓库身份验证所用的用户名。 空白用户名是有效的。 | | `password` **\[必需\]**
`string` | `password` 是对容器镜像仓库身份验证所用的密码。 空白密码是有效的。 | `PluginCacheKeyType`[](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-PluginCacheKeyType) --------------------------------------------------------------------------------------------------------------------------------------------------------------------- （`string` 的别名） **出现在：** * [CredentialProviderResponse](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#credentialprovider-kubelet-k8s-io-v1-CredentialProviderResponse) 反馈[](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/#feedback) ---------------------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1/) . 最后修改 October 19, 2025 at 5:16 PM PST: [\[zh-cn\]sync kubelet-credentialprovider.v1.md (b75b59f525)](https://github.com/kubernetes/website/commit/b75b59f525b5572a804acc86865068367e855dd0) --- # Установка дополнений | Kubernetes **Информация этой страницы может быть устаревшей** Оригинальная (английская) версия этого документа обновлялась с момента последнего перевода, поэтому информация может быть устаревшей. Если вы читаете на английском, посмотрите на оригинальную версию с наиболее актуальной информацией: [Installing Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) Установка дополнений ==================== **Примечание:** Этот раздел ссылается на сторонние проекты, реализующие функциональность, которая требуется Kubernetes. Авторы Kubernetes не несут ответственность за проекты, представленные здесь в алфавитном порядке. Чтобы добавить проект к этому списку, ознакомьтесь с [руководством по контенту](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) перед публикацией изменений. [Подробнее](https://kubernetes.io/ru/docs/concepts/cluster-administration/addons/#third-party-content-disclaimer) . Надстройки расширяют функциональность Kubernetes. На этой странице перечислены некоторые из доступных надстроек и ссылки на соответствующие инструкции по установке. Сеть и сетевая политика[](https://kubernetes.io/ru/docs/concepts/cluster-administration/addons/#%D1%81%D0%B5%D1%82%D1%8C-%D0%B8-%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F-%D0%BF%D0%BE%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * [ACI](https://www.github.com/noironetworks/aci-containers) обеспечивает интегрированную сеть контейнеров и сетевую безопасность с помощью Cisco ACI. * [Antrea](https://antrea.io/) работает на уровне 3, обеспечивая сетевые службы и службы безопасности для Kubernetes, используя Open vSwitch в качестве уровня сетевых данных. * [Calico](https://docs.projectcalico.org/latest/introduction/) Calico поддерживает гибкий набор сетевых опций, поэтому вы можете выбрать наиболее эффективный вариант для вашей ситуации, включая сети без оверлея и оверлейные сети, с или без BGP. Calico использует тот же механизм для обеспечения соблюдения сетевой политики для хостов, модулей и (при использовании Istio и Envoy) приложений на уровне сервисной сети (mesh layer). * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) объединяет Flannel и Calico, обеспечивая сеть и сетевую политику. * [Cilium](https://github.com/cilium/cilium) - это плагин сети L3 и сетевой политики, который может прозрачно применять политики HTTP/API/L7. Поддерживаются как режим маршрутизации, так и режим наложения/инкапсуляции, и он может работать поверх других подключаемых модулей CNI. * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) позволяет Kubernetes легко подключаться к выбору плагинов CNI, таких как Calico, Canal, Flannel, Romana или Weave. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) , основан на [Tungsten Fabric](https://tungsten.io/) , представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric интегрированы с системами оркестрации, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/подов и рабочих нагрузок без операционной системы. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) - это поставщик оверлейной сети, который можно использовать с Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes подов. * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) - это плагин Multi для работы с несколькими сетями в Kubernetes, который поддерживает большинство самых популярных [CNI](https://github.com/containernetworking/cni) (например: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/) , реализация виртуальной сети, появившийся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложенных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) плагин для контейнера (NCP) обеспечивающий интеграцию между VMware NSX-T и контейнерами оркестраторов, таких как Kubernetes, а так же интеграцию между NSX-T и контейнеров на основе платформы CaaS/PaaS, таких как Pivotal Container Service (PKS) и OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes подами и не Kubernetes окружением, с отображением и мониторингом безопасности. * [Romana](https://github.com/romana/romana) - это сетевое решение уровня 3 для сетей подов, которое также поддерживает [NetworkPolicy API](https://kubernetes.io/docs/concepts/services-networking/network-policies/) . Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize) . * [Weave Net](https://github.com/rajch/weave#using-weave-on-kubernetes) предоставляет сеть и обеспечивает сетевую политику, будет работать на обеих сторонах сетевого раздела и не требует внешней базы данных. Обнаружение служб[](https://kubernetes.io/ru/docs/concepts/cluster-administration/addons/#%D0%BE%D0%B1%D0%BD%D0%B0%D1%80%D1%83%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%BB%D1%83%D0%B6%D0%B1) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * [CoreDNS](https://coredns.io/) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/helm) в качестве внутрикластерного DNS для подов. Визуализация и контроль[](https://kubernetes.io/ru/docs/concepts/cluster-administration/addons/#%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D0%B8-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8C) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) - это веб-интерфейс панели инструментов для Kubernetes. Инфраструктура[](https://kubernetes.io/ru/docs/concepts/cluster-administration/addons/#%D0%B8%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) - это дополнение для запуска виртуальных машин в Kubernetes. Обычно работает на bare-metal кластерах. Legacy Add-ons[](https://kubernetes.io/ru/docs/concepts/cluster-administration/addons/#legacy-add-ons) ------------------------------------------------------------------------------------------------------- В устаревшем каталоге [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) задокументировано несколько других дополнений. Ссылки на те, в хорошем состоянии, должны быть здесь. Пул реквесты приветствуются! Обратная связь[](https://kubernetes.io/ru/docs/concepts/cluster-administration/addons/#feedback) ------------------------------------------------------------------------------------------------- Эта страница была полезна? Да Нет Спасибо за обратную связь! Если у вас есть конкретный вопрос об использовании Kubernetes, спросите на [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Создайте issue в репозитории GitHub, если вы хотите [сообщить о проблеме](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/ru/docs/concepts/cluster-administration/addons/) или [предложить улучшение](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/ru/docs/concepts/cluster-administration/addons/) . Изменено February 10, 2025 at 12:44 AM PST: [\[ru\] Fixed link for core dns helm charts (2d79a6d47b)](https://github.com/kubernetes/website/commit/2d79a6d47be3b1e5b6affe3f6cf286a55ac3a51e) Объекты этой страницы ссылаются на сторонние продукты или проекты, реализующие функциональность, которая требуется Kubernetes. Авторы Kubernetes не несут ответственность за эти сторонние продукты или проекты. Подробнее читайте в [инструкциях по сайту CNCF](https://github.com/cncf/foundation/blob/master/website-guidelines.md) . Перед тем, как предлагать изменения, которые добавят новую стороннюю ссылку, необходимо прочитать [руководство по контенту](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) . --- # Kubernetes Secret 良好实践 | Kubernetes Kubernetes Secret 良好实践 ====================== 帮助集群管理员和应用开发者更好管理 Secret 的原理和实践。 在 Kubernetes 中，Secret 是这样一个对象： secret 用于存储敏感信息，如密码、OAuth 令牌和 SSH 密钥。 Secret 允许用户对如何使用敏感信息进行更多的控制，并减少信息意外暴露的风险。 默认情况下，Secret 值被编码为 base64 字符串并以非加密的形式存储，但可以配置为 [静态加密（Encrypt at rest）](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) 。 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/) 可以通过多种方式引用 Secret， 例如在卷挂载中引用或作为环境变量引用。Secret 设计用于机密数据，而 [ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 设计用于非机密数据。 以下良好实践适用于集群管理员和应用开发者。遵从这些指导方针有助于提高 Secret 对象中敏感信息的安全性，还可以更有效地管理你的 Secret。 集群管理员[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#cluster-administrators) ----------------------------------------------------------------------------------------------------------- 本节提供了集群管理员可用于提高集群中机密信息安全性的良好实践。 ### 配置静态加密[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#configure-encryption-at-rest) 默认情况下，Secret 对象以非加密的形式存储在 [etcd](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/) 中。 你配置对在 `etcd` 中存储的 Secret 数据进行加密。相关的指导信息， 请参阅[静态加密 Secret 数据](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/encrypt-data/) 。 ### 配置 Secret 资源的最小特权访问[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#least-privilege-secrets) 当规划诸如 Kubernetes [基于角色的访问控制](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/) [(RBAC)](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/) 这类访问控制机制时，需要注意访问 `Secret` 对象的以下指导信息。 你还应遵从 [RBAC 良好实践](https://kubernetes.io/zh-cn/docs/concepts/security/rbac-good-practices) 中的其他指导信息。 * **组件**：限制仅最高特权的系统级组件可以执行 `watch` 或 `list` 访问。 仅在组件的正常行为需要时才授予对 Secret 的 `get` 访问权限。 * **人员**：限制对 Secret 的 `get`、`watch` 或 `list` 访问权限。仅允许集群管理员访问 `etcd`。 这包括只读访问。对于更复杂的访问控制，例如使用特定注解限制对 Secret 的访问，请考虑使用第三方鉴权机制。 #### 注意： 授予对 Secret 的 `list` 访问权限将意味着允许对应主体获取 Secret 的内容。 如果一个用户可以创建使用某 Secret 的 Pod，则该用户也可以看到该 Secret 的值。 即使集群策略不允许用户直接读取 Secret，同一用户也可能有权限运行 Pod 进而暴露该 Secret。 你可以检测或限制具有此访问权限的用户有意或无意地暴露 Secret 数据所造成的影响。 这里有一些建议： * 使用生命期短暂的 Secret * 实现对特定事件发出警报的审计规则，例如同一用户并发读取多个 Secret 时发出警报 #### 限制 Secret 的访问[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#%E9%99%90%E5%88%B6-secret-%E7%9A%84%E8%AE%BF%E9%97%AE) 使用单独的命名空间来隔离对挂载 Secret 的访问。 ### 改进 etcd 管理策略[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#improve-etcd-management-policies) 不再使用 `etcd` 所使用的持久存储时，考虑擦除或粉碎这些数据。 如果存在多个 `etcd` 实例，则在实例之间配置加密的 SSL/TLS 通信以保护传输中的 Secret 数据。 ### 配置对外部 Secret 的访问权限[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#configure-access-to-external-secrets) **说明：** 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) ，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读[内容指南](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) 。 你可以使用第三方 Secret 存储提供商将机密数据保存在你的集群之外，然后配置 Pod 访问该信息。 [Kubernetes Secret 存储 CSI 驱动](https://secrets-store-csi-driver.sigs.k8s.io/) 是一个 DaemonSet， 它允许 kubelet 从外部存储中检索 Secret，并将 Secret 作为卷挂载到特定的、你授权访问数据的 Pod。 有关支持的提供商列表，请参阅 [Secret 存储 CSI 驱动的提供商](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver) 。 使用交换内存的良好实践[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#good-practices-for-using-swap-memory) ------------------------------------------------------------------------------------------------------------------------------- 对于为 Linux 节点设置交换内存的最佳实践， 请参阅[交换内存管理](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/swap-memory-management/#good-practice-for-using-swap-in-a-kubernetes-cluster) 。 开发者[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#developers) --------------------------------------------------------------------------------------------- 本节为开发者提供了构建和部署 Kubernetes 资源时用于改进机密数据安全性的良好实践。 ### 限制特定容器集合才能访问 Secret[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#restrict-secret-access-to-specific-containers) 如果你在一个 Pod 中定义了多个容器，且仅其中一个容器需要访问 Secret，则可以定义卷挂载或环境变量配置， 这样其他容器就不会有访问该 Secret 的权限。 ### 读取后保护 Secret 数据[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#protect-secret-data-after-reading) 应用程序从一个环境变量或一个卷读取机密信息的值后仍然需要保护这些值。 例如，你的应用程序必须避免以明文记录 Secret 数据，还必须避免将这些数据传输给不受信任的一方。 ### 避免共享 Secret 清单[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#avoid-shareing-secret-manifests) 如果你通过[清单（Manifest）](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-manifest) 配置 Secret， 同时将该 Secret 数据编码为 base64， 那么共享此文件或将其检入一个源代码仓库就意味着有权读取该清单的所有人都能使用该 Secret。 #### 注意： Base64 编码**不是**一种加密方法，它没有为纯文本提供额外的保密机制。 反馈[](https://kubernetes.io/zh-cn/docs/concepts/security/secrets-good-practices/#feedback) ------------------------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/security/secrets-good-practices/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/security/secrets-good-practices/) . 最后修改 July 15, 2025 at 1:45 PM PST: [\[zh-cn\]sync linux-security secrets-good-practices (60feda2f4c)](https://github.com/kubernetes/website/commit/60feda2f4cd03754c7d855a714626115ec12f49b) 本页面中的条目引用了第三方产品或项目，这些产品（项目）提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品（项目）负责。请参阅[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) 了解更多细节。 在提交更改建议，向本页添加新的第三方链接之前，你应该先阅读[内容指南。](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) --- # CSI 卷克隆 | Kubernetes CSI 卷克隆 ======= 本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉 [卷](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes) 。 介绍[](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-pvc-datasource/#%E4%BB%8B%E7%BB%8D) -------------------------------------------------------------------------------------------------- [CSI](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi) 卷克隆功能增加了通过在 `dataSource` 字段中指定存在的 [PVC](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) ， 来表示用户想要克隆的 [卷（Volume）](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/) 。 克隆（Clone），意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。 唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。 从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时， 增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound 状态且可用的（不在使用中）。 用户在使用该功能时，需要注意以下事项： * 克隆支持（`VolumePVCDataSource`）仅适用于 CSI 驱动。 * 克隆支持仅适用于 动态供应器。 * CSI 驱动可能实现，也可能未实现卷克隆功能。 * 仅当 PVC 与目标 PVC 存在于同一命名空间（源和目标 PVC 必须在相同的命名空间）时，才可以克隆 PVC。 * 支持用一个不同存储类进行克隆。 * 目标卷和源卷可以是相同的存储类，也可以不同。 * 可以使用默认的存储类，也可以在 spec 中省略 storageClassName 字段。 * 克隆只能在两个使用相同 VolumeMode 设置的卷中进行 （如果请求克隆一个块存储模式的卷，源卷必须也是块存储模式）。 制备[](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-pvc-datasource/#%E5%88%B6%E5%A4%87) -------------------------------------------------------------------------------------------------- 克隆卷与其他任何 PVC 一样配置，除了需要增加 dataSource 来引用同一命名空间中现有的 PVC。 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: clone-of-pvc-1 namespace: myns spec: accessModes: - ReadWriteOnce storageClassName: cloning resources: requests: storage: 5Gi dataSource: kind: PersistentVolumeClaim name: pvc-1 #### 说明： 你必须为 `spec.resources.requests.storage` 指定一个值，并且你指定的值必须大于或等于源卷的值。 结果是一个名称为 `clone-of-pvc-1` 的新 PVC 与指定的源 `pvc-1` 拥有相同的内容。 使用[](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-pvc-datasource/#%E4%BD%BF%E7%94%A8) -------------------------------------------------------------------------------------------------- 一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。 可以预期的是，新创建的 PVC 是一个独立的对象。 可以独立使用、克隆、快照或删除它，而不需要考虑它的原始数据源 PVC。 这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。 反馈[](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-pvc-datasource/#feedback) ---------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/storage/volume-pvc-datasource/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/storage/volume-pvc-datasource/) . 最后修改 June 04, 2023 at 1:38 PM PST: [sync volume-pvc-datasource volume-snapshot-classes topology-spread-constraints security-checklist (279a835a9c)](https://github.com/kubernetes/website/commit/279a835a9c6a449b3b7a3ee860b04f81a36de866) --- # 外部 API | Kubernetes 外部 API ====== * * * ##### [Kubernetes 外部指标 (v1beta1)](https://kubernetes.io/zh-cn/docs/reference/external-api/external-metrics.v1beta1/) ##### [Kubernetes 指标 (v1beta1)](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/) ##### [Kubernetes 自定义指标 (v1beta2)](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/) 反馈[](https://kubernetes.io/zh-cn/docs/reference/external-api/#feedback) ------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/external-api/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/external-api/) . 最后修改 September 19, 2023 at 8:14 PM PST: [\[zh\] Sync /reference/external-api/ (31feb6a41c)](https://github.com/kubernetes/website/commit/31feb6a41c4b92532a2f6e17e424e417c851d4cb) --- # Storage | Kubernetes Storage ======= * * * ##### [Volume](https://kubernetes.io/id/docs/concepts/storage/volumes/) ##### [Persistent Volume](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/) ##### [VolumeSnapshot](https://kubernetes.io/id/docs/concepts/storage/volume-snapshots/) ##### [Pengklonaan Volume CSI](https://kubernetes.io/id/docs/concepts/storage/volume-pvc-datasource/) ##### [StorageClass](https://kubernetes.io/id/docs/concepts/storage/storage-classes/) ##### [VolumeSnapshotClass](https://kubernetes.io/id/docs/concepts/storage/volume-snapshot-classes/) ##### [Penyediaan Volume Dinamis](https://kubernetes.io/id/docs/concepts/storage/dynamic-provisioning/) ##### [Limit Volume yang Spesifik terhadap Node](https://kubernetes.io/id/docs/concepts/storage/storage-limits/) Masukan[](https://kubernetes.io/id/docs/concepts/storage/#feedback) -------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/concepts/storage/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/concepts/storage/) . Last modified June 22, 2021 at 6:19 PM PST: [\[id\] Remove exec permission on markdown files (4bcb8545e8)](https://github.com/kubernetes/website/commit/4bcb8545e8f64b8dbc032cb4059dcc7d66dabff3) --- # Linux 节点的交换（Swap）行为 | Kubernetes Linux 节点的交换（Swap）行为 =================== 要允许 Kubernetes 工作负载在 Linux 节点上使用交换分区， 你必须禁用 kubelet 在检测到交换分区时失败的默认行为， 并指定内存交换行为为 `LimitedSwap`： 可用的交换行为选项有： `NoSwap` （默认）在此节点上作为 Pod 运行的工作负载不会也不能使用交换分区。 然而，系统守护进程（包括 kubelet 本身！）等这类 Kubernetes 范围之外的进程**可以**利用交换分区。 这种行为有助于保护节点免受系统级别的内存峰值影响， 但这不能保护工作负载本身不受此类峰值的影响。 `LimitedSwap` Kubernetes 工作负载可以使用交换内存，Pod 可用的交换量是自动确定的。 要了解更多，请阅读[交换内存管理](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/swap-memory-management/) 。 反馈[](https://kubernetes.io/zh-cn/docs/reference/node/swap-behavior/#feedback) ------------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/node/swap-behavior/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/node/swap-behavior/) . 最后修改 November 25, 2025 at 9:32 PM PST: [\[zh-cn\]sync kubectl/\_index node/\_index swap-behavior (41b223ea07)](https://github.com/kubernetes/website/commit/41b223ea07bcb2ef846522edc54230e67c291c8f) --- # 由 kubelet 填充的节点标签 | Kubernetes 由 kubelet 填充的节点标签 ================= Kubernetes [节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 预先填充了一组标准 [标签](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/) 。 你还可以通过 kubelet 配置或使用 Kubernetes API 在节点上设置自己的标签。 预设标签[](https://kubernetes.io/zh-cn/docs/reference/node/node-labels/#preset-labels) ----------------------------------------------------------------------------------- Kubernetes 在节点上设置的预设标签有： * [`kubernetes.io/arch`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#kubernetes-io-arch) * [`kubernetes.io/hostname`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#kubernetesiohostname) * [`kubernetes.io/os`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#kubernetes-io-os) * [`node.kubernetes.io/instance-type`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#nodekubernetesioinstance-type) （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签） * [`topology.kubernetes.io/region`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesioregion) （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签） * [`topology.kubernetes.io/zone`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesiozone) （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签） #### 说明： 这些标签的值是特定于云提供商的，并且不保证其可靠性。 例如，`kubernetes.io/hostname` 的值在某些环境中可能与节点名称相同， 而在其他环境中可能与节点名称不同。 接下来[](https://kubernetes.io/zh-cn/docs/reference/node/node-labels/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) ------------------------------------------------------------------------------------------------ * 有关常见标签的列表，请参阅[众所周知的标签、注释和污点](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/) 。 * 了解如何[向节点添加标签](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node) 。 反馈[](https://kubernetes.io/zh-cn/docs/reference/node/node-labels/#feedback) ---------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/node/node-labels/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/node/node-labels/) . 最后修改 April 05, 2025 at 10:43 PM PST: [\[zh-cn\]sync node-labels.md (d8f49b1ece)](https://github.com/kubernetes/website/commit/d8f49b1ecedd1e9c2b999389ee6f431fa74a0ef6) --- # Ikhtisar | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Overview](https://kubernetes.io/docs/concepts/overview/) Ikhtisar ======== * * * ##### [Apa itu Kubernetes?](https://kubernetes.io/id/docs/concepts/overview/what-is-kubernetes/) Kubernetes merupakan _platform open-source_ yang digunakan untuk melakukan manajemen _workloads_ aplikasi yang dikontainerisasi, serta menyediakan konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada di dalam ekosistem yang besar dan berkembang cepat. _Service_, _support_, dan perkakas Kubernetes tersedia secara meluas. Kubernetes merupakan _platform open-source_ yang digunakan untuk melakukan manajemen _workloads_ aplikasi yang dikontainerisasi, serta menyediakan konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada di dalam ekosistem yang besar dan berkembang cepat. _Service_, _support_, dan perkakas Kubernetes tersedia secara meluas. ##### [Komponen-Komponen Kubernetes](https://kubernetes.io/id/docs/concepts/overview/components/) Sebuah klaster Kubernetes terdiri dari komponen yang merepresentasikan bidang kontrol dan sepasang mesin yaitu _nodes_. ##### [API Kubernetes](https://kubernetes.io/id/docs/concepts/overview/kubernetes-api/) API Kubernetes membuatmu dapat melakukan _query_ dan memanipulasi keadaan objek dalam Kubernetes. Inti dari bidang kontrol Kubernetes adalah _server_ API dan HTTP API yang diekspos. Pengguna, berbagai bagian klastermu, dan komponen eksternal semuanya berkomunikasi satu sama lain melalui server API. ##### [Menggunakan Objek-Objek Kubernetes](https://kubernetes.io/id/docs/concepts/overview/working-with-objects/) Objek-objek Kubernetes adalah entitas yang tetap dalam sistem Kubernetes. Kubernetes menggunakan entitas tersebut untuk merepresentasikan keadaan dari klastermu. Pelajari tentang objek model Kubernetes dan bagaimana menggunakan objek tersebut. Masukan[](https://kubernetes.io/id/docs/concepts/overview/#feedback) --------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/concepts/overview/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/concepts/overview/) . Last modified April 21, 2019 at 6:41 PM PST: [Add Kubernetes Components in lang ID. (#13888) (f1a8462407)](https://github.com/kubernetes/website/commit/f1a8462407b25aeb35f9c079f20032fb76ef8078) --- # Memberlakukan Standar Keamanan Pod | Kubernetes Memberlakukan Standar Keamanan Pod ================================== Laman ini memberikan sebuah gambaran umum tentang cara memberlakukan [Standar Keamanan Pod](https://kubernetes.io/docs/concepts/security/pod-security-standards) . Menggunakan Kontroler _Pod Security Admission_ Bawaan[](https://kubernetes.io/id/docs/setup/best-practices/enforcing-pod-security-standards/#menggunakan-kontroler-pod-security-admission-bawaan) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- FEATURE STATE: `Kubernetes v1.25 [stable]` [Kontroler _Pod Security Admission_](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podsecurity) bermaksud untuk menggantikan _PodSecurityPolicies_ yang sudah tidak berlaku lagi (_deprecated_). ### Mengkonfigurasi semua Namespace di klaster[](https://kubernetes.io/id/docs/setup/best-practices/enforcing-pod-security-standards/#mengkonfigurasi-semua-namespace-di-klaster) Namespace yang tidak memiliki konfigurasi apapun sebaiknya dianggap sebagai _gap_ dalam model keamanan klaster kamu. Kami menyarankan agar mengambil waktu untuk menganalisis jenis-jenis beban kerja yang terjadi di setiap Namespace, dan dengan merujuk pada Standar Keamanan Pod, lalu tentukan tingkat yang sesuai pada setiap Namespace. Namespace yang tidak berlabel sebaiknya hanya menunjukkan bahwa Namespace tersebut belum dievaluasi. Dalam skenario dimana semua beban kerja di semua Namespace memiliki persyaratan keamanan yang sama, Kami menyediakan sebuah [contoh](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) yang mengilustrasikan bagaimana label _PodSecurity_ dapat diterapkan secara massal. ### Mengikuti prinsip hak istimewa paling sedikit[](https://kubernetes.io/id/docs/setup/best-practices/enforcing-pod-security-standards/#mengikuti-prinsip-hak-istimewa-paling-sedikit) Di dunia yang ideal, semua pod di semua Namespace akan memenuhi persyaratan dari kebijakan `terbatas` . Namun, hal ini tidak mungkin dan tidak praktis, karena beberapa beban kerja akan memerlukan hak istimewa lebih untuk alasan yang sah. * Namespace memperbolehkan beban kerja yang `memiliki hak istimewa` sebaiknya mendirikan dan memberlakukan kontrol akses yang sesuai. * Untuk beban kerja yang berjalan di Namespace permisif, jagalah keunikan persyaratan keamanan dokumentasi tersebut. Jika memungkinkan, pertimbangkan bagaimana persyaratan tersebut dapat dibatasi lebih lanjut. ### Mengadopsi strategi multi mode[](https://kubernetes.io/id/docs/setup/best-practices/enforcing-pod-security-standards/#mengadopsi-strategi-multi-mode) Mode `audit` dan `warn` pada kontroler _Pod Security Admission_ memudahkan pengumpulan wawasan keamanan penting tentang pod tanpa mengganggu beban kerja yang sudah ada. Merupakan praktik yang baik untuk mengaktifkan mode-mode ini untuk semua Namespace, dan mengaturnya ke tingkat yang _diinginkan_ dan versi yang akan kamu `enforce`. Notasi peringatan dan audit yang dihasilkan di fase ini bisa memandu kamu menuju keadaan yang diinginkan. Jika kamu mengharapkan pembuat beban kerja akan membuat perubahan untuk memenuhi tingkat yang diinginkan, maka aktifkan mode `warn`. Jika kamu berharap akan menggunakan log audit untuk memantau/mendorong perubahan untuk memenuhi tingkat yang diinginkan, maka aktifkan mode `audit`. Ketika kamu memiliki mode `enforce` dipasang ke tingkat yang kamu inginkan, mode-mode ini masih dapat berguna dalam beberapa cara berbeda: * Dengan menetapkan `warn` ke tingkat yang sama dengan `enforce`, maka klien akan menerima peringatan ketika mencoba membuat Pod-pod (atau sumber daya yang memiliki template Pod) yang tidak memenuhi validasi. Hal ini akan membantu mereka memperbarui sumber daya tersebut untuk menjadi patuh. * Dalam Namespace yang menyematkan `enforce` ke spesifik versi yang tidak terbaru, menetapkan mode `audit` dan `warn` ke tingkat yang sama dengan `enforce`, tetapi ke versi `terakhir` akan memberikan visibilitas tentang pengaturan yang diperbolehkan oleh versi-versi sebelumnya namun tidak diperbolehkan per praktik terbaik saat ini. Alternatif Pihak Ketiga[](https://kubernetes.io/id/docs/setup/best-practices/enforcing-pod-security-standards/#alternatif-pihak-ketiga) ---------------------------------------------------------------------------------------------------------------------------------------- **Catatan:** Bagian ini tertaut ke proyek-proyek pihak ketiga yang menyediakan fungsionalitas yang dibutuhkan oleh Kubernetes. Pencipta proyek Kubernetes tidak bertanggung jawab atas proyek-proyek tersebut. Laman ini mengikuti [pedoman website CNCF](https://github.com/cncf/foundation/blob/master/website-guidelines.md) dengan membuat daftar proyek menurut abjad. Untuk menambakan proyek ke dalam daftar ini, bacalah [panduan](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) sebelum mengirimkan perubahan. Alternatif pihak ketiga untuk memberlakukan profil keamanan yang dibuat di ekosistem Kubernetes: * [Kubewarden](https://github.com/kubewarden) . * [Kyverno](https://kyverno.io/policies/) . * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) . Keputusan untuk menggunakan solusi bawaan (misalnya Kontroler _PodSecurity Admission_ ) dengan alat pihak ketiga sepenuhnya bergantung pada situasimu. Ketika mengevaluasi solusi apapun, kepercayaanmu terhadap rantai pasokmu adalah yang terpenting. Pada akhirnya, menggunakan _salah satu_ dari pendekatan yang disebutkan akan lebih baik dari tidak menggunakan apapun. Masukan[](https://kubernetes.io/id/docs/setup/best-practices/enforcing-pod-security-standards/#feedback) --------------------------------------------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/setup/best-practices/enforcing-pod-security-standards/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/setup/best-practices/enforcing-pod-security-standards/) . Last modified June 03, 2025 at 7:20 PM PST: [docs: fix minor letter case (424f165fe2)](https://github.com/kubernetes/website/commit/424f165fe207c00b981bffd0019a03f1e72bd2ed) Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the [CNCF website guidelines](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) for more details. You should read the [content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) before proposing a change that adds an extra third-party link. --- # 调试集群 | Kubernetes 调试集群 ==== * * * ##### [流控](https://kubernetes.io/zh-cn/docs/reference/debug-cluster/flow-control/) 反馈[](https://kubernetes.io/zh-cn/docs/reference/debug-cluster/#feedback) ------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/debug-cluster/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/debug-cluster/) . 最后修改 September 15, 2023 at 5:20 PM PST: [\[zh\] Sync /reference/debug-cluster/ (0388631398)](https://github.com/kubernetes/website/commit/0388631398d5c5118f7772ee053f762f72001a59) --- # 运行于多可用区环境 | Kubernetes 运行于多可用区环境 ========= 本页描述如何跨多个区（Zone）运行集群。 背景[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#background) --------------------------------------------------------------------------------------- Kubernetes 从设计上允许同一个 Kubernetes 集群跨多个失效区来运行， 通常这些区位于某个称作 **区域（Region）** 逻辑分组中。 主要的云提供商都将区域定义为一组失效区的集合（也称作 **可用区（Availability Zones**））， 能够提供一组一致的功能特性：每个区域内，各个可用区提供相同的 API 和服务。 典型的云体系结构都会尝试降低某个区中的失效影响到其他区中服务的概率。 控制面行为[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#control-plane-behavior) ------------------------------------------------------------------------------------------------------ 所有的[控制面组件](https://kubernetes.io/zh-cn/docs/concepts/architecture/#control-plane-components) 都支持以一组可相互替换的资源池的形式来运行，每个组件都有多个副本。 当你部署集群控制面时，应将控制面组件的副本跨多个失效区来部署。 如果可用性是一个很重要的指标，应该选择至少三个失效区， 并将每个控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本， 跨至少三个失效区来部署。如果你在运行云控制器管理器， 则也应该将该组件跨所选的三个失效区来部署。 #### 说明： Kubernetes 并不会为 API 服务器端点提供跨失效区的弹性。 你可以为集群 API 服务器使用多种技术来提升其可用性，包括使用 DNS 轮转、SRV 记录或者带健康检查的第三方负载均衡解决方案等等。 节点行为[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#node-behavior) -------------------------------------------------------------------------------------------- Kubernetes 自动为负载资源（如 [Deployment](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/) 或 [StatefulSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/) ） 跨集群中不同节点来部署其 Pod。 这种分布逻辑有助于降低失效带来的影响。 节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node 对象添加[标签](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/) 。 这些标签可能包含[区信息](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesiozone) 。 如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合 [Pod 拓扑分布约束](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/) 来控制如何在你的集群中多个失效域之间分布 Pod。这里的失效域可以是地理区域、可用区甚至是特定节点。 这些提示信息使得[调度器](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) 能够更好地调度 Pod，以实现更好的可用性，降低因为某种失效给整个工作负载带来的风险。 例如，你可以设置一种约束，确保某个 StatefulSet 中的 3 个副本都运行在不同的可用区中， 只要其他条件允许。你可以通过声明的方式来定义这种约束， 而不需要显式指定每个工作负载使用哪些可用区。 ### 跨多个区分布节点[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#distributing-nodes-across-zones) Kubernetes 的核心逻辑并不会帮你创建节点，你需要自行完成此操作，或者使用类似 [Cluster API](https://cluster-api.sigs.k8s.io/) 这类工具来替你管理节点。 使用类似 Cluster API 这类工具，你可以跨多个失效域来定义一组用做你的集群工作节点的机器， 以及当整个区的服务出现中断时如何自动治愈集群的策略。 为 Pod 手动指定区[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#manual-zone-assignment-for-pods) --------------------------------------------------------------------------------------------------------------------- 你可以应用[节点选择算符约束](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) 到你所创建的 Pod 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源中的 Pod 模板设置此类约束。 跨区的存储访问[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#storage-access-for-zones) ---------------------------------------------------------------------------------------------------------- 当创建持久卷时，Kubernetes 会自动向那些链接到特定区的 PersistentVolume 添加区标签。 [调度器](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) 通过其 `NoVolumeZoneConflict` 断言确保申领给定 PersistentVolume 的 Pod 只会被调度到该卷所在的可用区。 请注意，添加区标签的方法可能取决于你的云提供商和存储制备器。 请参阅具体的环境文档，确保配置正确。 请注意，添加区标签的方法可能会根据你所使用的云提供商和存储制备器而有所不同。 为确保配置正确，请始终参阅你的环境的特定文档。 你可以为 PersistentVolumeClaim 指定 [StorageClass](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/) 以设置该类中的存储可以使用的失效域（区）。 要了解如何配置能够感知失效域或区的 StorageClass， 请参阅[可用的拓扑逻辑](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#allowed-topologies) 。 网络[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#networking) --------------------------------------------------------------------------------------- Kubernetes 自身不提供与可用区相关的联网配置。 你可以使用[网络插件](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。 例如，如果你的云提供商支持 `type=LoadBalancer` 的 Service， 则负载均衡器可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。 请查阅云提供商的文档了解详细信息。 对于自定义的或本地集群部署，也可以考虑这些因素。 [Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 和 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/) 的行为， 包括处理不同失效区的方法，在很大程度上取决于你的集群是如何搭建的。 失效恢复[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#fault-recovery) --------------------------------------------------------------------------------------------- 在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何恢复服务。 例如，你是否要求在某个区中至少有一个节点能够运行 Pod？ 请确保任何对集群很关键的修复工作都不要指望集群中至少有一个健康节点。 例如：当所有节点都不健康时，你可能需要运行某个修复性的 Job， 该 Job 要设置特定的[容忍度](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/) ， 以便修复操作能够至少将一个节点恢复为可用状态。 Kubernetes 对这类问题没有现成的解决方案；不过这也是要考虑的因素之一。 接下来[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) --------------------------------------------------------------------------------------------------------- 要了解调度器如何在集群中放置 Pod 并遵从所配置的约束， 可参阅[调度与驱逐](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/) 。 反馈[](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/#feedback) ------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/setup/best-practices/multiple-zones/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/setup/best-practices/multiple-zones/) . 最后修改 September 03, 2024 at 10:15 AM PST: [sync open-a-pr cluster-large multiple-zones (0169c7078b)](https://github.com/kubernetes/website/commit/0169c7078bb169016bea4d13f295368f9c6dd4fc) --- # Официальный CVE-фид | Kubernetes Официальный CVE-фид =================== СТАТУС ФИЧИ: `Kubernetes v1.27 [beta]` Поддерживаемый сообществом список официальных CVE, анонсированных Комитетом по реагированию на проблемы безопасности Kubernetes. Подробности см. на странице [Общие сведения о безопасности Kubernetes и раскрытии информации](https://kubernetes.io/ru/docs/reference/issues-security/security/) . Проект Kubernetes публикует фиды с анонсами проблем в области безопасности в формате [JSON](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) и [RSS](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/feed.xml) , доступные для автоматического считывания. Доступ к ним можно получить, выполнив следующие команды: * [JSON-фид](https://kubernetes.io/ru/docs/reference/issues-security/official-cve-feed/#cve-%d1%84%d0%b8%d0%b4%d1%8b-0) * [RSS-фид](https://kubernetes.io/ru/docs/reference/issues-security/official-cve-feed/#cve-%d1%84%d0%b8%d0%b4%d1%8b-1) [Ссылка на JSON-формат](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json [Ссылка на RSS-формат](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/feed.xml) curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml | | | | | --- | --- | --- |Официальный список Kubernetes CVE (последнее обновление: 20 мар. 2026 12:45:52 UTC) | CVE ID | Описание проблемы | CVE GitHub Issue URL | | --- | --- | --- | | [CVE-2026-4342](https://github.com/kubernetes/kubernetes/issues/137893) | ingress-nginx comment-based nginx configuration injection | [#137893](https://github.com/kubernetes/kubernetes/issues/137893) | | [CVE-2026-3864](https://github.com/kubernetes/kubernetes/issues/137797) | CSI Driver for NFS path traversal via subDir may delete unintended directories on the NFS server | [#137797](https://github.com/kubernetes/kubernetes/issues/137797) | | [CVE-2025-15566](https://github.com/kubernetes/kubernetes/issues/136789) | ingress-nginx auth-proxy-set-headers nginx configuration injection | [#136789](https://github.com/kubernetes/kubernetes/issues/136789) | | [CVE-2026-24514](https://github.com/kubernetes/kubernetes/issues/136680) | ingress-nginx Admission Controller denial of service | [#136680](https://github.com/kubernetes/kubernetes/issues/136680) | | [CVE-2026-24513](https://github.com/kubernetes/kubernetes/issues/136679) | ingress-nginx auth-url protection bypass | [#136679](https://github.com/kubernetes/kubernetes/issues/136679) | | [CVE-2026-24512](https://github.com/kubernetes/kubernetes/issues/136678) | ingress-nginx rules.http.paths.path nginx configuration injection | [#136678](https://github.com/kubernetes/kubernetes/issues/136678) | | [CVE-2026-1580](https://github.com/kubernetes/kubernetes/issues/136677) | ingress-nginx auth-method nginx configuration injection | [#136677](https://github.com/kubernetes/kubernetes/issues/136677) | | [CVE-2025-14269](https://github.com/kubernetes/kubernetes/issues/135798) | Credential caching in Headlamp with Helm enabled | [#135798](https://github.com/kubernetes/kubernetes/issues/135798) | | [CVE-2025-13281](https://github.com/kubernetes/kubernetes/issues/135525) | Portworx Half-Blind SSRF in kube-controller-manager | [#135525](https://github.com/kubernetes/kubernetes/issues/135525) | | [CVE-2025-9708](https://github.com/kubernetes/kubernetes/issues/134063) | Kubernetes C# Client: improper certificate validation in custom CA mode may lead to man-in-the-middle attacks | [#134063](https://github.com/kubernetes/kubernetes/issues/134063) | | [CVE-2025-7445](https://github.com/kubernetes/kubernetes/issues/133897) | secrets-store-sync-controller discloses service account tokens in logs | [#133897](https://github.com/kubernetes/kubernetes/issues/133897) | | [CVE-2025-5187](https://github.com/kubernetes/kubernetes/issues/133471) | Nodes can delete themselves by adding an OwnerReference | [#133471](https://github.com/kubernetes/kubernetes/issues/133471) | | [CVE-2025-7342](https://github.com/kubernetes/kubernetes/issues/133115) | VM images built with Kubernetes Image Builder Nutanix or OVA providers use default credentials for Windows images if user did not override | [#133115](https://github.com/kubernetes/kubernetes/issues/133115) | | [CVE-2025-4563](https://github.com/kubernetes/kubernetes/issues/132151) | Nodes can bypass dynamic resource allocation authorization checks | [#132151](https://github.com/kubernetes/kubernetes/issues/132151) | | [CVE-2025-1974](https://github.com/kubernetes/kubernetes/issues/131009) | ingress-nginx admission controller RCE escalation | [#131009](https://github.com/kubernetes/kubernetes/issues/131009) | | [CVE-2025-1098](https://github.com/kubernetes/kubernetes/issues/131008) | ingress-nginx controller configuration injection via unsanitized mirror annotations | [#131008](https://github.com/kubernetes/kubernetes/issues/131008) | | [CVE-2025-1097](https://github.com/kubernetes/kubernetes/issues/131007) | ingress-nginx controller configuration injection via unsanitized auth-tls-match-cn annotation | [#131007](https://github.com/kubernetes/kubernetes/issues/131007) | | [CVE-2025-24514](https://github.com/kubernetes/kubernetes/issues/131006) | ingress-nginx controller configuration injection via unsanitized auth-url annotation | [#131006](https://github.com/kubernetes/kubernetes/issues/131006) | | [CVE-2025-24513](https://github.com/kubernetes/kubernetes/issues/131005) | ingress-nginx controller auth secret file path traversal vulnerability | [#131005](https://github.com/kubernetes/kubernetes/issues/131005) | | [CVE-2025-1767](https://github.com/kubernetes/kubernetes/issues/130786) | GitRepo Volume Inadvertent Local Repository Access | [#130786](https://github.com/kubernetes/kubernetes/issues/130786) | | [CVE-2025-0426](https://github.com/kubernetes/kubernetes/issues/130016) | Node Denial of Service via kubelet Checkpoint API | [#130016](https://github.com/kubernetes/kubernetes/issues/130016) | | [CVE-2024-9042](https://github.com/kubernetes/kubernetes/issues/129654) | Command Injection affecting Windows nodes via nodes/\*/logs/query API | [#129654](https://github.com/kubernetes/kubernetes/issues/129654) | | [CVE-2024-10220](https://github.com/kubernetes/kubernetes/issues/128885) | Arbitrary command execution through gitRepo volume | [#128885](https://github.com/kubernetes/kubernetes/issues/128885) | | [CVE-2024-9594](https://github.com/kubernetes/kubernetes/issues/128007) | VM images built with Image Builder with some providers use default credentials during builds | [#128007](https://github.com/kubernetes/kubernetes/issues/128007) | | [CVE-2024-9486](https://github.com/kubernetes/kubernetes/issues/128006) | VM images built with Image Builder and Proxmox provider use default credentials | [#128006](https://github.com/kubernetes/kubernetes/issues/128006) | | [CVE-2024-7646](https://github.com/kubernetes/kubernetes/issues/126744) | Ingress-nginx Annotation Validation Bypass | [#126744](https://github.com/kubernetes/kubernetes/issues/126744) | | [CVE-2024-7598](https://github.com/kubernetes/kubernetes/issues/126587) | Network restriction bypass via race condition during namespace termination | [#126587](https://github.com/kubernetes/kubernetes/issues/126587) | | [CVE-2024-5321](https://github.com/kubernetes/kubernetes/issues/126161) | Incorrect permissions on Windows containers logs | [#126161](https://github.com/kubernetes/kubernetes/issues/126161) | | [CVE-2024-3744](https://github.com/kubernetes/kubernetes/issues/124759) | azure-file-csi-driver discloses service account tokens in logs | [#124759](https://github.com/kubernetes/kubernetes/issues/124759) | | [CVE-2024-3177](https://github.com/kubernetes/kubernetes/issues/124336) | Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#124336](https://github.com/kubernetes/kubernetes/issues/124336) | | [CVE-2023-5528](https://github.com/kubernetes/kubernetes/issues/121879) | Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes | [#121879](https://github.com/kubernetes/kubernetes/issues/121879) | | [CVE-2023-5044](https://github.com/kubernetes/kubernetes/issues/126817) | Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation | [#126817](https://github.com/kubernetes/kubernetes/issues/126817) | | [CVE-2023-5043](https://github.com/kubernetes/kubernetes/issues/126816) | Ingress nginx annotation injection causes arbitrary command execution | [#126816](https://github.com/kubernetes/kubernetes/issues/126816) | | [CVE-2022-4886](https://github.com/kubernetes/kubernetes/issues/126815) | ingress-nginx path sanitization can be bypassed | [#126815](https://github.com/kubernetes/kubernetes/issues/126815) | | [CVE-2023-3955](https://github.com/kubernetes/kubernetes/issues/119595) | Insufficient input sanitization on Windows nodes leads to privilege escalation | [#119595](https://github.com/kubernetes/kubernetes/issues/119595) | | [CVE-2023-3893](https://github.com/kubernetes/kubernetes/issues/119594) | Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation | [#119594](https://github.com/kubernetes/kubernetes/issues/119594) | | [CVE-2023-3676](https://github.com/kubernetes/kubernetes/issues/119339) | Insufficient input sanitization on Windows nodes leads to privilege escalation | [#119339](https://github.com/kubernetes/kubernetes/issues/119339) | | [CVE-2023-2431](https://github.com/kubernetes/kubernetes/issues/118690) | Bypass of seccomp profile enforcement | [#118690](https://github.com/kubernetes/kubernetes/issues/118690) | | [CVE-2023-2728](https://github.com/kubernetes/kubernetes/issues/118640) | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#118640](https://github.com/kubernetes/kubernetes/issues/118640) | | [CVE-2023-2727](https://github.com/kubernetes/kubernetes/issues/118640) | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#118640](https://github.com/kubernetes/kubernetes/issues/118640) | | [CVE-2023-2878](https://github.com/kubernetes/kubernetes/issues/118419) | secrets-store-csi-driver discloses service account tokens in logs | [#118419](https://github.com/kubernetes/kubernetes/issues/118419) | | [CVE-2022-3294](https://github.com/kubernetes/kubernetes/issues/113757) | Node address isn't always verified when proxying | [#113757](https://github.com/kubernetes/kubernetes/issues/113757) | | [CVE-2022-3162](https://github.com/kubernetes/kubernetes/issues/113756) | Unauthorized read of Custom Resources | [#113756](https://github.com/kubernetes/kubernetes/issues/113756) | | [CVE-2022-3172](https://github.com/kubernetes/kubernetes/issues/112513) | Aggregated API server can cause clients to be redirected (SSRF) | [#112513](https://github.com/kubernetes/kubernetes/issues/112513) | | [CVE-2021-25749](https://github.com/kubernetes/kubernetes/issues/112192) | \`runAsNonRoot\` logic bypass for Windows containers | [#112192](https://github.com/kubernetes/kubernetes/issues/112192) | | [CVE-2021-25748](https://github.com/kubernetes/kubernetes/issues/126814) | Ingress-nginx \`path\` sanitization can be bypassed with newline character | [#126814](https://github.com/kubernetes/kubernetes/issues/126814) | | [CVE-2021-25746](https://github.com/kubernetes/kubernetes/issues/126813) | Ingress-nginx directive injection via annotations | [#126813](https://github.com/kubernetes/kubernetes/issues/126813) | | [CVE-2021-25745](https://github.com/kubernetes/kubernetes/issues/126812) | Ingress-nginx \`path\` can be pointed to service account token file | [#126812](https://github.com/kubernetes/kubernetes/issues/126812) | | [CVE-2021-25742](https://github.com/kubernetes/kubernetes/issues/126811) | Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces | [#126811](https://github.com/kubernetes/kubernetes/issues/126811) | | [CVE-2021-25741](https://github.com/kubernetes/kubernetes/issues/104980) | Symlink Exchange Can Allow Host Filesystem Access | [#104980](https://github.com/kubernetes/kubernetes/issues/104980) | | [CVE-2020-8561](https://github.com/kubernetes/kubernetes/issues/104720) | Webhook redirect in kube-apiserver | [#104720](https://github.com/kubernetes/kubernetes/issues/104720) | | [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675) | Endpoint & EndpointSlice permissions allow cross-Namespace forwarding | [#103675](https://github.com/kubernetes/kubernetes/issues/103675) | | [CVE-2021-25737](https://github.com/kubernetes/kubernetes/issues/102106) | Holes in EndpointSlice Validation Enable Host Network Hijack | [#102106](https://github.com/kubernetes/kubernetes/issues/102106) | | [CVE-2020-8562](https://github.com/kubernetes/kubernetes/issues/101493) | Bypass of Kubernetes API Server proxy TOCTOU | [#101493](https://github.com/kubernetes/kubernetes/issues/101493) | | [CVE-2021-3121](https://github.com/kubernetes/kubernetes/issues/101435) | Processes may panic upon receipt of malicious protobuf messages | [#101435](https://github.com/kubernetes/kubernetes/issues/101435) | | [CVE-2021-25735](https://github.com/kubernetes/kubernetes/issues/100096) | Validating Admission Webhook does not observe some previous fields | [#100096](https://github.com/kubernetes/kubernetes/issues/100096) | | [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076) | Man in the middle using LoadBalancer or ExternalIPs | [#97076](https://github.com/kubernetes/kubernetes/issues/97076) | | [CVE-2020-8566](https://github.com/kubernetes/kubernetes/issues/95624) | Ceph RBD adminSecrets exposed in logs when loglevel >= 4 | [#95624](https://github.com/kubernetes/kubernetes/issues/95624) | | [CVE-2020-8565](https://github.com/kubernetes/kubernetes/issues/95623) | Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9 | [#95623](https://github.com/kubernetes/kubernetes/issues/95623) | | [CVE-2020-8564](https://github.com/kubernetes/kubernetes/issues/95622) | Docker config secrets leaked when file is malformed and log level >= 4 | [#95622](https://github.com/kubernetes/kubernetes/issues/95622) | | [CVE-2020-8563](https://github.com/kubernetes/kubernetes/issues/95621) | Secret leaks in kube-controller-manager when using vSphere provider | [#95621](https://github.com/kubernetes/kubernetes/issues/95621) | | [CVE-2020-8557](https://github.com/kubernetes/kubernetes/issues/93032) | Node disk DOS by writing to container /etc/hosts | [#93032](https://github.com/kubernetes/kubernetes/issues/93032) | | [CVE-2020-8559](https://github.com/kubernetes/kubernetes/issues/92914) | Privilege escalation from compromised node to cluster | [#92914](https://github.com/kubernetes/kubernetes/issues/92914) | | [CVE-2020-8558](https://github.com/kubernetes/kubernetes/issues/92315) | Node setting allows for neighboring hosts to bypass localhost boundary | [#92315](https://github.com/kubernetes/kubernetes/issues/92315) | | [CVE-2020-8555](https://github.com/kubernetes/kubernetes/issues/91542) | Half-Blind SSRF in kube-controller-manager | [#91542](https://github.com/kubernetes/kubernetes/issues/91542) | | [CVE-2020-10749](https://github.com/kubernetes/kubernetes/issues/91507) | IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements | [#91507](https://github.com/kubernetes/kubernetes/issues/91507) | | [CVE-2019-11254](https://github.com/kubernetes/kubernetes/issues/89535) | kube-apiserver Denial of Service vulnerability from malicious YAML payloads | [#89535](https://github.com/kubernetes/kubernetes/issues/89535) | | [CVE-2020-8552](https://github.com/kubernetes/kubernetes/issues/89378) | apiserver DoS (oom) | [#89378](https://github.com/kubernetes/kubernetes/issues/89378) | | [CVE-2020-8551](https://github.com/kubernetes/kubernetes/issues/89377) | Kubelet DoS via API | [#89377](https://github.com/kubernetes/kubernetes/issues/89377) | | [CVE-2020-8553](https://github.com/kubernetes/kubernetes/issues/126818) | ingress-nginx auth-type basic annotation vulnerability | [#126818](https://github.com/kubernetes/kubernetes/issues/126818) | | [CVE-2019-11251](https://github.com/kubernetes/kubernetes/issues/87773) | kubectl cp symlink vulnerability | [#87773](https://github.com/kubernetes/kubernetes/issues/87773) | | [CVE-2018-1002102](https://github.com/kubernetes/kubernetes/issues/85867) | Unvalidated redirect | [#85867](https://github.com/kubernetes/kubernetes/issues/85867) | | [CVE-2019-11255](https://github.com/kubernetes/kubernetes/issues/85233) | CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation | [#85233](https://github.com/kubernetes/kubernetes/issues/85233) | | [CVE-2019-11253](https://github.com/kubernetes/kubernetes/issues/83253) | Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack | [#83253](https://github.com/kubernetes/kubernetes/issues/83253) | | [CVE-2019-11250](https://github.com/kubernetes/kubernetes/issues/81114) | Bearer tokens are revealed in logs (audit finding TOB-K8S-001) | [#81114](https://github.com/kubernetes/kubernetes/issues/81114) | | [CVE-2019-11248](https://github.com/kubernetes/kubernetes/issues/81023) | /debug/pprof exposed on kubelet's healthz port | [#81023](https://github.com/kubernetes/kubernetes/issues/81023) | | [CVE-2019-11249](https://github.com/kubernetes/kubernetes/issues/80984) | Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal | [#80984](https://github.com/kubernetes/kubernetes/issues/80984) | | [CVE-2019-11247](https://github.com/kubernetes/kubernetes/issues/80983) | API server allows access to custom resources via wrong scope | [#80983](https://github.com/kubernetes/kubernetes/issues/80983) | | [CVE-2019-11245](https://github.com/kubernetes/kubernetes/issues/78308) | container uid changes to root after first restart or if image is already pulled to the node | [#78308](https://github.com/kubernetes/kubernetes/issues/78308) | | [CVE-2019-11243](https://github.com/kubernetes/kubernetes/issues/76797) | rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig() | [#76797](https://github.com/kubernetes/kubernetes/issues/76797) | | [CVE-2019-11244](https://github.com/kubernetes/kubernetes/issues/76676) | \`kubectl --http-cache=\` creates world-writeable cached schema files | [#76676](https://github.com/kubernetes/kubernetes/issues/76676) | | [CVE-2019-1002100](https://github.com/kubernetes/kubernetes/issues/74534) | json-patch requests can exhaust apiserver resources | [#74534](https://github.com/kubernetes/kubernetes/issues/74534) | | [CVE-2018-1002105](https://github.com/kubernetes/kubernetes/issues/71411) | proxy request handling in kube-apiserver can leave vulnerable TCP connections | [#71411](https://github.com/kubernetes/kubernetes/issues/71411) | | [CVE-2018-1002101](https://github.com/kubernetes/kubernetes/issues/65750) | smb mount security issue | [#65750](https://github.com/kubernetes/kubernetes/issues/65750) | | [CVE-2018-1002100](https://github.com/kubernetes/kubernetes/issues/61297) | Kubectl copy doesn't check for paths outside of it's destination directory. | [#61297](https://github.com/kubernetes/kubernetes/issues/61297) | | [CVE-2017-1002102](https://github.com/kubernetes/kubernetes/issues/60814) | atomic writer volume handling allows arbitrary file deletion in host filesystem | [#60814](https://github.com/kubernetes/kubernetes/issues/60814) | | [CVE-2017-1002101](https://github.com/kubernetes/kubernetes/issues/60813) | subpath volume mount handling allows arbitrary file access in host filesystem | [#60813](https://github.com/kubernetes/kubernetes/issues/60813) | | [CVE-2017-1002100](https://github.com/kubernetes/kubernetes/issues/47611) | Azure PV should be Private scope not Container scope | [#47611](https://github.com/kubernetes/kubernetes/issues/47611) | | [CVE-2017-1000056](https://github.com/kubernetes/kubernetes/issues/43459) | PodSecurityPolicy admission plugin authorizes incorrectly | [#43459](https://github.com/kubernetes/kubernetes/issues/43459) | Список автоматически обновляется с заметной, но небольшой задержкой (от нескольких минут до нескольких часов) с момента анонса CVE до момента его появления в этом фиде. В качестве источника используется набор GitHub Issues, отфильтрованный по контролируемому и ограниченному лейблу `official-cve-feed`. Исходные данные хранятся в бакете Google Cloud, право на запись в который есть только у небольшого числа доверенных представителей сообщества. Обратная связь[](https://kubernetes.io/ru/docs/reference/issues-security/official-cve-feed/#feedback) ------------------------------------------------------------------------------------------------------ Эта страница была полезна? Да Нет Спасибо за обратную связь! Если у вас есть конкретный вопрос об использовании Kubernetes, спросите на [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Создайте issue в репозитории GitHub, если вы хотите [сообщить о проблеме](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/ru/docs/reference/issues-security/official-cve-feed/) или [предложить улучшение](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/ru/docs/reference/issues-security/official-cve-feed/) . Изменено March 02, 2024 at 7:20 PM PST: [Fix link to RSS feed (6950760e96)](https://github.com/kubernetes/website/commit/6950760e96a49258345134baf404abb361673421) --- # Utilizando Autorização ABAC | Kubernetes **Este documento pode estar desatualizado** Este documento possui uma data de atualização mais antiga que o documento original. Portanto, este conteúdo pode estar desatualizado. Se você lê inglês, veja a versão em inglês para acessar a versão mais atualizada: [Using ABAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/abac/) Utilizando Autorização ABAC =========================== O controle de acesso baseado em atributos (ABAC) define um paradigma de controle de acesso onde os direitos de acesso são concedidos aos usuários por meio do uso de políticas que combinam atributos. Formato do arquivo de política[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/abac/#formato-do-arquivo-de-pol%C3%ADtica) ------------------------------------------------------------------------------------------------------------------------------------------ Especifique os parametros de inicialização `--authorization-policy-file=NOME_DE_ALGUM_ARQUIVO` e `--authorization-mode=ABAC` para habilitar o modo `ABAC`. O formato do arquivo é de [um objeto JSON por linha](https://jsonlines.org/) . Nele não deve haver lista ou mapa envolvente, apenas um mapa por linha. Cada linha é um "objeto de política", onde cada objeto é um mapa com as seguintes propriedades: * Propriedades de versionamento: * `apiVersion`, tipo string; os valores válidos são "abac.authorization.kubernetes.io/v1beta1". Permite controle de versão e conversão do formato da política. * `kind`, tipo string: os valores válidos são "Policy". Permite controle de versão e conversão do formato da política. * `spec` definida para um mapa com as seguintes propriedades: * Propriedades de correspondência de sujeito: * `user`, tipo string; a string de usuário de `--token-auth-file`. Se você especificar `user`, ele deve corresponder ao nome do usuário autenticado. * `group`, tipo string; se você especificar `group`, ele deve corresponder a um dos grupos do usuário autenticado `system:authenticated` corresponde a todas as requisições autenticadas. `system:unauthenticated` corresponde a todas as requisições não autenticadas. * Propriedades de correspondência de recursos: * `apiGroup`, tipo string; um grupo de API. * Ex: `apps`, `networking.k8s.io` * Curinga: `*` corresponde a todos os grupos de API. * `namespace`, tipo string; um namespace. * Ex: `kube-system` * Curinga: `*` corresponde a todas as requisições de recursos. * `resource`, tipo string; um tipo de recurso * Ex: `pods`, `deployments` * Curinga: `*` corresponde a todas as requisições de recursos. * Propriedades sem correspondência de recursos: * `nonResourcePath`, tipo string; caminhos de solicitação sem recurso. * Ex: `/version` ou `/apis` * Curinga: * `*` corresponde a todas as requisições que não são de recursos. * `/foo/*` corresponde a todos os subcaminhos de `/foo/`. * `readonly`, tipo booleano. Quando verdadeiro, significa que a política de correspondência de recursos se aplica apenas às operações `get`, `list` e `watch`. Em caso de políticas sem correspondência de recursos se aplica apenas à operação `get`. #### Nota: Uma propriedade não definida é igual a uma propriedade definida com o valor zero para seu tipo (por exemplo, string vazia, 0, falso). No entanto, indefinido deve ser preferido para legibilidade. No futuro, as políticas poderão ser expressas no formato JSON e gerenciadas por meio de uma interface REST. Algoritmo de Autorização[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/abac/#algoritmo-de-autoriza%C3%A7%C3%A3o) ----------------------------------------------------------------------------------------------------------------------------------- Uma requisição possui atributos que correspondem às propriedades de um objeto de política. Quando uma requisição é recebida, os atributos são determinados. Atributos desconhecidos são definidos com o valor zero de seu tipo (por exemplo, string vazia, 0, falso). Uma propriedade definida como `"*"` corresponderá a qualquer valor do atributo correspondente. A tupla de atributos é verificada em relação a cada política do arquivo de política. Se pelo menos uma linha corresponder aos atributos da requisição, ela é então autorizada (mas pode falhar em validação posterior). Para permitir que qualquer usuário autenticado faça algo, escreva uma política com a propriedade do grupo definida como `"system:authenticated"`. Para permitir que qualquer usuário não autenticado faça algo, escreva uma política com a propriedade do grupo definida como `"system:unauthenticated"`. Para permitir que um usuário faça qualquer coisa, escreva uma política com as propriedades `apiGroup`, `namespace`, `resource` e `nonResourcePath` definidas como `"*"`. Kubectl[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/abac/#kubectl) --------------------------------------------------------------------------------------- O Kubectl usa os endpoints `/api` e `/apis` do servidor de API para descobrir os tipos de recursos servidos e valida objetos enviados para a API pelas operações criar/atualizar usando informações de esquema localizadas em `/openapi/v2`. Ao utilizar a autorização ABAC, esses recursos especiais devem ser explicitamente expostos por meio da propriedade `nonResourcePath` em uma política (consulte [exemplos](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/abac/#exemplos) abaixo): * `/api`, `/api/*`, `/apis` e `/apis/*` para negociação de versão da API. * `/version` para recuperar a versão do servidor via `kubectl version`. * `/swaggerapi/*` para operações de criação/atualização. Para inspecionar as chamadas HTTP envolvidas em uma operação kubectl específica, você pode aumentar a verbosidade: kubectl --v=8 version Exemplos[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/abac/#exemplos) ----------------------------------------------------------------------------------------- 1. Alice pode fazer qualquer coisa em todos os recursos: {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}} 2. O Kubelet pode ler qualquer Pod: {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}} 3. O Kubelet pode ler e escrever eventos: {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}} 4. Bob pode ler Pods somente pertencentes ao namespace "projectCaribou": {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}} 5. Qualquer pessoa pode realizar requisições somente-leitura em todos os caminhos que não são de recursos: {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}} [Exemplo de arquivo completo](https://releases.k8s.io/v1.35.0/pkg/auth/authorizer/abac/example_policy_file.jsonl) Uma rápida observação sobre contas de serviço[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/abac/#uma-r%C3%A1pida-observa%C3%A7%C3%A3o-sobre-contas-de-servi%C3%A7o) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Cada conta de serviço tem um nome de usuário ABAC correspondente, e o nome de usuário dessa conta de serviço é gerado de acordo com a convenção de nomenclatura: system:serviceaccount:: A criação de um novo namespace leva à criação de uma nova conta de serviço no seguinte formato: system:serviceaccount::default Por exemplo, se você quiser conceder à conta de serviço padrão (no namespace `kube-system`) privilégio total à API usando ABAC, adicione esta linha ao seu arquivo de política: {"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}} O servidor de API precisará ser reiniciado para carregar as novas linhas da política. Comentários[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/abac/#feedback) -------------------------------------------------------------------------------------------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/pt-br/docs/reference/access-authn-authz/abac/) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/pt-br/docs/reference/access-authn-authz/abac/) . Última modificação July 07, 2023 at 10:53 AM PST: [missing review items (4483e86e53)](https://github.com/kubernetes/website/commit/4483e86e533974bc1d791b78909607e84a806a52) --- # kube-apiserver Audit 配置（v1） | Kubernetes kube-apiserver Audit 配置（v1） =========================== 资源类型[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#resource-types) ------------------------------------------------------------------------------------------------- * [Event](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) * [EventList](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-EventList) * [Policy](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) * [PolicyList](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-PolicyList) `Event`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) ----------------------------------------------------------------------------------------------------------- **出现在：** * [EventList](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-EventList) Event 结构包含可出现在 API 审计日志中的所有信息。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `audit.k8s.io/v1` | | `kind`
string | `Event` | | `level` **\[必需\]**
[`Level`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Level) | 生成事件所对应的审计级别。 | | `auditID` **\[必需\]**
[`k8s.io/apimachinery/pkg/types.UID`](https://pkg.go.dev/k8s.io/apimachinery/pkg/types#UID) | 为每个请求所生成的唯一审计 ID。 | | `stage` **\[必需\]**
[`Stage`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Stage) | 生成此事件时请求的处理阶段。 | | `requestURI` **\[必需\]**
`string` | `requestURI` 是客户端发送到服务器端的请求 URI。 | | `verb` **\[必需\]**
`string` | `verb` 是与请求对应的 Kubernetes 动词。对于非资源请求， 此字段为 HTTP 方法的小写形式。 | | `user` **\[必需\]**
[`authentication/v1.UserInfo`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#userinfo-v1-authentication-k8s-io) | 关于认证用户的信息。 | | `impersonatedUser`
[`authentication/v1.UserInfo`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#userinfo-v1-authentication-k8s-io) | 关于所伪装（`impersonatedUser`）的用户的信息。 | | `authenticationMetadata`
[`AuthenticationMetadata`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-AuthenticationMetadata) | `authenticationMetadata` 包含有关请求如何进行身份认证的详细信息。 | | `sourceIPs`
`[]string` | 发起请求和中间代理的源 IP 地址。 源 IP 从以下（按顺序）列出：

1. X-Forwarded-For 请求标头 IP。
2. X-Real-Ip 标头，如果 X-Forwarded-For 列表中不存在。
3. 连接的远程地址，如果它无法与此处列表中的最后一个 IP（X-Forwarded-For 或 X-Real-Ip）匹配。 注意：除最后一个 IP 外的所有 IP 均可由客户端任意设置。 | | `userAgent`
`string` | `userAgent` 中记录客户端所报告的用户代理（User Agent）字符串。 注意 `userAgent` 信息是由客户端提供的，一定不要信任。 | | `objectRef`
[`ObjectReference`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-ObjectReference) | 此请求所指向的对象引用。对于 List 类型的请求或者非资源请求，此字段可忽略。 | | `responseStatus`
[`meta/v1.Status`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#status-v1-meta) | 响应的状态，当 `responseStatus` 不是 Status 类型时被赋值。 对于成功的请求，此字段仅包含 `code` 和 `statusSuccess`。 对于非 Status 类型的错误响应，此字段会被自动赋值为出错信息。 | | `requestObject`
[`k8s.io/apimachinery/pkg/runtime.Unknown`](https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime#Unknown) | 来自请求的 API 对象，以 JSON 格式呈现。`requestObject` 在请求中按原样记录 （可能会采用 JSON 重新编码），之后会进入版本转换、默认值填充、准入控制以及配置信息合并等阶段。 此对象为外部版本化的对象类型，甚至其自身可能并不是一个合法的对象。对于非资源请求，此字段被忽略。 只有当审计级别为 Request 或更高的时候才会记录。 | | `responseObject`
[`k8s.io/apimachinery/pkg/runtime.Unknown`](https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime#Unknown) | 响应中包含的 API 对象，以 JSON 格式呈现。`responseObject` 是在被转换为外部类型并序列化为 JSON 格式之后才被记录的。对于非资源请求，此字段会被忽略。 只有审计级别为 Response 时才会记录。 | | `requestReceivedTimestamp`
[`meta/v1.MicroTime`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#microtime-v1-meta) | 请求到达 API 服务器时的时间。 | | `stageTimestamp`
[`meta/v1.MicroTime`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#microtime-v1-meta) | 请求到达当前审计阶段时的时间。 | | `annotations`
`map[string]string` | `annotations` 是一个无结构的键-值映射，其中保存的是一个审计事件。 该事件可以由请求处理链路上的插件来设置，包括身份认证插件、鉴权插件以及准入控制插件等。 注意这些注解是针对审计事件本身的，与所提交的对象中的 metadata.annotations 之间不存在对应关系。 映射中的键名应该唯一性地标识生成该事件的组件，从而避免名字上的冲突 （例如 `podsecuritypolicy.admission.k8s.io/policy`）。 映射中的键值应该比较简洁。 当审计级别为 Metadata 时会包含 `annotations` 字段。 | `EventList`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-EventList) ------------------------------------------------------------------------------------------------------------------- EventList 是审计事件（Event）的列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `audit.k8s.io/v1` | | `kind`
string | `EventList` | | `metadata`
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#listmeta-v1-meta) | 列表结构元数据 | | `items` **\[必需\]**
[`[]Event`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) | 事件对象列表 | `Policy`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) ------------------------------------------------------------------------------------------------------------- **出现在：** * [PolicyList](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-PolicyList) `Policy` 定义的是审计日志的配置以及不同类型请求的日志记录规则。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `audit.k8s.io/v1` | | `kind`
string | `Policy` | | `metadata`
[`meta/v1.ObjectMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#objectmeta-v1-meta) | 包含 `metadata` 字段是为了便于与 API 基础设施之间实现互操作。

参考 Kubernetes API 文档了解 `metadata` 字段的详细信息。 | | `rules` **\[必需\]**
[`[]PolicyRule`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-PolicyRule) | 字段 `rules` 设置请求要被记录的审计级别（level）。 每个请求可能会与多条规则相匹配；发生这种状况时遵从第一条匹配规则。 默认的审计级别是 None，不过可以在列表的末尾使用一条全抓（catch-all）规则重载其设置。 列表中的规则（PolicyRule）是严格有序的。 | | `omitStages`
[`[]Stage`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Stage) | 字段 `omitStages` 是一个阶段（Stage）列表，其中包含无须生成事件的阶段。 注意这一选项也可以通过每条规则来设置。 审计组件最终会忽略出现在 `omitStages` 中阶段，也会忽略规则中的阶段。 | | `omitManagedFields`
`bool` | `omitManagedFields` 标明将请求和响应主体写入 API 审计日志时，是否省略其托管字段。 此字段值用作全局默认值 - 'true' 值将省略托管字段，否则托管字段将包含在 API 审计日志中。 请注意，也可以按规则指定此值，在这种情况下，规则中指定的值将覆盖全局默认值。 | `PolicyList`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-PolicyList) --------------------------------------------------------------------------------------------------------------------- PolicyList 是由审计策略（Policy）组成的列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `audit.k8s.io/v1` | | `kind`
string | `PolicyList` | | `metadata`
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.34/#listmeta-v1-meta) | 列表结构元数据。 | | `items` **\[必需\]**
[`[]Policy`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) | 策略（Policy）对象列表。 | `AuthenticationMetadata`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-AuthenticationMetadata) --------------------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [Event](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) | Field | 描述 | | --- | --- | | `impersonationConstraint`
`string` | `impersonationConstraint` 是与用于鉴权与此审计事件关联的 `impersonatedUser` 的受限模拟模式相关的动词。 它仅在使用了受限模拟时设置。 | `GroupResources`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-GroupResources) ----------------------------------------------------------------------------------------------------------------------------- **出现在：** * [PolicyRule](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-PolicyRule) `GroupResources` 代表的是某 API 组中的资源类别。 | 字段 | 描述 | | --- | --- | | `group`
`string` | 字段 `group` 给出包含资源的 API 组的名称。 空字符串代表 `core` API 组。 | | `resources`
`[]string` | `resources` 是此规则所适用的资源的列表。

例如：

* `pods` 匹配 Pod。
* `pods/log` 匹配 Pod 的 log 子资源。
* `` * `匹配所有资源及其子资源。` ``
* ``` `` `pods/*` 匹配 Pod 的所有子资源。 `` ```
* ``` `` `*/scale` 匹配所有的 scale 子资源。 `` ```

``` ``如果存在通配符，则合法性检查逻辑会确保 `resources` 中的条目不会彼此重叠。`` ```

`` `空的列表意味着规则适用于该 API 组中的所有资源及其子资源。` `` | | `resourceNames`
`[]string` | 字段 `resourceNames` 是策略将匹配的资源实例名称列表。 使用此字段时，`resources` 必须指定。 空的 `resourceNames` 列表意味着资源的所有实例都会匹配到此策略。 | `Level`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Level) ----------------------------------------------------------------------------------------------------------- `string` 数据类型的别名。 **出现在：** * [Event](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) * [PolicyRule](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-PolicyRule) Level 定义的是审计过程中在日志内记录的信息量。 `ObjectReference`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-ObjectReference) ------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [Event](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) ObjectReference 包含的是用来检查或修改所引用对象时将需要的全部信息。 | 字段 | 描述 | | --- | --- | | `resource`
`string` | 资源类别。 | | `namespace`
`string` | 资源对象所在名字空间。 | | `name`
`string` | 资源对象名称。 | | `uid`
[`k8s.io/apimachinery/pkg/types.UID`](https://pkg.go.dev/k8s.io/apimachinery/pkg/types#UID) | 资源对象的唯一标识（UID）。 | | `apiGroup`
`string` | 字段 `apiGroup` 给出包含所引用对象的 API 组的名称。 空字符串代表 `core` API 组。 | | `apiVersion`
`string` | 字段 `apiVersion` 是包含所引用对象的 API 组的版本。 | | `resourceVersion`
`string` | 资源对象自身的版本值。 | | `subresource`
`string` | 子资源的类别。 | `PolicyRule`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-PolicyRule) --------------------------------------------------------------------------------------------------------------------- **出现在：** * [Policy](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) `PolicyRule` 包含一个映射，基于元数据将请求映射到某审计级别。 请求必须与每个字段所定义的规则都匹配（即 `rules` 的交集）才被视为匹配。 | 字段 | 描述 | | --- | --- | | `level` **\[必需\]**
[`Level`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Level) | 与此规则匹配的请求所对应的日志记录级别（Level）。 | | `users`
`[]string` | 根据身份认证所确定的用户名的列表，给出此规则所适用的用户。 空列表意味着适用于所有用户。 | | `userGroups`
`[]string` | 此规则所适用的用户组的列表。如果用户是所列用户组中任一用户组的成员，则视为匹配。 空列表意味着适用于所有用户组。 | | `verbs`
`[]string` | 此规则所适用的动词（`verb`）列表。 空列表意味着适用于所有动词。 | | `resources`
[`[]GroupResources`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-GroupResources) | 此规则所适用的资源类别列表。 空列表意味着适用于 API 组中的所有资源类别。 | | `namespaces`
`[]string` | 此规则所适用的名字空间列表。 空字符串（""）意味着适用于非名字空间作用域的资源。 空列表意味着适用于所有名字空间。 | | `nonResourceURLs`
`[]string` | `nonResourceURLs` 是一组需要被审计的 URL 路径。 允许使用 `` *`，但只能作为路径中最后一个完整分段。 例如：` ``

* `` `"/metrics" - 记录对 API 服务器度量值（metrics）的所有请求；` ``
* `` `"/healthz*" - 记录所有健康检查。` `` | | `omitStages`
[`[]Stage`](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Stage) | 字段 `omitStages` 是一个阶段（Stage）列表，针对所列的阶段服务器不会生成审计事件。 注意这一选项也可以在策略（Policy）级别指定。服务器审计组件会忽略 `omitStages` 中给出的阶段，也会忽略策略中给出的阶段。 空列表意味着不对阶段作任何限制。 | | `omitManagedFields`
`bool` | `omitManagedFields` 决定将请求和响应主体写入 API 审计日志时，是否省略其托管字段。

* 值为 'true' 将从 API 审计日志中删除托管字段
* 值为 'false' 表示托管字段应包含在 API 审计日志中 请注意，如果指定此规则中的值将覆盖全局默认值。 如果未指定，则使用 `policy.omitManagedFields` 中指定的全局默认值。 | `Stage`[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Stage) ----------------------------------------------------------------------------------------------------------- `string` 数据类型的别名。 **出现在：** * [Event](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) * [Policy](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) * [PolicyRule](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-PolicyRule) `Stage` 定义在请求处理过程中可以生成审计事件的阶段。 反馈[](https://kubernetes.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/#feedback) ----------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/config-api/apiserver-audit.v1/) . 最后修改 January 02, 2026 at 5:17 PM PST: [\[zh-cn\]sync apiserver-audit.v1 (e25d363bbc)](https://github.com/kubernetes/website/commit/e25d363bbc6fa26c2e61e3d771c308ba2cb1a5f3) --- # কুবারনেটিসে অবদান | Kubernetes **এই ডকুমেন্টে তথ্য পুরানো হতে পারে** এই ডকুমেন্টটির আসলটির চেয়ে পুরানো আপডেটের তারিখ রয়েছে, তাই এতে থাকা তথ্য পুরানো হতে পারে৷ আপনি ইংরেজি পড়তে সক্ষম হলে, সবচেয়ে আপ-টু-ডেট তথ্যের জন্য ইংরেজি ভার্সনটি দেখুন: [Contribute to Kubernetes](https://kubernetes.io/docs/contribute/) কুবারনেটিসে অবদান ================= কুবারনেটিসে অবদান রাখার অনেক উপায় আছে। আপনি নতুন ফিচারগুলোর জন্য ডিজাইনে কাজ করতে পারেন, আপনি আমাদের কাছে ইতিমধ্যে থাকা কোডটি ডকুমেন্ট করতে পারেন, আপনি আমাদের [ব্লগের](https://kubernetes.io/bn/blog) জন্য লিখতে পারেন। আরও আছে: আপনি সেই নতুন ফিচারগুলোর বাস্তবায়ন করতে পারেন বা বাগগুলি ঠিক করতে পারেন৷ আপনি লোকেদের আমাদের অবদানকারী কমিউনিটিতে যোগ দিতে সাহায্য করতে পারেন, বা বিদ্যমান অবদানকারীদের সাপোর্ট করতে পারেন৷ এই সমস্ত ভিন্ন উপায়ে প্রকল্পে পার্থক্য আনতে, আমরা - কুবারনেটিস - একটি ডেডিকেটেড ওয়েবসাইট তৈরি করেছি: [https://k8s.dev/](https://k8s.dev/) । কুবারনেটিসে অবদান রাখার বিষয়ে আরও জানতে আপনি সেখানে যেতে পারেন। আপনি যদি বিশেষভাবে _এই_ ডকুমেন্টেশনে অবদান রাখার বিষয়ে জানতে চান, পড়ুন [কুবারনেটিস ডকুমেন্টেশনে অবদান রাখুন](https://kubernetes.io/docs/contribute/docs/) । এছাড়াও আপনি পড়তে পারেন [CNCF](https://cncf.io/) [পৃষ্ঠা](https://contribute.cncf.io/contributors/projects/#kubernetes) কুবারনেটিস অবদান সম্পর্কে। ফিডব্যাক[](https://kubernetes.io/bn/docs/contribute/#feedback) --------------------------------------------------------------- এই পেজটি কি সহায়ক ছিল? হ্যাঁ না সাহায্য করার জন্য ধন্যবাদ. কুবারনেটিস কীভাবে ব্যবহার করবেন সে সম্পর্কে আপনার যদি একটি নির্দিষ্ট, উত্তরযোগ্য প্রশ্ন থাকে তবে এটি জিজ্ঞাসা করুন [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . আপনি যদি চান তবে [গিটহাব রিপোতে](https://www.github.com/kubernetes/website/) এ একটি ইস্যু খুলুন [একটি সমস্যা রিপোর্ট করুন](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/bn/docs/contribute/) অথবা [উন্নতির পরামর্শ দিন](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/bn/docs/contribute/) . সর্বশেষ পরিবর্তিত May 05, 2024 at 1:39 PM PST: [Update \_index.md (5a53832081)](https://github.com/kubernetes/website/commit/5a538320814ee8dd87ef6a1fb570e3dfe34ca961) --- # Unterstützte Versionen der Kubernetes-Dokumentation | Kubernetes Unterstützte Versionen der Kubernetes-Dokumentation =================================================== Diese Website enthält Dokumentation für die aktuelle Version von Kubernetes und die vier vorherigen Versionen von Kubernetes. Aktuelle Version[](https://kubernetes.io/de/docs/home/supported-doc-versions/#version-latest) ---------------------------------------------------------------------------------------------- * [v1.35](https://kubernetes.io/de/docs/home/supported-doc-versions/) (dieser Dokumentation) Vorherige Versionen[](https://kubernetes.io/de/docs/home/supported-doc-versions/#versions-older) ------------------------------------------------------------------------------------------------- * [v1.34](https://v1-34.docs.kubernetes.io/de/docs/home/supported-doc-versions/) * [v1.33](https://v1-33.docs.kubernetes.io/de/docs/home/supported-doc-versions/) * [v1.32](https://v1-32.docs.kubernetes.io/de/docs/home/supported-doc-versions/) * [v1.31](https://v1-31.docs.kubernetes.io/de/docs/home/supported-doc-versions/) --- # kubelet 所使用的本地文件和路径 | Kubernetes kubelet 所使用的本地文件和路径 =================== [kubelet](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet) 是一个运行在 Kubernetes [节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 上的无状态进程。本文简要介绍了 kubelet 读写的文件。 #### 说明： 本文仅供参考，而非描述保证会发生的行为或 API。 本文档列举 kubelet 所使用的资源。所给的信息属于实现细节，可能会在后续版本中发生变更。 kubelet 通常使用[控制面](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-control-plane) 作为需要在 Node 上运行的事物的真实来源，并使用[容器运行时](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes) 获取容器的当前状态。 只要你向 kubelet 提供 **kubeconfig**（API 客户端配置），kubelet 就会连接到你的控制面； 否则，节点将以\*\*独立（Standalone）\*\*模式运行。 在 Linux 节点上，kubelet 还需要读取 cgroups 和各种系统文件来收集指标。 在 Windows 节点上，kubelet 不依赖于路径，而是通过其他机制来收集指标。 kubelet 所使用的还有其他文件，包括其使用本地 Unix 域套接字进行通信的文件。 有些文件是 kubelet 要监听的套接字，而其他套接字则是 kubelet 先发现后作为客户端连接的。 #### 说明： 本页列举的路径为 Linux 路径，若要映射到 Windows，你可以添加根磁盘 `C:\` 替换 `/`（除非另行指定）。 例如，`/var/lib/kubelet/device-plugins` 映射到 `C:\var\lib\kubelet\device-plugins`。 配置[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#configuration) ----------------------------------------------------------------------------------- ### kubelet 配置文件[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#kubelet-configuration-files) 你可以使用命令行参数 `--config` 指定 kubelet 配置文件的路径。kubelet 还支持[插件（Drop-in）配置文件](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/#kubelet-conf-d) 来增强配置。 ### 证书[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#certificates) 证书和私钥通常位于 `/var/lib/kubelet/pki`，但你可以使用 `--cert-dir` kubelet 命令行参数进行配置。 证书文件的名称也是可以配置的。 ### 清单[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#manifests) 静态 Pod 的清单通常位于 `/etc/kubernetes/manifests`。 你可以使用 `staticPodPath` kubelet 配置选项进行配置。 ### systemd 单元设置[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#systemd-unit-settings) 当 kubelet 作为 systemd 单元运行时，一些 kubelet 配置可以在 systemd 单元设置文件中声明。 这些配置通常包括： * [运行 kubelet 的命令行参数](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet/) * kubelet 所使用的环境变量或[配置 Golang 运行时](https://pkg.go.dev/runtime#hdr-Environment_Variables) 状态[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#state) --------------------------------------------------------------------------- ### 资源管理器的检查点文件[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#resource-managers-state) 所有资源管理器将 Pod 与已分配资源之间的映射保存在状态文件中。 状态文件位于 kubelet 的基础目录，也称为**根目录**（但与节点根目录 `/` 不同）之下。 你可以使用 kubelet 命令行参数 `--root-dir` 来配置 kubelet 的基础目录。 文件名称： * `memory_manager_state` 对应[内存管理器](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/memory-manager/) * `cpu_manager_state` 对应 [CPU 管理器](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/) * `dra_manager_state` 对应 [DRA](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) ### 设备管理器的检查点文件[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#device-manager-state) 设备管理器在与套接字文件相同的目录（`/var/lib/kubelet/device-plugins/`）中创建检查点。 对于[设备管理器](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) ， 检查点文件的名称为 `kubelet_internal_checkpoint`。 ### Pod 状态检查点[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#pod-resource-checkpoints) 特性状态： `Kubernetes v1.35 [stable]`（默认启用） 如果某个节点已启用了 `InPlacePodVerticalScaling` [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) ， 则 kubelet 存储有关 Pod 资源**已分配**和**已应用**状态的本地记录。 有关如何使用这些记录的更多细节， 请参阅[调整分配给容器的 CPU 和内存资源](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/) 。 文件名称如下： * `allocated_pods_state`：记录分配给该节点上每个 Pod 的资源。 * `actuated_pods_state`：记录运行时已接受并应用于该节点上每个 Pod 的资源。 这些文件位于 kubelet 的基础目录中（在 Linux 系统中默认是 `/var/lib/kubelet`； 也可以通过 `--root-dir` 参数进行配置）。 ### 容器运行时[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#container-runtime) kubelet 使用通过配置参数所配置的套接字与容器运行时进行通信： * `containerRuntimeEndpoint` 用于运行时操作 * `imageServiceEndpoint` 用于镜像管理操作 这些端点的实际值取决于所使用的容器运行时。 ### 设备插件[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#device-plugins) kubelet 在路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 为各个[要注册的设备插件](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-implementation) 公开一个套接字。 当设备插件注册自己时，它会为提供其套接字路径供 kubelet 连接使用。 设备插件套接字应位于 kubelet 基础目录中的 `device-plugins` 目录内。 在典型的 Linux 节点上，这意味着 `/var/lib/kubelet/device-plugins`。 ### Pod Resources API[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#pod-resources-api) [Pod Resources API](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) 将在路径 `/var/lib/kubelet/pod-resources` 上被公开。 ### DRA、CSI 和设备插件[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#dra-csi-and-device-plugins) kubelet 会查找通过 [DRA](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) 设备管理器或存储插件所管理的设备插件所创建的套接字文件，然后尝试连接到这些套接字。 kubelet 查找的目录是 kubelet 基础目录下的 `plugins_registry`， 因此在典型的 Linux 节点上这意味着 `/var/lib/kubelet/plugins_registry`。 请注意，对于设备插件，有两种备选的注册机制。每个给定的插件只能使用其中一种注册机制。 可以将套接字文件放入该目录的插件类型包括： * CSI 插件 * DRA 插件 * 设备管理器插件 （通常是 `/var/lib/kubelet/plugins_registry`）。 ### 节点体面关闭[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#graceful-node-shutdown) 特性状态： `Kubernetes v1.21 [beta]`（默认启用） [节点体面关闭](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/node-shutdown/#graceful-node-shutdown) 将状态存储在本地目录 `/var/lib/kubelet/graceful_node_shutdown_state`。 ### 镜像拉取记录[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#image-pull-records) 特性状态： `Kubernetes v1.35 [beta]`（默认启用） kubelet 存储镜像拉取的尝试记录和成功记录，并使用这些记录来验证镜像是否曾使用相同的凭据被成功拉取过。 这些记录作为文件缓存在 kubelet 基础目录下的 `image_registry` 目录中。 在典型的 Linux 节点上，这个路径通常为 `/var/lib/kubelet/image_manager`。 `image_manager` 目录下包含两个子目录： * `pulling`：存储 kubelet 正在尝试拉取的镜像的相关记录。 * `pulled`：存储 kubelet 成功拉取的镜像记录，以及与拉取所用凭据相关的元数据。 更多细节请参阅[确保镜像拉取凭据验证](https://kubernetes.io/zh-cn/docs/concepts/containers/images#ensureimagepullcredentialverification) 。 安全配置文件和配置[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#security-profiles-configuration) ------------------------------------------------------------------------------------------------------------ ### Seccomp[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#seccomp) 被 Pod 引用的 Seccomp 配置文件应放置在 `/var/lib/kubelet/seccomp`。 有关细节请参见 [Seccomp 参考](https://kubernetes.io/zh-cn/docs/reference/node/seccomp/) 。 ### AppArmor[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#apparmor) kubelet 不会通过特定于 Kubernetes 的路径加载或引用 AppArmor 配置文件。 AppArmor 配置文件通过节点操作系统被加载，而不是通过其路径被引用。 加锁[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#locking) ----------------------------------------------------------------------------- 特性状态： `Kubernetes v1.2 [alpha]` kubelet 的锁文件；通常为 `/var/run/kubelet.lock`。 kubelet 使用此文件确保尝试运行两个不同的、彼此冲突的 kubelet。 你可以使用 `--lock-file` kubelet 命令行参数来配置这个锁文件的路径。 如果同一节点上的两个 kubelet 使用不同的锁文件路径值，则这两个 kubelet 在同时运行时将不会检测到冲突。 接下来[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) -------------------------------------------------------------------------------------------------- * 了解 kubelet [命令行参数](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 。 * 查阅 [kubelet 配置 (v1beta1) 参考文档](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) 反馈[](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files/#feedback) ------------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/node/kubelet-files/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/node/kubelet-files/) . 最后修改 April 24, 2025 at 9:50 AM PST: [\[zh\] Sync node/kubelet-files.md and kernel-version-requirements.md (afc8753c8d)](https://github.com/kubernetes/website/commit/afc8753c8d565211807270f3199b193fdb66b575) --- # PKI証明書とその要件 | Kubernetes PKI証明書とその要件 =========== Kubernetesでは、TLS認証のためにPKI証明書が必要です。 [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) でKubernetesをインストールする場合、必要な証明書は自動で生成されます。 自身で証明書を作成することも可能です。例えば、秘密鍵をAPIサーバーに保持しないことで、管理をよりセキュアにする場合が挙げられます。 本ページでは、クラスターに必要な証明書について説明します。 クラスターではどのように証明書が使われているのか[](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%83%BC%E3%81%A7%E3%81%AF%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%81%8C%E4%BD%BF%E3%82%8F%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%81%AE%E3%81%8B) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Kubernetesは下記の用途でPKIを必要とします: * kubeletがAPIサーバーの認証をするためのクライアント証明書 * APIサーバーがkubeletと通信するためのkubeletの[サーバー証明書](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates) * APIサーバーのエンドポイント用サーバー証明書 * クラスターの管理者がAPIサーバーの認証を行うためのクライアント証明書 * APIサーバーがkubeletと通信するためのクライアント証明書 * APIサーバーがetcdと通信するためのクライアント証明書 * controller managerがAPIサーバーと通信するためのクライアント証明書およびkubeconfig * スケジューラーがAPIサーバーと通信するためのクライアント証明書およびkubeconfig * [front-proxy](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 用のクライアント証明書およびサーバー証明書 #### 備考: `front-proxy`証明書は、[Kubernetes APIの拡張](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-extension-api-server/) をサポートするためにkube-proxyを実行する場合のみ必要です。 さらに、etcdはクライアントおよびピア間の認証に相互TLS通信を実装しています。 証明書の保存場所[](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%81%AE%E4%BF%9D%E5%AD%98%E5%A0%B4%E6%89%80) ------------------------------------------------------------------------------------------------------------------------------------------------------ kubeadmを使用してKubernetesをインストールする場合、ほとんどの証明書は`/etc/kubernetes/pki`に保存されます。このドキュメントの全てのパスは、そのディレクトリの相対パスを表します。 ただしユーザーアカウントの証明書に関しては、kubeadmは`/etc/kubernetes`に配置します。 手動で証明書を設定する[](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#%E6%89%8B%E5%8B%95%E3%81%A7%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ もしkubeadmに必要な証明書の生成を望まない場合、それらを単一ルート認証局を使って作成するか、全ての証明書を提供することで作成できます。 自身の認証局を作成する詳細については、[証明書を手動で生成する](https://kubernetes.io/ja/docs/tasks/administer-cluster/certificates/) を参照してください。 証明書の管理についての詳細は、[kubeadmによる証明書管理](https://kubernetes.io/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) を参照してください。 ### 単一ルート認証局[](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#%E5%8D%98%E4%B8%80%E3%83%AB%E3%83%BC%E3%83%88%E8%AA%8D%E8%A8%BC%E5%B1%80) 管理者によりコントロールされた、単一ルート認証局の作成が可能です。このルート認証局は複数の中間認証局を作る事が可能で、作成はKubernetes自身に委ねます。 必要な認証局: | パス | デフォルトCN | 説明 | | --- | --- | --- | | ca.crt,key | kubernetes-ca | Kubernetes全体の認証局 | | etcd/ca.crt,key | etcd-ca | etcd用 | | front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
用 | 上記の認証局に加えて、サービスアカウント管理用に公開鍵/秘密鍵のペア(`sa.key`と`sa.pub`)を取得する事が必要です。 次の例は、前の表で示されたCAのキーと証明書を示しています: /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/ca.key /etc/kubernetes/pki/etcd/ca.crt /etc/kubernetes/pki/etcd/ca.key /etc/kubernetes/pki/front-proxy-ca.crt /etc/kubernetes/pki/front-proxy-ca.key ### 全ての証明書[](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#%E5%85%A8%E3%81%A6%E3%81%AE%E8%A8%BC%E6%98%8E%E6%9B%B8) CAの秘密鍵をクラスターにコピーしたくない場合、自身で全ての証明書を作成できます。 必要な証明書: | デフォルトCN | 親認証局 | 組織 | 種類 | ホスト名 (SAN) | | --- | --- | --- | --- | --- | | kube-etcd | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | | kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | | kube-etcd-healthcheck-client | etcd-ca | | client | | | kube-apiserver-etcd-client | etcd-ca | | client | | | kube-apiserver | kubernetes-ca | | server | ``, ``, ``, `[1]` | | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | #### 備考: `kube-apiserver-kubelet-client`にスーパーユーザーグループ`system:masters`を使用する代わりに、より権限の低いグループを使用することができます。 そのために、kubeadmは`kubeadm:cluster-admins`グループを使用します。 \[1\]: クラスターに接続するIPおよびDNS名( [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`) ここで`種類`は、一つまたは複数のx509の鍵用途にマッピングされており、これは[CertificateSigningRequest](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1#CertificateSigningRequest) の`.spec.usages`にも記載されています: | 種類 | 鍵の用途 | | --- | --- | | server | digital signature, key encipherment, server auth | | client | digital signature, key encipherment, client auth | #### 備考: 上記に挙げられたホスト名(SAN)は、クラスターを動作させるために推奨されるものです。 特別なセットアップが求められる場合、全てのサーバー証明書にSANを追加する事ができます。 #### 備考: kubeadm利用者のみ: * 秘密鍵なしでCA証明書をクラスターにコピーするシナリオは、kubeadmドキュメントの外部認証局の項目で言及されています。 * kubeadmでPKIを生成すると、`kube-etcd`、`kube-etcd-peer`および `kube-etcd-healthcheck-client`証明書は外部etcdを利用するケースでは生成されない事に留意してください。 ### 証明書のパス[](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#certificate-paths) 証明書は推奨パスに配置するべきです([kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) を使用する場合と同様)。 パスは場所に関係なく与えられた引数で特定されます。 | デフォルトCN | 鍵の推奨パス | 証明書の推奨パス | コマンド | 鍵を指定する引数 | 証明書を指定する引数 | | --- | --- | --- | --- | --- | --- | | etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | \--etcd-cafile | | kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | \--etcd-keyfile | \--etcd-certfile | | kubernetes-ca | ca.key | ca.crt | kube-apiserver | | \--client-ca-file | | kubernetes-ca | ca.key | ca.crt | kube-controller-manager | \--cluster-signing-key-file | \--client-ca-file, --root-ca-file, --cluster-signing-cert-file | | kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | \--tls-private-key-file | \--tls-cert-file | | kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | \--kubelet-client-key | \--kubelet-client-certificate | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | \--requestheader-client-ca-file | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | \--requestheader-client-ca-file | | front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | \--proxy-client-key-file | \--proxy-client-cert-file | | etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | \--trusted-ca-file, --peer-trusted-ca-file | | kube-etcd | etcd/server.key | etcd/server.crt | etcd | \--key-file | \--cert-file | | kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | \--peer-key-file | \--peer-cert-file | | etcd-ca | | etcd/ca.crt | etcdctl | | \--cacert | | kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | \--key | \--cert | サービスアカウント用の鍵ペアについても同様です。 | 秘密鍵のパス | 公開鍵のパス | コマンド | 引数 | | --- | --- | --- | --- | | sa.key | | kube-controller-manager | service-account-private | | | sa.pub | kube-apiserver | service-account-key | 次の例は、自分自身で全てのキーと証明書を生成している場合に提供する必要があるファイルパスを[前の表](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#certificate-paths) から示しています: /etc/kubernetes/pki/etcd/ca.key /etc/kubernetes/pki/etcd/ca.crt /etc/kubernetes/pki/apiserver-etcd-client.key /etc/kubernetes/pki/apiserver-etcd-client.crt /etc/kubernetes/pki/ca.key /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/front-proxy-ca.key /etc/kubernetes/pki/front-proxy-ca.crt /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/etcd/server.key /etc/kubernetes/pki/etcd/server.crt /etc/kubernetes/pki/etcd/peer.key /etc/kubernetes/pki/etcd/peer.crt /etc/kubernetes/pki/etcd/healthcheck-client.key /etc/kubernetes/pki/etcd/healthcheck-client.crt /etc/kubernetes/pki/sa.key /etc/kubernetes/pki/sa.pub ユーザーアカウント用に証明書を設定する[](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E7%94%A8%E3%81%AB%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 管理者アカウントおよびサービスアカウントは手動で設定しなければなりません。 | ファイル名 | クレデンシャル名 | デフォルトCN | O (in Subject) | | --- | --- | --- | --- | | admin.conf | default-admin | kubernetes-admin | `` | | super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters | | kubelet.conf | default-auth | system:node:`` (備考を参照) | system:nodes | | controller-manager.conf | default-controller-manager | system:kube-controller-manager | | | scheduler.conf | default-scheduler | system:kube-scheduler | | #### 備考: `kubelet.conf`における``の値は**必ず**APIサーバーに登録されたkubeletのノード名と一致しなければなりません。詳細は、[Node Authorization](https://kubernetes.io/docs/reference/access-authn-authz/node/) を参照してください。 #### 備考: 上記の例での``は実装に依存します。 一部のツールはデフォルトの`admin.conf`内の証明書に`system:masters`グループの一部として署名します。 `system:masters`は緊急用のスーパーユーザーグループであり、RBACのようなKubernetesの認証レイヤーをバイパスすることができます。 また、一部のツールはこのスーパーユーザーグループに紐づけられた証明書を含む`super-admin.conf`を生成しません。 kubeadmはkubeconfigファイル内に2つの別々の管理者証明書を生成します。 一つは`admin.conf`内にあり、`Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin`となっています。 `kubeadm:cluster-admins`は`cluster-admin` ClusterRoleに紐づけられたカスタムグループです。 このファイルは、kubeadmが管理する全てのコントロールプレーンマシン上で生成されます。 もう一つは`super-admin.conf`内にあり、`Subject: O = system:masters, CN = kubernetes-super-admin`となっています。 このファイルは`kubeadm init`が呼び出されたノード上でのみ生成されます。 1. 各コンフィグ毎に、CN名と組織を指定してx509証明書と鍵ペアを生成してください。 2. 以下のように、各コンフィグで`kubectl`を実行してください。 KUBECONFIG= kubectl config set-cluster default-cluster --server=https://:6443 --certificate-authority --embed-certs KUBECONFIG= kubectl config set-credentials --client-key .pem --client-certificate .pem --embed-certs KUBECONFIG= kubectl config set-context default-system --cluster default-cluster --user KUBECONFIG= kubectl config use-context default-system これらのファイルは以下のように利用されます: | ファイル名 | コマンド | コメント | | --- | --- | --- | | admin.conf | kubectl | クラスターの管理者設定用 | | kubelet.conf | kubelet | クラスターの各ノードに1つ必要です。 | | controller-manager.conf | kube-controller-manager | `manifests/kube-controller-manager.yaml`のマニフェストファイルに追記する必要があります。 | | scheduler.conf | kube-scheduler | `manifests/kube-scheduler.yaml`のマニフェストファイルに追記する必要があります。 | 以下のファイルは、前の表に挙げたファイルへの絶対パスを示しています: /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf フィードバック[](https://kubernetes.io/ja/docs/setup/best-practices/certificates/#feedback) ------------------------------------------------------------------------------------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/ja/docs/setup/best-practices/certificates/) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/ja/docs/setup/best-practices/certificates/) . 最終更新 March 26, 2025 at 6:05 PM PST: [chore: trim full-wide space (61ee0d16cc)](https://github.com/kubernetes/website/commit/61ee0d16ccdbb63d2da5bb9660e995cc8b7cf1f3) --- # 组件工具 | Kubernetes 组件工具 ==== * * * ##### [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) ##### [特性门控（已移除）](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates-removed/) ##### [kubelet](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet/) ##### [kube-apiserver](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) ##### [kube-controller-manager](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) ##### [kube-proxy](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) ##### [kube-scheduler](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) 反馈[](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/#feedback) ---------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/command-line-tools-reference/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/command-line-tools-reference/) . 最后修改 March 23, 2023 at 3:23 PM PST: [\[zh-cn\] Reference files to sync task-31 (2008a2fc4a)](https://github.com/kubernetes/website/commit/2008a2fc4a93c3c65d9fc9f6606c159bcd77f167) --- # 工作负载 | Kubernetes 工作负载 ==== 理解 Kubernetes 中可部署的最小计算对象 Pod 以及辅助 Pod 运行的上层抽象。 工作负载是在 Kubernetes 上运行的应用程序。 在 Kubernetes 中，无论你的负载是由单个组件还是由多个一同工作的组件构成， 你都可以在一组 [**Pod**](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods) 中运行它。在 Kubernetes 中， Pod 代表的是集群上处于运行状态的一组[容器](https://kubernetes.io/zh-cn/docs/concepts/containers/) 的集合。 Kubernetes Pod 遵循[预定义的生命周期](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 。 例如，当在你的集群中运行了某个 Pod，但是 Pod 所在的[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 出现致命错误时， 所有该节点上的 Pod 的状态都会变成失败。Kubernetes 将这类失败视为最终状态： 即使该节点后来恢复正常运行，你也需要创建新的 Pod 以恢复应用。 不过，为了减轻用户的使用负担，通常不需要用户直接管理每个 Pod。 而是使用**负载资源**来替用户管理一组 Pod。 这些负载资源通过配置[控制器](https://kubernetes.io/zh-cn/docs/concepts/architecture/controller/) 来确保正确类型的、处于运行状态的 Pod 个数是正确的，与用户所指定的状态相一致。 Kubernetes 提供若干种内置的工作负载资源： * [Deployment](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/) 和 [ReplicaSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicaset/) （替换原来的资源 [ReplicationController](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-replication-controller) ）。 Deployment 很适合用来管理你的集群上的无状态应用，Deployment 中的所有 Pod 都是相互等价的，并且在需要的时候被替换。 * [StatefulSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/) 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pod。 例如，如果你的负载会将数据作持久存储，你可以运行一个 StatefulSet，将每个 Pod 与某个 [PersistentVolume](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/) 对应起来。你在 StatefulSet 中各个 Pod 内运行的代码可以将数据复制到同一 StatefulSet 中的其它 Pod 中以提高整体的服务可靠性。 * [DaemonSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/) 定义提供节点本地支撑设施的 Pod。这些 Pod 可能对于你的集群的运维是非常重要的， 例如作为网络链接的辅助工具或者作为网络[插件](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/addons/) 的一部分等等。 每次你向集群中添加一个新节点时，如果该节点与某 `DaemonSet` 的规约匹配，则控制平面会为该 DaemonSet 调度一个 Pod 到该新节点上运行。 * [Job](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/) 和 [CronJob](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/cron-jobs/) 提供不同的方式来定义一些一直运行到结束并停止的任务。 你可以使用 [Job](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/) 来定义只需要执行一次并且执行后即视为完成的任务。你可以使用 [CronJob](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/cron-jobs/) 来根据某个排期表来多次运行同一个 Job。 在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方工作负载相关的资源。 通过使用[定制资源定义（CRD）](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) ， 你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。 例如，如果你希望运行一组 Pod，但要求**所有** Pod 都可用时才执行操作 （比如针对某种高吞吐量的分布式任务），你可以基于定制资源实现一个能够满足这一需求的扩展， 并将其安装到集群中运行。 调度工作负载[](https://kubernetes.io/zh-cn/docs/concepts/workloads/#workload-placement) ---------------------------------------------------------------------------------- 特性状态： `Kubernetes v1.35 [alpha]`（默认禁用） 虽然标准的工作负载资源（例如 Deployment 和 Job）用于管理 Pod 的生命周期， 但在某些场景下，你可能会有更复杂的调度需求，例如需要将几组 Pod 作为一个单元整体来处理。 [Workload API](https://kubernetes.io/zh-cn/docs/concepts/workloads/workload-api/) 允许你定义一组 Pod， 并对其应用高级的调度策略，例如[成组调度](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/gang-scheduling/) 。 在需要“全有或全无”的调度方式时，这对于批处理和机器学习类工作负载尤其有用。 接下来[](https://kubernetes.io/zh-cn/docs/concepts/workloads/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) ---------------------------------------------------------------------------------------- 除了阅读了解每类 API 资源方便管理工作负载外，你还可以了解如何运行以下特定任务： * [使用 Deployment 运行一个无状态的应用](https://kubernetes.io/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/) * 以[单实例](https://kubernetes.io/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application/) 或者[多副本集合](https://kubernetes.io/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/) 的形式运行有状态的应用； * [使用 CronJob 运行自动化的任务](https://kubernetes.io/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/) 要了解 Kubernetes 将代码与配置分离的实现机制，可参阅[配置](https://kubernetes.io/zh-cn/docs/concepts/configuration/) 节。 关于 Kubernetes 如何为应用管理 Pod，还有两个支撑概念能够提供相关背景信息： * [垃圾收集](https://kubernetes.io/zh-cn/docs/concepts/architecture/garbage-collection/) 机制负责在对象的**属主资源**被删除时在集群中清理这些对象。 * [**Time-to-Live** 控制器](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) 会在 Job 结束之后的指定时间间隔之后删除它们。 一旦你的应用处于运行状态，你就可能想要以 [Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 的形式使之可在互联网上访问；或者对于 Web 应用而言，使用 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 * * * ##### [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/) ##### [工作负载管理](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/) ##### [管理工作负载](https://kubernetes.io/zh-cn/docs/concepts/workloads/management/) ##### [自动扩缩工作负载](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/) 通过自动扩缩，你可以用某种方式自动更新你的工作负载。在面对资源需求变化的时候可以使你的集群更灵活、更高效。 ##### [Pod 水平自动扩缩](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) 反馈[](https://kubernetes.io/zh-cn/docs/concepts/workloads/#feedback) -------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/workloads/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/workloads/) . 最后修改 March 04, 2026 at 2:29 PM PST: [\[zh\] Sync workloads/\_index.md (48ddd9dde2)](https://github.com/kubernetes/website/commit/48ddd9dde2a9b3109dd15c221a4424621814d2c0) --- # Windows 存储 | Kubernetes Windows 存储 ========== 此页面提供特定于 Windows 操作系统的存储概述。 持久存储[](https://kubernetes.io/zh-cn/docs/concepts/storage/windows-storage/#storage) ----------------------------------------------------------------------------------- Windows 有一个分层文件系统驱动程序用来挂载容器层和创建基于 NTFS 的文件系统拷贝。 容器中的所有文件路径仅在该容器的上下文中解析。 * 使用 Docker 时，卷挂载只能是容器中的目录，而不能是单个文件。此限制不适用于 containerd。 * 卷挂载不能将文件或目录映射回宿主文件系统。 * 不支持只读文件系统，因为 Windows 注册表和 SAM 数据库始终需要写访问权限。不过，Windows 支持只读的卷。 * 不支持卷的用户掩码和访问许可，因为宿主与容器之间并不共享 SAM，二者之间不存在映射关系。 所有访问许可都是在容器上下文中解析的。 因此，Windows 节点不支持以下存储功能： * 卷子路径挂载：只能在 Windows 容器上挂载整个卷 * Secret 的子路径挂载 * 宿主挂载映射 * 只读的根文件系统（映射的卷仍然支持 `readOnly`） * 块设备映射 * 内存作为存储介质（例如 `emptyDir.medium` 设置为 `Memory`） * 类似 UID/GID、各用户不同的 Linux 文件系统访问许可等文件系统特性 * 使用 [DefaultMode 设置 Secret 权限](https://kubernetes.io/zh-cn/docs/tasks/inject-data-application/distribute-credentials-secure/#set-posix-permissions-for-secret-keys) （因为该特性依赖 UID/GID） * 基于 NFS 的存储和卷支持 * 扩展已挂载卷（resizefs） 使用 Kubernetes [卷](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/) ， 对数据持久性和 Pod 卷共享有需求的复杂应用也可以部署到 Kubernetes 上。 管理与特定存储后端或协议相关的持久卷时，相关的操作包括：对卷的制备（Provisioning）、 去配（De-provisioning）和调整大小，将卷挂接到 Kubernetes 节点或从节点上解除挂接， 将卷挂载到需要持久数据的 Pod 中的某容器上或从容器上卸载。 卷管理组件作为 Kubernetes 卷[插件](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#volume-types) 发布。 Windows 支持以下类型的 Kubernetes 卷插件： * [`FlexVolume plugins`](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#flexvolume) * 请注意自 1.23 版本起，FlexVolume 已被弃用 * [`CSI Plugins`](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi) ##### 树内（In-Tree）卷插件[](https://kubernetes.io/zh-cn/docs/concepts/storage/windows-storage/#in-tree-volume-plugins) 以下树内（In-Tree）插件支持 Windows 节点上的持久存储： * [`azureFile`](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#azurefile) * [`vsphereVolume`](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#vspherevolume) 反馈[](https://kubernetes.io/zh-cn/docs/concepts/storage/windows-storage/#feedback) ---------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/storage/windows-storage/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/storage/windows-storage/) . 最后修改 December 06, 2023 at 12:33 AM PST: [\[zh-cn\] sync windows-storage local-debugging (22c9a904ec)](https://github.com/kubernetes/website/commit/22c9a904ec1046381858de5b43da6e15edef4eaf) --- # 工作负载管理 | Kubernetes 工作负载管理 ====== Kubernetes 提供了几个内置的 API 来声明式管理[工作负载](https://kubernetes.io/zh-cn/docs/concepts/workloads/) 及其组件。 最终，你的应用以容器的形式在 [Pods](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/) 中运行； 但是，直接管理单个 Pod 的工作量将会非常繁琐。例如，如果一个 Pod 失败了，你可能希望运行一个新的 Pod 来替换它。Kubernetes 可以为你完成这些操作。 你可以使用 Kubernetes API 创建工作负载[对象](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/#kubernetes-objects) ， 这些对象所表达的是比 Pod 更高级别的抽象概念，Kubernetes [控制平面](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-control-plane) 根据你定义的工作负载对象规约自动管理 Pod 对象。 用于管理工作负载的内置 API 包括： [Deployment](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/) （也间接包括 [ReplicaSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicaset/) ） 是在集群上运行应用的最常见方式。Deployment 适合在集群上管理无状态应用工作负载， 其中 Deployment 中的任何 Pod 都是可互换的，可以在需要时进行替换。 （Deployment 替代原来的 [ReplicationController](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-replication-controller) API）。 [StatefulSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/) 允许你管理一个或多个运行相同应用代码、但具有不同身份标识的 Pod。 StatefulSet 与 Deployment 不同。Deployment 中的 Pod 预期是可互换的。 StatefulSet 最常见的用途是能够建立其 Pod 与其持久化存储之间的关联。 例如，你可以运行一个将每个 Pod 关联到 [PersistentVolume](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/) 的 StatefulSet。如果该 StatefulSet 中的一个 Pod 失败了，Kubernetes 将创建一个新的 Pod， 并连接到相同的 PersistentVolume。 [DaemonSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/) 定义了在特定[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 上提供本地设施的 Pod， 例如允许该节点上的容器访问存储系统的驱动。当必须在合适的节点上运行某种驱动或其他节点级别的服务时， 你可以使用 DaemonSet。DaemonSet 中的每个 Pod 执行类似于经典 Unix / POSIX 服务器上的系统守护进程的角色。DaemonSet 可能对集群的操作至关重要， 例如作为插件让该节点访问[集群网络](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model) ， 也可能帮助你管理节点，或者提供增强正在运行的容器平台所需的、不太重要的设施。 你可以在集群的每个节点上运行 DaemonSets（及其 Pod），或者仅在某个子集上运行 （例如，只在安装了 GPU 的节点上安装 GPU 加速驱动）。 你可以使用 [Job](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/) 和/或 [CronJob](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/cron-jobs/) 定义一次性任务和定时任务。 Job 表示一次性任务，而每个 CronJob 可以根据排期表重复执行。 本节中的其他主题： * [已完成 Job 的自动清理](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) * [ReplicationController](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/) 反馈[](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/#feedback) -------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/workloads/controllers/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/workloads/controllers/) . 最后修改 January 24, 2024 at 9:37 PM PST: [\[zh-cn\] sync controllers/\_index.md job.md pods/\_index.md (320dab7907)](https://github.com/kubernetes/website/commit/320dab7907b9dbe245d2fe23a586f6e6852e1211) --- # Visão Geral de Autorização | Kubernetes **Este documento pode estar desatualizado** Este documento possui uma data de atualização mais antiga que o documento original. Portanto, este conteúdo pode estar desatualizado. Se você lê inglês, veja a versão em inglês para acessar a versão mais atualizada: [Authorization](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) Visão Geral de Autorização ========================== Aprenda mais sobre autorização no Kubernetes, incluindo detalhes sobre criação de políticas utilizando módulos de autorização suportados. No Kubernetes, você deve estar autenticado (conectado) antes que sua requisição possa ser autorizada (permissão concedida para acesso). Para obter informações sobre autenticação, visite [Controlando Acesso à API do Kubernetes](https://kubernetes.io/pt-br/docs/concepts/security/controlling-access/) . O Kubernetes espera atributos que são comuns a requisições de APIs REST. Isto significa que autorização no Kubernetes funciona com sistemas de controle de acesso a nível de organizações ou de provedores de nuvem que possam lidar com outras APIs além das APIs do Kubernetes. Determinar se uma requisição é permitida ou negada[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#determinar-se-uma-requisi%C3%A7%C3%A3o-%C3%A9-permitida-ou-negada) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- O Kubernetes autoriza requisições de API utilizando o servidor de API. Ele avalia todos os atributos de uma requisição em relação a todas as políticas disponíveis e permite ou nega a requisição. Todas as partes de uma requisição de API deve ser permitidas por alguma política para que possa prosseguir. Isto significa que permissões são negadas por padrão. (Embora o Kubernetes use o servidor de API, controles de acesso e políticas que dependem de campos específicos de tipos específicos de objetos são tratados pelos controladores de admissão.) Quando múltiplos módulos de autorização são configurados, cada um será verificado em sequência. Se qualquer dos autorizadores aprovarem ou negarem uma requisição, a decisão é imediatamente retornada e nenhum outro autorizador é consultado. Se nenhum módulo de autorização tiver nenhuma opinião sobre requisição, então a requisição é negada. Uma negação retorna um código de status HTTP 403. Revisão de atributos de sua requisição[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#revis%C3%A3o-de-atributos-de-sua-requisi%C3%A7%C3%A3o) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- O Kubernetes revisa somente os seguintes atributos de uma requisição de API: * **user** - O string de `user` fornecido durante a autenticação. * **group** - A lista de nomes de grupos aos quais o usuário autenticado pertence. * **extra** - Um mapa de chaves de string arbitrárias para valores de string, fornecido pela camada de autenticação. * **API** - Indica se a solicitação é para um recurso de API. * **Caminho da requisição** - Caminho para diversos endpoints que não manipulam recursos, como `/api` ou `/healthz`. * **Verbo de requisição de API** - Verbos da API como `get`, `list`, `create`, `update`, `patch`, `watch`, `delete` e `deletecollection` que são utilizados para solicitações de recursos. Para determinar o verbo de requisição para um endpoint de recurso de API , consulte [Determine o verbo da requisição](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) . * **Verbo de requisição HTTP** - Métodos HTTP em letras minúsculas como `get`, `post`, `put` e `delete` que são utilizados para requisições que não são de recursos. * **Recurso** - O identificador ou nome do recurso que está sendo acessado (somente para requisições de recursos) - para requisições de recursos usando os verbos `get`, `update`, `patch` e `delete`, deve-se fornecer o nome do recurso. * **Subrecurso** - O sub-recurso que está sendo acessado (somente para solicitações de recursos). * **Namespace** - O namespace do objeto que está sendo acessado (somente para solicitações de recursos com namespace). * **Grupo de API** - O [API Group](https://kubernetes.io/pt-br/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) sendo acessado (somente para requisições de recursos). Uma string vazia designa o [Grupo de API](https://kubernetes.io/docs/reference/using-api/#api-groups) _core_. Determine o verbo da requisição[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) ------------------------------------------------------------------------------------------------------------------------------------------- **Requisições de não-recursos** Requisições sem recursos de `/api/v1/...` ou `/apis///...` são considerados "requisições sem recursos" e usam o método HTTP em letras minúsculas da solicitação como o verbo. Por exemplo, uma solicitação `GET` para endpoints como `/api` ou `/healthz` usaria `get` como o verbo. **Requisições de recursos** Para determinar o verbo de requisição para um endpoint de API de recurso, revise o verbo HTTP utilizado e se a requisição atua ou não em um recurso individual ou em uma coleção de recursos: | Verbo HTTP | Verbo de Requisição | | --- | --- | | POST | create | | GET, HEAD | get (para recursos individuais), list (para coleções, includindo o conteúdo do objeto inteiro), watch (para observar um recurso individual ou coleção de recursos) | | PUT | update | | PATCH | patch | | DELETE | delete (para recursos individuais), deletecollection (para coleções) | #### Cuidado: Os verbos `get`, `list` e `watch` podem retornar todos os detalhes de um recurso. Eles são equivalentes em relação aos dados retornados. Por exemplo, `list` em `secrets` revelará os atributos de `data` de qualquer recurso retornado. Às vezes, o Kubernetes verifica a autorização para permissões adicionais utilizando verbos especializados. Por exemplo: * [PodSecurityPolicy](https://kubernetes.io/pt-br/docs/concepts/security/pod-security-policy/) * Verbo `use` em recursos `podsecuritypolicies` no grupo `policy` de API. * [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) * Verbos `bind` e `escalate` em `roles` e recursos `clusterroles` no grupo `rbac.authorization.k8s.io` de API. * [Authentication](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authentication/) * Verbo `impersonate` em `users`, `groups`, e `serviceaccounts` no grupo de API `core`, e o `userextras` no grupo `authentication.k8s.io` de API. Modos de Autorização[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#authorization-modules) --------------------------------------------------------------------------------------------------------------------------- O servidor da API Kubernetes pode autorizar uma solicitação usando um dos vários modos de autorização: * **Node** - Um modo de autorização de finalidade especial que concede permissões a `kubelets` com base nos `Pods` que estão programados para execução. Para saber mais sobre como utilizar o modo de autorização do nó, consulte [Node Authorization](https://kubernetes.io/docs/reference/access-authn-authz/node/) . * **ABAC** - Attribute-based access control (ABAC), ou Controle de acesso baseado em atributos, define um paradigma de controle de acesso pelo qual os direitos de acesso são concedidos aos usuários por meio do uso de políticas que combinam atributos. As políticas podem usar qualquer tipo de atributo (atributos de usuário, atributos de recurso, objeto, atributos de ambiente, etc.). Para saber mais sobre como usar o modo ABAC, consulte [ABAC Mode](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/abac/) . * **RBAC** - Role-based access control (RBAC), ou controle de acesso baseado em função, é um método de regular o acesso a recursos computacionais ou de rede com base nas funções de usuários individuais dentro de uma empresa. Nesse contexto, acesso é a capacidade de um usuário individual realizar uma tarefa específica, como visualizar, criar ou modificar um arquivo. Para saber mais sobre como usar o modo RBAC, consulte [RBAC Mode](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) * Quando especificado RBAC (Role-Based Access Control) usa o grupo de API `rbac.authorization.k8s.io` para orientar as decisões de autorização, permitindo que os administradores configurem dinamicamente as políticas de permissão por meio da API do Kubernetes. * Para habilitar o modo RBAC, inicie o servidor de API (apiserver) com a opção `--authorization-mode=RBAC`. * **Webhook** - Um WebHook é um retorno de chamada HTTP: um HTTP POST que ocorre quando algo acontece; uma simples notificação de evento via HTTP POST. Um aplicativo da Web que implementa WebHooks postará uma mensagem em um URL quando um determinado evento ocorrer. Para saber mais sobre como usar o modo Webhook, consulte [Webhook Mode](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) . #### Verificando acesso a API[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#verificando-acesso-a-api) `kubectl` fornece o subcomando `auth can-i` para consultar rapidamente a camada de autorização da API. O comando usa a API `SelfSubjectAccessReview` para determinar se o usuário atual pode executar uma determinada ação e funciona independentemente do modo de autorização utilizado. # "can-i create" = "posso criar" kubectl auth can-i create deployments --namespace dev A saída é semelhante a esta: yes # "can-i create" = "posso criar" kubectl auth can-i create deployments --namespace prod A saída é semelhante a esta: no Os administradores podem combinar isso com [personificação de usuário](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authentication/#personifica%C3%A7%C3%A3o-de-usu%C3%A1rio) para determinar qual ação outros usuários podem executar. # "can-i list" = "posso listar" kubectl auth can-i list secrets --namespace dev --as dave A saída é semelhante a esta: no Da mesma forma, para verificar se uma ServiceAccount chamada `dev-sa` no Namespace `dev` pode listar `Pods` no namespace `target`: # "can-i list" = "posso listar" kubectl auth can-i list pods \ --namespace target \ --as system:serviceaccount:dev:dev-sa A saída é semelhante a esta: yes `SelfSubjectAccessReview` faz parte do grupo de API `authorization.k8s.io`, que expõe a autorização do servidor de API para serviços externos. Outros recursos neste grupo inclui: * `SubjectAccessReview` - Revisão de acesso para qualquer usuário, não apenas o atual. Útil para delegar decisões de autorização para o servidor de API. Por exemplo, o `kubelet` e extensões de servidores de API utilizam disso para determinar o acesso do usuário às suas próprias APIs. * `LocalSubjectAccessReview` - Similar a `SubjectAccessReview`, mas restrito a um namespace específico. * `SelfSubjectRulesReview` - Uma revisão que retorna o conjunto de ações que um usuário pode executar em um namespace. Útil para usuários resumirem rapidamente seu próprio acesso ou para interfaces de usuário mostrarem ações. Essas APIs podem ser consultadas criando recursos normais do Kubernetes, onde a resposta no campo `status` do objeto retornado é o resultado da consulta. kubectl create -f - -o yaml << EOF apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview spec: resourceAttributes: group: apps resource: deployments verb: create namespace: dev EOF A `SelfSubjectAccessReview` gerada seria: apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview metadata: creationTimestamp: null spec: resourceAttributes: group: apps resource: deployments namespace: dev verb: create status: allowed: true denied: false Usando flags para seu módulo de autorização[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#usando-flags-para-seu-m%C3%B3dulo-de-autoriza%C3%A7%C3%A3o) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Você deve incluir uma flag em sua política para indicar qual módulo de autorização suas políticas incluem: As seguintes flags podem ser utilizadas: * `--authorization-mode=ABAC` O modo de controle de acesso baseado em atributos (ABAC) permite configurar políticas usando arquivos locais. * `--authorization-mode=RBAC` O modo de controle de acesso baseado em função (RBAC) permite que você crie e armazene políticas usando a API do Kubernetes. * `--authorization-mode=Webhook` WebHook é um modo de retorno de chamada HTTP que permite gerenciar a autorização usando endpoint REST. * `--authorization-mode=Node` A autorização de nó é um modo de autorização de propósito especial que autoriza especificamente requisições de API feitas por `kubelets`. * `--authorization-mode=AlwaysDeny` Esta flag bloqueia todas as requisições. Utilize esta flag somente para testes. * `--authorization-mode=AlwaysAllow` Esta flag permite todas as requisições. Utilize esta flag somente se não existam requisitos de autorização para as requisições de API. Você pode escolher mais de um modulo de autorização. Módulos são verificados em ordem, então, um modulo anterior tem maior prioridade para permitir ou negar uma requisição. Escalonamento de privilégios através da criação ou edição da cargas de trabalho[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#privilege-escalation-via-pod-creation) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Usuários que podem criar ou editar `pods` em um namespace diretamente ou através de um [controlador](https://kubernetes.io/pt-br/docs/concepts/architecture/controller/) como, por exemplo, um operador, conseguiriam escalar seus próprios privilégios naquele namespace. #### Cuidado: Administradores de sistemas, tenham cuidado ao permitir acesso para criar ou editar cargas de trabalho. Detalhes de como estas permissões podem ser usadas de forma maliciosa podem ser encontradas em [caminhos para escalonamento](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#escalation-paths) . ### Caminhos para escalonamento[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#escalation-paths) * Montagem de Secret arbitrários nesse namespace * Pode ser utilizado para acessar Secret destinados a outras cargas de trabalho * Pode ser utilizado para obter um token da conta de serviço com maior privilégio * Uso de contas de serviço arbitrárias nesse namespace * Pode executar ações da API do Kubernetes como outra carga de trabalho (personificação) * Pode executar quaisquer ações privilegiadas que a conta de serviço tenha acesso * Montagem de configmaps destinados a outras cargas de trabalho nesse namespace * Pode ser utilizado para obter informações destinadas a outras cargas de trabalho, como nomes de host de banco de dados. * Montagem de volumes destinados a outras cargas de trabalho nesse namespace * Pode ser utilizado para obter informações destinadas a outras cargas de trabalho e alterá-las. #### Cuidado: Administradores de sistemas devem ser cuidadosos ao instalar CRDs que promovam mudanças nas áreas mencionadas acima. Estes podem abrir caminhos para escalonamento. Isto deve ser considerado ao decidir os controles de acesso baseado em função (RBAC). Próximos passos[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#pr%C3%B3ximos-passos) --------------------------------------------------------------------------------------------------------------------- * Para aprender mais sobre autenticação, visite **Authentication** in [Controlando acesso a APIs do Kubernetes](https://kubernetes.io/pt-br/docs/concepts/security/controlling-access/) . * Para aprender mais sobre Admission Control, visite [Utilizando Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) . Comentários[](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/#feedback) ----------------------------------------------------------------------------------------------------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/pt-br/docs/reference/access-authn-authz/authorization/) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/pt-br/docs/reference/access-authn-authz/authorization/) . Última modificação November 15, 2022 at 10:27 PM PST: [missing kubelet and pods format (ddfbaad0c6)](https://github.com/kubernetes/website/commit/ddfbaad0c6d835b60dde420b52bd5bd9997daf76) --- # Services, Load Balancing, dan Jaringan | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Services, Load Balancing, and Networking](https://kubernetes.io/docs/concepts/services-networking/) Services, Load Balancing, dan Jaringan ====================================== * * * ##### [Service](https://kubernetes.io/id/docs/concepts/services-networking/service/) ##### [Topologi Service (Service Topology)](https://kubernetes.io/id/docs/concepts/services-networking/service-topology/) ##### [EndpointSlice](https://kubernetes.io/id/docs/concepts/services-networking/endpoint-slices/) ##### [DNS untuk Service dan Pod](https://kubernetes.io/id/docs/concepts/services-networking/dns-pod-service/) ##### [Menghubungkan aplikasi dengan Service](https://kubernetes.io/id/docs/concepts/services-networking/connect-applications-service/) ##### [Ingress](https://kubernetes.io/id/docs/concepts/services-networking/ingress/) ##### [Kontroler Ingress](https://kubernetes.io/id/docs/concepts/services-networking/ingress-controllers/) ##### [NetworkPolicy](https://kubernetes.io/id/docs/concepts/services-networking/network-policies/) ##### [Gateway API](https://kubernetes.io/id/docs/concepts/services-networking/gateway/) Gateway API merupakan bagian dari API yang menyediakan penyediaan infrastruktur dinamis dan pengaturan trafik lanjutan. ##### [Menambahkan Entry pada /etc/hosts Pod dengan HostAliases](https://kubernetes.io/id/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/) ##### [Dual-stack IPv4/IPv6](https://kubernetes.io/id/docs/concepts/services-networking/dual-stack/) ##### [\_Topology Aware Routing\_ (Routing yang Mempertimbangkan Topologi)](https://kubernetes.io/id/docs/concepts/services-networking/topology-aware-routing/) _Topology Aware Routing_ (Routing yang Mempertimbangkan Topologi) menyediakan mekanisme untuk membantu menjaga trafik jaringan tetap berada di dalam zona tempat asalnya. Memprioritaskan trafik antar Pod yang berada di zona yang sama dalam klaster kamu dapat membantu meningkatkan keandalan, performa (latensi dan _throughput_ jaringan), serta mengurangi biaya. ##### [Alokasi ClusterIP pada servis (Service ClusterIP allocation)](https://kubernetes.io/id/docs/concepts/services-networking/cluster-ip-allocation/) Masukan[](https://kubernetes.io/id/docs/concepts/services-networking/#feedback) -------------------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/concepts/services-networking/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/concepts/services-networking/) . Last modified April 23, 2019 at 10:30 PM PST: [Translate ingress for Bahasa Indonesia. (#13958) (3c4a42b19d)](https://github.com/kubernetes/website/commit/3c4a42b19d601d513a471781b16811cab749ce2c) --- # 서비스가 지원하는 프로토콜 | Kubernetes 서비스가 지원하는 프로토콜 ============== [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/) 를 구성하여, 쿠버네티스가 지원하는 네트워크 프로토콜 중 하나를 선택할 수 있다. 쿠버네티스는 서비스에 대해 다음의 프로토콜을 지원한다. * [`SCTP`](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-sctp) * [`TCP`](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-tcp) _(기본값)_ * [`UDP`](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-udp) 서비스를 정의할 때, 서비스가 사용할 [애플리케이션 프로토콜](https://kubernetes.io/ko/docs/concepts/services-networking/service/#%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C) 을 지정할 수도 있다. 이 문서에서는 몇 가지 특수 사례에 대해 설명하며, 이들 모두는 일반적으로 전송 프로토콜(transport protocol)로 TCP를 사용한다. * [HTTP](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-http-special) 및 [HTTPS](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-http-special) * [PROXY 프로토콜](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-proxy-special) * 로드밸런서에서의 [TLS](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-tls-special) 터미네이션 지원하는 프로토콜[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-support) ---------------------------------------------------------------------------------------------------- 서비스 포트의 `protocol`에 대해 다음 3개의 값이 유효하다. ### `SCTP`[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-sctp) 기능 상태: `Kubernetes v1.20 [stable]` SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우, 대부분의 서비스에 SCTP를 사용할 수 있다. `type: LoadBalancer` 서비스의 경우 SCTP 지원 여부는 이 기능을 제공하는 클라우드 공급자에 따라 다르다. (대부분 지원하지 않음) SCTP는 윈도우 노드에서는 지원되지 않는다. #### 멀티홈(multihomed) SCTP 연결 지원[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#caveat-sctp-multihomed) 멀티홈 SCTP 연결 지원을 위해서는 CNI 플러그인이 파드에 복수개의 인터페이스 및 IP 주소를 할당하는 기능을 지원해야 한다. 멀티홈 SCTP 연결에서의 NAT는 상응하는 커널 모듈 내의 특수한 로직을 필요로 한다. ### `TCP`[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-tcp) 모든 종류의 서비스에 TCP를 사용할 수 있으며, 이는 기본 네트워크 프로토콜이다. ### `UDP`[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-udp) 대부분의 서비스에 UDP를 사용할 수 있다. `type: LoadBalancer` 서비스의 경우, UDP 지원 여부는 이 기능을 제공하는 클라우드 공급자에 따라 다르다. 특수 케이스[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#%ED%8A%B9%EC%88%98-%EC%BC%80%EC%9D%B4%EC%8A%A4) ------------------------------------------------------------------------------------------------------------------------------- ### HTTP[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-http-special) 클라우드 공급자가 이를 지원하는 경우, LoadBalancer 모드의 서비스를 사용하여, 쿠버네티스 클러스터 외부에, HTTP / HTTPS 리버스 프록싱을 통해 해당 서비스의 백엔드 엔드포인트로 트래픽을 전달하는 로드밸런서를 구성할 수 있다. 일반적으로, 트래픽을 HTTP 수준에서 제어하려면 해당 서비스의 프로토콜을 `TCP`로 지정하고 로드밸런서를 구성하는 [어노테이션](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/annotations) (보통 클라우드 공급자마다 다름)을 추가한다. 이 구성은 워크로드로의 HTTPS (HTTP over TLS) 지원 및 평문 HTTP 리버스 프록시도 포함할 수 있다. #### 참고: 서비스 대신 [인그레스](https://kubernetes.io/ko/docs/concepts/services-networking/ingress/) 를 사용하여 HTTP/HTTPS 서비스를 노출할 수도 있다. 특정 연결의 [애플리케이션 프로토콜](https://kubernetes.io/ko/docs/concepts/services-networking/service/#%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C) 을 `http` 또는 `https`로 추가적으로 명시하고 싶을 수도 있다. 로드밸런서에서 워크로드로 가는 세션이 HTTP without TLS이면 `http`를 사용하고, 로드밸런서에서 워크로드로 가는 세션이 TLS 암호화를 사용하면 `https`를 사용한다. ### PROXY 프로토콜[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-proxy-special) 클라우드 공급자가 지원하는 경우에, `type: LoadBalancer`로 설정된 서비스를 사용하여, 쿠버네티스 외부에 존재하면서 연결들을 [PROXY 프로토콜](https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt) 로 감싸 전달하는 로드밸런서를 구성할 수 있다. 이러한 로드 밸런서는 들어오는 연결을 설명하는 초기 일련의 옥텟(octets)을 전송하며, 이는 다음의 예시(PROXY 프로토콜 v1)와 유사하다. PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n 프록시 프로토콜 프리앰블(preamble) 뒤에 오는 데이터는 클라이언트가 전송한 원본 데이터이다. 양쪽 중 한쪽에서 연결을 닫으면, 로드밸런서도 연결 종료를 트리거하며 남아있는 데이터를 수신 가능한 쪽으로 보낸다. 일반적으로는, 프로토콜을 `TCP`로 설정한 서비스를 정의한다. 또한, 클라우드 공급자별로 상이한 어노테이션을 설정하여 로드밸런서가 각 인커밍 연결을 PROXY 프로토콜로 감싸도록 구성할 수도 있다. ### TLS[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#protocol-tls-special) 클라우드 공급자가 지원하는 경우에, `type: LoadBalancer`로 설정된 서비스를 사용하여, 쿠버네티스 외부에 존재하는 리버스 프록시를 구축할 수 있으며, 이 때 클라이언트로부터 로드밸런서까지의 연결은 TLS 암호화되고 로드밸런서는 TLS 서버 피어가 된다. 로드밸런서로부터 워크로드까지의 연결은 TLS일 수도 있으며, 평문일 수도 있다. 사용 가능한 정확한 옵션의 범위는 클라우드 공급자 또는 커스텀 서비스 구현에 따라 다를 수 있다. 일반적으로는, 프로토콜을 `TCP`로 설정하고 어노테이션(보통 클라우드 공급자별로 상이함)을 설정하여 로드밸런서가 TLS 서버로 작동하도록 구성한다. 클라우드 공급자별로 상이한 메커니즘을 사용하여 TLS 아이덴티티(서버, 그리고 경우에 따라 워크로드로 연결하는 클라이언트도 가능)를 구성할 수도 있다. 피드백[](https://kubernetes.io/ko/docs/reference/networking/service-protocols/#feedback) -------------------------------------------------------------------------------------- 이 페이지가 도움이 되었나요? 네 아니요 피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 원한다면 GitHub 리포지터리에 이슈를 열어서 [문제 리포트](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/ko/docs/reference/networking/service-protocols/) 또는 [개선 제안이 가능합니다.](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/ko/docs/reference/networking/service-protocols/) . 최종 수정 February 02, 2023 at 5:53 PM PST: [\[ko\] Update outdated files in dev-1.26-ko.1 M67 (5c6199cb0c)](https://github.com/kubernetes/website/commit/5c6199cb0c869d4a5e396c516f021af2cd25134a) --- # Connecting Applications with Services | Kubernetes Connecting Applications with Services ===================================== The Kubernetes model for connecting containers[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#the-kubernetes-model-for-connecting-containers) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Now that you have a continuously running, replicated application you can expose it on a network. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model. This tutorial uses a simple nginx web server to demonstrate the concept. Exposing pods to the cluster[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#exposing-pods-to-the-cluster) -------------------------------------------------------------------------------------------------------------------------------------------------- We did this in a previous example, but let's do it once again and focus on the networking perspective. Create an nginx Pod, and note that it has a container port specification: [`service/networking/run-my-nginx.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/run-my-nginx.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/run-my-nginx.yaml to clipboard") apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: selector: matchLabels: run: my-nginx replicas: 2 template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 80 This makes it accessible from any node in your cluster. Check the nodes the Pod is running on: kubectl apply -f ./run-my-nginx.yaml kubectl get pods -l run=my-nginx -o wide NAME READY STATUS RESTARTS AGE IP NODE my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd Check your pods' IPs: kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs POD_IP [map[ip:10.244.3.4]] [map[ip:10.244.2.5]] You should be able to ssh into any node in your cluster and use a tool such as `curl` to make queries against both IPs. Note that the containers are _not_ using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same `containerPort`, and access them from any other pod or node in your cluster using the assigned IP address for the pod. If you want to arrange for a specific port on the host Node to be forwarded to backing Pods, you can - but the networking model should mean that you do not need to do so. You can read more about the [Kubernetes Networking Model](https://kubernetes.io/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) if you're curious. Creating a Service[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#creating-a-service) ------------------------------------------------------------------------------------------------------------------------------ So we have pods running nginx in a flat, cluster wide, address space. In theory, you could talk to these pods directly, but what happens when a node dies? The pods die with it, and the ReplicaSet inside the Deployment will create new ones, with different IPs. This is the problem a Service solves. A Kubernetes Service is an abstraction which defines a logical set of Pods running somewhere in your cluster, that all provide the same functionality. When created, each Service is assigned a unique IP address (also called clusterIP). This address is tied to the lifespan of the Service, and will not change while the Service is alive. Pods can be configured to talk to the Service, and know that communication to the Service will be automatically load-balanced out to some pod that is a member of the Service. You can create a Service for your 2 nginx replicas with `kubectl expose`: kubectl expose deployment/my-nginx service/my-nginx exposed This is equivalent to `kubectl apply -f` in the following yaml: [`service/networking/nginx-svc.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/nginx-svc.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/nginx-svc.yaml to clipboard") apiVersion: v1 kind: Service metadata: name: my-nginx labels: run: my-nginx spec: ports: - port: 80 protocol: TCP selector: run: my-nginx This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [Service](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#service-v1-core) API object to see the list of supported fields in service definition. Check your Service: kubectl get svc my-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx ClusterIP 10.0.162.149 80/TCP 21s As mentioned previously, a Service is backed by a group of Pods. These Pods are exposed through [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) . The Service's selector will be evaluated continuously and the results will be POSTed to an EndpointSlice that is connected to the Service using [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels) . When a Pod dies, it is automatically removed from the EndpointSlices that contain it as an endpoint. New Pods that match the Service's selector will automatically get added to an EndpointSlice for that Service. Check the endpoints, and note that the IPs are the same as the Pods created in the first step: kubectl describe svc my-nginx Name: my-nginx Namespace: default Labels: run=my-nginx Annotations: Selector: run=my-nginx Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.0.162.149 IPs: 10.0.162.149 Port: 80/TCP TargetPort: 80/TCP Endpoints: 10.244.2.5:80,10.244.3.4:80 Session Affinity: None Events: kubectl get endpointslices -l kubernetes.io/service-name=my-nginx NAME ADDRESSTYPE PORTS ENDPOINTS AGE my-nginx-7vzhx IPv4 80 10.244.2.5,10.244.3.4 21s You should now be able to curl the nginx Service on `:` from any node in your cluster. Note that the Service IP is completely virtual, it never hits the wire. If you're curious about how this works you can read more about the [service proxy](https://kubernetes.io/docs/reference/networking/virtual-ips/) . Accessing the Service[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#accessing-the-service) ------------------------------------------------------------------------------------------------------------------------------------ Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the [CoreDNS cluster addon](https://releases.k8s.io/v1.35.0/cluster/addons/dns/coredns) . #### Note: If the service environment variables are not desired (because possible clashing with expected program ones, too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks` flag to `false` on the [pod spec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#pod-v1-core) . ### Environment Variables[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#environment-variables) When a Pod runs on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx Pods (your Pod name will be different): kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE KUBERNETES_SERVICE_HOST=10.0.0.1 KUBERNETES_SERVICE_PORT=443 KUBERNETES_SERVICE_PORT_HTTPS=443 Note there's no mention of your Service. This is because you created the replicas before the Service. Another disadvantage of doing this is that the scheduler might put both Pods on the same machine, which will take your entire Service down if it dies. We can do this the right way by killing the 2 Pods and waiting for the Deployment to recreate them. This time the Service exists _before_ the replicas. This will give you scheduler-level Service spreading of your Pods (provided all your nodes have equal capacity), as well as the right environment variables: kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2; kubectl get pods -l run=my-nginx -o wide NAME READY STATUS RESTARTS AGE IP NODE my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m You may notice that the pods have different names, since they are killed and recreated. kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE KUBERNETES_SERVICE_PORT=443 MY_NGINX_SERVICE_HOST=10.0.162.149 KUBERNETES_SERVICE_HOST=10.0.0.1 MY_NGINX_SERVICE_PORT=80 KUBERNETES_SERVICE_PORT_HTTPS=443 ### DNS[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#dns) Kubernetes offers a DNS cluster addon Service that automatically assigns dns names to other Services. You can check if it's running on your cluster: kubectl get services kube-dns --namespace=kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m The rest of this section will assume you have a Service with a long lived IP (my-nginx), and a DNS server that has assigned a name to that IP. Here we use the CoreDNS cluster addon (application name `kube-dns`), so you can talk to the Service from any pod in your cluster using standard methods (e.g. `gethostbyname()`). If CoreDNS isn't running, you can enable it referring to the [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) or [Installing CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/#installing-coredns) . Let's run another curl application to test this: kubectl run curl --image=radial/busyboxplus:curl -i --tty --rm Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false Hit enter for command prompt Then, hit enter and run `nslookup my-nginx`: [ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx Server: 10.0.0.10 Address 1: 10.0.0.10 Name: my-nginx Address 1: 10.0.162.149 Securing the Service[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#securing-the-service) ---------------------------------------------------------------------------------------------------------------------------------- Till now we have only accessed the nginx server from within the cluster. Before exposing the Service to the internet, you want to make sure the communication channel is secure. For this, you will need: * Self signed certificates for https (unless you already have an identity certificate) * An nginx server configured to use the certificates * A [secret](https://kubernetes.io/docs/concepts/configuration/secret/) that makes the certificates accessible to pods You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/master/_archived/https-nginx/) . This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short: make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt secret/nginxsecret created kubectl get secrets NAME TYPE DATA AGE nginxsecret kubernetes.io/tls 2 1m And also the configmap: kubectl create configmap nginxconfigmap --from-file=default.conf You can find an example for `default.conf` in [the Kubernetes examples project repo](https://github.com/kubernetes/examples/tree/bc9ca4ca32bb28762ef216386934bef20f1f9930/staging/https-nginx/) . configmap/nginxconfigmap created kubectl get configmaps NAME DATA AGE nginxconfigmap 1 114s You can view the details of the `nginxconfigmap` ConfigMap using the following command: kubectl describe configmap nginxconfigmap The output is similar to: Name: nginxconfigmap Namespace: default Labels: Annotations: Data ==== default.conf: ---- server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; listen 443 ssl; root /usr/share/nginx/html; index index.html; server_name localhost; ssl_certificate /etc/nginx/ssl/tls.crt; ssl_certificate_key /etc/nginx/ssl/tls.key; location / { try_files $uri $uri/ =404; } } BinaryData ==== Events: Following are the manual steps to follow in case you run into problems running make (on windows for example): # Create a public private key pair openssl req -x509 -noenc -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx" # Convert the keys to base64 encoding cat /d/tmp/nginx.crt | base64 cat /d/tmp/nginx.key | base64 Use the output from the previous commands to create a yaml file as follows. The base64 encoded value should all be on a single line. apiVersion: "v1" kind: "Secret" metadata: name: "nginxsecret" namespace: "default" type: kubernetes.io/tls data: # NOTE: Replace the following values with your own base64-encoded certificate and key. tls.crt: "REPLACE_WITH_BASE64_CERT" tls.key: "REPLACE_WITH_BASE64_KEY" Now create the secrets using the file: kubectl apply -f nginxsecrets.yaml kubectl get secrets NAME TYPE DATA AGE nginxsecret kubernetes.io/tls 2 1m Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443): [`service/networking/nginx-secure-app.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/nginx-secure-app.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/nginx-secure-app.yaml to clipboard") apiVersion: v1 kind: Service metadata: name: my-nginx labels: run: my-nginx spec: type: NodePort ports: - port: 8080 targetPort: 80 protocol: TCP name: http - port: 443 protocol: TCP name: https selector: run: my-nginx --- apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: selector: matchLabels: run: my-nginx replicas: 1 template: metadata: labels: run: my-nginx spec: volumes: - name: secret-volume secret: secretName: nginxsecret - name: configmap-volume configMap: name: nginxconfigmap containers: - name: nginxhttps image: bprashanth/nginxhttps:1.0 ports: - containerPort: 443 - containerPort: 80 volumeMounts: - mountPath: /etc/nginx/ssl name: secret-volume - mountPath: /etc/nginx/conf.d name: configmap-volume Noteworthy points about the nginx-secure-app manifest: * It contains both Deployment and Service specification in the same file. * The [nginx server](https://github.com/kubernetes/examples/blob/master/_archived/https-nginx/default.conf) serves HTTP traffic on port 80 and HTTPS traffic on 443, and nginx Service exposes both ports. * Each container has access to the keys through a volume mounted at `/etc/nginx/ssl`. This is set up _before_ the nginx server is started. kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml At this point you can reach the nginx server from any node. kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs POD_IP [map[ip:10.244.3.5]] node $ curl -k https://10.244.3.5 ...

Welcome to nginx!

Note how we supplied the `-k` parameter to curl in the last step, this is because we don't know anything about the pods running nginx at certificate generation time, so we have to tell curl to ignore the CName mismatch. By creating a Service we linked the CName used in the certificate with the actual DNS name used by pods during Service lookup. Let's test this from a pod (the same secret is being reused for simplicity, the pod only needs nginx.crt to access the Service): [`service/networking/curlpod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/curlpod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/curlpod.yaml to clipboard") apiVersion: apps/v1 kind: Deployment metadata: name: curl-deployment spec: selector: matchLabels: app: curlpod replicas: 1 template: metadata: labels: app: curlpod spec: volumes: - name: secret-volume secret: secretName: nginxsecret containers: - name: curlpod command: - sh - -c - while true; do sleep 1; done image: radial/busyboxplus:curl volumeMounts: - mountPath: /etc/nginx/ssl name: secret-volume kubectl apply -f ./curlpod.yaml kubectl get pods -l app=curlpod NAME READY STATUS RESTARTS AGE curl-deployment-1515033274-1410r 1/1 Running 0 1m kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt ... Welcome to nginx! ... Exposing the Service[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#exposing-the-service) ---------------------------------------------------------------------------------------------------------------------------------- For some parts of your applications you may want to expose a Service onto an external IP address. Kubernetes supports two ways of doing this: NodePorts and LoadBalancers. The Service created in the last section already used `NodePort`, so your nginx HTTPS replica is ready to serve traffic on the internet if your node has a public IP. kubectl get svc my-nginx -o yaml | grep nodePort -C 5 uid: 07191fb3-f61a-11e5-8ae5-42010af00002 spec: clusterIP: 10.0.162.149 ports: - name: http nodePort: 31704 port: 8080 protocol: TCP targetPort: 80 - name: https nodePort: 32453 port: 443 protocol: TCP targetPort: 443 selector: run: my-nginx kubectl get nodes -o yaml | grep ExternalIP -C 1 - address: 104.197.41.11 type: ExternalIP allocatable: -- - address: 23.251.152.56 type: ExternalIP allocatable: ... $ curl https://: -k ...

Welcome to nginx!

Let's now recreate the Service to use a cloud load balancer. Change the `Type` of `my-nginx` Service from `NodePort` to `LoadBalancer`: kubectl edit svc my-nginx kubectl get svc my-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s curl https:// -k ... Welcome to nginx! The IP address in the `EXTERNAL-IP` column is the one that is available on the public internet. The `CLUSTER-IP` is only available inside your cluster/private cloud network. Note that on AWS, type `LoadBalancer` creates an ELB, which uses a (long) hostname, not an IP. It's too long to fit in the standard `kubectl get svc` output, in fact, so you'll need to do `kubectl describe service my-nginx` to see it. You'll see something like this: kubectl describe service my-nginx ... LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com ... What's next[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#what-s-next) ---------------------------------------------------------------------------------------------------------------- * Learn more about [Using a Service to Access an Application in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/) * Learn more about [Connecting a Front End to a Back End Using a Service](https://kubernetes.io/docs/tasks/access-application-cluster/connecting-frontend-backend/) * Learn more about [Creating an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) Feedback[](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service#feedback) ---------------------------------------------------------------------------------------------------------- Was this page helpful? Yes No Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the [GitHub Repository](https://www.github.com/kubernetes/website/) if you want to [report a problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/docs/tutorials/services/connect-applications-service/) or [suggest an improvement](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/docs/tutorials/services/connect-applications-service/) . Last modified February 03, 2026 at 9:34 PM PST: [Fix typo in OpenSSL command for key generation (cf2028f053)](https://github.com/kubernetes/website/commit/cf2028f0539e4e8094f7187e20f6ea4e4a1a36cb) --- # VolumeSnapshotClass | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Volume Snapshot Classes](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/) VolumeSnapshotClass =================== Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan, sangat disarankan untuk membaca [_snapshot_ volume](https://kubernetes.io/id/docs/concepts/storage/volume-snapshots/) dan [kelas penyimpanan (_storage class_)](https://kubernetes.io/id/docs/concepts/storage/storage-classes) terlebih dahulu. Pengenalan[](https://kubernetes.io/id/docs/concepts/storage/volume-snapshot-classes/#pengenalan) ------------------------------------------------------------------------------------------------- Seperti halnya StorageClass yang menyediakan cara bagi admin untuk mendefinisikan "kelas" penyimpanan yang mereka tawarkan saat proses penyediaan sebuah volume, VolumeSnapshotClass menyediakan cara untuk mendefinisikan "kelas" penyimpanan saat menyediakan _snapshot_ volume. Sumber Daya VolumeSnapshotClass[](https://kubernetes.io/id/docs/concepts/storage/volume-snapshot-classes/#sumber-daya-volumesnapshotclass) ------------------------------------------------------------------------------------------------------------------------------------------- Masing-masing VolumeSnapshotClass terdiri dari _field_ `snapshotter` dan `parameters`, yang digunakan saat sebuah VolumeSnapshot yang dimiliki kelas tersebut perlu untuk disediakan secara dinamis. Nama yang dimiliki suatu objek VolumeSnapshotClass sangatlah penting, karena digunakan oleh pengguna saat meminta sebuah kelas tertentu. Admin dapat mengatur nama dan parameter lainnya dari sebuah kelas saat pertama kali membuat objek VolumeSnapshotClass. Objek tidak dapat diubah setelah dibuat. Admin dapat mengatur VolumeSnapshotClass _default_ untuk VolumeSnapshot yang tidak memiliki spesifikasi kelas apapun. apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass snapshotter: csi-hostpath parameters: ### `snapshotter`[](https://kubernetes.io/id/docs/concepts/storage/volume-snapshot-classes/#snapshotter) VolumeSnapshotClass memiliki sebuah `snapshotter` yang menentukan plugin volume CSI apa yang digunakan untuk penyediaan VolumeSnapshot. _Field_ ini wajib diatur. ### `parameters`[](https://kubernetes.io/id/docs/concepts/storage/volume-snapshot-classes/#parameters) VolumeSnapshotClass memiliki parameter-parameter yang menggambarkan _snapshot_ volume di dalam VolumeSnapshotClass. Parameter-parameter yang berbeda diperbolehkan tergantung dari `shapshotter`. Masukan[](https://kubernetes.io/id/docs/concepts/storage/volume-snapshot-classes/#feedback) -------------------------------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/concepts/storage/volume-snapshot-classes/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/concepts/storage/volume-snapshot-classes/) . Last modified July 10, 2020 at 10:24 PM PST: [Replace EN links to ID links (0c799ef757)](https://github.com/kubernetes/website/commit/0c799ef757368c8839a912df5d949fa2603042f5) --- # 进程 ID 约束与预留 | Kubernetes 进程 ID 约束与预留 =========== 特性状态： `Kubernetes v1.20 [stable]` Kubernetes 允许你限制一个 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/) 中可以使用的进程 ID（PID）数目。 你也可以为每个[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 预留一定数量的可分配的 PID， 供操作系统和守护进程（而非 Pod）使用。 进程 ID（PID）是节点上的一种基础资源。很容易就会在尚未超出其它资源约束的时候就已经触及任务个数上限， 进而导致宿主机器不稳定。 集群管理员需要一定的机制来确保集群中运行的 Pod 不会导致 PID 资源枯竭， 甚而造成宿主机上的守护进程（例如 [kubelet](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet) 或者 [kube-proxy](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) 乃至包括容器运行时本身）无法正常运行。 此外，确保 Pod 中 PID 的个数受限对于保证其不会影响到同一节点上其它负载也很重要。 #### 说明： 在某些 Linux 安装环境中，操作系统会将 PID 约束设置为一个较低的默认值，例如 `32768`。这时可以考虑提升 `/proc/sys/kernel/pid_max` 的设置值。 你可以配置 kubelet 限制给定 Pod 能够使用的 PID 个数。 例如，如果你的节点上的宿主操作系统被设置为最多可使用 `262144` 个 PID， 同时预期节点上会运行的 Pod 个数不会超过 `250`，那么你可以为每个 Pod 设置 `1000` 个 PID 的预算，避免耗尽该节点上可用 PID 的总量。 如果管理员系统像 CPU 或内存那样允许对 PID 进行过量分配（Overcommit），他们也可以这样做， 只是会有一些额外的风险。不管怎样，任何一个 Pod 都不可以将整个机器的运行状态破坏。 这类资源限制有助于避免简单的派生炸弹（Fork Bomb）影响到整个集群的运行。 在 Pod 级别设置 PID 限制使得管理员能够保护 Pod 之间不会互相伤害， 不过无法确保所有调度到该宿主机器上的所有 Pod 都不会影响到节点整体。 Pod 级别的限制也无法保护节点代理任务自身不会受到 PID 耗尽的影响。 你也可以预留一定量的 PID，作为节点的额外开销，与分配给 Pod 的 PID 集合独立。 这有点类似于在给操作系统和其它设施预留 CPU、内存或其它资源时所做的操作， 这些任务都在 Pod 及其所包含的容器之外运行。 PID 限制是与[计算资源](https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/) 请求和限制相辅相成的一种机制。不过，你需要用一种不同的方式来设置这一限制： 你需要将其设置到 kubelet 上而不是在 Pod 的 `.spec` 中为 Pod 设置资源限制。 目前还不支持在 Pod 级别设置 PID 限制。 #### 注意： 这意味着，施加在 Pod 之上的限制值可能因为 Pod 运行所在的节点不同而有差别。 为了简化系统，最简单的方法是为所有节点设置相同的 PID 资源限制和预留值。 节点级别 PID 限制[](https://kubernetes.io/zh-cn/docs/concepts/policy/pid-limiting/#node-pid-limits) ---------------------------------------------------------------------------------------------- Kubernetes 允许你为系统预留一定量的进程 ID。为了配置预留数量，你可以使用 kubelet 的 `--system-reserved` 和 `--kube-reserved` 命令行选项中的参数 `pid=`。你所设置的参数值分别用来声明为整个系统和 Kubernetes 系统守护进程所保留的进程 ID 数目。 Pod 级别 PID 限制[](https://kubernetes.io/zh-cn/docs/concepts/policy/pid-limiting/#pod-pid-limits) ----------------------------------------------------------------------------------------------- Kubernetes 允许你限制 Pod 中运行的进程个数。你可以在节点级别设置这一限制， 而不是为特定的 Pod 来将其设置为资源限制。每个节点都可以有不同的 PID 限制设置。 要设置限制值，你可以设置 kubelet 的命令行参数 `--pod-max-pids`，或者在 kubelet 的[配置文件](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 中设置 `PodPidsLimit`。 基于 PID 的驱逐[](https://kubernetes.io/zh-cn/docs/concepts/policy/pid-limiting/#pid-based-eviction) ------------------------------------------------------------------------------------------------ 你可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。这一特性称作驱逐。 你可以针对不同的驱逐信号[配置资源不足的处理](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/) 。 使用 `pid.available` 驱逐信号来配置 Pod 使用的 PID 个数的阈值。 你可以设置硬性的和软性的驱逐策略。不过，即使使用硬性的驱逐策略， 如果 PID 个数增长过快，节点仍然可能因为触及节点 PID 限制而进入一种不稳定状态。 驱逐信号的取值是周期性计算的，而不是一直能够强制实施约束。 Pod 级别和节点级别的 PID 限制会设置硬性限制。 一旦触及限制值，工作负载会在尝试获得新的 PID 时开始遇到问题。 这可能会也可能不会导致 Pod 被重新调度，取决于工作负载如何应对这类失败以及 Pod 的存活性和就绪态探测是如何配置的。 可是，如果限制值被正确设置，你可以确保其它 Pod 负载和系统进程不会因为某个 Pod 行为不正常而没有 PID 可用。 接下来[](https://kubernetes.io/zh-cn/docs/concepts/policy/pid-limiting/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) -------------------------------------------------------------------------------------------------- * 参阅 [PID 约束改进文档](https://github.com/kubernetes/enhancements/blob/097b4d8276bc9564e56adf72505d43ce9bc5e9e8/keps/sig-node/20190129-pid-limiting.md) 以了解更多信息。 * 关于历史背景，请阅读 [Kubernetes 1.14 中限制进程 ID 以提升稳定性](https://kubernetes.io/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/) 的博文。 * 请阅读[为容器管理资源](https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/) 。 * 学习如何[配置资源不足情况的处理](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/) 。 反馈[](https://kubernetes.io/zh-cn/docs/concepts/policy/pid-limiting/#feedback) ------------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/policy/pid-limiting/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/policy/pid-limiting/) . 最后修改 December 24, 2024 at 8:47 PM PST: [\[zh-cn\]sync device-plugins pid-limiting (9d14a75378)](https://github.com/kubernetes/website/commit/9d14a75378ab23b263fbbe654106419a95d46b77) --- # Keamanan | Kubernetes Keamanan ======== Konsep-konsep untuk menjaga _cloud-native workload_ tetap aman. Bagian dokumentasi Kubernetes ini memiliki tujuan untuk membantu anda menjalankan _workloads_ lebih aman, dan aspek-aspek mendasar dalam menjaga klaster Kubernetes tetap aman. Kubernetes berbasiskan arsitektur _cloud-native_ dan mengambil saran dari [CNCF](https://cncf.io/) mengenai praktik yang baik dari _cloud native information security_. Baca [Cloud Native Security and Kubernetes](https://kubernetes.io/id/docs/concepts/security/cloud-native-security/) untuk konteks yang lebih luas mengenai bagaimana cara mengamankan klaster anda dan aplikasi yang berjalan di atasnya. Mekanisme keamanan Kubernetes[](https://kubernetes.io/id/docs/concepts/security/#security-mechanisms) ------------------------------------------------------------------------------------------------------ ### Proteksi _control plane_[](https://kubernetes.io/id/docs/concepts/security/#proteksi-control-plane) Kunci penting pada apapun varian klaster Kubernetes adalah [kontrol akses ke Kubernetes API](https://kubernetes.io/docs/concepts/security/controlling-access) . Kubernetes menyarankan anda untuk mengkonfigurasi dan menggunakan TLS dalam menyediakan [enkripsi data saat transit](https://kubernetes.io/id/docs/tasks/tls/managing-tls-in-a-cluster/) di dalam _control plane_, dan di antara _control plane_ dengan _client_. Anda juga bisa mengaktifkan [encryption at rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) untuk data yang tersimpan di dalam Kubernetes control plane; hal ini terpisah dari menggunanakan _encryption at rest_ untuk data anda di workload. ### Secrets[](https://kubernetes.io/id/docs/concepts/security/#secrets) [Secret](https://kubernetes.io/id/docs/concepts/configuration/secret/) API menyediakan perlindungan dasar untuk variabel konfigurasi yang konfidensial. ### Perlindungan Workload[](https://kubernetes.io/id/docs/concepts/security/#perlindungan-workload) Terapkan [Pod security standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) untuk memastikan Pods dan containers terisolasi dengan baik. Anda juga dapat menggunakan [RuntimeClasses](https://kubernetes.io/id/docs/concepts/containers/runtime-class/) untuk mendefinisikan isolasi _custom_ jika dibutuhkan. [Network policies](https://kubernetes.io/id/docs/concepts/services-networking/network-policies/) memungkinkan anda mengendalikan trafik jaringan di antara Pods, atau antara Pods dengan jaringan di luar klaster. Anda dapat men-deploy security controls dari ekosistem yang lebih besar untuk mengimplementasikan kontrol pencegahan atau pendeteksian di sekitar Pods, kontainer dan images yang berjalan. ### Audit[](https://kubernetes.io/id/docs/concepts/security/#audit) Kubernetes [audit logging](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) menyediakan sebuah set catatan yang berurutan terkait dengan keamanan, mendokumentasikan urutan aktivitas dalam suatu cluster. Aktivitas _cluster audit_ dihasilkan oleh pengguna, aplikasi yang menggunakan Kubernetes API dan control plane. Keamanan penyedia cloud[](https://kubernetes.io/id/docs/concepts/security/#keamanan-penyedia-cloud) ---------------------------------------------------------------------------------------------------- **Catatan:** Items on this page refer to vendors external to Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. To add a vendor, product or project to this list, read the [content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) before submitting a change. [More information.](https://kubernetes.io/id/docs/concepts/security/#third-party-content-disclaimer) Jika anda menjalankan klaster Kubernetes pada perangkat keras anda sendiri atau pada penyedia layanan komputasi awan, silakan kunjungi halaman dokumentasi untuk melihat saran/tips dalam keamanan. Berikut ini beberapa tautan ke halaman dokumentasi keamanan dari beberapa penyedia jasa komputasi awan: | | | | --- | --- |Keamanan cloud provider | Penyedia IaaS | Tautan | | --- | --- | | Alibaba Cloud | [https://www.alibabacloud.com/trust-center](https://www.alibabacloud.com/trust-center) | | Amazon Web Services | [https://aws.amazon.com/security](https://aws.amazon.com/security) | | Google Cloud Platform | [https://cloud.google.com/security](https://cloud.google.com/security) | | Huawei Cloud | [https://www.huaweicloud.com/intl/en-us/securecenter/overallsafety](https://www.huaweicloud.com/intl/en-us/securecenter/overallsafety) | | IBM Cloud | [https://www.ibm.com/cloud/security](https://www.ibm.com/cloud/security) | | Microsoft Azure | [https://docs.microsoft.com/en-us/azure/security/azure-security](https://docs.microsoft.com/en-us/azure/security/azure-security) | | Oracle Cloud Infrastructure | [https://www.oracle.com/security](https://www.oracle.com/security) | | Tencent Cloud | [https://www.tencentcloud.com/solutions/data-security-and-information-protection](https://www.tencentcloud.com/solutions/data-security-and-information-protection) | | VMware vSphere | [https://www.vmware.com/solutions/security/hardening-guides](https://www.vmware.com/solutions/security/hardening-guides) | Policies[](https://kubernetes.io/id/docs/concepts/security/#policies) ---------------------------------------------------------------------- Anda dapat mendefinisikan _security policies_ menggunakan mekanisme _Kubernetes-native_ seperti [NetworkPolicy](https://kubernetes.io/id/docs/concepts/services-networking/network-policies/) (kontrol deklaratif atas network packet filtering) atau [ValidatingAdmissionPolicy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) (larangan deklaratif atas perubahan apa yang bisa dibuat seseorang menggunakan Kubernetes API). Bagaimanapun juga, anda dapat mengandalkan dari implementasi _policy_ dari ekosistem yang lebih besar di sekitar Kubernetes. Kubernetes menyediakan mekanisme ekstensi untuk membiarkan ekosistem proyek tersebut mengimplementasikan _policy controls_ mereka pada peninjauan kode sumber, persetujuan image container, akses kontrol API, jaringan dan lain-lain. Untuk informasi lebih lanjut mengenai mekanisme _policy_ dan Kubernetes, silakan baca [Policies](https://kubernetes.io/id/docs/concepts/policy/) . Selanjutnya[](https://kubernetes.io/id/docs/concepts/security/#selanjutnya) ---------------------------------------------------------------------------- Pelajari lebih lanjut topik terkait keamanan Kubernetes: * [Securing your cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) * [Known vulnerabilities](https://kubernetes.io/id/docs/reference/issues-security/official-cve-feed/) in Kubernetes (dan tautan untuk informasi lebih lanjut) * [Data encryption in transit](https://kubernetes.io/id/docs/tasks/tls/managing-tls-in-a-cluster/) untuk _control plane_ * [Data encryption at rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) * [Controlling Access to the Kubernetes API](https://kubernetes.io/docs/concepts/security/controlling-access) * [Network policies](https://kubernetes.io/id/docs/concepts/services-networking/network-policies/) untuk Pods * [Secrets in Kubernetes](https://kubernetes.io/id/docs/concepts/configuration/secret/) * [Pod security standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [RuntimeClasses](https://kubernetes.io/id/docs/concepts/containers/runtime-class/) Pelajari konteks: * [Cloud Native Security and Kubernetes](https://kubernetes.io/id/docs/concepts/security/cloud-native-security/) Ambil sertifikasi: * [Certified Kubernetes Security Specialist](https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/) sertifikasi dan kursus pelatihan resmi. Baca lebih lanjut dalam bagian ini: * [Ikhtisar Keamanan Cloud Native](https://kubernetes.io/id/docs/concepts/security/overview/) * [Panduan Pengamanan - Mekanisme Autentikasi](https://kubernetes.io/id/docs/concepts/security/hardening-guide/authentication-mechanisms/) * [Daftar Periksa Keamanan](https://kubernetes.io/id/docs/concepts/security/security-checklist/) * [Daftar Keamanan Aplikasi](https://kubernetes.io/id/docs/concepts/security/application-security-checklist/) Masukan[](https://kubernetes.io/id/docs/concepts/security/#feedback) --------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/concepts/security/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/concepts/security/) . Last modified March 17, 2025 at 2:57 PM PST: [ID: small fixes including typos (0a4ce0a514)](https://github.com/kubernetes/website/commit/0a4ce0a5143972883fd3d4d3e6ce309201eb148e) Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the [CNCF website guidelines](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) for more details. You should read the [content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) before proposing a change that adds an extra third-party link. --- # Addons Installieren | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Installing Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) Addons Installieren =================== Add-Ons erweitern die Funktionalität von Kubernetes. Diese Seite gibt eine Übersicht über einige verfügbare Add-Ons und verweist auf die entsprechenden Installationsanleitungen. Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenfolge impliziert keine bevorzugung einzelner Projekte. Networking und Network Policy[](https://kubernetes.io/de/docs/concepts/cluster-administration/addons/#networking-und-network-policy) ------------------------------------------------------------------------------------------------------------------------------------- * [ACI](https://www.github.com/noironetworks/aci-containers) bietet Container-Networking und Network-Security mit Cisco ACI. * [Calico](https://docs.projectcalico.org/latest/introduction/) ist ein Networking- und Network-Policy-Provider. Calico unterstützt eine Reihe von Networking-Optionen, damit Du die richtige für deinen Use-Case wählen kannst. Dies beinhaltet Non-Overlaying and Overlaying-Networks mit oder ohne BGP. Calico nutzt die gleiche Engine um Network-Policies für Hosts, Pods und (falls Du Istio & Envoy benutzt) Anwendungen auf Service-Mesh-Ebene durchzusetzen. * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) vereint Flannel und Calico um Networking- und Network-Policies bereitzustellen. * [Cilium](https://github.com/cilium/cilium) ist ein L3 Network- and Network-Policy-Plugin welches das transparent HTTP/API/L7-Policies durchsetzen kann. Sowohl Routing- als auch Overlay/Encapsulation-Modes werden uterstützt. Außerdem kann Cilium auf andere CNI-Plugins aufsetzen. * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave. * [Contiv](https://contivpp.io/) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv) . Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) , basierend auf [Tungsten Fabric](https://tungsten.io/) , ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann. * [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht. * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) ist eine SDN-Plattform die Policy-Basiertes Networking zwischen Kubernetes Pods und nicht-Kubernetes Umgebungen inklusive Sichtbarkeit und Security-Monitoring bereitstellt. * [Romana](https://github.com/romana/romana) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](https://kubernetes.io/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar. * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) bietet Networking and Network-Policies und arbeitet auf beiden Seiten der Network-Partition ohne auf eine externe Datenbank angwiesen zu sein. Service-Discovery[](https://kubernetes.io/de/docs/concepts/cluster-administration/addons/#service-discovery) ------------------------------------------------------------------------------------------------------------- * [CoreDNS](https://coredns.io/) ist ein flexibler, erweiterbarer DNS-Server der in einem Cluster [installiert](https://github.com/coredns/helm) werden kann und das Cluster-interne DNS für Pods bereitzustellen. Visualisierung & Überwachung[](https://kubernetes.io/de/docs/concepts/cluster-administration/addons/#visualisierung-amp-%C3%BCberwachung) ------------------------------------------------------------------------------------------------------------------------------------------ * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) ist ein Dashboard Web Interface für Kubernetes. Infrastruktur[](https://kubernetes.io/de/docs/concepts/cluster-administration/addons/#infrastruktur) ----------------------------------------------------------------------------------------------------- * [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) ist ein Add-On um Virtuelle Maschinen in Kubernetes auszuführen. Wird typischer auf Bare-Metal Clustern eingesetzt. Legacy Add-Ons[](https://kubernetes.io/de/docs/concepts/cluster-administration/addons/#legacy-add-ons) ------------------------------------------------------------------------------------------------------- Es gibt einige weitere Add-Ons die in dem abgekündigten [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) \-Verzeichnis dokumentiert sind. Add-Ons die ordentlich gewartet werden dürfen gerne hier aufgezählt werden. Wir freuen uns auf PRs! Feedback[](https://kubernetes.io/de/docs/concepts/cluster-administration/addons/#feedback) ------------------------------------------------------------------------------------------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/de/docs/concepts/cluster-administration/addons/) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/de/docs/concepts/cluster-administration/addons/) . Zuletzt geändert February 16, 2025 at 1:50 AM PST: [\[de\] Fixed link for core dns helm charts (06a7e77db8)](https://github.com/kubernetes/website/commit/06a7e77db878f0ac4d4954192826402616ea46c4) --- # Supervisión del Estado del Volumen | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Volume Health Monitoring](https://kubernetes.io/docs/concepts/storage/volume-health-monitoring/) Supervisión del Estado del Volumen ================================== FEATURE STATE: `Kubernetes v1.21 [alpha]` La supervisión del estado del volumen de [CSI](https://kubernetes.io/es/docs/concepts/storage/volumes/#csi) permite que los controladores de CSI detecten condiciones de volumen anómalas de los sistemas de almacenamiento subyacentes y las notifiquen como eventos en [PVCs](https://kubernetes.io/es/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) o [Pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/) . Supervisión del Estado del Volumen[](https://kubernetes.io/es/docs/concepts/storage/volume-health-monitoring/#supervisi%C3%B3n-del-estado-del-volumen) ------------------------------------------------------------------------------------------------------------------------------------------------------- El _monitoreo del estado del volumen_ de Kubernetes es parte de cómo Kubernetes implementa la Interfaz de Almacenamiento de Contenedores (CSI). La función de supervisión del estado del volumen se implementa en dos componentes: un controlador de supervisión del estado externo y [Kubelet](https://kubernetes.io/es/docs/reference/generated/kubelet) . Si un controlador CSI admite la función supervisión del estado del volumen desde el lado del controlador, se informará un evento en el [PersistentVolumeClaim](https://kubernetes.io/es/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) relacionado cuando se detecte una condición de volumen anormal en un volumen CSI. El [controlador](https://kubernetes.io/es/docs/concepts/architecture/controller/) de estado externo también observa los eventos de falla del nodo. Se puede habilitar la supervisión de fallas de nodos configurando el indicador `enable-node-watcher` en verdadero. Cuando el monitor de estado externo detecta un evento de falla de nodo, el controlador reporta que se informará un evento en el PVC para indicar que los Pods que usan este PVC están en un nodo fallido. Si un controlador CSI es compatible con la función monitoreo del estado del volumen desde el lado del nodo, se informará un evento en cada Pod que use el PVC cuando se detecte una condición de volumen anormal en un volumen CSI. #### Nota: Se necesita habilitar el `CSIVolumeHealth` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) para usar esta función desde el lado del nodo. Siguientes pasos[](https://kubernetes.io/es/docs/concepts/storage/volume-health-monitoring/#siguientes-pasos) -------------------------------------------------------------------------------------------------------------- Ver la [documentación del controlador CSI](https://kubernetes-csi.github.io/docs/drivers.html) para averiguar qué controladores CSI han implementado esta característica. Comentarios[](https://kubernetes.io/es/docs/concepts/storage/volume-health-monitoring/#feedback) ------------------------------------------------------------------------------------------------- ¿Esta página le ha sido de ayuda? Sí No Muchas gracias por el feedback. Si tienes alguna pregunta específica sobre como usar Kubernetes, puedes preguntar en [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abre un issue en el repositorio de GitHub si quieres [reportar un problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/es/docs/concepts/storage/volume-health-monitoring/) o [sugerir alguna mejora](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/es/docs/concepts/storage/volume-health-monitoring/) . Última modificación July 21, 2022 at 6:12 AM PST: [Update content/es/docs/concepts/storage/volume-health-monitoring.md (5beb2fe4d9)](https://github.com/kubernetes/website/commit/5beb2fe4d991029aea37830c883c96b42faad6a2) --- # Berpartisipasi dalam SIG Docs | Kubernetes Berpartisipasi dalam SIG Docs ============================= SIG Docs merupakan salah satu [kelompok peminatan khusus (_special interest groups_)](https://github.com/kubernetes/community/blob/master/sig-list.md) dalam proyek Kubernetes, yang berfokus pada penulisan, pembaruan, dan pemeliharaan dokumentasi untuk Kubernetes secara keseluruhan. Lihatlah [SIG Docs dari repositori github komunitas](https://github.com/kubernetes/community/tree/master/sig-docs) untuk informasi lebih lanjut tentang SIG. SIG Docs menerima konten dan ulasan dari semua kontributor. Siapa pun dapat membuka _pull request_ (PR), dan siapa pun boleh mengajukan isu tentang konten atau komen pada _pull request_ yang sedang berjalan. Kamu juga bisa menjadi [anggota (_member_)](https://kubernetes.io/id/docs/contribute/participating/roles-and-responsibilities/#anggota) , [pengulas (_reviewer_](https://kubernetes.io/id/docs/contribute/participating/roles-and-responsibilities/#pengulas) , atau [pemberi persetujuan (_approver_)](https://kubernetes.io/id/docs/contribute/participating/roles-and-responsibilities/#approvers) . Peran tersebut membutuhkan akses dan mensyaratkan tanggung jawab tertentu untuk menyetujui dan melakukan perubahan. Lihatlah [keanggotaan-komunitas (_community-membership_)](https://github.com/kubernetes/community/blob/master/community-membership.md) untuk informasi lebih lanjut tentang cara kerja keanggotaan dalam komunitas Kubernetes. Selebihnya dari dokumen ini akan menguraikan beberapa cara unik dari fungsi peranan tersebut dalam SIG Docs, yang bertanggung jawab untuk memelihara salah satu aspek yang paling berhadapan dengan publik dalam Kubernetes - situs web dan dokumentasi dari Kubernetes. Ketua umum (_chairperson_) SIG Docs[](https://kubernetes.io/id/docs/contribute/participate/#ketua-umum-sig-docs) ----------------------------------------------------------------------------------------------------------------- Setiap SIG, termasuk SIG Docs, memilih satu atau lebih anggota SIG untuk bertindak sebagai ketua umum. Mereka merupakan kontak utama antara SIG Docs dan bagian lain dari organisasi Kubernetes. Mereka membutuhkan pengetahuan yang luas tentang struktur proyek Kubernetes secara keseluruhan dan bagaimana SIG Docs bekerja di dalamnya. Lihatlah [Kepemimpinan (_leadership_)](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) untuk daftar ketua umum yang sekarang. Tim dan automasi dalam SIG Docs[](https://kubernetes.io/id/docs/contribute/participate/#tim-dan-automasi-dalam-sig-docs) ------------------------------------------------------------------------------------------------------------------------- Automasi dalam SIG Docs bergantung pada dua mekanisme berbeda: Tim GitHub dan berkas OWNERS. ### Tim GitHub[](https://kubernetes.io/id/docs/contribute/participate/#tim-github) Terdapat dua kategori tim dalam SIG Docs [tim (_teams_)](https://github.com/orgs/kubernetes/teams?query=sig-docs) dalam GitHub: * `@sig-docs-{language}-owners` merupakan pemberi persetujuan (_approver_) dan pemimpin (_lead_) * `@sig-docs-{language}-reviews` merupakan pengulas (_reviewer_) Setiap tim dapat direferensikan dengan `@name` mereka dalam komen GitHub untuk berkomunikasi dengan setiap orang di dalam grup. Terkadang tim Prow dan GitHub tumpang tindih (_overlap_) tanpa kecocokan sama persis. Untuk penugasan masalah, _pull request_, dan untuk mendukung persetujuan PR, otomatisasi menggunakan informasi dari berkas `OWNERS`. ### Berkas OWNERS dan bagian yang utama (_front-matter_)[](https://kubernetes.io/id/docs/contribute/participate/#berkas-owners-dan-bagian-yang-utama-front-matter) Proyek Kubernetes menggunakan perangkat otomatisasi yang disebut prow untuk melakukan automatisasi yang terkait dengan isu dan _pull request_ dalam GitHub. [Repositori situs web Kubernetes](https://github.com/kubernetes/website) menggunakan dua buah [prow _plugin_](https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins) ): * blunderbuss * approve Kedua _plugin_ menggunakan berkas [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) dan [OWNERS\_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) dalam level teratas dari repositori GitHub `kubernetes/website` untuk mengontrol bagaimana prow bekerja di dalam repositori. Berkas OWNERS berisi daftar orang-orang yang menjadi pengulas dan pemberi persetujuan di dalam SIG Docs. Berkas OWNERS juga bisa terdapat di dalam subdirektori, dan dapat menimpa peranan karena dapat bertindak sebagai pengulas atau pemberi persetujuan berkas untuk subdirektori itu dan apa saja yang ada di dalamnya. Untuk informasi lebih lanjut tentang berkas OWNERS pada umumnya, lihatlah [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) . Selanjutnya, berkas _markdown_ individu dapat menyimpan daftar pengulas dan pemberi persetujuan pada bagian yang utama, baik dengan menyimpan daftar nama pengguna individu GitHub atau grup GitHub. Kombinasi dari berkas OWNERS dan bagian yang utama dalam berkas _markdown_ menentukan saran kepada pemilik PR yang didapat dari sistem otomatis tentang siapa yang akan meminta ulasan teknis dan ulasan editorial untuk PR mereka. Cara menggabungkan pekerjaan[](https://kubernetes.io/id/docs/contribute/participate/#cara-menggabungkan-pekerjaan) ------------------------------------------------------------------------------------------------------------------- Ketika _pull request_ digabungkan ke cabang (_branch_) yang digunakan untuk mempublikasikan konten, konten itu dipublikasikan di [https://kubernetes.io](https://kubernetes.io/) . Untuk memastikan bahwa kualitas konten yang kita terbitkan bermutu tinggi, kita membatasi penggabungan _pull request_ bagi para pemberi persetujuan SIG Docs. Beginilah cara kerjanya. * Ketika _pull request_ memiliki label `lgtm` dan `approve`, tidak memiliki label `hold`, dan telah lulus semua tes, _pull request_ akan digabungkan secara otomatis. * Anggota organisasi Kubernetes dan pemberi persetujuan SIG Docs dapat menambahkan komen untuk mencegah penggabungan otomatis dari _pull request_ yang diberikan (dengan menambahkan komen `/hold` atau menahan komen `/lgtm`). * Setiap anggota Kubernetes dapat menambahkan label `lgtm` dengan menambahkan komen `lgtm` * Hanya pemberi persetujuan SIG Docs yang bisa menggabungkan _pull request_ dengan menambahkan komen `/approve`. Beberapa pemberi persetujuan juga dapat melakukan tugas tambahan seperti [PR _Wrangler_](https://kubernetes.io/id/docs/contribute/advanced#menjadi-pr-wrangler-untuk-seminggu) atau [Ketua Umum SIG Docs](https://kubernetes.io/id/docs/contribute/participate/#ketua-umum-sig-docs) . Selanjutnya[](https://kubernetes.io/id/docs/contribute/participate/#selanjutnya) --------------------------------------------------------------------------------- Untuk informasi lebih lanjut tentang cara berkontribusi pada dokumentasi Kubernetes, lihatlah: * [Berkontribusi konten baru](https://kubernetes.io/id/docs/contribute/overview/) * [Mengulas konten](https://kubernetes.io/id/docs/contribute/review/reviewing-prs) * [Panduan gaya dokumentasi](https://kubernetes.io/id/docs/contribute/style/) Masukan[](https://kubernetes.io/id/docs/contribute/participate/#feedback) -------------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/contribute/participate/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/contribute/participate/) . Last modified November 06, 2024 at 12:38 AM PST: [\[id\] update kubernetes link (d100ca6343)](https://github.com/kubernetes/website/commit/d100ca63438426f6dc47e992b78285e4da28503f) --- # 客户端身份认证（Client Authentication）(v1beta1) | Kubernetes 客户端身份认证（Client Authentication）(v1beta1) ======================================= 资源类型[](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#resource-types) ------------------------------------------------------------------------------------------------------------ * [ExecCredential](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential) `ExecCredential`[](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential) ------------------------------------------------------------------------------------------------------------------------------------------------------------- ExecCredential 由基于 exec 的插件使用，与 HTTP 传输组件沟通凭据信息。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `client.authentication.k8s.io/v1beta1` | | `kind`
string | `ExecCredential` | | `spec` **\[必需\]**
[`ExecCredentialSpec`](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredentialSpec) | 字段 `spec` 包含由 HTTP 传输组件传递给插件的信息。 | | `status`
[`ExecCredentialStatus`](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredentialStatus) | 字段 `status` 由插件填充，包含传输组件与 API 服务器连接时需要提供的凭据。 | `Cluster`[](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-Cluster) ----------------------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [ExecCredentialSpec](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredentialSpec) Cluster 中包含允许 exec 插件与 Kubernetes 集群进行通信身份认证时所需的信息。 为了确保该结构体包含需要与 Kubernetes 集群进行通信的所有内容（就像通过 Kubeconfig 一样）， 该字段应该映射到 "k8s.io/client-go/tools/clientcmd/api/v1".cluster， 除了证书授权之外，由于 CA 数据将始终以字节形式传递给插件。 | 字段 | 描述 | | --- | --- | | `server` **\[必需\]**
`string` | 字段 server 是 Kubernetes 集群的地址（https://hostname:port）。 | | `tls-server-name`
`string` | tls-server-name 是用来提供给服务器用作 SNI 解析的，客户端以此检查服务器的证书。 如此字段为空，则使用链接服务器时使用的主机名。 | | `insecure-skip-tls-verify`
`bool` | 设置此字段之后，会令客户端跳过对服务器端证书的合法性检查。 这会使得你的 HTTPS 链接不再安全。 | | `certificate-authority-data`
`[]byte` | 此字段包含 PEM 编码的证书机构（CA）证书。 如果为空，则使用系统的根证书。 | | `proxy-url`
`string` | 此字段用来设置向集群发送所有请求时要使用的代理服务器。 | | `disable-compression`
`bool` | disable-compression 允许客户端针对到服务器的所有请求选择取消响应压缩。 当客户端服务器网络带宽充足时，这有助于通过节省压缩（服务器端）和解压缩 （客户端）时间来加快请求（特别是列表）的速度： https://github.com/kubernetes/kubernetes/issues/112296。 | | `config`
[`k8s.io/apimachinery/pkg/runtime.RawExtension`](https://godoc.org/k8s.io/apimachinery/pkg/runtime/#RawExtension) | 此字段包含一些额外的、特定于 exec 插件和所连接的集群的数据。

此字段来自于 clientcmd 集群对象的 `extensions[client.authentication.k8s.io/exec]` 字段：

clusters:
- name: my-cluster
cluster:
...
extensions:
- name: client.authentication.k8s.io/exec # 针对每个集群 exec 配置所预留的扩展名称
extension:
audience: 06e3fbd18de8 # 任意配置信息

在某些环境中，用户配置可能对很多集群而言都完全一样（即调用同一个 exec 插件）， 只是针对不同集群会有一些细节上的差异，例如 audience。 此字段使得特定于集群的配置可以直接使用集群信息来设置。 不建议使用此字段来保存 Secret 数据，因为 exec 插件的主要优势之一是不需要在 Kubeconfig 中保存 Secret 数据。 | `ExecCredentialSpec`[](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredentialSpec) --------------------------------------------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [ExecCredential](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential) ExecCredentialSpec 保存传输组件所提供的特定于请求和运行时的信息。 | 字段 | 描述 | | --- | --- | | `cluster`
[`Cluster`](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-Cluster) | 此字段中包含的信息使得 exec 插件能够与要访问的 Kubernetes 集群通信。 注意，cluster 字段只有在 exec 驱动的配置中 provideClusterInfo （即：`ExecConfig.ProvideClusterInfo`）被设置为 true 时才不能为空。 | `ExecCredentialStatus`[](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredentialStatus) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [ExecCredential](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential) ExecCredentialStatus 中包含传输组件要使用的凭据。 字段 token 和 clientKeyData 都是敏感字段。 此数据只能在客户端与 exec 插件进程之间使用内存来传递。 exec 插件本身至少应通过文件访问许可来实施保护。 | 字段 | 描述 | | --- | --- | | `expirationTimestamp`
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#time-v1-meta) | 给出所提供的凭据到期的时间。 | | `token` **\[必需\]**
`string` | 客户端用做请求身份认证的持有者令牌。 | | `clientCertificateData` **\[必需\]**
`string` | PEM 编码的客户端 TLS 证书（如果有临时证书，也会包含）。 | | `clientKeyData` **\[必需\]**
`string` | 与上述证书对应的、PEM 编码的私钥。 | 反馈[](https://kubernetes.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#feedback) ---------------------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/config-api/client-authentication.v1beta1/) . 最后修改 March 08, 2026 at 5:21 PM PST: [\[zh-cn\]sync client-authentication.v1beta1 (cfc480a82e)](https://github.com/kubernetes/website/commit/cfc480a82ec531e7a810ae07c926e781276f855f) --- # kubelet systemd 看门狗 | Kubernetes kubelet systemd 看门狗 =================== 特性状态： `Kubernetes v1.32 [beta]`（默认启用） 在 Linux 节点上，Kubernetes 1.35 支持与 [systemd](https://systemd.io/) 集成，以允许操作系统监视程序恢复失败的 kubelet。 这种集成默认并未被启用。它可以作为一个替代方案，通过定期请求 kubelet 的 `/healthz` 端点进行健康检查。 如果 kubelet 在设定的超时时限内未对看门狗做出响应，看门狗将杀死 kubelet。 systemd 看门狗的工作原理是要求服务定期向 systemd 进程发送一个**保持活跃**的信号。 如果 systemd 进程在指定的超时时限内未接收到某服务发出的信号，则对应的服务被视为无响应并被终止。 之后 systemd 进程可以基于配置重启该服务。 配置[](https://kubernetes.io/zh-cn/docs/reference/node/systemd-watchdog/#configuration) -------------------------------------------------------------------------------------- 使用 systemd 看门狗需要在 kubelet 服务单元文件的 `[Service]` 部分配置 `WatchdogSec` 参数： [Service] WatchdogSec=30s 设置 `WatchdogSec=30s` 表示服务看门狗超时时限为 30 秒。 在 kubelet 内，`sd_notify()` 函数被调用，以 WatchdogSec÷2 WatchdogSec \\div 2WatchdogSec÷2 的时间间隔， 发送 `WATCHDOG=1`（保持活跃的消息）。如果在超时时限内看门狗未被“投喂”此信号，kubelet 将被杀死。 将 `Restart` 设置为 "always"、"on-failure"、"on-watchdog" 或 "on-abnormal" 将确保服务被自动重启。 systemd 配置相关的一些细节： 1. 如果你将 systemd 的 `WatchdogSec` 值设置为 0，或省略不设置，则对应的单元上不启用 systemd 看门狗。 2. kubelet 支持设置的最小看门狗超时时限为 1.0 秒；这是为了防止 kubelet 被意外杀死。 你可以在 systemd 单元定义中将 `WatchdogSec` 的值设置为短于 1 秒的超时时限， 但 Kubernetes 不支持任何更短的时间间隔。超时时限不必是整数的秒数。 3. Kubernetes 项目建议将 `WatchdogSec` 时限设置为大约 15 秒。 系统支持超过 10 分钟的时限设置，但明确**不**推荐这样做。 ### 示例配置[](https://kubernetes.io/zh-cn/docs/reference/node/systemd-watchdog/#example-configuration) [Unit] Description=kubelet: The Kubernetes Node Agent Documentation=https://kubernetes.io/docs/home/ Wants=network-online.target After=network-online.target [Service] ExecStart=/usr/bin/kubelet # 配置看门狗的超时时限 WatchdogSec=30s Restart=on-failure StartLimitInterval=0 RestartSec=10 [Install] WantedBy=multi-user.target 接下来[](https://kubernetes.io/zh-cn/docs/reference/node/systemd-watchdog/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) ----------------------------------------------------------------------------------------------------- 有关 systemd 配置的细节，请参阅 [systemd 文档](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#WatchdogSec=) 。 反馈[](https://kubernetes.io/zh-cn/docs/reference/node/systemd-watchdog/#feedback) --------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/node/systemd-watchdog/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/node/systemd-watchdog/) . 最后修改 March 06, 2025 at 10:09 PM PST: [\[zh-cn\]sync systemd-watchdog.md (c2e1e321c2)](https://github.com/kubernetes/website/commit/c2e1e321c25ff6a392fffa8deba6c4eb39bd487b) --- # Pod 安全性准入 | Kubernetes Pod 安全性准入 ========= 对 Pod 安全性准入控制器的概述，Pod 安全性准入控制器可以实施 Pod 安全性标准。 特性状态： `Kubernetes v1.25 [stable]` Kubernetes [Pod 安全性标准（Security Standard）](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/) 为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。 Kubernetes 提供了一个内置的 **Pod Security** [准入控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 来执行 Pod 安全标准 （Pod Security Standard）。 创建 Pod 时在[名字空间](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/namespaces/) 级别应用这些 Pod 安全限制。 ### 内置 Pod 安全准入强制执行[](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#built-in-pod-security-admission-enforcement) 本页面是 Kubernetes v1.35 文档的一部分。 如果你运行的是其他版本的 Kubernetes，请查阅该版本的文档。 Pod 安全性级别[](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#pod-security-levels) ------------------------------------------------------------------------------------------------------------ Pod 安全性准入插件对 Pod 的[安全性上下文](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/) 有一定的要求， 并且依据 [Pod 安全性标准](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards) 所定义的三个级别 （`privileged`、`baseline` 和 `restricted`）对其他字段也有要求。 关于这些需求的更进一步讨论，请参阅 [Pod 安全性标准](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/) 页面。 为名字空间设置 Pod 安全性准入控制标签[](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces) ------------------------------------------------------------------------------------------------------------------------------------------------- 一旦特性被启用或者安装了 Webhook，你可以配置名字空间以定义每个名字空间中 Pod 安全性准入控制模式。 Kubernetes 定义了一组[标签](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/) ， 你可以设置这些标签来定义某个名字空间上要使用的预定义的 Pod 安全性标准级别。 你所选择的标签定义了检测到潜在违例时， [控制面](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-control-plane) 要采取什么样的动作。 | | | | --- | --- |Pod 安全准入模式 | 模式 | 描述 | | --- | --- | | **enforce** | 策略违例会导致 Pod 被拒绝 | | **audit** | 策略违例会触发[审计日志](https://kubernetes.io/zh-cn/docs/tasks/debug/debug-cluster/audit/)
中记录新事件时添加审计注解；但是 Pod 仍是被接受的。 | | **warn** | 策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的。 | 名字空间可以配置任何一种或者所有模式，或者甚至为不同的模式设置不同的级别。 对于每种模式，决定所使用策略的标签有两个： # 模式的级别标签用来标示对应模式所应用的策略级别 # # MODE 必须是 `enforce`、`audit` 或 `warn` 之一 # LEVEL 必须是 `privileged`、baseline` 或 `restricted` 之一 pod-security.kubernetes.io/: # 可选：针对每个模式版本的版本标签可以将策略锁定到 # 给定 Kubernetes 小版本号所附带的版本（例如 v1.35） # # MODE 必须是 `enforce`、`audit` 或 `warn` 之一 # VERSION 必须是一个合法的 Kubernetes 小版本号或者 `latest` pod-security.kubernetes.io/-version: 关于用法示例，可参阅[使用名字空间标签来强制实施 Pod 安全标准](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) 。 负载资源和 Pod 模板[](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#workload-resources-and-pod-templates) -------------------------------------------------------------------------------------------------------------------------------- Pod 通常是通过创建 [Deployment](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/) 或 [Job](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/) 这类[工作负载对象](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/) 来间接创建的。 工作负载对象为工作负载资源定义一个 **Pod 模板**和一个对应的负责基于该模板来创建 Pod 的[控制器](https://kubernetes.io/zh-cn/docs/concepts/architecture/controller/) 。 为了尽早地捕获违例状况，`audit` 和 `warn` 模式都应用到负载资源。 不过，`enforce` 模式并**不**应用到工作负载资源，仅应用到所生成的 Pod 对象上。 豁免[](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#exemptions) -------------------------------------------------------------------------------------------- 你可以为 Pod 安全性的实施设置**豁免（Exemptions）** 规则， 从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。 豁免规则可以在[准入控制器配置](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller) 中静态配置。 豁免规则必须显式枚举。满足豁免标准的请求会被准入控制器**忽略** （所有 `enforce`、`audit` 和 `warn` 行为都会被略过）。 豁免的维度包括： * **Username：** 来自用户名已被豁免的、已认证的（或伪装的）的用户的请求会被忽略。 * **RuntimeClassName：** 指定了已豁免的运行时类名称的 Pod 和[负载资源](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#workload-resources-and-pod-templates) 会被忽略。 * **Namespace：** 位于被豁免的名字空间中的 Pod 和[负载资源](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#workload-resources-and-pod-templates) 会被忽略。 #### 注意： 大多数 Pod 是作为对[工作负载资源](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#workload-resources-and-pod-templates) 的响应， 由控制器所创建的，这意味着为某最终用户提供豁免时，只会当该用户直接创建 Pod 时对其实施安全策略的豁免。用户创建工作负载资源时不会被豁免。 控制器服务账号（例如：`system:serviceaccount:kube-system:replicaset-controller`） 通常不应该被豁免，因为豁免这类服务账号隐含着对所有能够创建对应工作负载资源的用户豁免。 策略检查时会对以下 Pod 字段的更新操作予以豁免，这意味着如果 Pod 更新请求仅改变这些字段时，即使 Pod 违反了当前的策略级别，请求也不会被拒绝。 * 除了对 seccomp 或 AppArmor 注解之外的所有元数据（Metadata）更新操作： * `seccomp.security.alpha.kubernetes.io/pod` （已弃用） * `container.seccomp.security.alpha.kubernetes.io/*` （已弃用） * `container.apparmor.security.beta.kubernetes.io/*`（已弃用） * 对 `.spec.activeDeadlineSeconds` 的合法更新 * 对 `.spec.tolerations` 的合法更新 指标[](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#metrics) ----------------------------------------------------------------------------------------- 以下是 kube-apiserver 公开的 Prometheus 指标： * `pod_security_errors_total`：此指标表示妨碍正常评估的错误数量。 如果错误是非致命的，kube-apiserver 可能会强制实施最新的受限配置。 * `pod_security_evaluations_total`：此指标表示已发生的策略评估的数量， 不包括导出期间被忽略或豁免的请求。 * `pod_security_exemptions_total`：该指标表示豁免请求的数量， 不包括被忽略或超出范围的请求。 接下来[](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) -------------------------------------------------------------------------------------------------------------- * [Pod 安全性标准](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/) * [强制实施 Pod 安全性标准](https://kubernetes.io/zh-cn/docs/setup/best-practices/enforcing-pod-security-standards/) * [通过配置内置的准入控制器强制实施 Pod 安全性标准](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) * [使用名字空间标签来实施 Pod 安全性标准](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) 如果你正运行较老版本的 Kubernetes，想要升级到不包含 PodSecurityPolicy 的 Kubernetes 版本， 可以参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp) 。 反馈[](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/#feedback) ------------------------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/security/pod-security-admission/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/security/pod-security-admission/) . 最后修改 April 21, 2024 at 11:25 PM PST: [\[zh-cn\] sync manage-resources-containers secret pod-security-admission web-ui-dashboard (9b03a0735d)](https://github.com/kubernetes/website/commit/9b03a0735dbfc72977be09ab52b8621151faae72) --- # Pods | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) Pods ==== _Pods_ sind die kleinsten einsetzbaren Einheiten, die in Kubernetes erstellt und verwaltet werden können. Ein _Pod_ (übersetzt Gruppe/Schote, wie z. B. eine Gruppe von Walen oder eine Erbsenschote) ist eine Gruppe von einem oder mehreren [Containern](https://kubernetes.io/de/docs/concepts/containers/) mit gemeinsam genutzten Speicher- und Netzwerkressourcen und einer Spezifikation für die Ausführung der Container. Die Ressourcen eines Pods befinden sich immer auf dem gleichen (virtuellen) Server, werden gemeinsam geplant und in einem gemeinsamen Kontext ausgeführt. Ein Pod modelliert einen anwendungsspezifischen "logischen Server": Er enthält eine oder mehrere containerisierte Anwendungen, die relativ stark voneinander abhängen. In Nicht-Cloud-Kontexten sind Anwendungen, die auf demselben physischen oder virtuellen Server ausgeführt werden, vergleichbar zu Cloud-Anwendungen, die auf demselben logischen Server ausgeführt werden. Ein Pod kann neben Anwendungs-Containern auch sogenannte [Initialisierungs-Container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) enthalten, die beim Starten des Pods ausgeführt werden. Es können auch kurzlebige/[ephemere Container](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) zum Debuggen gestartet werden, wenn dies der Cluster anbietet. Was ist ein Pod?[](https://kubernetes.io/de/docs/concepts/workloads/pods/#was-ist-ein-pod) ------------------------------------------------------------------------------------------- #### Hinweis: Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere [Container-Laufzeitumgebungen](https://kubernetes.io/de/docs/setup/production-environment/container-runtimes) unterstützt, ist Docker am bekanntesten und es ist hilfreich, Pods mit der Terminologie von Docker zu beschreiben. Der gemeinsame Kontext eines Pods besteht aus einer Reihe von Linux-Namespaces, Cgroups und möglicherweise anderen Aspekten der Isolation, also die gleichen Dinge, die einen Dockercontainer isolieren. Innerhalb des Kontexts eines Pods können die einzelnen Anwendungen weitere Unterisolierungen haben. Im Sinne von Docker-Konzepten ähnelt ein Pod einer Gruppe von Docker-Containern, die gemeinsame Namespaces und Dateisystem-Volumes nutzen. Pods verwenden[](https://kubernetes.io/de/docs/concepts/workloads/pods/#pods-verwenden) ---------------------------------------------------------------------------------------- Normalerweise müssen keine Pods erzeugt werden, auch keine Singleton-Pods. Stattdessen werden sie mit Workload-Ressourcen wie [Deployment](https://kubernetes.io/de/docs/concepts/workloads/controllers/deployment/) oder [Job](https://kubernetes.io/de/docs/concepts/workloads/controllers/job/) erzeugt. Für Pods, die von einem Systemzustand abhängen, ist die Nutzung von [StatefulSet](https://kubernetes.io/de/docs/concepts/workloads/controllers/statefulset/) \-Ressourcen zu erwägen. Pods in einem Kubernetes-Cluster werden hauptsächlich auf zwei Arten verwendet: * **Pods, die einen einzelnen Container ausführen**. Das "Ein-Container-per-Pod"-Modell ist der häufigste Kubernetes-Anwendungsfall. In diesem Fall kannst du dir einen einen Pod als einen Behälter vorstellen, der einen einzelnen Container enthält; Kubernetes verwaltet die Pods anstatt die Container direkt zu verwalten. * **Pods, in denen mehrere Container ausgeführt werden, die zusammenarbeiten müssen**. Wenn eine Softwareanwendung aus co-lokaliserten Containern besteht, die sich gemeinsame Ressourcen teilen und stark voneinander abhängen, kann ein Pod die Container verkapseln. Diese Container bilden eine einzelne zusammenhängende Serviceeinheit, z. B. ein Container, der Daten in einem gemeinsam genutzten Volume öffentlich verfügbar macht, während ein separater _Sidecar_\-Container die Daten aktualisiert. Der Pod fasst die Container, die Speicherressourcen und eine kurzlebige Netzwerk-Identität als eine Einheit zusammen. #### Hinweis: Das Gruppieren mehrerer gemeinsam lokalisierter und gemeinsam verwalteter Container in einem einzigen Pod ist ein relativ fortgeschrittener Anwendungsfall. Du solltest diese Architektur nur in bestimmten Fällen verwenden, wenn deine Container stark voneinander abhängen. Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn du deine Anwendung horizontal skalieren willst (um mehr Instanzen auszuführen und dadurch mehr Gesamtressourcen bereitstellen), solltest du mehrere Pods verwenden, einen für jede Instanz. In Kubernetes wird dies typischerweise als Replikation bezeichnet. Replizierte Pods werden normalerweise als eine Gruppe durch eine Workload-Ressource und deren [Controller](https://kubernetes.io/de/docs/concepts/architecture/controller/) erstellt und verwaltet. Der Abschnitt [Pods und Controller](https://kubernetes.io/de/docs/concepts/workloads/pods/#pods-und-controller) beschreibt, wie Kubernetes Workload-Ressourcen und deren Controller verwendet, um Anwendungen zu skalieren und zu heilen. ### Wie Pods mehrere Container verwalten[](https://kubernetes.io/de/docs/concepts/workloads/pods/#wie-pods-mehrere-container-verwalten) Pods unterstützen mehrere kooperierende Prozesse (als Container), die eine zusammenhängende Serviceeinheit bilden. Kubernetes plant und stellt automatisch sicher, dass sich die Container in einem Pod auf demselben physischen oder virtuellen Server im Cluster befinden. Die Container können Ressourcen und Abhängigkeiten gemeinsam nutzen, miteinander kommunizieren und ferner koordinieren wann und wie sie beendet werden. Zum Beispiel könntest du einen Container haben, der als Webserver für Dateien in einem gemeinsamen Volume arbeitet. Und ein separater "Sidecar" -Container aktualisiert die Daten von einer externen Datenquelle, siehe folgenden Abbildung: ![Pod-Beispieldiagramm](https://kubernetes.io/images/docs/pod.svg) Einige Pods haben sowohl [Initialisierungs-Container](https://kubernetes.io/de/docs/concepts/workloads/pods/init-containers/) als auch [Anwendungs-Container](https://kubernetes.io/de/docs/reference/glossary/?all=true#term-app-container) . Initialisierungs-Container werden gestartet und beendet bevor die Anwendungs-Container gestartet werden. Pods stellen standardmäßig zwei Arten von gemeinsam Ressourcen für die enthaltenen Container bereit: [Netzwerk](https://kubernetes.io/de/docs/concepts/workloads/pods/#pod-netzwerk) und [Speicher](https://kubernetes.io/de/docs/concepts/workloads/pods/#datenspeicherung-in-pods) . Mit Pods arbeiten[](https://kubernetes.io/de/docs/concepts/workloads/pods/#mit-pods-arbeiten) ---------------------------------------------------------------------------------------------- Du wirst selten einzelne Pods direkt in Kubernetes erstellen, selbst Singleton-Pods. Das liegt daran, dass Pods als relativ kurzlebige Einweg-Einheiten konzipiert sind. Wenn ein Pod erstellt wird (entweder direkt von Ihnen oder indirekt von einem [Controller](https://kubernetes.io/de/docs/concepts/architecture/controller/) ), wird die Ausführung auf einem [Knoten](https://kubernetes.io/de/docs/concepts/architecture/nodes/) in Ihrem Cluster geplant. Der Pod bleibt auf diesem (virtuellen) Server, bis entweder der Pod die Ausführung beendet hat, das Pod-Objekt gelöscht wird, der Pod aufgrund mangelnder Ressourcen _evakuiert_ wird oder der Node ausfällt. #### Hinweis: Das Neustarten eines Containers in einem Pod sollte nicht mit dem Neustarten eines Pods verwechselt werden. Ein Pod ist kein Prozess, sondern eine Umgebung zur Ausführung von Containern. Ein Pod bleibt bestehen bis er gelöscht wird. Stelle beim Erstellen des Manifests für ein Pod-Objekt sicher, dass der angegebene Name ein gültiger [DNS-Subdomain-Name](https://kubernetes.io/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) ist. ### Pods und Controller[](https://kubernetes.io/de/docs/concepts/workloads/pods/#pods-und-controller) Mit Workload-Ressourcen kannst du mehrere Pods erstellen und verwalten. Ein Controller für die Ressource kümmert sich um Replikation, Roll-Out sowie automatische Wiederherstellung im Fall von versagenden Pods. Wenn beispielsweise ein Node ausfällt, bemerkt ein Controller, dass die Pods auf dem Node nicht mehr laufen und plant die Ausführung eines Ersatzpods auf einem funktionierenden Node. Hier sind einige Beispiele für Workload-Ressourcen, die einen oder mehrere Pods verwalten: * [Deployment](https://kubernetes.io/de/docs/concepts/workloads/controllers/deployment/) * [StatefulSet](https://kubernetes.io/de/docs/concepts/workloads/controllers/statefulset/) * [DaemonSet](https://kubernetes.io/de/docs/concepts/workloads/controllers/daemonset) ### Pod-Vorlagen[](https://kubernetes.io/de/docs/concepts/workloads/pods/#pod-vorlagen) Controller für [Workload](https://kubernetes.io/de/docs/concepts/workloads/) \-Ressourcen erstellen Pods von einer _Pod-Vorlage_ und verwalten diese Pods für dich. Pod-Vorlagen sind Spezifikationen zum Erstellen von Pods und sind in Workload-Ressourcen enthalten wie z. B. [Deployments](https://kubernetes.io/de/docs/concepts/workloads/controllers/deployment/) , [Jobs](https://kubernetes.io/de/docs/concepts/workloads/controllers/job/) , and [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) . Jeder Controller für eine Workload-Ressource verwendet die Pod-Vorlage innerhalb des Workload-Objektes, um Pods zu erzeugen. Die Pod-Vorlage ist Teil des gewünschten Zustands der Workload-Ressource, mit der du deine Anwendung ausgeführt hast. Das folgende Beispiel ist ein Manifest für einen einfachen Job mit einer `Vorlage`, die einen Container startet. Der Container in diesem Pod druckt eine Nachricht und pausiert dann. apiVersion: batch/v1 kind: Job metadata: name: hello spec: template: # Dies is the Pod-Vorlage spec: containers: - name: hello image: busybox command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure # Die Pod-Vorlage endet hier Das Ändern der Pod-Vorlage oder der Wechsel zu einer neuen Pod-Vorlage hat keine direkten Auswirkungen auf bereits existierende Pods. Wenn du die Pod-Vorlage für eine Workload-Ressource änderst, dann muss diese Ressource die Ersatz-Pods erstellen, welche die aktualisierte Vorlage verwenden. Beispielsweise stellt der StatefulSet-Controller sicher, dass für jedes StatefulSet-Objekt die ausgeführten Pods mit der aktueller Pod-Vorlage übereinstimmen. Wenn du das StatefulSet bearbeitest und die Vorlage änderst, beginnt das StatefulSet mit der Erstellung neuer Pods basierend auf der aktualisierten Vorlage. Schließlich werden alle alten Pods durch neue Pods ersetzt, und das Update ist abgeschlossen. Jede Workload-Ressource implementiert eigenen Regeln für die Umsetzung von Änderungen der Pod-Vorlage. Wenn du mehr über StatefulSet erfahren möchtest, dann lese die Seite [Update-Strategien](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) im Tutorial StatefulSet Basics. Auf Nodes beobachtet oder verwaltet das [Kubelet](https://kubernetes.io/de/docs/reference/generated/kubelet) nicht direkt die Details zu Pod-Vorlagen und Updates. Diese Details sind abstrahiert. Die Abstraktion und Trennung von Aufgaben vereinfacht die Systemsemantik und ermöglicht so das Verhalten des Clusters zu ändern ohne vorhandenen Code zu ändern. Pod Update und Austausch[](https://kubernetes.io/de/docs/concepts/workloads/pods/#pod-update-und-austausch) ------------------------------------------------------------------------------------------------------------ Wie im vorherigen Abschnitt erwähnt, erstellt der Controller neue Pods basierend auf der aktualisierten Vorlage, wenn die Pod-Vorlage für eine Workload-Ressource geändert wird anstatt die vorhandenen Pods zu aktualisieren oder zu patchen. Kubernetes hindert dich nicht daran, Pods direkt zu verwalten. Es ist möglich, einige Felder eines laufenden Pods zu aktualisieren. Allerdings haben Pod-Aktualisierungsvorgänge wie zum Beispiel [`patch`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#patch-pod-v1-core) , und [`replace`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#replace-pod-v1-core) einige Einschränkungen: * Die meisten Metadaten zu einem Pod können nicht verändert werden. Zum Beispiel kannst du nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` ändern. Das `generation`\-Feld muss eindeutig sein. Es werden nur Aktualisierungen akzeptiert, die den Wert des Feldes inkrementieren. * Wenn das Feld `metadata.deletionTimestamp` gesetzt ist, kann kein neuer Eintrag zur Liste `metadata.finalizers` hinzugefügt werden. * Pod-Updates dürfen keine Felder ändern, die Ausnahmen sind `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` oder `spec.tolerations`. Für `spec.tolerations` kannnst du nur neue Einträge hinzufügen. * Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt: 1. ungesetztes Feld in eine positive Zahl 2. positive Zahl in eine kleinere positive Zahl, die nicht negativ ist Gemeinsame Nutzung von Ressourcen und Kommunikation[](https://kubernetes.io/de/docs/concepts/workloads/pods/#gemeinsame-nutzung-von-ressourcen-und-kommunikation) ------------------------------------------------------------------------------------------------------------------------------------------------------------------ Pods ermöglichen den Datenaustausch und die Kommunikation zwischen den Containern, die im Pod enthalten sind. ### Datenspeicherung in Pods[](https://kubernetes.io/de/docs/concepts/workloads/pods/#datenspeicherung-in-pods) Ein Pod kann eine Reihe von gemeinsam genutzten Speicher- [Volumes](https://kubernetes.io/de/docs/concepts/storage/volumes/) spezifizieren. Alle Container im Pod können auf die gemeinsamen Volumes zugreifen und dadurch Daten austauschen. Volumes ermöglichen auch, dass Daten ohne Verlust gespeichert werden, falls einer der Container neu gestartet werden muss. Im Kapitel [Datenspeicherung](https://kubernetes.io/de/docs/concepts/storage/) findest du weitere Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und Pods zur Verfügung stellt. ### Pod-Netzwerk[](https://kubernetes.io/de/docs/concepts/workloads/pods/#pod-netzwerk) Jedem Pod wird für jede Adressenfamilie eine eindeutige IP-Adresse zugewiesen. Jeder Container in einem Pod nutzt den gemeinsamen Netzwerk-Namespace, einschließlich der IP-Adresse und der Ports. In einem Pod (und **nur** dann) können die Container, die zum Pod gehören, über `localhost` miteinander kommunizieren. Wenn Container in einem Pod mit Entitäten _außerhalb des Pods_ kommunizieren, müssen sie koordinieren, wie die gemeinsam genutzten Netzwerkressourcen (z. B. Ports) verwenden werden. Innerhalb eines Pods teilen sich Container eine IP-Adresse und eine Reihe von Ports und können sich gegenseitig über `localhost` finden. Die Container in einem Pod können auch die üblichen Kommunikationsverfahren zwischen Prozessen nutzen, wie z. B. SystemV-Semaphoren oder "POSIX Shared Memory". Container in verschiedenen Pods haben unterschiedliche IP-Adressen und können nicht per IPC ohne [spezielle Konfiguration](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) kommunizieren. Container, die mit einem Container in einem anderen Pod interagieren möchten, müssen IP Netzwerke verwenden. Für die Container innerhalb eines Pods stimmt der "hostname" mit dem konfigurierten `Namen` des Pods überein. Mehr dazu im Kapitel [Netzwerke](https://kubernetes.io/docs/concepts/cluster-administration/networking/) . Privilegierter Modus für Container[](https://kubernetes.io/de/docs/concepts/workloads/pods/#privilegierter-modus-f%C3%BCr-container) ------------------------------------------------------------------------------------------------------------------------------------- Jeder Container in einem Pod kann den privilegierten Modus aktivieren, indem das Flag `privileged` im [Sicherheitskontext](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) der Container-Spezifikation verwendet wird. Dies ist nützlich für Container, die Verwaltungsfunktionen des Betriebssystems verwenden möchten, z. B. das Manipulieren des Netzwerk-Stacks oder den Zugriff auf Hardware. Prozesse innerhalb eines privilegierten Containers erhalten fast die gleichen Rechte wie sie Prozessen außerhalb eines Containers zur Verfügung stehen. #### Hinweis: Ihre [Container-Umgebung](https://kubernetes.io/de/docs/setup/production-environment/container-runtimes) muss das Konzept eines privilegierten Containers unterstützen, damit diese Einstellung relevant ist. Statische Pods[](https://kubernetes.io/de/docs/concepts/workloads/pods/#statische-pods) ---------------------------------------------------------------------------------------- _Statische Pods_ werden direkt vom Kubelet-Daemon auf einem bestimmten Node verwaltet ohne dass sie vom [API Server](https://kubernetes.io/de/docs/reference/generated/kube-apiserver/) überwacht werden. Die meisten Pods werden von der Kontrollebene verwaltet (z. B. [Deployment](https://kubernetes.io/de/docs/concepts/workloads/controllers/deployment/) ). Aber für statische Pods überwacht das Kubelet jeden statischen Pod direkt (und startet ihn neu, wenn er ausfällt). Statische Pods sind immer an ein [Kubelet](https://kubernetes.io/de/docs/reference/generated/kubelet) auf einem bestimmten Node gebunden. Der Hauptanwendungsfall für statische Pods besteht darin, eine selbst gehostete Steuerebene auszuführen. Mit anderen Worten: Das Kubelet dient zur Überwachung der einzelnen [Komponenten der Kontrollebene](https://kubernetes.io/de/docs/concepts/overview/components/#control-plane-components) . Das Kubelet versucht automatisch auf dem Kubernetes API-Server für jeden statischen Pod einen spiegelbildlichen Pod (im Englischen: [mirror pod](https://kubernetes.io/de/docs/reference/glossary/?all=true#term-mirror-pod) ) zu erstellen. Das bedeutet, dass die auf einem Node ausgeführten Pods auf dem API-Server sichtbar sind jedoch von dort nicht gesteuert werden können. Nächste Schritte[](https://kubernetes.io/de/docs/concepts/workloads/pods/#n%C3%A4chste-schritte) ------------------------------------------------------------------------------------------------- * Verstehe den [Lebenszyklus eines Pods](https://kubernetes.io/de/docs/concepts/workloads/pods/pod-lifecycle/) . * Erfahre mehr über [RuntimeClass](https://kubernetes.io/docs/concepts/containers/runtime-class/) und wie du damit verschiedene Pods mit unterschiedlichen Container-Laufzeitumgebungen konfigurieren kannst. * Mehr zum Thema [Restriktionen für die Verteilung von Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) . * Lese [Pod-Disruption-Budget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) und wie du es verwenden kannst, um die Verfügbarkeit von Anwendungen bei Störungen zu verwalten. Die [Pod](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#pod-v1-core) -Objektdefinition beschreibt das Objekt im Detail. * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) erläutert allgemeine Layouts für Pods mit mehr als einem Container. Um den Hintergrund zu verstehen, warum Kubernetes eine gemeinsame Pod-API in andere Ressourcen, wie z. B. [StatefulSets](https://kubernetes.io/de/docs/concepts/workloads/controllers/statefulset/) oder [Deployments](https://kubernetes.io/de/docs/concepts/workloads/controllers/deployment/) einbindet, kannst du Artikel zu früheren Technologien lesen, unter anderem: * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) * [Borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/) * [Marathon](https://github.com/d2iq-archive/marathon) * [Omega](https://research.google/pubs/pub41684/) * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/) . Feedback[](https://kubernetes.io/de/docs/concepts/workloads/pods/#feedback) ---------------------------------------------------------------------------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/de/docs/concepts/workloads/pods/) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/de/docs/concepts/workloads/pods/) . Zuletzt geändert January 06, 2025 at 1:08 AM PST: [\[de\] Fix Borg research publication link (54792eb4b9)](https://github.com/kubernetes/website/commit/54792eb4b980287331cb88d7ccf8f9dcfc508f31) --- # Arsitektur Kubernetes | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Cluster Architecture](https://kubernetes.io/docs/concepts/architecture/) Arsitektur Kubernetes ===================== * * * ##### [Node](https://kubernetes.io/id/docs/concepts/architecture/nodes/) ##### [Komunikasi antara Control Plane dan Node](https://kubernetes.io/id/docs/concepts/architecture/control-plane-node-communication/) ##### [Controller](https://kubernetes.io/id/docs/concepts/architecture/controller/) ##### [Konsep-konsep di balik Controller Manager](https://kubernetes.io/id/docs/concepts/architecture/cloud-controller/) ##### [Tentang cgroup v2](https://kubernetes.io/id/docs/concepts/architecture/cgroups/) Masukan[](https://kubernetes.io/id/docs/concepts/architecture/#feedback) ------------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/concepts/architecture/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/concepts/architecture/) . Last modified April 21, 2019 at 2:59 PM PST: [Translate kube architecture section to Indonesian (#13887) (734eb9a086)](https://github.com/kubernetes/website/commit/734eb9a086022e4ba8656eb21ecb747fd83b44dd) --- # Resourcen-Verwaltung für Pods und Container | Kubernetes Resourcen-Verwaltung für Pods und Container =========================================== Feedback[](https://kubernetes.io/de/docs/concepts/configuration/manage-resource-containers/#feedback) ------------------------------------------------------------------------------------------------------ War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/de/docs/concepts/configuration/manage-resource-containers/) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/de/docs/concepts/configuration/manage-resource-containers/) . Zuletzt geändert April 08, 2023 at 6:56 PM PST: [Add translation for "Automatic bin packing" (791432d7f3)](https://github.com/kubernetes/website/commit/791432d7f3a02b003721893b4c61ec29603aacba) --- # Windows 节点的安全性 | Kubernetes Windows 节点的安全性 ============== 本篇介绍特定于 Windows 操作系统的安全注意事项和最佳实践。 保护节点上的 Secret 数据[](https://kubernetes.io/zh-cn/docs/concepts/security/windows-security/#protection-for-secret-data-on-nodes) ----------------------------------------------------------------------------------------------------------------------------- 在 Windows 上，来自 Secret 的数据以明文形式写入节点的本地存储 （与在 Linux 上使用 tmpfs / 内存中文件系统不同）。 作为集群操作员，你应该采取以下两项额外措施： 1. 使用文件 ACL 来保护 Secret 的文件位置。 2. 使用 [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) 进行卷级加密。 容器用户[](https://kubernetes.io/zh-cn/docs/concepts/security/windows-security/#container-users) --------------------------------------------------------------------------------------------- 可以为 Windows Pod 或容器指定 [RunAsUsername](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-runasusername) 以作为特定用户执行容器进程。这大致相当于 [RunAsUser](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-policy/#users-and-groups) 。 Windows 容器提供两个默认用户帐户，ContainerUser 和 ContainerAdministrator。 在微软的 **Windows 容器安全** 文档 [何时使用 ContainerAdmin 和 ContainerUser 用户帐户](https://docs.microsoft.com/zh-cn/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts) 中介绍了这两个用户帐户之间的区别。 在容器构建过程中，可以将本地用户添加到容器镜像中。 #### 说明： * 基于 [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) 的镜像默认以 `ContainerUser` 运行 * 基于 [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) 的镜像默认以 `ContainerAdministrator` 运行 Windows 容器还可以通过使用[组管理的服务账号](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/) 作为 Active Directory 身份运行。 Pod 级安全隔离[](https://kubernetes.io/zh-cn/docs/concepts/security/windows-security/#pod-level-security-isolation) --------------------------------------------------------------------------------------------------------------- Windows 节点不支持特定于 Linux 的 Pod 安全上下文机制（例如 SELinux、AppArmor、Seccomp 或自定义 POSIX 权能字）。 Windows 上[不支持](https://kubernetes.io/zh-cn/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext) 特权容器。 然而，可以在 Windows 上使用 [HostProcess 容器](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod) 来执行 Linux 上特权容器执行的许多任务。 反馈[](https://kubernetes.io/zh-cn/docs/concepts/security/windows-security/#feedback) ------------------------------------------------------------------------------------ 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/security/windows-security/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/security/windows-security/) . 最后修改 September 03, 2022 at 11:56 PM PST: [\[zh\]sync windows-security.md (667453a5c9)](https://github.com/kubernetes/website/commit/667453a5c9473b027861c9dd1d492032e3240ac9) --- # Acceder al clúster y las aplicaciones | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Access Applications in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/) Acceder al clúster y las aplicaciones ===================================== Comentarios[](https://kubernetes.io/es/docs/tasks/access-application-cluster/#feedback) ---------------------------------------------------------------------------------------- ¿Esta página le ha sido de ayuda? Sí No Muchas gracias por el feedback. Si tienes alguna pregunta específica sobre como usar Kubernetes, puedes preguntar en [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abre un issue en el repositorio de GitHub si quieres [reportar un problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/es/docs/tasks/access-application-cluster/) o [sugerir alguna mejora](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/es/docs/tasks/access-application-cluster/) . Última modificación June 22, 2021 at 6:14 PM PST: [\[es\] Remove exec permission on markdown files (f36d230101)](https://github.com/kubernetes/website/commit/f36d23010104cf166b61e11297f9b177b90e1654) --- # Pertimbangan untuk klaster besar | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Considerations for large clusters](https://kubernetes.io/docs/setup/best-practices/cluster-large/) Pertimbangan untuk klaster besar ================================ Klaster adalah kumpulan ([node](https://kubernetes.io/id/docs/concepts/architecture/nodes/) ) berupa mesin fisik ataupun virtual yang menjalankan agen Kubernetes, dan dikelola oleh [bidang kontrol](https://kubernetes.io/id/docs/reference/glossary/?all=true#term-control-plane) . Kubernetes v1.35 mendukung klaster hingga 5000 _node_. Lebih tepatnya, Kubernetes didesain untuk mengakomodasi konfigurasi yang mendukung kriteria dibawah ini: * Jumlah pods tidak lebih dari 110 pods per _node_ * Jumlah _node_ tidak lebih dari 5000 * Total pods tidak lebih dari 150000 * Total kontainer tidak lebih dari 300000 Kamu dapat mengubah ukuran klaster dengan menambah atau menghapus _node_. Cara yang digunakan untuk pengubahan ukuran ini tergantung dari bagaimana kamu membangun klaster. Kuota sumber daya penyedia cloud[](https://kubernetes.io/id/docs/setup/best-practices/cluster-large/#quota-issues) ------------------------------------------------------------------------------------------------------------------- Untuk menghindari masalah kuota penyedia _cloud_, ketika membuat klaster dengan banyak _node_, pertimbangkanlah hal berikut ini: * Mengajukan penambahan kuota untuk sumber daya _cloud_ berikut ini: * Jumlah mesin virtual * CPU * Volume penyimpanan * Penggunaan alamat IP * Aturan penyaringan paket * Jumlah penyeimbang beban (_load balancer_) * Subnet jaringan * Aliran log * Mengatur pengubahan ukuran klaster untuk menambah _node_ baru menggunakan mode _batches_, dengan jeda antar _batches_, karena sejumlah penyedia _cloud_ membatasi laju (_rate limit_) pembuatan mesin baru. Komponen bidang kontrol[](https://kubernetes.io/id/docs/setup/best-practices/cluster-large/#komponen-bidang-kontrol) --------------------------------------------------------------------------------------------------------------------- Untuk klaster besar, kamu membutuhkan bidang kontrol dengan komputasi yang cukup dan sumber daya lainnya. Biasanya, kamu akan menjalankan satu atau dua bidang kontrol untuk tiap zona kegagalan (_failure zone_), mengubah ukuran bidang kontrol secara vertikal terlebih dahulu dan kemudian mengubah ukurannya secara horizontal setelah mencapai batas dari mengubah ukuran secara vertikal. Kamu harus menjalankan paling tidak satu bidang kontrol per zona kegagalan untuk memberikan toleransi kegagalan (_fault-tolerance_). _node_ Kubernetes tidak secara otomatis mengendalikan arus ke bidang kontrol yang berada di zona kegagalan yang sama; bagaimanapun, penyedia _cloud_ kamu mungkin memiliki mekanisme toleransi kegagalan mereka sendiri untuk menangani hal tersebut. Sebagai contoh, dengan menggunakan penyeimbang beban bawaan (_managed load balancer_), kamu dapat mengonfigurasi penyeimbang beban untuk mengirim arus yang berasal dari kubelet dan pods di zona A, kemudian hanya mengarahkan arus tersebut ke bidang kontrol yang hanya ada di zona _A_. Jika salah satu bidang kontrol atau zona kegagalan _A_ mati, artinya semua arus bidang kontrol untuk _node_ di zona _A_ akan dikirim ke zona lain. Menjalankan banyak bidang kontrol di setiap zona dapat mencegah masalah tersebut. ### Penyimpanan etcd[](https://kubernetes.io/id/docs/setup/best-practices/cluster-large/#penyimpanan-etcd) Untuk meningkatkan performa klaster besar, kamu dapat menyimpan objek _Event_ di _instance_ etcd terpisah. Ketika membangun sebuah klaster, kamu dapat (menggunakan alat khusus): * Nyalakan dan konfigurasikan _instance_ tambahan etcd * konfigurasikan _[API server](https://kubernetes.io/id/docs/reference/generated/kube-apiserver/) _ untuk menggunakan _instance_ etcd tambahan tersebut dalam penyimpanan _events_ Lihat juga [Mengoperasikan klaster etcd untuk Kubernetes](https://kubernetes.io/id/docs/tasks/administer-cluster/configure-upgrade-etcd/) dan [Membangun klaster etcd dengan ketersediaan tinggi (_high-availability_) menggunakan kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) untuk detail tentang konfigurasi dan mengelola etcd untuk klaster besar. Resource tambahan[](https://kubernetes.io/id/docs/setup/best-practices/cluster-large/#resource-tambahan) --------------------------------------------------------------------------------------------------------- [Batas sumber daya](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) Kubernetes membantu untuk meminimalisasi dampak dari kebocoran memori dan hal lainnya yang dapat membuat pods dan kontainer memberikan dampak terhadap komponen lainnya. Batasan sumber daya ini berlaku untuk sumber daya _[addon](https://kubernetes.io/id/docs/concepts/cluster-administration/addons/) _ layaknya berlaku untuk _workload_ aplikasi. Sebagai contoh, kamu dapat mengatur batas CPU dan memori untuk komponen _logging_ berikut ini: ... containers: - name: fluentd-cloud-logging image: fluent/fluentd-kubernetes-daemonset:v1 resources: limits: cpu: 100m memory: 200Mi Batas bawaan _addon_ biasanya diatur berdasarkan data yang dikumpulkan dari pengalaman menjalankan _addon_ pada klaster Kubernetes kecil atau menengah. Ketika menjalankan klaster besar, _addon_ biasanya menggunakan lebih banyak sumber daya dibanding batasnya. Jika klaster besar dijalankan tanpa mengubah nilai batasan, _addon_ dapat terhenti terus menerus karena mencapai batas memori. Selain itu, _addon_ dapat berjalan dengan performa buruk karena pembatasan potongan waktu (_time slice_) CPU. Untuk mencegah masalah sumber daya _addon_ di Kubernetes, saat membangun klaster dengan _node_ yang banyak, pertimbangkanlah beberapa hal berikut ini: * Beberapa _addon_ memperbesar ukurannya secara vertikal - terdapat satu replika dari _addon_ untuk satu klaster atau melayani hanya satu zona kegagalan. Untuk _addon_ tersebut, tambahkan permintaan (_request_) dan batasan ketika kamu memperbesar ukuran klaster. * Banyak _addon_ memperbesar ukurannya secara horizontal - kamu dapat menambah kapasitas dengan menjalankan lebih banyak pods - tapi dengan klaster yang sangat besar, kamu juga perlu untuk menaikan batas CPU atau memori secukupnya. [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) dapat berjalan dalam mode _recommender_ untuk menyediakan angka yang disarankan bagi permintaan dan batasan. * Beberapa _addon_ berjalan di setiap _node_ yang dikontrol oleh [DaemonSet](https://kubernetes.io/id/docs/concepts/workloads/controllers/daemonset) . Sebagai contoh, agregator log tingkat _node_. Mirip dengan kasus _addon_ yang memperbesar ukuran secara horizontal, kamu juga dapat menaikkan batas CPU dan memori secukupnya. Selanjutnya[](https://kubernetes.io/id/docs/setup/best-practices/cluster-large/#selanjutnya) --------------------------------------------------------------------------------------------- * `VerticalPodAutoscaler` adalah _custom resource_ yang dapat dijalankan di klaster untuk membantu kamu mengelola permintaan sumber daya dan batasan untuk pods. Pelajari lebih lanjut tentang [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) dan bagaimana kamu dapat menggunakannya untuk mengubah ukuran klaster. * Baca juga tentang [Node autoscaling](https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/) . * [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) membantu kamu mengubah ukuran _addon_ secara otomatis ketika ukuran klaster kamu berubah. Masukan[](https://kubernetes.io/id/docs/setup/best-practices/cluster-large/#feedback) -------------------------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/setup/best-practices/cluster-large/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/setup/best-practices/cluster-large/) . Last modified April 30, 2025 at 6:36 AM PST: [\[id\] kontainer should not be italic (aab8fda20e)](https://github.com/kubernetes/website/commit/aab8fda20efb7f3a16a9bd76a06a7b91decf63d4) --- # Image Policy API (v1alpha1) | Kubernetes Image Policy API (v1alpha1) =========================== 资源类型[](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#resource-types) --------------------------------------------------------------------------------------------------- * [ImageReview](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReview) `ImageReview`[](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReview) ------------------------------------------------------------------------------------------------------------------------------------- `` ImageReview `检查某个 Pod 中是否可以使用某些镜像。` `` | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `imagepolicy.k8s.io/v1alpha1` | | `kind`
string | `ImageReview` | | `metadata`
[`meta/v1.ObjectMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#objectmeta-v1-meta) | 标准的对象元数据。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

参阅 Kubernetes API 文档了解 `metadata` 字段的内容。 | | `spec` **\[必需\]**
[`ImageReviewSpec`](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReviewSpec) | `spec` 中包含与被评估的 Pod 相关的信息。 | | `status`
[`ImageReviewStatus`](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReviewStatus) | `status` 由后台负责填充，用来标明 Pod 是否会被准入。 | ``` `` `ImageReviewContainerSpec` `` ```[](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReviewContainerSpec) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- `` `**出现在：**` `` * `` `[ImageReviewSpec](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReviewSpec) ` `` ``` `` `ImageReviewContainerSpec` 是对 Pod 创建请求中的某容器的描述。 `` ``` | 字段 | 描述 | | --- | --- | | `image`
`string` | 此字段的格式可以是 `image:tag` 或 `image@SHA:012345679abcdef`。 | ``` `` `ImageReviewSpec` `` ```[](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReviewSpec) ----------------------------------------------------------------------------------------------------------------------------------------------------------- `` `**出现在：**` `` * `` `[ImageReview](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReview) ` `` ``` `` `ImageReviewSpec` 是对 Pod 创建请求的描述。 `` ``` | 字段 | 描述 | | --- | --- | | `containers`
[`[]ImageReviewContainerSpec`](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReviewContainerSpec) | `containers` 是一个列表，其中包含正被创建的 Pod 中各容器的信息子集。 | | `annotations`
`map[string]string` | `annotations` 是一个键值对列表，内容抽取自 Pod 的注解（``` annotations``）。 其中仅包含与模式 `*.image-policy.k8s.io/*` 匹配的键。 每个 Webhook 后端要负责决定如何解释这些注解（如果有的话）。`` ``` | | `namespace`
`string` | `namespace` 是 Pod 创建所针对的名字空间。 | ``` `` `ImageReviewStatus` `` ```[](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReviewStatus) --------------------------------------------------------------------------------------------------------------------------------------------------------------- `` `**出现在：**` `` * `` `[ImageReview](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#imagepolicy-k8s-io-v1alpha1-ImageReview) ` `` ``` `` `ImageReviewStatus` 是针对 Pod 创建请求所作的评估结果。 `` ``` | 字段 | 描述 | | --- | --- | | `allowed` **\[必需\]**
`bool` | `allowed` 表明所有镜像都可以被运行。 | | `reason`
`string` | 若 `allowed` 不是 false，`reason` 应该为空。 否则其中应包含出错信息的简短描述。Kubernetes 在向用户展示此信息时可能会截断过长的错误文字。 | | `auditAnnotations`
`map[string]string` | `auditAnnotations` 会被通过 `AddAnnotation` 添加到准入控制器的 attributes 对象上。 注解键应该不含前缀，换言之，准入控制器会添加合适的前缀。 | `` `反馈` ``[](https://kubernetes.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/#feedback) --------------------------------------------------------------------------------------------------- `` `此页是否对你有帮助？` `` `` `是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/) . ` `` `` ` 最后修改 January 07, 2026 at 10:23 AM PST: [[zh-cn]sync imagepolicy.v1alpha1 (12604e7533)](https://github.com/kubernetes/website/commit/12604e75330b9b8569fab78ae76ecb31df73b733) ` `` --- # 容器 | Kubernetes 容器 == 打包应用及其运行依赖环境的技术。 本页将讨论容器和容器镜像，以及它们在运维和解决方案开发中的应用。 **容器**是一个多义词。每当你使用这个词时，请确认你的受众是否使用相同的定义。 每个运行的容器都是可重复的； 包含依赖环境在内的标准，意味着无论你在哪里运行它都会得到相同的行为。 容器将应用程序从底层的主机设施中解耦。 这使得在不同的云或 OS 环境中部署更加容易。 Kubernetes 集群中的每个[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 都会运行容器， 这些容器构成分配给该节点的 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/) 。 单个 Pod 中的容器会在共同调度下，于同一位置运行在相同的节点上。 容器镜像[](https://kubernetes.io/zh-cn/docs/concepts/containers/#container-images) ------------------------------------------------------------------------------- [容器镜像](https://kubernetes.io/zh-cn/docs/concepts/containers/images/) 是一个随时可以运行的软件包， 包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。 容器旨在设计成无状态且[不可变的](https://glossary.cncf.io/immutable-infrastructure/) ： 你不应更改已经运行的容器的代码。如果有一个容器化的应用程序需要修改， 正确的流程是：先构建包含更改的新镜像，再基于新构建的镜像重新运行容器。 容器运行时[](https://kubernetes.io/zh-cn/docs/concepts/containers/#container-runtimes) ---------------------------------------------------------------------------------- 这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。 Kubernetes 支持许多容器运行环境，例如 [containerd](https://containerd.io/docs/) 、 [CRI-O](https://cri-o.io/#what-is-cri-o) 以及 [Kubernetes CRI (容器运行环境接口)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) 的其他任何实现。 通常，你可以允许集群为一个 Pod 选择其默认的容器运行时。如果你需要在集群中使用多个容器运行时， 你可以为一个 Pod 指定 [RuntimeClass](https://kubernetes.io/zh-cn/docs/concepts/containers/runtime-class/) ， 以确保 Kubernetes 会使用特定的容器运行时来运行这些容器。 你还可以通过 RuntimeClass，使用相同的容器运行时，但使用不同设定的配置来运行不同的 Pod。 * * * ##### [容器环境](https://kubernetes.io/zh-cn/docs/concepts/containers/container-environment/) ##### [容器生命周期回调](https://kubernetes.io/zh-cn/docs/concepts/containers/container-lifecycle-hooks/) ##### [容器运行时接口（CRI）](https://kubernetes.io/zh-cn/docs/concepts/containers/cri/) 反馈[](https://kubernetes.io/zh-cn/docs/concepts/containers/#feedback) --------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/containers/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/containers/) . 最后修改 October 14, 2024 at 9:17 PM PST: [\[zh-cn\] sync concepts/containers/\_index.md (7addd65274)](https://github.com/kubernetes/website/commit/7addd652742690854569252b70d61130bccea271) --- # 노드 레퍼런스 정보 | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Node Reference Information](https://kubernetes.io/docs/reference/node/) 노드 레퍼런스 정보 ========== 이 섹션에서는 노드에 관한 다음의 레퍼런스 주제를 다룬다. * kubelet의 [체크포인트 API](https://kubernetes.io/ko/docs/reference/node/kubelet-checkpoint-api/) * [도커심 제거 및 CRI 호환 런타임 사용에 대한 글](https://kubernetes.io/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) 목록 다음과 같은 다른 쿠버네티스 문서에서도 노드 레퍼런스 상세에 대해 읽어볼 수 있다. * [노드 메트릭 데이터](https://kubernetes.io/ko/docs/reference/instrumentation/node-metrics/) . 피드백[](https://kubernetes.io/ko/docs/reference/node/#feedback) -------------------------------------------------------------- 이 페이지가 도움이 되었나요? 네 아니요 피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 원한다면 GitHub 리포지터리에 이슈를 열어서 [문제 리포트](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/ko/docs/reference/node/) 또는 [개선 제안이 가능합니다.](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/ko/docs/reference/node/) . 최종 수정 June 07, 2023 at 5:58 PM PST: [\[ko\] Update links in dev-1.26-ko.1 (00461e0912)](https://github.com/kubernetes/website/commit/00461e09121809c80d80bda50173ba1958e00567) --- # Imagens | Kubernetes **Este documento pode estar desatualizado** Este documento possui uma data de atualização mais antiga que o documento original. Portanto, este conteúdo pode estar desatualizado. Se você lê inglês, veja a versão em inglês para acessar a versão mais atualizada: [Images](https://kubernetes.io/docs/concepts/containers/images/) Imagens ======= Uma imagem de contêiner representa dados binários que encapsulam uma aplicação e todas as suas dependências de software. As imagens de contêiner são pacotes de software executáveis que podem ser executados de forma autônoma e que fazem suposições muito bem definidas sobre seu agente de execução do ambiente. Normalmente, você cria uma imagem de contêiner da sua aplicação e a envia para um registro antes de fazer referência a ela em um [Pod](https://kubernetes.io/pt-br/docs/concepts/workloads/pods/) . Esta página fornece um resumo sobre o conceito de imagem de contêiner. #### Nota: Se você está procurando pelas imagens de contêiner de uma versão do Kubernetes (como a v1.35, a versão menor mais recente), visite [Download Kubernetes](https://kubernetes.io/releases/download/) . Nomes das imagens[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#nomes-das-imagens) ---------------------------------------------------------------------------------------------------- As imagens de contêiner geralmente recebem um nome como `pause`, `exemplo/meuconteiner`, ou `kube-apiserver`. As imagens também podem incluir um hostname de algum registro; por exemplo: `exemplo.registro.ficticio/nomeimagem`, e um possível número de porta; por exemplo: `exemplo.registro.ficticio:10443/nomeimagem`. Se você não especificar um nome de host do registro, o Kubernetes assume que você está se referindo ao [registro público do Docker](https://hub.docker.com/) . Você pode alterar esse comportamento definindo um registro de imagem padrão na configuração do [agente de execução do contêiner](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) . Após a parte do nome da imagem, você pode adicionar uma _tag_ ou _digest_ (da mesma forma que faria ao usar comandos como `docker` ou `podman`). As tags permitem identificar diferentes versões da mesma série de imagens. Digests são identificadores únicos para uma versão específica de uma imagem. Digests são hashes do conteúdo da imagem e são imutáveis. As tags podem ser movidas para apontar para imagens diferentes, mas os digests são fixos. Tags de imagem consistem em letras minúsculas e maiúsculas, dígitos, sublinhados (`_`), pontos (`.`) e hifens (`-`). Elas podem ter até 128 caracteres de comprimento e devem seguir o seguinte padrão de expressão regular: `[a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}`. Você pode ler mais sobre e encontrar a expressão regular de validação na [Especificação de Distribuição OCI](https://github.com/opencontainers/distribution-spec/blob/master/spec.md#workflow-categories) . Se você não especificar uma tag, o Kubernetes assume que você está se referindo à tag `latest`. Digests de imagem consistem em um algoritmo de hash (como `sha256`) e um valor de hash. Por exemplo: `sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07`. Você pode encontrar mais informações sobre o formato de digests na [Especificação de Imagem OCI](https://github.com/opencontainers/image-spec/blob/master/descriptor.md#digests) . Alguns exemplos de nomes de imagem que o Kubernetes pode usar são: * `busybox` - Nome da imagem apenas, sem tag ou digest. O Kubernetes usará o registro público do Docker e a tag `latest`. (Equivalente a `docker.io/library/busybox:latest`) * `busybox:1.32.0` - Nome da imagem com tag. O Kubernetes usará o registro público do Docker. (Equivalente a `docker.io/library/busybox:1.32.0`) * `registry.k8s.io/pause:latest` - Nome da imagem com um registro personalizado e tag `latest`. * `registry.k8s.io/pause:3.5` - Nome da imagem com um registro personalizado e tag diferente de `latest`. * `registry.k8s.io/pause@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07` - Nome da imagem com digest. * `registry.k8s.io/pause:3.5@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07` - Nome da imagem com tag e digest. Apenas o digest será usado para o download. Atualizando imagens[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#atualizando-imagens) -------------------------------------------------------------------------------------------------------- Quando você cria um [Deployment](https://kubernetes.io/pt-br/docs/concepts/workloads/controllers/deployment/) , [StatefulSet](https://kubernetes.io/pt-br/docs/concepts/workloads/controllers/statefulset/) , Pod ou outro objeto que inclua um template de Pod, por padrão a política utilizada para baixar as imagens dos contêineres nesse Pod será definida como `IfNotPresent` quando não especificada explicitamente. Essa política faz com que o [kubelet](https://kubernetes.io/pt-br/docs/reference/command-line-tools-reference/kubelet) ignore o download da imagem se ela já existir. ### Política de download de imagem[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#pol%C3%ADtica-de-download-de-imagem) A `imagePullPolicy` de um contêiner e a tag da imagem afetam quando o [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) tenta puxar (download) a imagem especificada. Aqui está uma lista dos valores que você pode definir para `imagePullPolicy` e os efeitos que esses valores têm: `IfNotPresent` a imagem será baixada apenas se não estiver presente localmente. `Always` toda vez que o kubelet iniciar um contêiner, ele consultará o registro de imagens de contêiner para resolver o nome para um [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier) . Se o kubelet tiver uma imagem de contêiner com exatamente esse digest em cache local, ele usará a imagem em cache; caso contrário, o kubelet fará o download da imagem com o digest resolvido e usará essa imagem para iniciar o contêiner. `Never` o kubelet não tenta buscar a imagem. Se a imagem já estiver presente localmente de alguma forma, o kubelet tentará iniciar o contêiner; caso contrário, a inicialização falhará. Veja [imagens pré-baixadas](https://kubernetes.io/pt-br/docs/concepts/containers/images/#pre-pulled-images) para mais detalhes. A semântica de cache do provedor de imagens subjacente torna mesmo `imagePullPolicy: Always` eficiente, desde que o registro esteja acessível de forma confiável. Seu agente de execução de contêiner pode perceber que as camadas da imagem já existem no nó, evitando que precisem ser baixadas novamente. #### Nota: Você deve evitar o uso da tag `:latest` ao implantar contêineres em produção, pois isso torna mais difícil rastrear qual versão da imagem está em execução e também dificulta realizar um rollback corretamente. Em vez disso, especifique uma tag significativa como `v1.42.0` e/ou um digest. Para garantir que o Pod sempre use a mesma versão de uma imagem de contêiner, você pode especificar o digest da imagem; substitua `:` por `@` (por exemplo, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). Ao usar tags de imagem, se o registro de imagens alterar o código que a tag representa, você pode acabar com uma mistura de Pods executando o código antigo e o novo. Um digest de imagem identifica de forma única uma versão específica da imagem, então o Kubernetes executa o mesmo código sempre que inicia um contêiner com aquele nome de imagem e digest especificado. Especificar uma imagem por digest fixa o código que será executado, de modo que uma alteração no registro não leve a essa mistura de versões. Existem [controladores de admissão](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) de terceiros que mutam Pods (e templates de Pods) quando eles são criados, de forma que a carga de trabalho em execução seja definida com base em um digest de imagem em vez de uma tag. Isso pode ser útil se você quiser garantir que toda sua carga de trabalho esteja executando o mesmo código, independentemente das mudanças de tags no registro. #### Política padrão de download de imagem[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#imagepullpolicy-defaulting) Quando você (ou um controlador) envia um novo Pod para o servidor de API, seu cluster define o campo `imagePullPolicy` quando certas condições são atendidas: * se você omitir o campo `imagePullPolicy` e especificar o digest da imagem do contêiner, o `imagePullPolicy` será automaticamente definido como `IfNotPresent`; * se você omitir o campo `imagePullPolicy` e a tag da imagem do contêiner for `:latest`, o `imagePullPolicy` será automaticamente definido como `Always`; * se você omitir o campo `imagePullPolicy` e não especificar uma tag para a imagem do contêiner, o `imagePullPolicy` será automaticamente definido como `Always`; * se você omitir o campo `imagePullPolicy` e especificar uma tag para a imagem do contêiner que não seja `:latest`, o `imagePullPolicy` será automaticamente definido como `IfNotPresent`. #### Nota: O valor de `imagePullPolicy` do contêiner é sempre definido quando o objeto é _criado_ pela primeira vez, e não é atualizado se a tag ou o digest da imagem for alterado posteriormente. Por exemplo, se você criar um Deployment com uma imagem cuja tag _não_ é `:latest`, e mais tarde atualizar a imagem desse Deployment para a tag `:latest`, o campo `imagePullPolicy` _NÃO_ será alterado para `Always`. Você deve alterar manualmente a política de puxar imagem de qualquer objeto após sua criação inicial. #### Download obrigatório da imagem[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#download-obrigat%C3%B3rio-da-imagem) Se você deseja forçar sempre o download da imagem, pode fazer uma das seguintes opções: * Defina o `imagePullPolicy` do contêiner como `Always`. * Omita o `imagePullPolicy` e use `:latest` como a tag da imagem a ser usada; o Kubernetes definirá a política como `Always` ao enviar o Pod. * Omita o `imagePullPolicy` e a tag da imagem a ser usada; o Kubernetes definirá a política como `Always` ao enviar o Pod. * Ative o controlador de admissão [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) . ### ImagePullBackOff[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#imagepullbackoff) Quando o kubelet começa a criar contêineres para um Pod usando um agente de execução de contêiner, é possível que o contêiner esteja no estado [Waiting](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) devido a `ImagePullBackOff`. O status `ImagePullBackOff` significa que um contêiner não pôde ser iniciado porque o Kubernetes não conseguiu fazer o download da imagem do contêiner (por motivos como nome de imagem inválido ou tentativa de download de um registro privado sem `imagePullSecret`). A parte `BackOff` indica que o Kubernetes continuará tentando fazer o download da imagem, com um atraso incremental entre as tentativas. O Kubernetes aumenta o intervalo entre cada tentativa até atingir um limite definido no código, que é de 300 segundos (5 minutos). ### Download de imagem por classe de agente de execução[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#download-de-imagem-por-classe-de-agente-de-execu%C3%A7%C3%A3o) ESTADO DA FUNCIONALIDADE: `Kubernetes v1.29 [alpha]`(desabilitado por padrão) O Kubernetes inclui suporte em estado alpha para realizar o download de imagens com base na RuntimeClass de um Pod. Se você habilitar o [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) `RuntimeClassInImageCriApi`, o kubelet passará a referenciar imagens de contêiner por uma tupla (nome da imagem, manipulador de agente de execução) em vez de apenas pelo nome da imagem ou digest. Seu [agente de execução do contêiner](https://kubernetes.io/pt-br/docs/setup/production-environment/container-runtimes) pode adaptar seu comportamento com base no manipulador de agente de execução selecionado. Fazer download de imagens com base na classe de agente de execução será útil para contêineres baseados em máquina virtual, como contêineres do tipo Windows Hyper-V. Downloads de imagem em série e em paralelo[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#downloads-de-imagem-em-s%C3%A9rie-e-em-paralelo) ----------------------------------------------------------------------------------------------------------------------------------------------------------- Por padrão, o kubelet realiza downloads de imagens de forma sequencial. Em outras palavras, o kubelet envia apenas uma solicitação de download de imagem por vez para o serviço de imagens. Outras solicitações de download precisam aguardar até que a solicitação em andamento seja concluída. Os Nós tomam decisões de download de imagem de forma isolada. Mesmo quando você usa downloads de imagem em série, dois Nós diferentes podem puxar a mesma imagem em paralelo. Se você quiser habilitar downloads de imagem em paralelo, pode definir o campo `serializeImagePulls` como `false` na [configuração do kubelet](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/) . Com `serializeImagePulls` definido como `false`, as solicitações de download de imagem serão enviadas imediatamente para o serviço de imagens, permitindo que várias imagens sejam puxadas ao mesmo tempo. Ao habilitar downloads de imagem em paralelo, certifique-se de que o serviço de imagens do seu agente de execução do contêiner pode lidar com esse tipo de operação. O kubelet nunca realiza download de múltiplas imagens em paralelo para um único Pod. Por exemplo, se você tiver um Pod com um Init Container e um contêiner de aplicação, os downloads de imagem desses dois contêineres não serão paralelizados. No entanto, se você tiver dois Pods que usam imagens diferentes, o kubelet puxará as imagens em paralelo para os dois Pods diferentes, quando o download paralelo estiver habilitado. ### Máximo de downloads de imagem em paralelo[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#m%C3%A1ximo-de-downloads-de-imagem-em-paralelo) ESTADO DA FUNCIONALIDADE: `Kubernetes v1.32 [beta]` Quando `serializeImagePulls` está definido como `false`, o kubelet, por padrão, não impõe limite ao número máximo de imagens sendo puxadas ao mesmo tempo. Se você quiser limitar a quantidade de downloads de imagem paralelos, pode definir o campo `maxParallelImagePulls` na configuração do kubelet. Com `maxParallelImagePulls` definido como _n_, apenas _n_ imagens podem ser puxadas simultaneamente, e qualquer download de imagem além de _n_ terá que aguardar até que pelo menos um download em andamento seja concluído. Limitar o número de downloads de imagem paralelos ajuda a evitar que o processo de download consuma muita largura de banda de rede ou I/O de disco quando esta funcionalidade estiver habilitada. Você pode definir `maxParallelImagePulls` para um número positivo maior ou igual a 1. Se você definir `maxParallelImagePulls` como maior ou igual a 2, também deverá definir `serializeImagePulls` como `false`. O kubelet não iniciará se as configurações de `maxParallelImagePulls` forem inválidas. Multiarquitetura de imagens com índice de imagens[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#multiarquitetura-de-imagens-com-%C3%ADndice-de-imagens) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Além de fornecer o binário das imagens, um registro de contêiner também pode servir um [índice de imagem do contêiner](https://github.com/opencontainers/image-spec/blob/master/image-index.md) . Um índice de imagem pode apontar para múltiplos [manifestos da imagem](https://github.com/opencontainers/image-spec/blob/master/manifest.md) para versões específicas de arquitetura de um contêiner. A ideia é que você possa ter um nome para uma imagem (por exemplo: `pause`, `exemple/meuconteiner`, `kube-apiserver`) e permitir que diferentes sistemas busquem o binário da imagem correta para a arquitetura de máquina que estão usando. O próprio Kubernetes normalmente nomeia as imagens de contêiner com o sufixo `-$(ARCH)`. Para retrocompatibilidade, gere as imagens mais antigas com sufixos. A ideia é gerar a imagem `pause` que tem o manifesto para todas as arquiteturas e `pause-amd64` que é retrocompatível com as configurações anteriores ou arquivos YAML que podem ter codificado as imagens com sufixos. Usando um registro privado[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#usando-um-registro-privado) ---------------------------------------------------------------------------------------------------------------------- Os registros privados podem exigir chaves para acessar as imagens deles. As credenciais podem ser fornecidas de várias maneiras: * Configurando nós para autenticação em um registro privado * todos os pods podem ler qualquer registro privado configurado * requer configuração de nó pelo administrador do cluster * Imagens pré-obtidas * todos os pods podem usar qualquer imagem armazenada em cache em um nó * requer acesso root a todos os nós para configurar * Especificando ImagePullSecrets em um Pod * apenas pods que fornecem chaves próprias podem acessar o registro privado * Extensões locais ou específicas do fornecedor * se estiver usando uma configuração de nó personalizado, você (ou seu provedor de nuvem) pode implementar seu mecanismo para autenticar o nó ao registro do contêiner. Essas opções são explicadas com mais detalhes abaixo. ### Configurando nós para autenticação em um registro privado[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#configurando-n%C3%B3s-para-autentica%C3%A7%C3%A3o-em-um-registro-privado) As instruções específicas para configurar as credenciais dependem do agente de execução de contêiner e do registro que você escolheu utilizar. Você deve consultar a documentação da sua solução para obter as informações mais precisas. Para um exemplo de configuração de um registro de imagens de contêiner privado, veja a tarefa [Realizar download de uma Imagem a partir de um Registro Privado](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry) . Esse exemplo utiliza um registro privado no Docker Hub. ### Provedor de credenciais do kubelet para downloads de imagem autenticados[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#kubelet-credential-provider) #### Nota: Essa abordagem é especialmente adequada quando o kubelet precisa buscar credenciais de registro de forma dinâmica. É mais comumente usada com registros fornecidos por provedores de nuvem, onde os tokens de autenticação têm vida curta. Você pode configurar o kubelet para invocar um binário de plugin a fim de buscar dinamicamente as credenciais de registro para uma imagem de contêiner. Essa é a maneira mais robusta e versátil de obter credenciais para registros privados, mas também exige uma configuração no nível do kubelet para ser habilitada. Veja [Configurar um provedor de credenciais de imagem no kubelet](https://kubernetes.io/pt-br/docs/tasks/administer-cluster/kubelet-credential-provider/) para mais detalhes. ### Interpretação do config.json[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#config-json) A interpretação do `config.json` varia entre a implementação original do Docker e a interpretação feita pelo Kubernetes. No Docker, as chaves em `auths` podem especificar apenas URLs raiz, enquanto o Kubernetes permite URLs com _glob_ e também caminhos com correspondência por prefixo. A única limitação é que os padrões _glob_ (`*`) devem incluir o ponto (`.`) para cada subdomínio. A quantidade de subdomínios correspondentes deve ser igual à quantidade de padrões glob (`*.`), por exemplo: * `*.kubernetes.io` _não_ corresponderá a `kubernetes.io`, mas corresponderá a `abc.kubernetes.io` * `*.*.kubernetes.io` _não_ corresponderá a `abc.kubernetes.io`, mas corresponderá a `abc.def.kubernetes.io` * `prefix.*.io` corresponderá a `prefix.kubernetes.io` * `*-good.kubernetes.io` corresponderá a `prefix-good.kubernetes.io` Isso significa que um `config.json` como este é válido: { "auths": { "my-registry.io/images": { "auth": "…" }, "*.my-registry.io/images": { "auth": "…" } } } As operações de pull de imagem agora passarão as credenciais para o agente de execução de contêiner via CRI para cada padrão válido. Por exemplo, os seguintes nomes de imagem de contêiner corresponderiam com sucesso: * `my-registry.io/images` * `my-registry.io/images/my-image` * `my-registry.io/images/another-image` * `sub.my-registry.io/images/my-image` Mas não: * `a.sub.my-registry.io/images/my-image` * `a.b.sub.my-registry.io/images/my-image` O kubelet realiza downloads de imagem de forma sequencial para cada credencial encontrada. Isso significa que múltiplas entradas no `config.json` para caminhos diferentes também são possíveis: { "auths": { "my-registry.io/images": { "auth": "…" }, "my-registry.io/images/subpath": { "auth": "…" } } } Se agora um contêiner especificar uma imagem `my-registry.io/images/subpath/my-image` para ser baixada, o kubelet tentará fazer o download utilizando ambas as fontes de autenticação, caso uma delas falhe. ### Imagens pré-obtidas[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#pre-pulled-images) #### Nota: Essa abordagem é adequada se você puder controlar a configuração do nó. Isto não funcionará de forma confiável se o seu provedor de nuvem for responsável pelo gerenciamento de nós e os substituir automaticamente. Por padrão, o kubelet tenta realizar um "pull" para cada imagem do registro especificado. No entanto, se a propriedade `imagePullPolicy` do contêiner for definida como `IfNotPresent` ou `Never`, em seguida, uma imagem local é usada (preferencial ou exclusivamente, respectivamente). Se você quiser usar imagens pré-obtidas como um substituto para a autenticação do registro, você deve garantir que todos os nós no cluster tenham as mesmas imagens pré-obtidas. Isso pode ser usado para pré-carregar certas imagens com o intuíto de aumentar a velocidade ou como uma alternativa para autenticação em um registro privado. Todos os pods terão permissão de leitura a quaisquer imagens pré-obtidas. ### Especificando imagePullSecrets em um pod[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#especificando-imagepullsecrets-em-um-pod) #### Nota: Esta é a abordagem recomendada para executar contêineres com base em imagens de registros privados. O Kubernetes oferece suporte à especificação de chaves de registro de imagem de contêiner em um Pod. Todos os `imagePullSecrets` devem estar no mesmo namespace que o Pod. Os Secrets referenciados devem ser do tipo `kubernetes.io/dockercfg` ou `kubernetes.io/dockerconfigjson`. #### Criando um segredo com Docker config[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#criando-um-segredo-com-docker-config) Você precisa saber o nome de usuário, a senha do registro, o endereço de e-mail do cliente para autenticação no registro, além do nome do host. Execute o seguinte comando, substituindo os valores em letras maiúsculas pelos apropriados: kubectl create secret docker-registry \ --docker-server=DOCKER_REGISTRY_SERVER \ --docker-username=DOCKER_USER \ --docker-password=DOCKER_PASSWORD \ --docker-email=DOCKER_EMAIL Se você já tem um arquivo de credenciais do Docker, em vez de usar o comando acima, você pode importar o arquivo de credenciais como um Kubernetes [Secrets](https://kubernetes.io/pt-br/docs/concepts/configuration/secret/) . [Criar um segredo com base nas credenciais Docker existentes](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explica como configurar isso. Isso é particularmente útil se você estiver usando vários registros privados de contêineres, como `kubectl create secret docker-registry` cria um Segredo que só funciona com um único registro privado. #### Nota: Os pods só podem fazer referência a _pull secrets_ de imagem em seu próprio namespace, portanto, esse processo precisa ser feito uma vez por namespace. #### Referenciando um imagePullSecrets em um pod[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#referenciando-um-imagepullsecrets-em-um-pod) Agora, você pode criar Pods que referenciam esse Secret adicionando uma seção `imagePullSecrets` na definição do Pod. Cada item no array `imagePullSecrets` pode referenciar apenas um Secret no mesmo namespace. Por exemplo: cat < pod.yaml apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey EOF cat <> ./kustomization.yaml resources: - pod.yaml EOF Isso precisa ser feito para cada pod que está usando um registro privado. No entanto, a configuração deste campo pode ser automatizada definindo o imagePullSecrets em um recurso de [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) . Verifique [Adicionar ImagePullSecrets a uma conta de serviço](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) para obter instruções detalhadas. Você pode usar isso em conjunto com um `.docker / config.json` por nó. As credenciais serão mescladas. Casos de uso[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#casos-de-uso) ------------------------------------------------------------------------------------------ Existem várias soluções para configurar registros privados. Aqui estão alguns casos de uso comuns e soluções sugeridas. 1. Cluster executando apenas imagens não proprietárias (por exemplo, código aberto). Não há necessidade de ocultar imagens. * Use imagens públicas no Docker hub. * Nenhuma configuração necessária. * Alguns provedores de nuvem armazenam em cache ou espelham automaticamente imagens públicas, o que melhora a disponibilidade e reduz o tempo para extrair imagens. 2. Cluster executando algumas imagens proprietárias que devem ser ocultadas para quem está fora da empresa, mas visível para todos os usuários do cluster. * Use um [registro Docker](https://docs.docker.com/registry/) privado hospedado. * Pode ser hospedado no [Docker Hub](https://hub.docker.com/signup) ou em outro lugar. * Configure manualmente .docker/config.json em cada nó conforme descrito acima. * Ou execute um registro privado interno atrás de seu firewall com permissão de leitura. * Nenhuma configuração do Kubernetes é necessária. * Use um serviço de registro de imagem de contêiner que controla o acesso à imagem * Funcionará melhor com o escalonamento automático do cluster do que com a configuração manual de nós. * Ou, em um cluster onde alterar a configuração do nó é inconveniente, use `imagePullSecrets`. 3. Cluster com imagens proprietárias, algumas das quais requerem controle de acesso mais rígido. * Certifique-se de que o [controlador de admissão AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) está ativo. Caso contrário, todos os pods têm potencialmente acesso a todas as imagens. * Mova dados confidenciais para um recurso "secreto", em vez de empacotá-los em uma imagem. 4. Um cluster multilocatário em que cada locatário precisa de seu próprio registro privado. * Certifique-se de que o [controlador de admissão AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) está ativo. Caso contrário, todos os Pods de todos os locatários terão potencialmente acesso a todas as imagens. * Execute um registro privado com autorização necessária. * Gere credenciais de registro para cada locatário, coloque em segredo e preencha o segredo para cada namespace de locatário. * O locatário adiciona esse segredo a imagePullSecrets de cada namespace. Se precisar de acesso a vários registros, você pode criar um segredo para cada registro. Provedor de credenciais legado embutido no kubelet[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#provedor-de-credenciais-legado-embutido-no-kubelet) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Em versões mais antigas do Kubernetes, o kubelet tinha uma integração direta com as credenciais de provedores de nuvem. Isso permitia buscar dinamicamente as credenciais para registros de imagens. Havia três implementações embutidas do provedor de credenciais do kubelet: ACR (Azure Container Registry), ECR (Elastic Container Registry) e GCR (Google Container Registry). Para mais informações sobre o mecanismo legado, consulte a documentação da versão do Kubernetes que você está utilizando. As versões do Kubernetes da v1.26 até a v1.35 não incluem mais esse mecanismo legado, portanto, você precisará: * configurar um provedor de credenciais de imagem no kubelet em cada nó * ou especificar credenciais de download de imagem usando `imagePullSecrets` e pelo menos um Secret Próximos passos[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#pr%C3%B3ximos-passos) ----------------------------------------------------------------------------------------------------- * Leia a [Especificação do Manifesto de Imagem OCI](https://github.com/opencontainers/image-spec/blob/master/manifest.md) * Saiba mais sobre [coleta de lixo de imagens de contêiner](https://kubernetes.io/pt-br/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection) . * Saiba mais sobre [realizar download de uma imagem a partir de um registro privado](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry) . Comentários[](https://kubernetes.io/pt-br/docs/concepts/containers/images/#feedback) ------------------------------------------------------------------------------------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/pt-br/docs/concepts/containers/images/) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/pt-br/docs/concepts/containers/images/) . Última modificação April 13, 2025 at 8:40 PM PST: [\[pt-br\] Update concepts/containers/images (#50183) (71f58940d3)](https://github.com/kubernetes/website/commit/71f58940d3b42f34ce08d190d115e052a817535e) --- # 네트워킹 레퍼런스 | Kubernetes 네트워킹 레퍼런스 ========= 이 섹션에서는 쿠버네티스 네트워킹의 레퍼런스 상세를 제공한다. * * * ##### [서비스가 지원하는 프로토콜](https://kubernetes.io/ko/docs/reference/networking/service-protocols/) ##### [포트와 프로토콜](https://kubernetes.io/ko/docs/reference/networking/ports-and-protocols/) ##### [가상 IP 및 서비스 프록시](https://kubernetes.io/ko/docs/reference/networking/virtual-ips/) 피드백[](https://kubernetes.io/ko/docs/reference/networking/#feedback) -------------------------------------------------------------------- 이 페이지가 도움이 되었나요? 네 아니요 피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 원한다면 GitHub 리포지터리에 이슈를 열어서 [문제 리포트](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/ko/docs/reference/networking/) 또는 [개선 제안이 가능합니다.](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/ko/docs/reference/networking/) . 최종 수정 February 02, 2023 at 5:53 PM PST: [\[ko\] Update outdated files in dev-1.26-ko.1 M67 (5c6199cb0c)](https://github.com/kubernetes/website/commit/5c6199cb0c869d4a5e396c516f021af2cd25134a) --- # Persistent Volume | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) Persistent Volume ================= Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](https://kubernetes.io/id/docs/concepts/storage/volumes/) . Pengenalan[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#pengenalan) -------------------------------------------------------------------------------------------- Mengelola penyimpanan adalah hal yang berbeda dengan mengelola komputasi. Sub-sistem `PersistentVolume` (PV) menyediakan API untuk para pengguna dan administrator yang mengabstraksi detail-detail tentang bagaimana penyimpanan disediakan dari bagaimana penyimpanan dikonsumsi. Untuk melakukan ini, kami mengenalkan dua sumber daya API baru: `PersistentVolume` (PV) dan `PersistentVolumeClaim` (PVC). Sebuah `PersistentVolume` (PV) adalah suatu bagian dari penyimpanan pada klaster yang telah disediakan oleh seorang administrator. PV merupakan sebuah sumber daya pada klaster sama halnya dengan _node_ yang juga merupakan sumber daya klaster. PV adalah _volume plugin_ seperti _Volumes_, tetapi memiliki siklus hidup yang independen dari _pod_ individual yang menggunakan PV tersebut. Objek API ini menangkap detail-detail implementasi dari penyimpanan, seperti NFS, iSCSI, atau sistem penyimpanan yang spesifik pada penyedia layanan _cloud_. Sebuah `PersistentVolumeClaim` (PVC) merupakan permintaan penyimpanan oleh pengguna. PVC mirip dengan sebuah _pod_. _Pod_ mengonsumsi sumber daya _node_ dan PVC mengonsumsi sumber daya PV. _Pods_ dapat meminta taraf-taraf spesifik dari sumber daya (CPU dan Memory). Klaim dapat meminta ukuran dan mode akses yang spesifik (seperti, dapat dipasang sekali sebagai _read/write_ atau lain kali sebagai _read-only_). Meskipun `PersistentVolumeClaims` mengizinkan pengguna untuk mengkonsumsi sumber daya penyimpanan abstrak, pada umumnya para pengguna membutuhkan `PersistentVolumes` dengan properti yang bermacam-macam, seperti performa, untuk mengatasi masalah yang berbeda. Para administrator klaster harus dapat menawarkan berbagai macam `PersistentVolumes` yang berbeda tidak hanya pada ukuran dan mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimplementasikan kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya `StorageClass`. Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](https://kubernetes.io/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage/) . Siklus hidup dari sebuah volume dan klaim[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#siklus-hidup-dari-sebuah-volume-dan-klaim) ---------------------------------------------------------------------------------------------------------------------------------------------------------- PV adalah sumber daya dalam sebuah klaster. PVC adalah permintaan terhadap sumber daya tersebut dan juga berperan sebagai pemeriksaan klaim dari sumber daya yang diminta. Interaksi antara PV dan PVC mengikuti siklus hidup berikut ini: ### Penyediaan[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#penyediaan) Ada dua cara untuk menyediakan PV: secara statis atau dinamis. #### Statis[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#statis) Seorang administrator klaster membuat beberapa PV. PV yang telah dibuat membawa detail-detail dari penyimpanan yang sesungguhnya tersedia untuk digunakan oleh pengguna klaster. PV tersebut ada pada Kubernetes API dan siap untuk digunakan. #### Dinamis[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#dinamis) Ketika tidak ada PV statis yang dibuat oleh administrator yang sesuai dengan `PersistentVolumeClaim` (PVC) yang dibuat oleh pengguna, klaster akan mencoba untuk menyediakan volume khusus sesuai permintaan PVC. Penyediaan dinamis ini berbasis `StorageClass`: artinya PVC harus meminta sebuah _storage class_ dan _storage class_ tersebut harus sudah dibuat dan dikonfigurasi oleh administrator agar penyediaan dinamis bisa terjadi. Klaim yang meminta PV dengan _storage class_ `""` secara efektif telah menonaktifkan penyediaan dinamis. Untuk mengaktifkan penyediaan _storage_ dinamis berdasarkan _storage class_, administrator klaster harus mengaktifkan [_admission controller_](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` pada API _server_. Hal ini dapat dilakukan, dengan cara memastikan `DefaultStorageClass` ada di antara urutan daftar _value_ yang dibatasi koma untuk _flag_ `--enable-admission-plugins` pada komponen API _server_. Untuk informasi lebih lanjut mengenai _flag_ perintah pada API _server_, silakan cek dokumentasi, [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver/) . ### Pengikatan[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#pengikatan) Seorang pengguna membuat, atau telah membuat (dalam kasus penyediaan dinamis), sebuah `PersistentVolumeClaim` (PVC) dengan jumlah penyimpanan spesifik yang diminta dan dengan mode akses tertentu. Sebuah _control loop_ pada _master_ akan melihat adanya PVC baru, mencari PV yang cocok (jika memungkinkan), dan mengikat PVC dengan PV tersebut. Jika sebuah PV disediakan secara dinamis untuk sebuah PVC baru, _loop_ tersebut akan selalu mengikat PV tersebut pada PVC yang baru dibuat itu. Jika tidak, pengguna akan selalu mendapatkan setidaknya apa yang dimintanya, tetapi volume tersebut mungkin lebih dari apa yang diminta sebelumnya. Setelah terikat, ikatan `PersistentVolumeClaim` (PVC) bersifat eksklusif, terlepas dari bagaimana caranya mereka bisa terikat. Sebuah ikatan PVC ke PV merupakan pemetaan satu ke satu. Klaim akan berada dalam kondisi tidak terikat tanpa kepastian jika tidak ada volume yang cocok. Klaim akan terikat dengan volume yang cocok ketika ada volume yang cocok. Sebagai contoh, sebuah klaster yang sudah menyediakan banyak PV berukuran 50Gi tidak akan cocok dengan PVC yang meminta 100Gi. PVC hanya akan terikat ketika ada PV 100Gi yang ditambahkan ke klaster. ### Penggunaan[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#penggunaan) _Pod_ menggunakan klaim sebagai volume. Klaster menginspeksi klaim untuk menemukan volume yang terikat dengan klaim tersebut dan memasangkan volume tersebut ke pada _pod_. Untuk volume yang mendukung banyak mode akses, pengguna yang menentukan mode yang diinginkan ketika menggunakan klaim sebagai volume dalam sebuah _pod_. Ketika pengguna memiliki klaim dan klaim tersebut telah terikat, PV yang terikat menjadi hak penggunanya selama yang dibutuhkan. Pengguna menjadwalkan _pod_ dan mengakses PV yang sudah diklaim dengan menambahkan `persistentVolumeClaim` pada blok volume pada _Pod_ miliknya. [Lihat pranala di bawah untuk detail-detail mengenai sintaks](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#claims-as-volumes) . ### Object Penyimpanan dalam Perlindungan Penggunaan[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#object-penyimpanan-dalam-perlindungan-penggunaan) Tujuan dari Objek Penyimpanan dalam Perlindungan Penggunan adalah untuk memastikan _Persistent Volume Claim_ (PVC) yang sedang aktif digunakan oleh sebuah _pod_ dan _Persistent Volume_ (PV) yang terikat pada PVC tersebut tidak dihapus dari sistem karena hal ini dapat menyebabkan kehilangan data. #### Catatan: PVC dikatakan aktif digunakan oleh sebuah _pod_ ketika sebuah objek _pod_ ada yang menggunakan PVC tersebut. Jika seorang pengguna menghapus PVC yang sedang aktif digunakan oleh sebuah _pod_, PVC tersebut tidak akan langsung dihapus. Penghapusan PVC akan ditunda sampai PVC tidak lagi aktif digunakan oleh _pod_ manapun, dan juga ketika admin menghapus sebuah PV yang terikat dengan sebuah PVC, PV tersebut tidak akan langsung dihapus. Penghapusan PV akan ditunda sampai PV tidak lagi terikat dengan sebuah PVC. Kamu dapat melihat PVC yang dilindungi ketika status PVC berisi `Terminating` dan daftar `Finalizers` meliputi `kubernetes.io/pvc-protection`: kubectl describe pvc hostpath Name: hostpath Namespace: default StorageClass: example-hostpath Status: Terminating Volume: Labels: Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath Finalizers: [kubernetes.io/pvc-protection] ... Kamu dapat melihat sebuah PV dilindungi ketika status PV berisi `Terminating` dan daftar `Finalizers` juga meliputi `kubernetes.io/pv-protection`: kubectl describe pv task-pv-volume Name: task-pv-volume Labels: type=local Annotations: Finalizers: [kubernetes.io/pv-protection] StorageClass: standard Status: Available Claim: Reclaim Policy: Delete Access Modes: RWO Capacity: 1Gi Message: Source: Type: HostPath (bare host directory volume) Path: /tmp/data HostPathType: Events: ### Melakukan Reklaim[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#melakukan-reklaim) Ketika seorang pengguna telah selesai dengan volumenya, ia dapat menghapus objek PVC dari API yang memungkinkan untuk reklamasi dari sumber daya tersebut. Kebijakan reklaim dari sebuah `PersistentVolume` (PV) menyatakan apa yang dilakukan klaster setelah volume dilepaskan dari klaimnya. Saat ini, volume dapat dipertahankan (_Retained_), didaur ulang (_Recycled_), atau dihapus (_Deleted_). #### _Retain_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#retain) `Retain` merupakan kebijakan reklaim yang mengizinkan reklamasi manual dari sebuah sumber daya. Ketika `PersistentVolumeClaim` (PVC) dihapus, `PersistentVolume` (PV) masih akan tetap ada dan volume tersebut dianggap "terlepas" . Tetapi PV tersebut belum tersedia untuk klaim lainnya karena data milik pengklaim sebelumnya masih terdapat pada volume. Seorang administrator dapat mereklaim volume secara manual melalui beberapa langkah. 1. Menghapus `PersistentVolume` (PV). Aset _storage_ yang terasosiasi dengan infrastruktur eksternal (seperti AWS EBS, GCE PD, Azure Disk, atau Cinder Volume) akan tetap ada setelah PV dihapus. 2. Secara manual membersihkan data pada aset _storage_ terkait. 3. Secara manual menghapus aset _storage_, atau jika kamu ingin menggunakan aset _storage_ yang sama, buatlah sebuah `PersistentVolume` baru dengan definisi aset _storage_ tersebut. #### _Delete_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#delete) Untuk _volume plugin_ yang mendukung kebijakan reklaim `Delete`, penghapusan akan menghilangkan kedua objek dari Kubernetes, `PersistentVolume` (PV) dan juga aset _storage_ yang terasosiasi pada infrastruktur eksternal seperti, AWS EBS, GCE PD, Azure Disk, atau Cinder Volume. Volume yang disediakan secara dinamis mewarisi [kebijakan reklaim dari `StorageClass` miliknya](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#reclaim-policy) , yang secara bawaan adalah `Delete`. Administrator harus mengkonfigurasi `StorageClass` sesuai ekspektasi pengguna, jika tidak maka PV tersebut harus diubah atau ditambal setelah dibuat nanti. Lihat [Mengganti Kebijakan Reklaim pada PersistentVolume](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/) . #### _Recycle_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#recycle) #### Peringatan: Kebijakan reklaim `Recycle` sudah ditinggalkan. Sebagai gantinya, pendekatan yang direkomendasikan adalah menggunakan penyediaan dinamis. Jika didukung oleh _plugin volume_ yang berada di baliknya, kebijakan reklaim `Recycle` melakukan penghapusan dasar (`rm -rf /thevolume/*`) pada volume dan membuatnya kembali tersedia untuk klaim baru. Namun, seorang administrator dapat mengkonfigurasi templat _recycler pod_ kustom menggunakan argumen baris perintah _controller manager_ Kubernetes sebagaimana dijelaskan [di sini](https://kubernetes.io/docs/admin/kube-controller-manager/) . Templat _reycler pod_ kustom harus memiliki spesifikasi `volumes`, seperti yang ditunjukkan pada contoh di bawah: apiVersion: v1 kind: Pod metadata: name: pv-recycler namespace: default spec: restartPolicy: Never volumes: - name: vol hostPath: path: /any/path/it/will/be/replaced containers: - name: pv-recycler image: "registry.k8s.io/busybox" command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] volumeMounts: - name: vol mountPath: /scrub Namun, alamat yang dispesifikasikan pada templat _recycler pod_ kustom pada bagian `volumes` diganti dengan alamat pada volume yang akan didaur ulang. ### Memperluas _Persistent Volumes Claim_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#memperluas-persistent-volumes-claim) FEATURE STATE: `Kubernetes v1.24 [stable]` Dukungan untuk memperluas PersistentVolumeClaim (PVC) sekarang sudah diaktifkan sejak awal. Kamu dapat memperluas tipe-tipe volume berikut: * gcePersistentDisk * awsElasticBlockStore * Cinder * glusterfs * rbd * Azure File * Azure Disk * Portworx * FlexVolumes * CSI Kamu hanya dapat memperluas sebuah PVC jika kolom `allowVolumeExpansion` dipasang sebagai benar pada _storage class_ miliknya. apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gluster-vol-default provisioner: kubernetes.io/glusterfs parameters: resturl: "http://192.168.10.100:8080" restuser: "" secretNamespace: "" secretName: "" allowVolumeExpansion: true Untuk meminta volume yang lebih besar pada sebuah PVC, ubah objek PVC dan spesifikasikan ukuran yang lebih besar. Hal ini akan memicu perluasan dari volume yang berada di balik `PersistentVolume` (PV). Sebuah `PersistentVolume` (PV) baru tidak akan dibuat untuk memenuhi klaim tersebut. Sebaliknya, volume yang sudah ada akan diatur ulang ukurannya. #### Perluasan Volume CSI[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#perluasan-volume-csi) FEATURE STATE: `Kubernetes v1.14 [alpha]` Perluasan volume CSI mengharuskan kamu untuk mengaktifkan gerbang fitur `ExpandCSIVolumes` dan juga membutuhkan _driver_ CSI yang spesifik untuk mendukung perluasan volume. Silakan merujuk pada dokumentasi _driver_ spesifik CSI untuk informasi lebih lanjut. #### Mengubah ukuran sebuah volume yang memiliki _file system_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#mengubah-ukuran-sebuah-volume-yang-memiliki-file-system) Kamu hanya dapat mengubah ukuran volume yang memiliki _file system_ jika _file system_ tersebut adalah XFS, Ext3, atau Ext4. Ketika sebuah volume memiliki _file system_, _file system_ tersebut hanya akan diubah ukurannya ketika sebuah _pod_ baru dinyalakan menggunakan `PersistentVolumeClaim` (PVC) dalam mode _ReadWrite_. Maka dari itu, jika sebuah _pod_ atau _deployment_ menggunakan sebuah volume dan kamu ingin memperluasnya, kamu harus menghapus atau membuat ulang _pod_ tersebut setelah volume selesai diperluas oleh penyedia _cloud_ dalam _controller-manager_. Kamu dapat melihat status dari operasi pengubahan ukuran dengan menjalankan perintah `kubectl describe pvc`: kubectl describe pvc Jika `PersistentVolumeClaim` (PVC) memiliki status `FileSystemResizePending`, maka berarti aman untuk membuat ulang _pod_ menggunakan PersistentVolumeClaim (PVC) tersebut. FlexVolumes mengizinkan pengubahan ukuran jika _driver_ diatur dengan kapabilitas `RequiresFSResize` menjadi "_true_". FlexVolume dapat diubah ukurannya pada saat _pod_ mengalami _restart_. FEATURE STATE: `Kubernetes v1.11 [alpha]` #### Mengubah ukuran PersistentVolumeClaim (PVC) yang sedang digunakan[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#mengubah-ukuran-persistentvolumeclaim-pvc-yang-sedang-digunakan) Memperluas PVC yang sedang digunakan merupakan fitur alfa. Untuk menggunakannya, aktifkan gerbang fitur `ExpandInUsePersistentVolumes`. Pada kasus ini, kamu tidak perlu menghapus dan membuat ulang sebuah _Pod_ atau _deployment_ yang menggunakan PVC yang telah ada. PVC manapun yang sedang digunakan secara otomatis menjadi tersedia untuk _pod_ yang menggunakannya segera setelah _file system_ miliknya diperluas. Fitur ini tidak memiliki efek pada PVC yang tidak sedang digunakan oleh _Pod_ atau _deployment_. Kamu harus membuat sebuah _Pod_ yang menggunakan PVC sebelum perluasan dapat selesai dilakukan. Memperluas PVC yang sedang digunakan sudah ditambahkan pada rilis 1.13. Untuk mengaktifkan fitur ini gunakan `ExpandInUsePersistentVolumes` dan gerbang fitur `ExpandPersistentVolumes`. Gerbang fitur `ExpandPersistentVolumes` sudah diaktifkan sejak awal. Jika `ExpandInUsePersistentVolumes` sudah terpasang, FlexVolume dapat diubah ukurannya secara langsung tanpa perlu melakukan _restart_ pada _pod_. #### Catatan: Pengubahan ukuran FlexVolume hanya mungkin dilakukan ketika _driver_ yang menjalankannya mendukung pengubahan ukuran. #### Catatan: Memperluas volume EBS merupakan operasi yang memakan waktu. Terlebih lagi, ada kuota per volume untuk satu kali modifikasi setiap 6 jam. Tipe-tipe _Persistent Volume_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#tipe-tipe-persistent-volume) -------------------------------------------------------------------------------------------------------------------------------- Tipe-tipe `PersistentVolume` (PV) diimplementasikan sebagai _plugin_. Kubernetes saat ini mendukung _plugin_ berikut: * GCEPersistentDisk * AWSElasticBlockStore * AzureFile * AzureDisk * FC (Fibre Channel) * FlexVolume * Flocker * NFS * iSCSI * RBD (Ceph Block Device) * CephFS * Cinder (OpenStack block storage) * Glusterfs * VsphereVolume * Quobyte Volumes * HostPath (Hanya untuk pengujian _single node_ -- penyimpanan lokal tidak didukung dan TIDAK AKAN BEKERJA pada klaster _multi-node_) * Portworx Volumes * ScaleIO Volumes * StorageOS _Persistent Volume_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#persistent-volume) ------------------------------------------------------------------------------------------------------------ Setiap PV memiliki sebuah _spec_ dan status, yang merupakan spesifikasi dan status dari volume tersebut. apiVersion: v1 kind: PersistentVolume metadata: name: pv0003 spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow mountOptions: - hard - nfsvers=4.1 nfs: path: /tmp server: 172.17.0.2 #### Catatan: Program pembantu yang berkaitan dengan tipe volume bisa saja diperlukan untuk mengonsumsi sebuah PersistentVolume di dalam klaster. Contoh ini menggunakan PersistentVolume dengan tipe NFS dan program pembantu /sbin/mount.nfs diperlukan untuk mendukung proses mounting sistem berkas (filesystem) NFS. ### Kapasitas[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#kapasitas) Secara umum, sebuah PV akan memiliki kapasitas _storage_ tertentu. Hal ini ditentukan menggunakan atribut `capacity` pada PV. Lihat [Model Sumber Daya](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) Kubernetes untuk memahami satuan yang diharapkan pada atribut `capacity`. Saat ini, ukuran _storage_ merupakan satu-satunya sumber daya yang dapat ditentukan atau diminta. Atribut-atribut lainnya di masa depan dapat mencakup IOPS, _throughput_, dsb. ### Mode Volume[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#mode-volume) FEATURE STATE: `Kubernetes v1.13 [beta]` Sebelum Kubernetes 1.9, semua _volume plugin_ akan membuat sebuah _filesystem_ pada PersistentVolume (PV). Sekarang, kamu dapat menentukan nilai dari `volumeMode` menjadi `block` untuk menggunakan perangkat _raw block_, atau `filesystem` untuk menggunakan sebuah _filesystem_. `filesystem` menjadi standar yang digunakan jika nilainya dihilangkan. Hal ini merupakan parameter API opsional. ### Mode Akses[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#mode-akses) Sebuah `PersistentVolume` (PV) dapat dipasangkan pada sebuah _host_ dengan cara apapun yang didukung oleh penyedia sumber daya. Seperti ditunjukkan pada tabel di bawah, para penyedia akan memiliki kapabilitas yang berbeda-beda dan setiap mode akses PV akan ditentukan menjadi mode-mode spesifik yang didukung oleh tiap volume tersebut. Sebagai contoh, NFS dapat mendukung banyak klien _read/write_, tetapi sebuah NFS PV tertentu mungkin diekspor pada server sebagai _read-only_. Setiap PV memilik seperangkat mode aksesnya sendiri yang menjelaskan kapabilitas dari PV tersebut. Beberapa mode akses tersebut antara lain: * ReadWriteOnce -- volume dapat dipasang sebagai _read-write_ oleh satu _node_ * ReadOnlyMany -- volume dapat dipasang sebagai _read-only_ oleh banyak _node_ * ReadWriteMany -- volume dapat dipasang sebagai _read-write_ oleh banyak _node_ Pada CLI, mode-mode akses tersebut disingkat menjadi: * RWO - ReadWriteOnce * ROX - ReadOnlyMany * RWX - ReadWriteMany > **Penting!** Sebuah volume hanya dapat dipasang menggunakan satu mode akses dalam satu waktu, meskipun volume tersebut mendukung banyak mode. Sebagai contoh, sebuah GCEPersistentDisk dapat dipasangkan sebagai ReadWriteOnce oleh satu _node_ atau ReadOnlyMany oleh banyak node, tetapi tidak dalam waktu yang bersamaan. | Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | | --- | --- | --- | --- | | AWSElasticBlockStore | ✓ | \- | \- | | AzureFile | ✓ | ✓ | ✓ | | AzureDisk | ✓ | \- | \- | | CephFS | ✓ | ✓ | ✓ | | Cinder | ✓ | \- | \- | | FC | ✓ | ✓ | \- | | FlexVolume | ✓ | ✓ | depends on the driver | | Flocker | ✓ | \- | \- | | GCEPersistentDisk | ✓ | ✓ | \- | | Glusterfs | ✓ | ✓ | ✓ | | HostPath | ✓ | \- | \- | | iSCSI | ✓ | ✓ | \- | | Quobyte | ✓ | ✓ | ✓ | | NFS | ✓ | ✓ | ✓ | | RBD | ✓ | ✓ | \- | | VsphereVolume | ✓ | \- | \- (works when pods are collocated) | | PortworxVolume | ✓ | \- | ✓ | | ScaleIO | ✓ | ✓ | \- | | StorageOS | ✓ | \- | \- | ### Kelas[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#kelas) Sebuah PV bisa memiliki sebuah kelas, yang dispesifikasi dalam pengaturan atribut `storageClassName` menjadi nama [StorageClass](https://kubernetes.io/id/docs/concepts/storage/storage-classes/) . Sebuah PV dari kelas tertentu hanya dapat terikat dengan PVC yang meminta kelas tersebut. Sebuah PV tanpa `storageClassName` tidak memiliki kelas dan hanya dapat terikat dengan PVC yang tidak meminta kelas tertentu. Dahulu, anotasi `volume.beta.kubernetes.io/storage-class` digunakan sebagai ganti atribut `storageClassName`. Anotasi ini masih dapat bekerja, namun akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang. ### Kebijakan Reklaim[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#kebijakan-reklaim) Kebijakan-kebijakan reklaim saat ini antara lain: * Retain -- reklamasi manual * Recycle -- penghapusan dasar (`rm -rf /thevolume/*`) * Delete -- aset _storage_ terasosiasi seperti AWS EBS, GCE PD, Azure Disk, atau OpenStack Cinder volume akan dihapus Saat ini, hanya NFS dan HostPath yang mendukung daur ulang. AWS EBS, GCE PD, Azure Disk, dan Cinder Volume mendukung penghapusan. ### Opsi Pemasangan[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#opsi-pemasangan) Seorang administrator Kubernetes dapat menspesifikasi opsi pemasangan tambahan untuk ketika sebuah _Persistent Volume_ dipasangkan pada sebuah _node_. #### Catatan: Tidak semua tipe _Persistent Volume_ mendukung opsi pemasanagan. Tipe-tipe volume yang mendukung opsi pemasangan antara lain: * AWSElasticBlockStore * AzureDisk * AzureFile * CephFS * Cinder (OpenStack block storage) * GCEPersistentDisk * Glusterfs * NFS * Quobyte Volumes * RBD (Ceph Block Device) * StorageOS * VsphereVolume * iSCSI Opsi pemasangan tidak divalidasi, sehingga pemasangan akan gagal jika salah satunya tidak valid. Dahulu, anotasi `volume.beta.kubernetes.io/mount-options` digunakan sebagai ganti atribut `mountOptions`. Anotasi ini masih dapat bekerja, namun akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang. ### Afinitas Node[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#afinitas-node) #### Catatan: Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](https://kubernetes.io/id/docs/concepts/storage/volumes/#awselasticblockstore) , [GCE PD](https://kubernetes.io/id/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](https://kubernetes.io/id/docs/concepts/storage/volumes/#azuredisk) . Kamu harus mengaturnya secara eksplisit untuk volume [lokal](https://kubernetes.io/id/docs/concepts/storage/volumes/#local) . Sebuah PV dapat menspesifikasi [afinitas node](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#volumenodeaffinity-v1-core) untuk mendefinisikan batasan yang membatasi _node_ mana saja yang dapat mengakses volume tersebut. _Pod_ yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke _node_ yang dipilih oleh afinitas _node_. ### Fase[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#fase) Sebuah volume akan berada dalam salah satu fase di bawah ini: * Available -- sumber daya bebas yang belum terikat dengan sebuah klaim * Bound -- volume sudah terikat dengan sebuah klaim * Released -- klaim sudah dihapus, tetapi sumber daya masih belum direklaim oleh klaster * Failed -- volume gagal menjalankan reklamasi otomatis CLI akan menunjukkan nama dari PVC yang terikat pada PV. PersistentVolumeClaims[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) -------------------------------------------------------------------------------------------------------------------- Setiap PVC memiliki _spec_ dan status, yang merupakan spesifikasi dan status dari klaim. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 8Gi storageClassName: slow selector: matchLabels: release: "stable" matchExpressions: - {key: environment, operator: In, values: [dev]} ### Mode Akses[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#mode-akses-1) Klaim menggunakan penulisan yang sama dengan volume ketika meminta _storage_ dengan mode akses tertentu. ### Mode Volume[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#mode-volume-1) Klaim menggunakan penulisan yang sama dengan volume untuk mengindikasikan konsumsi dari volume sebagai _filesystem_ ataupun perangkat _block_. ### Sumber daya[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#sumber-daya) Klaim, seperti _pod_, bisa meminta sumber daya dengan jumlah tertentu. Pada kasus ini, permintaan untuk _storage_. [Model sumber daya](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) yang sama berlaku untuk baik volume maupun klaim. ### _Selector_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#selector) Klaim dapat menspesifikasi [_label selector_](https://kubernetes.io/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom: * `matchLabels` - volume harus memiliki label dengan nilai ini * `matchExpressions` - daftar dari persyaratan yang dibuat dengan menentukan kunci, daftar nilai, dan operator yang menghubungkan kunci dengan nilai. Operator yang valid meliputi In, NotIn, Exists, dan DoesNotExist. Semua persyaratan tersebut, dari `matchLabels` dan `matchExpressions` akan dilakukan operasi AND bersama – semuanya harus dipenuhi untuk mendapatkan kecocokan. ### Kelas[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#kelas-1) Sebuah klaim dapat meminta kelas tertentu dengan menspesifikasi nama dari [StorageClass](https://kubernetes.io/id/docs/concepts/storage/storage-classes/) menggunakan atribut `storageClassName`. Hanya PV dari kelas yang diminta, yang memiliki `storageClassName` yang sama dengan PVC, yang dapat terikat dengan PVC. PVC tidak harus meminta sebuah kelas. Sebuah PVC dengan `storageClassName` miliknya bernilai `""` akan selalu diinterpretasikan sebagai meminta PV tanpa kelas, jadi PVC hanya bisa terikat ke PV tanpa kelas (tanpa anotasi atau bernilai `""`). Sebuah PVC tanpa `storageClassName` tidaklah sama dan diperlakukan berbeda oleh klaster tergantung apakah [_admission plugin_ `DefaultStorageClass`](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) dinyalakan. * Jika _admission plugin_ dinyalakan, administrator bisa menspesifikasi `StorageClass` standar. Seluruh PVC yang tidak memiliki `storageClassName` dapat terikat hanya ke PVs standar. Menspesifikasikan `StorageClass` standar dapat dilakukan dengan mengatur anotasi `storageclass.kubernetes.io/is-default-class` menjadi "_true_" pada sebuah objek `StorageClass`. Jika administrator tidak menspesifikasikan standar apapun, klaster menanggapi pembuatan PVC sekan-akan _admission plugin_ dimatikan. Jika ada lebih dari satu setelan standar dispesifikasikan, _admission plugin_ melarang pembuatan seluruh PVC. * Jika _admission plugin_ dimatikan, tidak ada pilihan menggunakan `StorageClass` standar. Semua PVC yang tidak memiliki `storageClassName` hanya dapat diikat ke PV yang tidak memiliki kelas. Pada kasus ini, PVC yang tidak memiliki `storageClassName` diperlakukan sama seperti PVC yang memiliki `storageClassName` bernilai `""`. Tergantung metode instalasi, sebuah StorageClass dari setelan standar dapat dibuat ke klaster Kubernetes oleh _addon manager_ pada saat instalasi. Ketika sebuah PVC menspesifikasi sebuah `selector` selain meminta `StorageClass`, kebutuhan tersebut akan digabungkan dengan operasi AND bersama: hanya PV dari kelas yang diminta dan dengan label yang diminta yang dapat terikat ke PVC. #### Catatan: Saat ini, sebuah PVC dengan `selector` yang tak kosong tidak dapat memiliki PV yang disediakan secara dinamis untuknya. Dahulu, anotasi `volume.beta.kubernetes.io/storage-class` digunakan sebagai ganti atribut `storageClassName`. Anotasi ini masih dapat bekerja, namun akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang. Klaim sebagai Volume[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#klaim-sebagai-volume) ---------------------------------------------------------------------------------------------------------------- _Pod_ mengakses _storage_ dengan menggunakan klaim sebagai volume. Klaim harus berada pada _namespace_ yang sama dengan _pod_ yang menggunakan klaim tersebut. Klaster menemukan klaim pada _namespace_ yang sama dengan _pod_ dan menggunakannya untuk mendapatkan `PersistentVolume` (PV) yang ada di baliknya. Volume tersebut kemudian dipasangkan ke _host_ dan lalu ke _pod_. apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: myclaim ### Catatan Mengenai _Namespace_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#catatan-mengenai-namespace) Ikatan `PersistentVolumes` bersifat eksklusif, dan karena `PersistentVolumeClaims` merupakan objek yang berada pada _namespace_, pemasangan klaim dengan "banyak" mode (`ROX`, `RWX`) hanya dimungkinkan jika berada dalam satu _namespace_ yang sama. Dukungan Volume _Raw Block_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#dukungan-volume-raw-block) ---------------------------------------------------------------------------------------------------------------------------- FEATURE STATE: `Kubernetes v1.13 [beta]` _Volume plugins_ berikut mendukung volume _raw block_, termasuk penyediaan dinamis jika mungkin diterapkan. * AWSElasticBlockStore * AzureDisk * FC (Fibre Channel) * GCEPersistentDisk * iSCSI * Local volume * RBD (Ceph Block Device) * VsphereVolume (alpha) #### Catatan: Hanya FC dan volume iSCSI yang mendukung volume _raw block_ pada Kubernetes 1.9. Dukungan untuk _plugin_ lainnya ditambahkan pada 1.10. ### _Persistent Volume_ menggunakan Volume _Raw Block_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#persistent-volume-menggunakan-volume-raw-block) apiVersion: v1 kind: PersistentVolume metadata: name: block-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce volumeMode: Block persistentVolumeReclaimPolicy: Retain fc: targetWWNs: ["50060e801049cfd1"] lun: 0 readOnly: false ### _Persistent Volume Claim_ meminta Volume _Raw Block_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#persistent-volume-claim-meminta-volume-raw-block) apiVersion: v1 kind: PersistentVolumeClaim metadata: name: block-pvc spec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 10Gi ### Spesifikasi _Pod_ yang menambahkan alamat Perangkat _Raw Block_ pada kontainer[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#spesifikasi-pod-yang-menambahkan-alamat-perangkat-raw-block-pada-kontainer) apiVersion: v1 kind: Pod metadata: name: pod-with-block-volume spec: containers: - name: fc-container image: fedora:26 command: ["/bin/sh", "-c"] args: [ "tail -f /dev/null" ] volumeDevices: - name: data devicePath: /dev/xvda volumes: - name: data persistentVolumeClaim: claimName: block-pvc #### Catatan: Ketika menambahkan sebuah perangkat _raw block_ untuk sebuah _Pod_, kita menspesifikasi alamat perangkat dalam kontainer alih-alih alamat pemasangan. ### Mengikat _Block Volume_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#mengikat-block-volume) Jika seorang pengguna meminta sebuah volume _raw block_ dengan mengindikasikannya menggunakan kolom `volumeMode` pada _spec_ `PersistentVolumeClaim` (PVC), aturan pengikatannya sedikit berbeda dibanding rilis-rilis sebelumnya yang tidak memerhatikan mode ini sebagai bagian dari _spec_. Di bawah merupakan tabel dari kemungkinan kombinasi yang pengguna dan admin dapat spesifikasikan untuk meminta sebuah perangkat _raw block_. Tabel tersebut mengindikasikan apakah volume akan terikat atau tidak jika dikombinasikan dengan cara tertentu: Matriks pengikatan volume untuk volume yang disediakan secara statis: | PV volumeMode | PVC volumeMode | Hasil | | --- | --- | --- | | unspecified | unspecified | TERIKAT | | unspecified | Block | TIDAK TERIKAT | | unspecified | Filesystem | TERIKAT | | Block | unspecified | TIDAK TERIKAT | | Block | Block | TERIKAT | | Block | Filesystem | TIDAK TERIKAT | | Filesystem | Filesystem | TERIKAT | | Filesystem | Block | TIDAK TERIKAT | | Filesystem | unspecified | TERIKAT | #### Catatan: Hanya volume yang disediakan secara statis yang didukung untuk rilis alfa. Administrator harus memperhatikan nilai-nilai tersebut ketika mengerjakan perangkat-perangkat _raw block_. _Volume Snapshot_ dan Dukungan Pemulihan Volume dari _Snapshot_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#volume-snapshot-dan-dukungan-pemulihan-volume-dari-snapshot) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- FEATURE STATE: `Kubernetes v1.12 [alpha]` Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](https://kubernetes.io/id/docs/concepts/storage/volume-snapshots/) . Untuk mengaktifkan dukungan pemulihan sebuah volume dari sebuah sumber data _volume snapshot_, aktifkan gerbang fitur `VolumeSnapshotDataSource` pada apiserver dan _controller-manager_. ### Membuat _Persistent Volume Claim_ dari _Volume Snapshot_[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#membuat-persistent-volume-claim-dari-volume-snapshot) apiVersion: v1 kind: PersistentVolumeClaim metadata: name: restore-pvc spec: storageClassName: csi-hostpath-sc dataSource: name: new-snapshot-test kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 10Gi Menulis Konfigurasi Portabel[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#menulis-konfigurasi-portabel) -------------------------------------------------------------------------------------------------------------------------------- Jika kamu menulis templat konfigurasi atau contoh yang dapat berjalan pada berbagai macam klaster dan membutuhkan _persistent storage_, kami merekomendasikan agar kamu menggunakan pola berikut: * Masukkan objek PersistentVolumeClaim (PVC) pada kumpulan _config_ (bersamaan dengan Deployments, ConfigMaps, dsb). * Jangan memasukkan objek PersistentVolume (PV) pada _config_, karena pengguna yang menginstantiasi _config_ tersebut kemungkinan tidak memiliki izin untuk membuat PersistentVolume (PV). * Berikan pengguna opsi untuk menyediakan nama _storage class_ ketika menginstantiasi templat. * Jika pengguna menyediakan nama _storage class_, taruh nilai tersebut pada kolom `persistentVolumeClaim.storageClassName`. Hal ini akan membuat PVC agar sesuai dengan _storage class_ yang tepat jika klaster memiliki banyak StorageClass yang diaktifkan oleh admin. * Jika pengguna tidak menyediakan nama _storage class_, biarkan kolom `persistentVolumeClaim.storageClassName` kosong. * Hal ini kakan membuat sebuah PV disediakan secara otomatis untuk pengguna dengan StorageClass standar pada klaster. Banyak lingkungan klaster memiliki StorageClass standar yang sudah terpasang, atau administrator dapat membuat StorageClass standar sendiri. * Dalam pembuatan, perhatikan PVC yang tidak kunjung terikat setelah beberapa lama dan beritahukan hal ini pada pengguna, karena hal ini dapat mengindikasikan klaster tidak memiliki dukungan penyimpanan dinamis (di mana pengguna harus membuat PV yang sesuai) atau klaster tidak memiliki sistem penyimpanan (di mana penggun tidak dapat membuat PVC yang membutuhkan _config_). Masukan[](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#feedback) --------------------------------------------------------------------------------------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/id/docs/concepts/storage/persistent-volumes/) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/id/docs/concepts/storage/persistent-volumes/) . Last modified February 03, 2023 at 4:40 PM PST: [Replace k8s.gcr.io with registry.k8s.io (f335df748c)](https://github.com/kubernetes/website/commit/f335df748cfb16e98a3b3825f075e2bfb1d3ce92) --- # Kubernetes 自定义指标 (v1beta2) | Kubernetes Kubernetes 自定义指标 (v1beta2) ========================== v1beta2 包是 v1beta2 版本的 custom\_metrics API。 资源类型[](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#resource-types) ------------------------------------------------------------------------------------------------------- * [MetricListOptions](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricListOptions) * [MetricValue](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricValue) * [MetricValueList](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricValueList) `MetricListOptions`[](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricListOptions) ------------------------------------------------------------------------------------------------------------------------------------------------------- MetricListOptions 用于按其标签选择算符来选择指标。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `custom.metrics.k8s.io/v1beta2` | | `kind`
string | `MetricListOptions` | | `labelSelector`
`string` | 这个选择算符通过标签来限制所返回对象的列表。 默认为任意值。 | | `metricLabelSelector`
`string` | 这个选择算符通过标签来限制所返回指标的列表。 | `MetricValue`[](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricValue) ------------------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [MetricValueList](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricValueList) MetricValue 是某些对象的指标值。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `custom.metrics.k8s.io/v1beta2` | | `kind`
string | `MetricValue` | | `describedObject` **\[必需\]**
[`core/v1.ObjectReference`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#objectreference-v1-core) | 指向描述对象的引用。 | | `metric` **\[必需\]**
[`MetricIdentifier`](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricIdentifier) | 无描述。 | | `timestamp` **\[必需\]**
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#time-v1-meta) | 标明度量值生成的时间。 | | `windowSeconds` **\[必需\]**
`int64` | 当返回根据累积度量计算的速率度量值时，此字段标明计算这些度量值的时间窗口 （\[Timestamp-Window, Timestamp\]）（或对于非计算的瞬时度量值为零）。 | | `value` **\[必需\]**
[`k8s.io/apimachinery/pkg/api/resource.Quantity`](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity) | 度量值。 | `MetricValueList`[](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricValueList) --------------------------------------------------------------------------------------------------------------------------------------------------- MetricValueList 是某个给定指标的某些对象集的数值列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `custom.metrics.k8s.io/v1beta2` | | `kind`
string | `MetricValueList` | | `metadata` **\[必需\]**
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#listmeta-v1-meta) | 无描述。 | | `items` **\[必需\]**
[`[]MetricValue`](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricValue) | 所描述对象的度量值。 | `MetricIdentifier`[](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricIdentifier) ----------------------------------------------------------------------------------------------------------------------------------------------------- **出现在：** * [MetricValue](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#custom-metrics-k8s-io-v1beta2-MetricValue) MetricIdentifier 按名称和可选的选择算符来标识指标。 | 字段 | 描述 | | --- | --- | | `name` **\[必需\]**
`string` | name 是给定指标的名称。 | | `selector`
[`meta/v1.LabelSelector`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#labelselector-v1-meta) | selector 表示可用于选择此指标的标签选择算符，通常就是传递给查询用于获取此指标的选择算符。 当留空时，仅使用指标的 Name 来采集指标。 | 反馈[](https://kubernetes.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/#feedback) ----------------------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/reference/external-api/custom-metrics.v1beta2/) . 最后修改 September 21, 2023 at 9:54 PM PST: [\[zh\] Sync custom-metrics.v1beta2.md (d5e513d89f)](https://github.com/kubernetes/website/commit/d5e513d89fdf9aea3f09b2de00e17cb6d02a7a34) --- # 自动扩缩工作负载 | Kubernetes 自动扩缩工作负载 ======== 通过自动扩缩，你可以用某种方式自动更新你的工作负载。在面对资源需求变化的时候可以使你的集群更灵活、更高效。 在 Kubernetes 中，你可以根据当前的资源需求**扩缩**工作负载。 这让你的集群可以更灵活、更高效地面对资源需求的变化。 当你扩缩工作负载时，你可以增加或减少工作负载所管理的副本数量，或者就地调整副本的可用资源。 第一种手段称为**水平扩缩**，第二种称为**垂直扩缩**。 扩缩工作负载有手动和自动两种方式，这取决于你的使用情况。 手动扩缩工作负载[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#scaling-workloads-manually) -------------------------------------------------------------------------------------------------------- Kubernetes 支持工作负载的手动扩缩。水平扩缩可以使用 `kubectl` 命令行工具完成。 对于垂直扩缩，你需要**更新**工作负载的资源定义。 这两种策略的示例见下文。 * **水平扩缩**：[运行应用程序的多个实例](https://kubernetes.io/zh-cn/docs/tutorials/kubernetes-basics/scale/scale-intro/) * **垂直扩缩**：[调整分配给容器的 CPU 和内存资源](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/resize-container-resources) 自动扩缩工作负载[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#scaling-workloads-automatically) ------------------------------------------------------------------------------------------------------------- Kubernetes 也支持工作负载的**自动扩缩**，这也是本页的重点。 在 Kubernetes 中**自动扩缩**的概念是指自动更新管理一组 Pod 的能力（例如 [Deployment](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/) ）。 ### 水平扩缩工作负载[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#scaling-workloads-horizontally) 在 Kubernetes 中，你可以使用 [HorizontalPodAutoscaler](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) （HPA） 实现工作负载的自动水平扩缩。 它以 Kubernetes API 资源和[控制器](https://kubernetes.io/zh-cn/docs/concepts/architecture/controller/) 的方式实现， 并定期调整工作负载中[副本](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-replica) 的数量以满足设置的资源利用率，如 CPU 或内存利用率。 这是一个为 Deployment 部署配置 HorizontalPodAutoscaler 的[示例教程](https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough) 。 ### 垂直扩缩工作负载[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#scaling-workloads-vertically) 特性状态： `Kubernetes v1.25 [stable]` 你可以使用 [VerticalPodAutoscaler](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/) （VPA） 实现工作负载的垂直扩缩。 不同于 HPA，VPA 并非默认包含于 Kubernetes，而是一个附加组件， 你或集群管理员可能需要在使用它之前部署该组件。 安装后，你可以为工作负载创建 [CustomResourceDefinitions](https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) (CRD)， 定义**如何**以及**何时**扩缩被管理副本的资源。 #### 说明： 你需要在集群中安装 [Metrics Server](https://github.com/kubernetes-sigs/metrics-server) ，这样，你的 VPA 才能正常工作。 #### 就地 Pod 垂直扩缩容[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#in-place-pod-vertical-scaling) 特性状态： `Kubernetes v1.35 [stable]`（默认启用） 截至 Kubernetes 1.35，VPA（垂直 Pod 自动伸缩）尚不支持就地调整 Pod 大小，但该集成正在开发中。 如需手动进行就地扩缩容，请参阅[就地调整容器资源](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/) 。 ### 根据集群规模自动扩缩[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#autoscaling-based-on-cluster-size) 对于需要根据集群规模实现扩缩的工作负载（例如：`cluster-dns` 或者其他系统组件）， 你可以使用 [Cluster Proportional Autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) 。 与 VPA 一样，这个项目不是 Kubernetes 核心项目的一部分，它在 GitHub 上有自己的项目。 集群弹性伸缩器（Cluster Proportional Autoscaler）会观测可调度[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 和处理器核数量， 并调整目标工作负载的副本数量。 如果副本的数量需要保持一致， 你可以使用 [Cluster Proportional Vertical Autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-vertical-autoscaler) 来根据集群规模进行垂直扩缩。 这个项目目前处于 **Beta** 阶段，你可以在 GitHub 上找到它。 集群弹性伸缩器（Cluster Proportional Autoscaler）通过调整工作负载副本数量实现扩缩容， 而垂直集群弹性伸缩器 (Cluster Proportional Vertical Autoscaler) 则根据集群中的节点数和/或 CPU 核数， 调整工作负载（例如 Deployment 或 DaemonSet）的资源请求值。 ### 事件驱动型自动扩缩[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#event-driven-autoscaling) 通过事件驱动实现工作负载的扩缩也是可行的， 例如使用 [Kubernetes Event Driven Autoscaler (**KEDA**)](https://keda.sh/) 。 KEDA 是 CNCF 的毕业项目，能让你根据要处理事件的数量对工作负载进行扩缩，例如队列中消息的数量。 有多种针对不同事件源的适配可供选择。 ### 根据计划自动扩缩[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#autoscaling-based-on-schedules) 扩缩工作负载的另一种策略是**计划**进行扩缩，例如在非高峰时段减少资源消耗。 与事件驱动自动扩缩容类似， 这种行为可以使用 KEDA 和 [`Cron` scaler](https://keda.sh/docs/latest/scalers/cron/) 实现。 `Cron` 扩缩器允许你根据预设的时间表（以及时区）对工作负载进行扩容或缩容。 扩缩集群基础设施[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#scaling-cluster-infrastructure) ------------------------------------------------------------------------------------------------------------ 如果扩缩工作负载无法满足你的需求，你也可以扩缩集群基础设施本身。 扩缩集群基础设施通常是指增加或移除[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 。 阅读[节点自动扩缩](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/node-autoscaling/) 了解更多信息。 接下来[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#%E6%8E%A5%E4%B8%8B%E6%9D%A5) ---------------------------------------------------------------------------------------------------- * 了解有关横向扩缩的更多信息 * [扩缩 StatefulSet](https://kubernetes.io/zh-cn/docs/tasks/run-application/scale-stateful-set/) * [HorizontalPodAutoscaler 演练](https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) * [调整分配给容器的 CPU 和内存资源](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/) * [自动扩缩集群 DNS 服务](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) * 了解[节点自动扩缩](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/(/zh-cn/docs/concepts/cluster-administration/node-autoscaling/)) 反馈[](https://kubernetes.io/zh-cn/docs/concepts/workloads/autoscaling/#feedback) -------------------------------------------------------------------------------- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/zh-cn/docs/concepts/workloads/autoscaling/) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/zh-cn/docs/concepts/workloads/autoscaling/) . 最后修改 March 04, 2026 at 2:29 PM PST: [\[zh\] Sync workloads/\_index.md (48ddd9dde2)](https://github.com/kubernetes/website/commit/48ddd9dde2a9b3109dd15c221a4424621814d2c0) --- # Comunicação entre Nós e a Camada de Gerenciamento | Kubernetes Comunicação entre Nós e a Camada de Gerenciamento ================================================= Este documento cataloga os caminhos de comunicação entre o [servidor de API](https://kubernetes.io/pt-br/docs/concepts/overview/components/#kube-apiserver) e o [cluster](https://kubernetes.io/pt-br/docs/reference/glossary/?all=true#term-cluster) Kubernetes. A intenção é permitir que os usuários personalizem sua instalação para endurecer a configuração de rede de tal forma que o cluster pode ser executado em uma rede não confiável (ou em IPs totalmente públicos em um provedor de nuvem). Nó para a Camada de Gerenciamento[](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#n%C3%B3-para-a-camada-de-gerenciamento) --------------------------------------------------------------------------------------------------------------------------------------------------------------------- O Kubernetes tem um padrão de API "hub-and-spoke". Todo uso da API dos nós (ou dos pods que eles executam) termina no servidor de API. Nenhum dos outros componentes da camada de gerenciamento são projetados para expor serviços remotos. O servidor de API é configurado para escutar conexões remotas em uma porta HTTPS segura (tipicamente 443) com uma ou mais formas de [autenticação](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authentication/) de cliente habilitada. Uma ou mais formas de [autorização](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/) devem ser habilitadas, especialmente se [requisições anônimas](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authentication/#anonymous-requests) ou [tokens da conta de serviço](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authentication/#service-account-tokens) são permitidos. Os nós devem ser provisionados com o [certificado](https://kubernetes.io/pt-br/docs/tasks/tls/managing-tls-in-a-cluster/) raiz público do cluster de tal forma que eles podem se conectar de forma segura ao servidor de API junto com credenciais de cliente válidas. Uma boa abordagem é que as credenciais de cliente fornecidas ao kubelet estejam na forma de um certificado de cliente. Veja [inicialização TLS do kubelet](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) para provisionamento automatizado de certificados de cliente do kubelet. [Pods](https://kubernetes.io/pt-br/docs/concepts/workloads/pods/) que desejam se conectar ao servidor de API podem fazê-lo com segurança, aproveitando uma conta de serviço para que o Kubernetes injete automaticamente o certificado raiz público e um token de portador válido no pod quando ele for instanciado. O serviço `kubernetes` (no namespace `default`) é configurado com um endereço IP virtual que é redirecionado (via `[kube-proxy](https://kubernetes.io/pt-br/docs/reference/command-line-tools-reference/kube-proxy/) `) para o endpoint HTTPS no servidor de API. Os componentes da camada de gerenciamento também se comunicam com o servidor de API através da porta segura. Como resultado, o modo de operação padrão para conexões dos nós e dos pods em execução nos nós para a camada de gerenciamento é seguro por padrão e pode operar em redes não confiáveis e/ou públicas. Camada de Gerenciamento para o Nó[](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#camada-de-gerenciamento-para-o-n%C3%B3) --------------------------------------------------------------------------------------------------------------------------------------------------------------------- Existem dois caminhos de comunicação primários da camada de gerenciamento (o servidor de API) para os nós. O primeiro é do servidor de API para o processo [kubelet](https://kubernetes.io/pt-br/docs/reference/command-line-tools-reference/kubelet) que executa em cada nó no cluster. O segundo é do servidor de API para qualquer nó, pod, ou serviço através da funcionalidade de _proxy_ do servidor de API. ### Servidor de API para o kubelet[](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#servidor-de-api-para-o-kubelet) As conexões do servidor de API para o kubelet são usadas para: * Buscar logs para pods. * Conectar-se (geralmente através de `kubectl`) a pods em execução. * Fornecer a funcionalidade de encaminhamento de porta do kubelet. Essas conexões terminam no endpoint HTTPS do kubelet. Por padrão, o servidor de API não verifica o certificado de serviço do kubelet, o que torna a conexão sujeita a ataques man-in-the-middle e **insegura** para executar por redes não confiáveis e/ou públicas. Para verificar essa conexão, use a flag `--kubelet-certificate-authority` para fornecer ao servidor de API um pacote de certificado raiz para usar e verificar o certificado de serviço do kubelet. Se isso não for possível, use [túneis SSH](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#ssh-tunnels) entre o servidor de API e kubelet se necessário para evitar conectar por uma rede não confiável ou pública. Finalmente, [Autenticação e/ou autorização do Kubelet](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) deve ser habilitada para proteger a API do kubelet. ### Servidor de API para nós, pods e serviços[](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#servidor-de-api-para-n%C3%B3s-pods-e-servi%C3%A7os) As conexões do servidor de API com um nó, pod, ou serviço são conexões HTTP simples por padrão e, portanto, não são autenticadas nem criptografadas. Elas podem ser executadas por uma conexão HTTPS segura prefixando `https:` ao nome do nó, pod, ou serviço na URL da API, mas elas não validarão o certificado fornecido pelo endpoint HTTPS nem fornecerão credenciais de cliente. Então enquanto a conexão será criptografada, ela não fornecerá nenhuma garantia de integridade. Essas conexões **não são atualmente seguras** para executar por redes não confiáveis e/ou públicas. ### Túneis SSH[](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#t%C3%BAneis-ssh) O Kubernetes suporta [túneis SSH](https://www.ssh.com/academy/ssh/tunneling) para proteger os caminhos de comunicação da camada de gerenciamento para os nós. Nesta configuração, o servidor de API inicia um túnel SSH para cada nó no cluster (conectando ao servidor SSH escutando na porta 22) e passa todo o tráfego destinado a um kubelet, nó, pod, ou serviço através do túnel. Este túnel garante que o tráfego não seja exposto fora da rede na qual os nós estão executando. #### Nota: Os túneis SSH estão atualmente descontinuados, então você não deve optar por usá-los a menos que saiba o que está fazendo. O [serviço Konnectivity](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#konnectivity-service) é um substituto para este canal de comunicação. ### Serviço Konnectivity[](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#konnectivity-service) ESTADO DA FUNCIONALIDADE: `Kubernetes v1.18 [beta]` Como um substituto aos túneis SSH, o serviço Konnectivity fornece proxy de nível TCP para a comunicação da camada de gerenciamento para o cluster. O serviço Konnectivity consiste em duas partes: o servidor Konnectivity na rede da camada de gerenciamento e os agentes Konnectivity na rede dos nós. Os agentes Konnectivity iniciam conexões com o servidor Konnectivity e mantêm as conexões de rede. Após habilitar o serviço Konnectivity, todo o tráfego da camada de gerenciamento para os nós passa por essas conexões. Siga a [tarefa do serviço Konnectivity](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) para configurar o serviço Konnectivity no seu cluster. Próximos passos[](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#pr%C3%B3ximos-passos) --------------------------------------------------------------------------------------------------------------------------------- * Leia sobre os [componentes da camada de gerenciamento do Kubernetes](https://kubernetes.io/pt-br/docs/concepts/architecture/#control-plane-components) * Saiba mais sobre o [modelo Hubs and Spoke](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors) * Aprenda como [Proteger um Cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) * Saiba mais sobre a [API do Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/) * [Configurar o serviço Konnectivity](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) * [Usar Encaminhamento de Porta para Acessar Aplicações em um Cluster](https://kubernetes.io/pt-br/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) * Aprenda como [Buscar logs para Pods](https://kubernetes.io/pt-br/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs) , [usar kubectl port-forward](https://kubernetes.io/pt-br/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod) Comentários[](https://kubernetes.io/pt-br/docs/concepts/architecture/control-plane-node-communication/#feedback) ----------------------------------------------------------------------------------------------------------------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/pt-br/docs/concepts/architecture/control-plane-node-communication/) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/pt-br/docs/concepts/architecture/control-plane-node-communication/) . Última modificação August 24, 2025 at 9:57 AM PST: [\[pt-br\] Update content/pt-br/docs/concepts/architecture/control-plane-node-communication.md (#51719) (33d3a8a01c)](https://github.com/kubernetes/website/commit/33d3a8a01c8c6a2fdd1579aa6be5f7ce506b78b1) --- # Tài liệu tham khảo | Kubernetes **Thông tin trong tài liệu này có thể đã lỗi thời** Tài liệu này có ngày cập nhật cũ hơn so với bản gốc, vì vậy thông tin mà nó chứa có thể đã lỗi thời. Nếu bạn có thể đọc tiếng Anh, hãy xem phiên bản tiếng Anh để có thông tin mới nhất: [Reference](https://kubernetes.io/docs/reference/) Tài liệu tham khảo ================== Phần này chứa các tài liệu tham khảo của Kubernetes. Phản hồi[](https://kubernetes.io/vi/docs/reference/#feedback) -------------------------------------------------------------- Trang này có hữu ích không? Có Không Cảm ơn bạn đã phản hồi. Nếu bạn có một câu hỏi cụ thể và có thể trả lời về cách sử dụng Kubernetes, hãy đặt nó trên [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Mở một vấn đề trong [Kho GitHub](https://www.github.com/kubernetes/website/) nếu bạn muốn [báo cáo một vấn đề](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/vi/docs/reference/) hoặc [đề xuất một cải tiến](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/vi/docs/reference/) . Last modified March 27, 2025 at 6:42 PM PST: [Reconstruct vietnamese docs (adeef47157)](https://github.com/kubernetes/website/commit/adeef471571b9ab53c33f722d80baaf9bc7de369) --- # Podセキュリティ標準の強制 | Kubernetes Podセキュリティ標準の強制 ============== このページでは、[Podセキュリティの標準](https://kubernetes.io/ja/docs/concepts/security/pod-security-standards) を強制する際のベストプラクティスの概要を説明します。 ビルトインPodセキュリティアドミッションコントローラーの使用[](https://kubernetes.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/#%E3%83%93%E3%83%AB%E3%83%88%E3%82%A4%E3%83%B3pod%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%A2%E3%83%89%E3%83%9F%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%83%BC%E3%81%AE%E4%BD%BF%E7%94%A8) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- FEATURE STATE: `Kubernetes v1.25 [stable]` [Podセキュリティアドミッションコントローラー](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podsecurity) は、非推奨のPodSecurityPolicyを置き換えます。 ### すべてのNamespaceに設定する[](https://kubernetes.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/#%E3%81%99%E3%81%B9%E3%81%A6%E3%81%AEnamespace%E3%81%AB%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B) 設定が全く無いNamespaceは、クラスターのセキュリティモデルにおいて重大な弱点とみなすべきです。 各Namespaceで発生するワークロードのタイプを時間をかけて分析し、Podセキュリティ標準を参照しながら、それぞれに適切なレベルを決定することを推奨します。 また、ラベルのないNamespaceは、まだ評価されていないことだけを示すべきです。 すべてのNamespaceのワークロードが同じセキュリティ要件を持つというシナリオでは、PodSecurityラベルを一括適用する方法を[例](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) で説明しています。 ### 最小特権の原則を採用する[](https://kubernetes.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/#%E6%9C%80%E5%B0%8F%E7%89%B9%E6%A8%A9%E3%81%AE%E5%8E%9F%E5%89%87%E3%82%92%E6%8E%A1%E7%94%A8%E3%81%99%E3%82%8B) 理想的な世界では、すべてのNamespaceのPodが`restricted`ポリシーの要件を満たすでしょう。 しかし、ワークロードの中には正当な理由で昇格した特権を必要とするものもあるため、それは不可能であり、現実的でもありません。 * `privileged`ワークロードを許可するNamespaceは、適切なアクセス制御を確立し、実施すべきである。 * 最小権限のNamespaceで実行されるワークロードについては、そのワークロードのセキュリティ要件に関するドキュメントを整備する。可能であれば、それらの要件がどのように制約される可能性があるのかを考慮する。 ### マルチモード戦略の採用[](https://kubernetes.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/#%E3%83%9E%E3%83%AB%E3%83%81%E3%83%A2%E3%83%BC%E3%83%89%E6%88%A6%E7%95%A5%E3%81%AE%E6%8E%A1%E7%94%A8) Podセキュリティアドミッションコントローラーの`audit`と`warn`モードを使用すると、既存のワークロードを破壊することなく、Podに関する重要なセキュリティインサイトを簡単に収集できます。 すべてのNamespaceでこれらのモードを有効にし、最終的に`enforce`したいレベルやバージョンに設定するのがよい方法です。 このフェーズで生成される警告と監査注釈は、その状態への指針となります。 ワークロード作成者が希望のレベルに収まるように変更することを期待している場合は、`warn`モードを有効にしてください。 監査ログを使用して、希望のレベルに収まるように変更を監視/推進することを期待している場合は、`audit`モードを有効にしてください。 `enforce`モードが希望通りの値に設定されている場合でも、これらのモードはいくつかの異なる方法で役立ちます。 * `warn`を`enforce`と同じレベルに設定すると、バリデーションを通過しないPod(またはPodテンプレートを持つリソース)を作成しようとしたときに、クライアントが警告を受け取るようになります。これにより、対象のリソースを更新して準拠させることができます。 * `enforce`を特定の最新バージョンではないに固定するNamespaceでは、`audit`と`warn`モードを`enforce`と同じレベルに設定するが、最新バージョンに対して設定することで、以前のバージョンでは許可されていたが、現在のベストプラクティスでは許可されていない設定を可視化することができます。 サードパーティによる代替案[](https://kubernetes.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/#%E3%82%B5%E3%83%BC%E3%83%89%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%81%AB%E3%82%88%E3%82%8B%E4%BB%A3%E6%9B%BF%E6%A1%88) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **備考:** このセクションでは、Kubernetesが必要とする機能を提供するサードパーティープロジェクトにリンクしています。これらのプロジェクトはアルファベット順に記載されていて、Kubernetesプロジェクトの作者は責任を持ちません。このリストにプロジェクトを追加するには、変更を提出する前に[content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) をお読みください。[詳細はこちら。](https://kubernetes.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/#third-party-content-disclaimer) Kubernetesエコシステムでは、セキュリティプロファイルを強制するための他の選択肢も開発されています。 * [Kubewarden](https://github.com/kubewarden) * [Kyverno](https://kyverno.io/policies/) * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) ビルトインソリューション(PodSecurityアドミッションコントローラーなど)とサードパーティツールのどちらを選ぶかは、あなたの状況次第です。 どのようなソリューションを評価する場合でも、サプライチェーンの信頼が非常に重要です。最終的には、前述のアプローチのどれを使っても、何もしないよりはましでしょう。 フィードバック[](https://kubernetes.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/#feedback) --------------------------------------------------------------------------------------------------------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/ja/docs/setup/best-practices/enforcing-pod-security-standards/) . 最終更新 March 27, 2024 at 11:58 PM PST: [\[ja\] Translate Enforcing Pod Security Standards into Japanese (#44924) (a863629186)](https://github.com/kubernetes/website/commit/a863629186adaa839ed121f98b6243cb455abe91) このページの項目は、Kubernetesが必要とする機能を提供するサードパーティー製品またはプロジェクトです。Kubernetesプロジェクトの作者は、それらのサードパーティー製品またはプロジェクトに責任を負いません。詳しくは、[CNCFウェブサイトのガイドライン](https://github.com/cncf/foundation/blob/master/website-guidelines.md) をご覧ください。第三者のリンクを追加するような変更を提案する前に、[コンテンツガイド](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) を読むべきです。 --- # Instalación de Complementos (AddOns) | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Installing Addons](https://kubernetes.io/docs/concepts/cluster-administration/addons/) Instalación de Complementos (AddOns) ==================================== **Nota:** This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically. To add a project to this list, read the [content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) before submitting a change. [More information.](https://kubernetes.io/es/docs/concepts/cluster-administration/addons/#third-party-content-disclaimer) Los complementos amplían las funcionalidades de Kubernetes. En esta página se listan algunos de los complementos disponibles con sus respectivos enlaces de instrucciones para su instalación y uso. La lista no pretende ser exhaustiva. Redes y Política de Redes[](https://kubernetes.io/es/docs/concepts/cluster-administration/addons/#redes-y-pol%C3%ADtica-de-redes) ---------------------------------------------------------------------------------------------------------------------------------- * [ACI](https://www.github.com/noironetworks/aci-containers) (Cisco ACI) proporciona redes de contenedores integradas y seguridad de red. * [Antrea](https://antrea.io/) proporciona servicios de red y seguridad para Kubernetes, aprovechando Open vSwitch como plano de datos de red, opera en la capa 3/4. Antrea es un [proyecto de la CNCF de nivel Sandbox](https://www.cncf.io/projects/antrea/) . * [Calico](https://www.tigera.io/project-calico/) es un proveedor de redes y políticas de red. Calico admite un conjunto flexible de opciones de red, para poder elegir la opción más eficiente para su situación, incluidas las redes superpuestas y no superpuestas, con o sin BGP (Border Gateway Protocol). Calico utiliza el mismo motor para aplicar las políticas de red para hosts, Pods, y (si se usa Istio y Envoy) aplicaciones en la capa de la malla de servicios. * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) Es la unión de Flannel y Calico, proporciona redes y políticas de redes. * [Cilium](https://github.com/cilium/cilium) es una solución de red, observabilidad y seguridad con un plano de datos basado en eBPF. Cilium proporciona una red sencilla y plana en capa 3 con la capacidad de abarcar varios clústeres en un modo de enrutamiento nativo o de superposición/encapsulación, y puede aplicar políticas de red en L3-L7 utilizando un modelo de seguridad basado en identidad que está desacoplado del direccionamiento de red. Cilium puede actuar como sustituto de kube-proxy, también ofrece características adicionales de observabilidad y seguridad de manera opcional. Cilium es un [proyecto de la CNCF de nivel Incubación](https://www.cncf.io/projects/cilium/) . * [CNI-Genie](https://github.com/cni-genie/CNI-Genie) permite a Kubernetes conectarse sin problemas a una selección de complementos de CNI, como Calico, Canal, Flannel o Weave. CNI-Genie es un [proyecto de la CNCF de nivel Sandbox](https://www.cncf.io/projects/cni-genie/) . * [Contiv](https://contivpp.io/) proporciona redes configurables (L3 nativo mediante BGP, con superposición mediante vxlan, L2 clásica y Cisco-SDN/ACI) para diversos casos de uso y un vasto marco de políticas. El proyecto Contiv es de [código abierto](https://github.com/contiv) . El [instalador](https://github.com/contiv/install) ofrece opciones de instalación basadas en kubeadm y no basadas en kubeadm. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) , basada en [Tungsten Fabric](https://tungsten.io/) , es una plataforma de gestión de políticas y virtualización de redes multicloud de código abierto. Contrail y Tungsten Fabric se integran con sistemas de orquestación como Kubernetes, OpenShift, OpenStack y Mesos, y proporcionan modos de aislamiento para máquinas virtuales, contenedores/Pods y cargas de trabajo para bare metal. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) es un proveedor de red superpuesta que se puede usar con Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) es un complemento que soportar múltiples interfaces de red en un Pod de Kubernetes. * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) es un multicomplemento para soporte de múltiple redes en Kubernetes, que admite todos los complementos de CNI (ej. Calico, Cilium, Contiv, Flannel), además de SRIOV, DPDK, OVS-DPDK y cargas de trabajo basadas en VPP en Kubernetes. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) es un proveedor de red para Kubernetes basado en [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/) , es una implementación de red virtual que surgió del proyecto Open vSwitch (OVS). OVN-Kubernetes proporciona una implementación de red basada en la superposición para Kubernetes, incluyendo una implementación basada en OVS de balanceo de carga y política de red. * [Nodus](https://github.com/akraino-edge-stack/icn-nodus) es un complemento de controlador CNI basado en OVN para proveer Service function chaining(SFC) con base nativa para la nube. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) proporciona integración entre VMware NSX-T y orquestadores de contenedores como Kubernetes, así como integración entre NSX-T y plataformas CaaS/PaaS basadas en contenedores como Pivotal Container Service (PKS) y OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) es una plataforma SDN que proporciona redes basadas en políticas entre Kubernetes Pods y entornos no Kubernetes con visibilidad y supervisión de la seguridad. * [Romana](https://github.com/romana) es una solución de red de capa 3 para las redes de Pods que también son compatibles con la API de [NetworkPolicy](https://kubernetes.io/es/docs/concepts/services-networking/network-policies/) . * [Weave Net](https://github.com/rajch/weave#using-weave-on-kubernetes) proporciona redes y políticas de red, funciona en ambos lados de una partición de red y no requiere una base de datos externa. Detección de Servicios[](https://kubernetes.io/es/docs/concepts/cluster-administration/addons/#detecci%C3%B3n-de-servicios) ---------------------------------------------------------------------------------------------------------------------------- * [CoreDNS](https://coredns.io/) es un servidor de DNS flexible y extensible que puede [instalarse](https://github.com/coredns/helm) como DNS dentro del clúster para los Pods. Visualización y Control[](https://kubernetes.io/es/docs/concepts/cluster-administration/addons/#visualizaci%C3%B3n-y-control) ------------------------------------------------------------------------------------------------------------------------------ * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) es un panel de control con una interfaz web para Kubernetes. Infraestructura[](https://kubernetes.io/es/docs/concepts/cluster-administration/addons/#infraestructura) --------------------------------------------------------------------------------------------------------- * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) es un complemento para ejecutar máquinas virtuales en Kubernetes. Suele ejecutarse en clústeres de Bare metal. * El [detector de problemas de nodo](https://github.com/kubernetes/node-problem-detector) se ejecuta en nodos Linux e informa de los problemas del sistema como [Eventos](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/) o [Condiciones de nodo](https://kubernetes.io/es/docs/concepts/architecture/nodes/#condition) . Complementos Antiguos[](https://kubernetes.io/es/docs/concepts/cluster-administration/addons/#complementos-antiguos) --------------------------------------------------------------------------------------------------------------------- Hay otros complementos documentados como obsoletos en el directorio [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) . Los que mejor mantenimiento tienen deben estar vinculados aquí. !PRs son bienvenidos! Comentarios[](https://kubernetes.io/es/docs/concepts/cluster-administration/addons/#feedback) ---------------------------------------------------------------------------------------------- ¿Esta página le ha sido de ayuda? Sí No Muchas gracias por el feedback. Si tienes alguna pregunta específica sobre como usar Kubernetes, puedes preguntar en [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abre un issue en el repositorio de GitHub si quieres [reportar un problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io/es/docs/concepts/cluster-administration/addons/) o [sugerir alguna mejora](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io/es/docs/concepts/cluster-administration/addons/) . Última modificación February 18, 2025 at 12:23 AM PST: [\[es\] Fixed link for core dns helm charts (8998215922)](https://github.com/kubernetes/website/commit/89982159222d6a98762b02e1cfb1eda5569f91a1) Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the [CNCF website guidelines](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) for more details. You should read the [content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) before proposing a change that adds an extra third-party link. --- # 提出内容改进建议 | Kubernetes 提出内容改进建议 ======== 如果你发现 Kubernetes 文档中存在问题或者你有一个关于新内容的想法， 可以考虑提出一个问题（issue）。你只需要具有 [GitHub 账号](https://github.com/join) 和 Web 浏览器就可以完成这件事。 在大多数情况下，Kubernetes 文档的新工作都是开始于 GitHub 上的某个问题。 Kubernetes 贡献者会审阅这些问题并根据需要对其分类、打标签。 接下来，你或者别的 Kubernetes 社区成员就可以发起一个带有变更的拉取请求， 以解决这一问题。 创建问题 ---- 如果你希望就改进已有内容提出建议或者在文档中发现了错误，请创建一个问题（issue）。 1. 点击右侧边栏的 **提交文档问题** 按钮。浏览器会重定向到一个 GitHub 问题页面， 其中包含了一些预先填充的内容。 2. 请描述遇到的问题或关于改进的建议。尽可能提供细节信息。 3. 点击 **Submit new issue**。 提交之后，偶尔查看一下你所提交的问题，或者开启 GitHub 通知。 评审人（reviewers）和其他社区成员可能在针对所提问题采取行动之前，问一些问题。 关于新内容的建议 -------- 如果你对新内容有想法，但是你不确定这些内容应该放在哪里，你仍可以提出问题。 * 在预期的节区中选择一个现有页面，点击 **提交文档问题**。 * 前往 [GitHub Issues 页面](https://github.com/kubernetes/website/issues/new/) ， 直接记录问题。 如何更好地记录问题 --------- 在记录问题时，请注意以下事项： * 提供问题的清晰描述，描述具体缺失的内容、过期的内容、错误的内容或者需要改进的文字。 * 解释该问题对用户的特定影响。 * 将给定问题的范围限定在一个工作单位范围内。如果问题牵涉的领域较大，可以将其分解为多个小一点的问题。 例如："Fix the security docs" 是一个过于宽泛的问题，而 "Add details to the 'Restricting network access' topic" 就是一个足够具体的、可操作的问题。 * 搜索现有问题的列表，查看是否已经有相关的或者类似的问题已被记录。 * 如果新问题与某其他问题或 PR 有关联，可以使用其完整 URL 或带 `#` 字符的 PR 编号来引用之。 例如：`Introduced by #987654`。 * 遵从[行为准则](https://kubernetes.io/zh-cn/community/code-of-conduct/) 。尊重同行贡献者。 例如，"The docs are terrible" 就是无用且无礼的反馈。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 June 20, 2025 at 11:01 AM PST: [\[zh-cn\]sync submission suggesting-improvements (7b327846b1)](https://github.com/kubernetes/website/commit/7b327846b112c910750944cdf5c33112a56f78ab) --- # 容器环境 | Kubernetes 容器环境 ==== 本页描述了在容器环境里容器可用的资源。 容器环境 ---- Kubernetes 的容器环境给容器提供了几个重要的资源： * 文件系统，其中包含一个[镜像](https://kubernetes.io/zh-cn/docs/concepts/containers/images/) 和一个或多个的[卷](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/) * 容器自身的信息 * 集群中其他对象的信息 ### 容器信息 一个容器的 **hostname** 是该容器运行所在的 Pod 的名称。通过 `hostname` 命令或者调用 libc 中的 [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 函数可以获取该名称。 Pod 名称和命名空间可以通过 [下行 API](https://kubernetes.io/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 转换为环境变量。 Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 container 镜像中静态指定的任何环境变量一样。 ### 集群信息 创建容器时正在运行的所有服务都可用作该容器的环境变量。 这里的服务仅限于新容器的 Pod 所在的名字空间中的服务，以及 Kubernetes 控制面的服务。 对于名为 **foo** 的服务，它公开一组 Pod，每个 Pod 运行一个名为 **bar** 的容器，定义了以下变量： FOO_SERVICE_HOST=<其上服务正运行的主机> FOO_SERVICE_PORT=<其上服务正运行的端口> 服务具有专用的 IP 地址。如果启用了 [DNS 插件](https://releases.k8s.io/v1.35.0/cluster/addons/dns/) ， 可以在容器中通过 DNS 来访问服务。 接下来 --- * 学习更多有关[容器生命周期回调](https://kubernetes.io/zh-cn/docs/concepts/containers/container-lifecycle-hooks/) 的知识。 * 动手[为容器的生命周期事件设置处理函数](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 March 03, 2026 at 11:18 AM PST: [\[zh-cn\]sync container-environment (7d7b11d6df)](https://github.com/kubernetes/website/commit/7d7b11d6df1055cb2cd2cdf2b1cbd24de2af3f5a) --- # Service 与 Pod 的 DNS | Kubernetes Service 与 Pod 的 DNS =================== 你的工作负载可以使用 DNS 发现集群内的 Service，本页说明具体工作原理。 Kubernetes 为 Service 和 Pod 创建 DNS 记录。 你可以使用稳定的 DNS 名称而非 IP 地址访问 Service。 Kubernetes 发布有关 Pod 和 Service 的信息，用于配置 DNS。 kubelet 配置 Pod 的 DNS，使运行中的容器可以通过名称而非 IP 查找 Service。 集群中定义的 Service 被赋予 DNS 名称。 默认情况下，客户端 Pod 的 DNS 搜索列表包括 Pod 所在的命名空间和集群的默认域名。 ### Service 的命名空间 DNS 查询可能因为执行查询的 Pod 所在的命名空间而返回不同的结果。 不指定命名空间的 DNS 查询会被限制在 Pod 所在的命名空间内。 要访问其他命名空间中的 Service，需要在 DNS 查询中指定命名空间。 例如，假定命名空间 `test` 中存在一个 Pod，`prod` 命名空间中存在一个服务 `data`。 Pod 查询 `data` 时没有返回结果，因为使用的是 Pod 所在的 `test` 命名空间。 Pod 查询 `data.prod` 时则会返回预期的结果，因为查询中指定了命名空间。 DNS 查询可以使用 Pod 中的 `/etc/resolv.conf` 展开。 Kubelet 为每个 Pod 配置此文件。 例如，对 `data` 的查询可能被扩展为 `data.test.svc.cluster.local`。 `search` 选项的值用于扩展查询。要进一步了解 DNS 查询，可参阅 [`resolv.conf` 手册页面](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) 。 nameserver 10.32.0.10 search .svc.cluster.local svc.cluster.local cluster.local options ndots:5 概括起来，命名空间 **test** 中的 Pod 可以成功地解析 `data.prod` 或者 `data.prod.svc.cluster.local`。 ### DNS 记录 哪些对象会获得 DNS 记录呢？ 1. Service 2. Pod 以下各节详细介绍已支持的 DNS 记录类型和布局。 其它布局、名称或者查询即使碰巧可以工作，也应视为实现细节， 将来很可能被更改而且不会因此发出警告。 有关最新规范请查看 [Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md) 。 ### Service #### A/AAAA 记录 除了无头 Service 之外的“普通” Service 会被赋予一个形如 `my-svc.my-namespace.svc.cluster-domain.example` 的 DNS A 和/或 AAAA 记录，取决于 Service 的 IP 协议族（可能有多个）设置。 该名称会解析成对应 Service 的集群 IP。 没有集群 IP 的[无头 Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services) 也会被赋予一个形如 `my-svc.my-namespace.svc.cluster-domain.example` 的 DNS A 和/或 AAAA 记录。 与普通 Service 不同，这一记录会被解析成对应 Service 所选择的 Pod IP 的集合。 客户端要能够使用这组 IP，或者使用标准的轮转策略从这组 IP 中进行选择。 #### SRV 记录 Kubernetes 根据普通 Service 或无头 Service 中的命名端口创建 SRV 记录。 * 每个命名端口，SRV 记录的格式：`_port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example`。 * 对于普通 Service，该记录会被解析成端口号和域名：`my-svc.my-namespace.svc.cluster-domain.example`。 * 对于无头 Service，该记录会被解析成多个结果，即该 Service 的每个后端 Pod 各一个 SRV 记录， 其中包含 Pod 端口号和域名，格式为：`hostname.my-svc.my-namespace.svc.cluster-domain.example`。 Pod --- ### A/AAAA 记录 在实现 [DNS 规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md) 之前， Kube-DNS 版本使用以下 DNS 解析： ..pod. 例如，对于一个位于 `default` 命名空间，IP 地址为 172.17.0.3 的 Pod， 如果集群的域名为 `cluster.local`，则 Pod 会对应 DNS 名称： 172-17-0-3.default.pod.cluster.local 一些集群 DNS 机制（如 [CoreDNS](https://coredns.io/) ）还会为以下内容提供 `A` 记录： ...svc. 例如，如果 `cafe` 命名空间中的一个 Pod 拥有 IP 地址 172.17.0.3（是名为 `barista` 的服务的端点）， 并且集群的域名是 `cluster.local`， 那么此 Pod 将拥有这样的服务范围的 DNS A 记录： 172-17-0-3.barista.cafe.svc.cluster.local ### Pod 的 hostname 和 subdomain 字段 当前，创建 Pod 时其主机名（从 Pod 内部观察）取自 Pod 的 `metadata.name` 值。 Pod 规约中包含一个可选的 `hostname` 字段，可以用来指定一个不同的主机名。 当这个字段被设置时，它将优先于 Pod 的名字成为该 Pod 的主机名（同样是从 Pod 内部观察）。 举个例子，给定一个 `spec.hostname` 设置为 `“my-host”` 的 Pod， 该 Pod 的主机名将被设置为 `“my-host”`。 Pod 规约还有一个可选的 `subdomain` 字段，可以用来表明该 Pod 属于命名空间的一个子组。 例如，某 Pod 的 `spec.hostname` 设置为 `“foo”`，`spec.subdomain` 设置为 `“bar”`， 在命名空间 `“my-namespace”` 中，主机名称被设置成 `“foo”` 并且对应的完全限定域名（FQDN）为 “`foo.bar.my-namespace.svc.cluster-domain.example`”（还是从 Pod 内部观察）。 如果 Pod 所在的命名空间中存在一个无头 Service，其名称与子域相同， 则集群的 DNS 服务器还会为 Pod 的完全限定主机名返回 A 和/或 AAAA 记录。 示例： apiVersion: v1 kind: Service metadata: name: busybox-subdomain spec: selector: name: busybox clusterIP: None ports: - name: foo # 单个端口的 service 可以不指定 name port: 1234 --- apiVersion: v1 kind: Pod metadata: name: busybox1 labels: name: busybox spec: hostname: busybox-1 subdomain: busybox-subdomain containers: - image: busybox:1.28 command: - sleep - "3600" name: busybox --- apiVersion: v1 kind: Pod metadata: name: busybox2 labels: name: busybox spec: hostname: busybox-2 subdomain: busybox-subdomain containers: - image: busybox:1.28 command: - sleep - "3600" name: busybox 鉴于上述 `"busybox-subdomain"` Service 和将 `spec.subdomain` 设置为 `"busybox-subdomain"` 的 Pod， 第一个 Pod 将看到自己的 FQDN 为 `"busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example"`。 DNS 会为此名字提供一个 A 记录和/或 AAAA 记录，指向该 Pod 的 IP。 Pod “`busybox1`” 和 “`busybox2`” 都将有自己的地址记录。 [EndpointSlice](https://kubernetes.io/zh-cn/docs/concepts/services-networking/endpoint-slices/ "EndpointSlices 跟踪提供 Service 的 Pod 的 IP 地址。") 对象可以为任何端点地址及其 IP 指定 `hostname`。 #### 说明： 由于 Pod 缺少 `hostname`，所以没有为这些 Pod 名称创建 A 和 AAAA 记录。 没有设置 `hostname` 但设置了 `subdomain` 的 Pod 只会为 无头 Service 创建 A 或 AAAA 记录（`busybox-subdomain.my-namespace.svc.cluster-domain.example`） 指向 Pod 的 IP 地址。 另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则只有 Pod 准备就绪 才会有与之对应的记录。 ### Pod 的 setHostnameAsFQDN 字段 特性状态： `Kubernetes v1.22 [stable]` 当 Pod 配置为具有全限定域名（FQDN）时，其主机名是短主机名。 例如，如果你有一个具有完全限定域名 `busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example` 的 Pod， 则默认情况下，该 Pod 内的 `hostname` 命令返回 `busybox-1`，而 `hostname --fqdn` 命令返回 FQDN。 当你在 Pod 规约中设置了 `setHostnameAsFQDN: true` 时，kubelet 会将 Pod 的全限定域名（FQDN）作为该 Pod 的主机名记录到 Pod 所在命名空间。 在这种情况下，`hostname` 和 `hostname --fqdn` 都会返回 Pod 的全限定域名。 #### 说明： 在 Linux 中，内核的主机名字段（`struct utsname` 的 `nodename` 字段）限定最多 64 个字符。 如果 Pod 启用这一特性，而其 FQDN 超出 64 字符，Pod 的启动会失败。 Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerCreating`）， 并产生错误事件，例如 "Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested)." （无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64 个字符，请求字符数为 70）。 对于这种场景而言，改善用户体验的一种方式是创建一个 [准入 Webhook 控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) ， 在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。 ### Pod 的 DNS 策略 DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。 这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置： * "`Default`": Pod 从运行所在的节点继承域名解析配置。 参考[相关讨论](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) 获取更多信息。 * "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"） 都会由 DNS 服务器转发到上游域名服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 参阅[相关讨论](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) 了解在这些场景中如何处理 DNS 查询的信息。 * "`ClusterFirstWithHostNet`": 对于以 hostNetwork 方式运行的 Pod，应将其 DNS 策略显式设置为 "`ClusterFirstWithHostNet`"。否则，以 hostNetwork 方式和 `"ClusterFirst"` 策略运行的 Pod 将会做出回退至 `"Default"` 策略的行为。 #### 说明： 这在 Windows 上不支持。有关详细信息，请参见[下文](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dns-pod-service/#dns-windows) 。 * "`None`": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其 `dnsConfig` 字段所提供的 DNS 设置。 参见 [Pod 的 DNS 配置](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dns-pod-service/#pod-dns-config) 节。 #### 说明： "Default" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "ClusterFirst"。 下面的示例显示了一个 Pod，其 DNS 策略设置为 "`ClusterFirstWithHostNet`"， 因为它已将 `hostNetwork` 设置为 `true`。 apiVersion: v1 kind: Pod metadata: name: busybox namespace: default spec: containers: - image: busybox:1.28 command: - sleep - "3600" imagePullPolicy: IfNotPresent name: busybox restartPolicy: Always hostNetwork: true dnsPolicy: ClusterFirstWithHostNet ### Pod 的 DNS 配置 特性状态： `Kubernetes v1.14 [stable]` Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。 `dnsConfig` 字段是可选的，它可以与任何 `dnsPolicy` 设置一起使用。 但是，当 Pod 的 `dnsPolicy` 设置为 "`None`" 时，必须指定 `dnsConfig` 字段。 用户可以在 `dnsConfig` 字段中指定以下属性： * `nameservers`：将用作于 Pod 的 DNS 服务器的 IP 地址列表。 最多可以指定 3 个 IP 地址。当 Pod 的 `dnsPolicy` 设置为 "`None`" 时， 列表必须至少包含一个 IP 地址，否则此属性是可选的。 所列出的服务器将合并到从指定的 DNS 策略生成的基本域名服务器，并删除重复的地址。 * `searches`：用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。 指定此属性时，所提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。 重复的域名将被删除。Kubernetes 最多允许 32 个搜索域。 * `options`：可选的对象列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。 重复的条目将被删除。 以下是具有自定义 DNS 设置的 Pod 示例： [`service/networking/custom-dns.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/custom-dns.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/custom-dns.yaml 到剪贴板") apiVersion: v1 kind: Pod metadata: namespace: default name: dns-example spec: containers: - name: test image: nginx dnsPolicy: "None" dnsConfig: nameservers: - 192.0.2.1 # 这是一个示例 searches: - ns1.svc.cluster-domain.example - my.dns.search.suffix options: - name: ndots value: "2" - name: edns0 创建上面的 Pod 后，容器 `test` 会在其 `/etc/resolv.conf` 文件中获取以下内容： nameserver 192.0.2.1 search ns1.svc.cluster-domain.example my.dns.search.suffix options ndots:2 edns0 对于 IPv6 设置，搜索路径和名称服务器应按以下方式设置： kubectl exec -it dns-example -- cat /etc/resolv.conf 输出类似于： nameserver 2001:db8:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example options ndots:5 DNS 搜索域列表限制 ----------- 特性状态： `Kubernetes 1.28 [stable]` Kubernetes 本身不限制 DNS 配置，最多可支持 32 个搜索域列表，所有搜索域的总长度不超过 2048。 此限制分别适用于节点的解析器配置文件、Pod 的 DNS 配置和合并的 DNS 配置。 #### 说明： 早期版本的某些容器运行时可能对 DNS 搜索域的数量有自己的限制。 根据容器运行环境，那些具有大量 DNS 搜索域的 Pod 可能会卡在 Pending 状态。 众所周知 containerd v1.5.5 或更早版本和 CRI-O v1.21 或更早版本都有这个问题。 Windows 节点上的 DNS 解析 ------------------- * 在 Windows 节点上运行的 Pod 不支持 `ClusterFirstWithHostNet`。 Windows 将所有带有 `.` 的名称视为全限定域名（FQDN）并跳过全限定域名（FQDN）解析。 * 在 Windows 上，可以使用的 DNS 解析器有很多。 由于这些解析器彼此之间会有轻微的行为差别，建议使用 [`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname) powershell cmdlet 进行名称查询解析。 * 在 Linux 上，有一个 DNS 后缀列表，当解析全名失败时可以使用。 在 Windows 上，你只能有一个 DNS 后缀， 即与该 Pod 的命名空间相关联的 DNS 后缀（例如：`mydns.svc.cluster.local`）。 Windows 可以解析全限定域名（FQDN），和使用了该 DNS 后缀的 Services 或者网络名称。 例如，在 `default` 命名空间中生成一个 Pod，该 Pod 会获得的 DNS 后缀为 `default.svc.cluster.local`。 在 Windows 的 Pod 中，你可以解析 `kubernetes.default.svc.cluster.local` 和 `kubernetes`， 但是不能解析部分限定名称（`kubernetes.default` 和 `kubernetes.default.svc`）。 接下来 --- 有关管理 DNS 配置的指导， 请查看[配置 DNS 服务](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/) 。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 August 30, 2025 at 1:07 PM PST: [\[zh-cn\]sync dns-pod-service.md (af70bee61e)](https://github.com/kubernetes/website/commit/af70bee61eb354c4fb26f0c1a1097076024114a3) --- # NetworkPolicy | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) NetworkPolicy ============= Sebuah NetworkPolicy adalah spesifikasi dari sekelompok Pod atau _endpoint_ yang diizinkan untuk saling berkomunikasi. `NetworkPolicy` menggunakan label untuk memilih Pod serta mendefinisikan serangkaian _rule_ yang digunakan untuk mendefinisikan trafik yang diizinkan untuk suatu Pod tertentu. Prasyarat --------- NetworkPolicy diimplementasikan dengan menggunakan _plugin_ jaringan, dengan demikian kamu harus memiliki penyedia jaringan yang mendukung `NetworkPolicy` - membuat _resource_ tanpa adanya _controller_ tidak akan berdampak apa pun. Pod yang terisolasi dan tidak terisolasi ---------------------------------------- Secara _default_, Pod bersifat tidak terisolasi; Pod-Pod tersebut menerima trafik dari _resource_ apa pun. Pod menjadi terisolasi apabila terdapat `NetworkPolicy` yang dikenakan pada Pod-Pod tersebut. Apabila terdapat `NetworkPolicy` di dalam _namespace_ yang dikenakan pada suatu Pod, Pod tersebut akan menolak koneksi yang tidak diizinkan `NetworkPolicy`. (Pod lain dalam _namespace_ yang tidak dikenakan `NetworkPolicy` akan tetap menerima trafik dari semua _resource_.) _Resource_ `NetworkPolicy` -------------------------- Lihat [`NetworkPolicy`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#networkpolicy-v1-networking-k8s-io) untuk definisi lengkap _resource_. Sebuah contoh `NetworkPolicy` akan terlihat seperti berikut: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: role: db policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978 Mengirimkan ini ke API server dengan metode POST tidak akan berdampak apa pun kecuali penyedia jaringan mendukung network policy. **_Field-field_ yang bersifat wajib**: Sama dengan seluruh _config_ Kubernetes lainnya, sebuah `NetworkPolicy` membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai bagaimana bekerja dengan _file_ `config`, dapat dilihat di [Konfigurasi Kontainer menggunakan `ConfigMap`](https://kubernetes.io/id/docs/tasks/configure-pod-container/configure-pod-configmap/) , serta [Manajemen Objek](https://kubernetes.io/id/docs/tasks/manage-kubernetes-objects/) . **spec**: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) memiliki semua informasi yang harus diberikan untuk memberikan definisi _network policy_ yang ada pada _namespace_ tertentu. **podSelector**: Setiap `NetworkPolicy` memiliki sebuah `podSelector` yang bertugas memfilter Pod-Pod yang dikenai _policy_ tersebut. Contoh yang ada memfilter Pod dengan label `"role=db"`. Sebuah `podSelector` yang empty akan memilih semua Pod yang ada di dalam _namespace_. **policyTypes**: Setiap `NetworkPolicy` memiliki sebuah daftar `policyTypes` yang dapat berupa `Ingress`, `Egress`, atau keduanya. _Field_ `policyTypes` mengindikasikan apakah suatu _policy_ diberikan pada trafik _ingress_, _egress_, atau camputan _ingress_ dan _egress_ pada Pod tertentu. Jika tidak ada `policyTypes` tyang diberikan pada `NetworkPolicy` maka `Ingress` _default_ akan diterapkan dan `Egress` akan diterapkan apabila _policy_ tersebut memberikan spesifikasi _egress_. **ingress**: Setiap `NetworkPolicy` bisa saja memberikan serangkaian whitelist _rule-rule_ `ingress`. Setiap _rule_ mengizinkan trafik yang sesuai dengan _section_ `from` dan `ports`. Contoh _policy_ yang diberikan memiliki sebuah _rule_, yang sesuai dengan trafik pada sebuah `port` _single_, bagian pertama dispesifikasikan melalui `ipBlock`, yang kedua melalui `namespaceSelector` dan yang ketiga melalui `podSelector`. **egress**: Setiap `NetworkPolicy` bisa saja meliputi serangkaian _whitelist_ _rule-rule_ `egress`. Setiap _rule_ mengizinkan trafik yang sesuai dengan _section_ `to` dan `ports`. Contoh _policy_ yang diberikan memiliki sebuah _rule_, yang sesuai dengan `port` _single_ pada destinasi `10.0.0.0/24`. Pada contoh, `NetworkPolicy` melakukan hal berikut: 1. Mengisolasi Pod-Pod dengan label `"role=db"` pada _namespace_ `"default"` baik untuk `ingress` atau `egress`. 2. (_Rule_ `Ingress`) mengizinkan koneksi ke semua Pod pada _namespace_ `“default”` dengan label `“role=db”` untuk protokol TCP `port` `6379` dari: * semua Pod pada _namespace_ `"default"` dengan label `"role=frontend"` * semua Pod dalam sebuah _namespace_ dengan label `"project=myproject"` * alamat IP pada _range_ `172.17.0.0–172.17.0.255` dan `172.17.2.0–172.17.255.255` (yaitu, semua `172.17.0.0/16` kecuali `172.17.1.0/24`) 3. (_Rule_ Egress) mengizinkan koneksi dari semua Pod pada _namespace_ `"default"` dengan label `"role=db"` ke CIDR `10.0.0.0/24` untuk protokol TCP pada `port` `5978` Lihat mekanisme [Deklarasi _Network Policy_](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/) untuk penjelasan lebih mendalam. Perilaku selektor `to` dan `from` --------------------------------- Terdapat empat jenis selektor yang dapat dispesifikasikan dalam `section` `ingress` `from` atau `section` `egress` `to`: **podSelector**: Ini digunakan untuk memfilter Pod tertentu pada _namespace_ dimana `NetworkPolicy` berada yang akan mengatur destinasi _ingress_ atau _egress_. **namespaceSelector**: Ini digunakan untuk memfilter _namespace_ tertentu dimana semua Pod diperbolehkan sebagai _source_ `ingress` atau destinasi `egress`. **namespaceSelector** _and_ **podSelector**: Sebuah entri `to`/`from` yang memberikan spesifikasi `namespaceSelector` dan `podSelector` serta memilih Pod-Pod tertentu yang ada di dalam _namespace_. Pastikan kamu menggunakan sintaks YAML yang tepat; `policy` ini: ... ingress: - from: - namespaceSelector: matchLabels: user: alice podSelector: matchLabels: role: client ... mengandung sebuah elemen `from` yang mengizinkan koneksi dari Pod-Pod dengan label `role=client` di _namespace_ dengan label `user=alice`. Akan tetapi, _policy_ _ini_: ... ingress: - from: - namespaceSelector: matchLabels: user: alice - podSelector: matchLabels: role: client ... mengandung dua elemen pada _array_ `from`, dan mengizinkan koneksi dari Pod pada Namespace lokal dengan label `role=client`, _atau_ dari Pod di _namespace_ apa pun dengan label `user=alice`. Ketika kamu merasa ragu, gunakan `kubectl describe` untuk melihat bagaimana Kubernetes menginterpretasikan _policy_ tersebut. **ipBlock**: Ini digunakan untuk memilih _range_ IP CIDR tertentu untuk berperan sebagai _source_ _ingress_ atau destinasi _egress_. Alamat yang digunakan harus merupakan alamat IP eksternal klaster, karena alamat IP Pod bersifat _ephemeral_ dan tidak dapat ditebak. Mekanisme _ingress_ dan _egress_ klaster seringkali membutuhkan mekanisme _rewrite_ alamat IP _source_ dan destinasi paket. Pada kasus-kasus dimana hal ini, tidak dapat dipastikan bahwa apakah hal ini terjadi sebelum atau setelah pemrosesan `NetworkPolicy`, dan perilaku yang ada mungkin saja berbeda untuk kombinasi _plugin_ jaringan, penyedia layanan _cloud_, serta implementasi `Service` yang berbeda. Pada _ingress_, artinya bisa saja kamu melakukan _filter_ paket yang masuk berdasarkan `source IP`, sementara di kasus lain "source IP" yang digunakan oleh Network Policy adalah alamat IP `LoadBalancer`, _node_ dimana Pod berada, dsb. Pada _egress_, bisa saja sebuah koneksi dari Pod ke IP `Service` di-_rewrite_ ke IP eksternal klaster atau bahkan tidak termasuk di dalam `ipBlock` _policy_. _Policy_ _Default_ ------------------ Secara _default_, jika tidak ada _policy_ yang ada dalam suatu _namespace_, maka semua trafik _ingress_ dan _egress_ yang diizinkan ke atau dari Pod dalam _namespace_. Contoh di bawah ini akan memberikan gambaran bagaimana kamu dapat mengubah perilaku _default_ pada sebuah _namespace_. ### _Default_: tolak semua trafik _ingress_ Kamu dapat membuat _policy_ isolasi `"default"` untuk sebuah _namespace_ dengan membuat sebuah `NetworkPolicy` yang memilih semua Pod tapi tidak mengizinkan trafik _ingress_ masuk ke Pod-Pod tersebut. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector: {} policyTypes: - Ingress Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` lain masih terisolasi. _Policy_ ini tidak mengubah perilaku _default_ dari _egress_. ### _Default_: izinkan semua trafik _ingress_ Jika kamu ingin mengizinkan semua trafik _ingress_ pada semua Pod dalam sebuah _namespace_ (bahkan jika _policy_ ditambahkan dan menyebabkan beberapa Pod menjadi terisolasi), kamu dapat secara eksplisit mengizinkan semua trafik bagi _namespace_ tersebut. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all spec: podSelector: {} ingress: - {} policyTypes: - Ingress ### _Default_: tolak semua trafik _egress_ Kamu dapat membuat _policy_ isolasi `"default"` untuk sebuah _namespace_ dengan membuat sebuah `NetworkPolicy` yang memilih semua Pod tapi tidak mengizinkan trafik _egress_ keluar dari Pod-Pod tersebut. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector: {} policyTypes: - Egress Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` lain masih terisolasi. _Policy_ ini tidak mengubah perilaku _default_ dari _ingress_. ### _Default_: izinkan semua trafik _egress_ Jika kamu ingin mengizinkan semua trafik _egress_ pada semua Pod dalam sebuah _namespace_ (bahkan jika _policy_ ditambahkan dan menyebabkan beberapa Pod menjadi terisolasi), kamu dapat secara eksplisit mengizinkan semua trafik bagi _namespace_ tersebut. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all spec: podSelector: {} egress: - {} policyTypes: - Egress ### _Default_: tolak semua trafik _ingress_ dan _egress_ Kamu dapat membuat sebuah _policy_ _"default"_ jika kamu ingin menolak semua trafik _ingress_ maupun _egress_ pada semua Pod dalam sebuah _namespace_. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector: {} policyTypes: - Ingress - Egress Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` tidak akan mengizinkan trafik _ingress_ atau _egress_. Dukungan terhadap SCTP ---------------------- FEATURE STATE: `Kubernetes v1.12 [alpha]` Kubernetes mendukung SCTP sebagai _value_ `protocol` pada definisi `NetworkPolicy` sebagai fitur alpha. Untuk mengaktifkan fitur ini, administrator klaster harus mengaktifkan gerbang fitur `SCTPSupport` pada `apiserver`, contohnya `“--feature-gates=SCTPSupport=true,...”`. Ketika gerbang fitur ini diaktifkan, pengguna dapat menerapkan `value` dari _field_ `protocol` pada `NetworkPolicy` menjadi `SCTP`. Kubernetes akan mengatur jaringan sesuai dengan SCTP, seperti halnya koneksi TCP. _Plugin_ CNI harus mendukung SCTP sebagai _value_ dari `protocol` pada `NetworkPolicy`. Selanjutnya ----------- * Lihat [Deklarasi _Network Policy_](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/) untuk melihat lebih banyak contoh penggunaan. * Baca lebih lanjut soal [panduan](https://github.com/ahmetb/kubernetes-network-policy-recipes) bagi skenario generik _resource_ `NetworkPolicy`. Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified October 06, 2020 at 12:31 AM PST: [Moved object management to task section and fix link (b948e0fff5)](https://github.com/kubernetes/website/commit/b948e0fff567ad9c2b465c0174ea667389ddb7b7) --- # Ingress 控制器 | Kubernetes Ingress 控制器 =========== 为了让 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/) 在集群中工作， 你必须运行一个 Ingress 控制器。你需要选择至少一个 Ingress 控制器并确保其已被部署到你的集群中。 本页列出了你可以部署的常见 Ingress 控制器。 #### 说明： Kubernetes 项目推荐使用 [Gateway](https://gateway-api.sigs.k8s.io/) 而不是 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/) 。 Ingress API 已经被冻结。 这意味着： * Ingress API 是正式发布的，并且遵循正式发布 API 的[稳定性保证](https://kubernetes.io/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) 。 Kubernetes 项目没有计划从 Kubernetes 中移除 Ingress。 * Ingress API 不再进行开发，也不会对其进行进一步的更改或更新。 Kubernetes 项目支持并维护 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme) 和 [GCE](https://git.k8s.io/ingress-gce/README.md#readme) ingress 控制器。 第三方 Ingress 控制器 --------------- **说明：** 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) ，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读[内容指南](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) 。 * [AKS 应用程序网关 Ingress 控制器](https://docs.microsoft.com/zh-cn/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json) 是一个配置 [Azure 应用程序网关](https://docs.microsoft.com/zh-cn/azure/application-gateway/overview) 的 Ingress 控制器。 * [阿里云 API 网关 Ingress](https://www.alibabacloud.com/help/zh/api-gateway/cloud-native-api-gateway/user-guide/ingress-managementapig-ngress-management) 是一个 Ingress 控制器，它负责配置[阿里云原生 API 网关](https://www.alibabacloud.com/help/en/api-gateway/cloud-native-api-gateway/product-overview/what-is-cloud-native-api-gateway) ， 也是 [Higress](https://github.com/alibaba/higress) 的商业版本。 * [Apache APISIX Ingress 控制器](https://github.com/apache/apisix-ingress-controller) 是一个基于 [Apache APISIX 网关](https://github.com/apache/apisix) 的 Ingress 控制器。 * [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) 使用 [VMware NSX Advanced Load Balancer](https://avinetworks.com/) 提供第 4 到第 7 层的负载均衡。 * [BFE Ingress 控制器](https://github.com/bfenetworks/ingress-bfe) 是一个基于 [BFE](https://www.bfe-networks.net/) 的 Ingress 控制器。 * [BunkerWeb Ingress 控制器](https://docs.bunkerweb.io/latest/integrations/#kubernetes) 是 [BunkerWeb](https://www.bunkerweb.io/) 的 Ingress 控制器， BunkerWeb 是一款基于 Nginx 的 Web 应用防火墙（WAF）。 * [Cilium Ingress 控制器](https://docs.cilium.io/en/stable/network/servicemesh/ingress/) 是一个由 [Cilium](https://cilium.io/) 出品支持的 Ingress 控制器。 * [Citrix Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller#readme) 可以用来与 Citrix Application Delivery Controller 一起使用。 * [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 Ingress 控制器。 * [Emissary-Ingress](https://www.getambassador.io/products/api-gateway) API 网关是一个基于 [Envoy](https://www.envoyproxy.io/) 的入口控制器。 * [EnRoute](https://getenroute.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 API 网关，可以用作 Ingress 控制器。 * F5 BIG-IP 的 [用于 Kubernetes 的容器 Ingress 服务](https://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest) 让你能够使用 Ingress 来配置 F5 BIG-IP 虚拟服务器。 * [FortiADC Ingress 控制器](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller/742835/fortiadc-ingress-controller-overview) 支持 Kubernetes Ingress 资源，并允许你从 Kubernetes 管理 FortiADC 对象。 * [Gloo](https://gloo.solo.io/) 是一个开源的、基于 [Envoy](https://www.envoyproxy.io/) 的 Ingress 控制器，能够提供 API 网关功能。 * [HAProxy Ingress](https://haproxy-ingress.github.io/) 是一个针对 [HAProxy](https://www.haproxy.org/#desc) 的 Ingress 控制器。 * [Higress](https://github.com/alibaba/higress) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 API 网关，可以作为一个 Ingress 控制器运行。 * [用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress#readme) 也是一个针对 [HAProxy](https://www.haproxy.org/#desc) 的 Ingress 控制器。 * [Istio Ingress](https://istio.io/latest/zh/docs/tasks/traffic-management/ingress/kubernetes-ingress/) 是一个基于 [Istio](https://istio.io/zh/) 的 Ingress 控制器。 * [用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller#readme) 是一个用来驱动 [Kong Gateway](https://konghq.com/kong/) 的 Ingress 控制器。 * [Kusk Gateway](https://kusk.kubeshop.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的、OpenAPI 驱动的 Ingress 控制器。 * [用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx-ingress-controller/) 能够与 [NGINX](https://www.nginx.com/resources/glossary/nginx/) 网页服务器（作为代理）一起使用。 * [ngrok-operator](https://github.com/ngrok/ngrok-operator) 是一个支持 Ingress 和 Gateway API 的 [ngrok](https://ngrok.com/) 控制器，用于为你的 K8s 服务添加安全的公开访问。 * [OCI Native Ingress Controller](https://github.com/oracle/oci-native-ingress-controller#readme) 是一个适用于 Oracle Cloud Infrastructure 的 Ingress 控制器，可帮助你管理 [OCI 负载均衡](https://docs.oracle.com/en-us/iaas/Content/Balance/home.htm) 。 * [OpenNJet Ingress Controller](https://gitee.com/njet-rd/open-njet-kic) 是一个基于 [OpenNJet](https://njet.org.cn/) 的 Ingress 控制器。 * [Pomerium Ingress 控制器](https://www.pomerium.com/docs/k8s/ingress.html) 基于 [Pomerium](https://pomerium.com/) ，能提供上下文感知的准入策略。 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理可用于服务组装，支持包括 Kubernetes Ingress 这类使用场景，是一个用以构造你自己的定制代理的库。 * [Traefik Kubernetes Ingress 提供程序](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) 是一个用于 [Traefik](https://traefik.io/traefik/) 代理的 Ingress 控制器。 * [Tyk Operator](https://github.com/TykTechnologies/tyk-operator) 使用自定义资源扩展 Ingress，为之带来 API 管理能力。Tyk Operator 使用开源的 Tyk Gateway & Tyk Cloud 控制面。 * [Voyager](https://voyagermesh.com/) 是一个针对 [HAProxy](https://www.haproxy.org/#desc) 的 Ingress 控制器。 * [Wallarm Ingress Controller](https://www.wallarm.com/solutions/waf-for-kubernetes) 是提供 WAAP（WAF）和 API 安全功能的 Ingress Controller。 使用多个 Ingress 控制器 ---------------- 你可以使用 [Ingress 类](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#ingress-class) 在集群中部署任意数量的 Ingress 控制器。 请注意你的 Ingress 类资源的 `.metadata.name` 字段。 当你创建 Ingress 时，你需要用此字段的值来设置 Ingress 对象的 `ingressClassName` 字段（请参考 [IngressSpec v1 reference](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec) ）。 `ingressClassName` 是之前的[注解](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#deprecated-annotation) 做法的替代。 如果你不为 Ingress 指定 IngressClass，并且你的集群中只有一个 IngressClass 被标记为默认，那么 Kubernetes 会将此集群的默认 IngressClass [应用](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#default-ingress-class) 到 Ingress 上。 你可以通过将 [`ingressclass.kubernetes.io/is-default-class` 注解](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) 的值设置为 `"true"` 来将一个 IngressClass 标记为集群默认。 理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。 #### 说明： 确保你查看了 ingress 控制器的文档，以了解选择它的注意事项。 接下来 --- * 进一步了解 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/) 。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 January 27, 2026 at 10:34 AM PST: [\[zh-cn\] sync ingress-controllers.md (ec6b916ff7)](https://github.com/kubernetes/website/commit/ec6b916ff7c9c18353dba85e51d06d1eb0665ca2) 本页面中的条目引用了第三方产品或项目，这些产品（项目）提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品（项目）负责。请参阅[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) 了解更多细节。 在提交更改建议，向本页添加新的第三方链接之前，你应该先阅读[内容指南。](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) --- # 安装工具 | Kubernetes 安装工具 ==== * * * ##### [Kubeadm](https://kubernetes.io/zh-cn/docs/reference/setup-tools/kubeadm/) 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 March 23, 2023 at 4:03 PM PST: [\[zh-cn\] Reference files to sync task-28 (1e63bd87df)](https://github.com/kubernetes/website/commit/1e63bd87df8b18d14a89d5a5975236f883c259ba) --- # Kubernetes z-pages | Kubernetes Kubernetes z-pages ================== 为 Kubernetes 组件提供运行时诊断，展示组件运行状态和配置标志的监测信息。 特性状态： `Kubernetes v1.32 [alpha]` Kubernetes 的核心组件可以暴露一系列 **z-endpoints**，以便用户更轻松地调试他们的集群及其组件。 这些端点仅用于人工检查，以获取组件二进制文件的实时调试信息。请不要自动抓取这些端点返回的数据； 在 Kubernetes 1.35 中，这些是 **Alpha** 特性，响应格式可能会在未来版本中发生变化。 z-pages ------- Kubernetes v1.35 允许你启用 **z-pages** 来帮助排查其核心控制平面组件的问题。 这些特殊的调试端点提供与正在运行的组件有关的内部信息。对于 Kubernetes 1.35， 这些组件提供以下端点（当启用 z-pages 后）： * [z-pages](https://kubernetes.io/zh-cn/docs/reference/instrumentation/zpages/#z-pages) * [statusz](https://kubernetes.io/zh-cn/docs/reference/instrumentation/zpages/#statusz) * [statusz (structured)](https://kubernetes.io/zh-cn/docs/reference/instrumentation/zpages/#statusz-structured) * [flagz](https://kubernetes.io/zh-cn/docs/reference/instrumentation/zpages/#flagz) * [flagz (structured)](https://kubernetes.io/zh-cn/docs/reference/instrumentation/zpages/#flagz-structured) ### statusz 使用 `ComponentStatusz` [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates#ComponentStatusz) 启用后， `/statusz` 端点显示有关组件的高级信息，例如其 Kubernetes 版本、仿真版本、启动时间等。 来自 API 服务器的 `/statusz` 纯文本响应类似于： kube-apiserver statusz Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only. Started: Wed Oct 16 21:03:43 UTC 2024 Up: 0 hr 00 min 16 sec Go version: go1.23.2 Binary version: 1.32.0-alpha.0.1484+5eeac4f21a491b-dirty Emulation version: 1.32.0-alpha.0.1484 Paths: /healthz /livez /metrics /readyz /statusz /version #### statusz（结构化的） 特性状态： `Kubernetes v1.32 [alpha]`（默认禁用） 从 Kubernetes v1.35 开始，`/statusz` 端点支持结构化的、版本化的响应格式， 前提是请求时使用了正确的 `Accept` 标头。 如果没有 `Accept` 标头，则该端点默认返回纯文本响应格式。 如需获取结构化回复，请使用： Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Statusz #### 说明： 如果你请求 `application/json` 时未指定所有必需参数（`g`、`v` 和 `as`）， 服务器将响应 `406 Not Acceptable`。 结构化响应示例： { "kind": "Statusz", "apiVersion": "config.k8s.io/v1alpha1", "metadata": { "name": "kube-apiserver" }, "startTime": "2025-10-29T00:30:01Z", "uptimeSeconds": 856, "goVersion": "go1.23.2", "binaryVersion": "1.35.0", "emulationVersion": "1.35", "paths": [\ "/healthz",\ "/livez",\ "/metrics",\ "/readyz",\ "/statusz",\ "/version"\ ] } 结构化 `/statusz` 响应的 `config.k8s.io/v1alpha1` 模式如下： // Statusz is the config.k8s.io/v1alpha1 schema for the /statusz endpoint. type Statusz struct { // Kind is "Statusz". Kind string `json:"kind"` // APIVersion is the version of the object, e.g., "config.k8s.io/v1alpha1". APIVersion string `json:"apiVersion"` // Standard object's metadata. // +optional Metadata metav1.ObjectMeta `json:"metadata,omitempty"` // StartTime is the time the component process was initiated. StartTime metav1.Time `json:"startTime"` // UptimeSeconds is the duration in seconds for which the component has been running continuously. UptimeSeconds int64 `json:"uptimeSeconds"` // GoVersion is the version of the Go programming language used to build the binary. // The format is not guaranteed to be consistent across different Go builds. // +optional GoVersion string `json:"goVersion,omitempty"` // BinaryVersion is the version of the component's binary. // The format is not guaranteed to be semantic versioning and may be an arbitrary string. BinaryVersion string `json:"binaryVersion"` // EmulationVersion is the Kubernetes API version which this component is emulating. // if present, formatted as "." // +optional EmulationVersion string `json:"emulationVersion,omitempty"` // MinimumCompatibilityVersion is the minimum Kubernetes API version with which the component is designed to work. // if present, formatted as "." // +optional MinimumCompatibilityVersion string `json:"minimumCompatibilityVersion,omitempty"` // Paths contains relative URLs to other essential read-only endpoints for debugging and troubleshooting. // +optional Paths []string `json:"paths,omitempty"` } ### flagz 使用 `ComponentFlagz` [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates#ComponentFlagz) 启用后， `/flagz` 端点为你显示用于启动某组件的命令行参数。 API 服务器的 `/flagz` 纯文本响应看起来类似于： kube-apiserver flags Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only. advertise-address=192.168.8.2 contention-profiling=false enable-priority-and-fairness=true profiling=true authorization-mode=[Node,RBAC] authorization-webhook-cache-authorized-ttl=5m0s authorization-webhook-cache-unauthorized-ttl=30s authorization-webhook-version=v1beta1 default-watch-cache-size=100 #### flagz (structured) 特性状态： `Kubernetes v1.32 [alpha]`（默认禁用） 从 Kubernetes v1.35 开始，`/flagz` 端点支持结构化、版本化的响应格式， 前提是请求时使用了正确的 `Accept` 标头。 如果没有 `Accept` 标头，则该端点默认返回纯文本响应格式。 要请求结构化响应，请使用： Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Flagz #### 说明： 如果你请求 `application/json` 时未指定所有必需参数（`g`、`v` 和 `as`）， 服务器将响应 `406 Not Acceptable`。 Example structured response: { "kind": "Flagz", "apiVersion": "config.k8s.io/v1alpha1", "metadata": { "name": "kube-apiserver" }, "flags": { "advertise-address": "192.168.8.4", "allow-privileged": "true", "anonymous-auth": "true", "authorization-mode": "[Node,RBAC]", "enable-priority-and-fairness": "true", "profiling": "true", "default-watch-cache-size": "100" } } The `config.k8s.io/v1alpha1` schema for the structured `/flagz` response is as follows: // Flagz is the config.k8s.io/v1alpha1 schema for the /flagz endpoint. type Flagz struct { // Kind is "Flagz". Kind string `json:"kind"` // APIVersion is the version of the object, e.g., "config.k8s.io/v1alpha1". APIVersion string `json:"apiVersion"` // Standard object's metadata. // +optional Metadata metav1.ObjectMeta `json:"metadata,omitempty"` // Flags contains the command-line flags and their values. // The keys are the flag names and the values are the flag values, // possibly with confidential values redacted. // +optional Flags map[string]string `json:"flags,omitempty"` } #### 说明： `/statusz` 和 `/flagz` 的结构化响应在 v1.35 版本中仍处于 Alpha 阶段，未来版本可能会有所更改。 它们旨在为调试和自省工具提供机器可解析的输出。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 February 20, 2026 at 4:36 PM PST: [\[zh-cn\]sync zpages (d84f92223b)](https://github.com/kubernetes/website/commit/d84f92223ba8c69031066669aaf20ce82b1bed34) --- # kubelet 配置 (v1alpha1) | Kubernetes kubelet 配置 (v1alpha1) ===================== 资源类型 ---- * [CredentialProviderConfig](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-CredentialProviderConfig) `CredentialProviderConfig` -------------------------- CredentialProviderConfig 包含有关每个 exec 凭据提供者的配置信息。 kubelet 从磁盘上读取这些配置信息，并根据 CredentialProvider 类型启用各个提供者。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `kubelet.config.k8s.io/v1alpha1` | | `kind`
string | `CredentialProviderConfig` | | `providers` **\[必需\]**
[`[]CredentialProvider`](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-CredentialProvider) | `providers` 是一组凭据提供者插件，这些插件会被 kubelet 启用。 多个提供者可以匹配到同一镜像上，这时，来自所有提供者的凭据信息都会返回给 kubelet。 如果针对同一镜像调用了多个提供者，则结果会被组合起来。如果提供者返回的认证主键有重复， 列表中先出现的提供者所返回的值将第一个被尝试使用。 | `ImagePullIntent` ----------------- `ImagePullIntent` 是 kubelet 尝试拉取镜像的记录。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `kubelet.config.k8s.io/v1alpha1` | | `kind`
string | `ImagePullIntent` | | `image` **\[必需\]**
`string` | `image` 是容器 `image` 字段中的镜像规约。 文件名是此值的 SHA-256 哈希，这样做是为了避免文件名中不安全的字符，如 ':' 和 '/'。 | `ImagePulledRecord` ------------------- `ImagePullRecord` 是 kubelet 拉取的镜像的记录。 如果 `kubernetesSecrets` 字段中没有记录，且 `nodeWideCredentials` 和 `anonymous` 均为 `false`，则当请求此记录表示的镜像时，必须重新检查凭据。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `kubelet.config.k8s.io/v1alpha1` | | `kind`
string | `ImagePulledRecord` | | `lastUpdatedTime` **\[必需\]**
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#time-v1-meta) | `lastUpdatedTime` 是此记录上次更新的时间。 | | `imageRef` **\[必需\]**
`string` | `imageRef` 是从 CRI 接收到的此文件所代表的镜像的引用。 文件名是此值的 SHA-256 哈希。这是为了避免文件名中不安全的字符，如 ':' 和 '/'。 | | `credentialMapping` **\[必需\]**
[`map[string]ImagePullCredentials`](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ImagePullCredentials) | `credentialMapping` 将 `image` 映射到之前拉取它时使用的凭据集。 这里的 `image` 是 Pod 的容器中 `image` 字段的内容， 已去除其标签/摘要。

示例： 容器请求 `hello-world:latest@sha256:91fb4b041da273d5a3273b6d587d62d518300a6ad268b28628f74997b93171b2` 镜像： "credentialMapping": { "hello-world": { "nodePodsAccessible": true } } | `CredentialProvider` -------------------- **出现在：** * [CredentialProviderConfig](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-CredentialProviderConfig) * [ImagePullIntent](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ImagePullIntent) * [ImagePulledRecord](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ImagePulledRecord) CredentialProvider 代表的是要被 kubelet 调用的一个 exec 插件。 这一插件只会在所拉取的镜像与该插件所处理的镜像匹配时才会被调用（参见 `matchImages`）。 | 字段 | 描述 | | --- | --- | | `name` **\[必需\]**
`string` | `name` 是凭据提供者的名称（必需）。此名称必须与 kubelet 所看到的提供者可执行文件的名称匹配。可执行文件必须位于 kubelet 的 `bin` 目录（通过 `--image-credential-provider-bin-dir` 设置）下。 必须在所有提供商之间保持唯一。 | | `matchImages` **\[必需\]**
`[]string` | `matchImages` 是一个必须设置的字符串列表，用来匹配镜像以便确定是否要调用此提供者。 如果字符串之一与 kubelet 所请求的镜像匹配，则此插件会被调用并给予提供凭证的机会。 镜像应该包含镜像库域名和 URL 路径。

`matchImages` 中的每个条目都是一个模式字符串，其中可以包含端口号和路径。 域名部分可以包含统配符，但端口或路径部分不可以。通配符可以用作子域名，例如 `*.k8s.io` 或 `k8s.*.io`，以及 `k8s.*` 这类顶级域名。

对类似 `app*.k8s.io` 这类部分子域名的匹配也是支持的。 每个通配符只能用来匹配一个子域名段，所以 `*.io` 不会匹配 `*.k8s.io`。

镜像与 `matchImages` 之间存在匹配时，以下条件都要满足：

* 二者均包含相同个数的域名部分，并且每个域名部分都对应匹配；
* `matchImages` 条目中的 URL 路径部分必须是目标镜像的 URL 路径的前缀；
* 如果 `matchImages` 条目中包含端口号，则端口号也必须与镜像端口号匹配。

`matchImages` 的一些示例如下：

* `123456789.dkr.ecr.us-east-1.amazonaws.com`
* `*.azurecr.io`
* `gcr.io`
* `*.*.registry.io`
* `registry.io:8080/path` | | `defaultCacheDuration` **\[必需\]**
[`meta/v1.Duration`](https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration) | `defaultCacheDuration` 是插件在内存中缓存凭据的默认时长， 在插件响应中没有给出缓存时长时，使用这里设置的值。此字段是必需的。 | | `apiVersion` **\[必需\]**
`string` | 要求 exec 插件 CredentialProviderRequest 请求的输入版本。 所返回的 CredentialProviderResponse 必须使用与输入相同的编码版本。当前支持的值有：

* `credentialprovider.kubelet.k8s.io/v1alpha1` | | `args`
`[]string` | 在执行插件可执行文件时要传递给命令的参数。 | | `env`
[`[]ExecEnvVar`](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ExecEnvVar) | `env` 定义要提供给插件进程的额外的环境变量。 这些环境变量会与主机上的其他环境变量以及 client-go 所使用的环境变量组合起来， 一起传递给插件。 | `ExecEnvVar` ------------ **出现在：** * [CredentialProvider](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-CredentialProvider) ExecEnvVar 用来在执行基于 exec 的凭据插件时设置环境变量。 | 字段 | 描述 | | --- | --- | | `name` **\[必需\]**
`string` | 环境变量名称。 | | `value` **\[必需\]**
`string` | 环境变量取值。 | `ImagePullCredentials` ---------------------- **出现在：** * [ImagePulledRecord](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ImagePulledRecord) `ImagePullCredentials` 描述可以用于拉取镜像的凭据。 | 字段 | 描述 | | --- | --- | | `kubernetesSecrets`
[`[]ImagePullSecret`](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ImagePullSecret) | `kuberneteSecretCoordinates` 是用于拉取镜像的所有 Kubernetes Secret 的坐标索引。 | | `kubernetesServiceAccounts`
[`[]ImagePullServiceAccount`](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ImagePullServiceAccount) | `kubernetesServiceAccounts` 是用于拉取镜像的所有 Kubernetes 服务账号的坐标索引。 | | `nodePodsAccessible`
`bool` | `nodePodsAccessible` 是一个标志，表示节点上的所有 Pod 都可以访问拉取凭据， 或者拉取不需要凭据。

如果为 true，则与 `kubernetesSecrets` 字段互斥。 | `ImagePullSecret` ----------------- **出现在：** * [ImagePullCredentials](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ImagePullCredentials) `ImagePullSecret` 是 Kubernetes Secret 对象坐标的表示， 以及此对象包含的拉取 Secret 凭据的哈希值。 | 字段 | 描述 | | --- | --- | | `uid` **\[必需\]**
`string` | 没有提供描述。 | | `namespace` **\[必需\]**
`string` | 没有提供描述。 | | `name` **\[必需\]**
`string` | 没有提供描述。 | | `credentialHash` **\[必需\]**
`string` | `credentialHash` 是通过对镜像拉取凭据的内容进行哈希计算获得的 SHA-256 值， 这些凭据由 UID/命名空间/名称坐标指定的 Secret 提供。 | `ImagePullServiceAccount` ------------------------- **出现在：** * [ImagePullCredentials](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/#kubelet-config-k8s-io-v1alpha1-ImagePullCredentials) ImagePullServiceAccount 是 Kubernetes 服务账号对象坐标的表示， kubelet 将服务账号令牌发送给凭据提供程序以用于拉取镜像的凭据。 | 字段 | 描述 | | --- | --- | | `uid` **必需**
`string` | 资源对象的唯一标识（UID）。 | | `namespace` **必需**
`string` | 资源对象所在名字空间。 | | `name` **必需**
`string` | 资源对象的名称。 | 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 January 06, 2026 at 4:34 PM PST: [\[zh-cn\]sync kubelet-config.v1alpha1 (b54d53cd6b)](https://github.com/kubernetes/website/commit/b54d53cd6b5e37a5eef506f6520ad5e43661b984) --- # Überblick | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Overview](https://kubernetes.io/docs/concepts/overview/) Überblick ========= Kubernetes ist eine portable, erweiterbare und quelloffene Plattform, um containerisierte Arbeitslasten und Dienste zu verwalten. Dies wird mithilfe von Automatisierungen und deklarativen Konfigurationen erreicht. Kubernetes hat ein großes, schnell wachsendes Ökosystem. Dienstleistungen, Hilfestellungen und Tools für Kubernetes sind weit verbreitet. * * * ##### [Was ist Kubernetes?](https://kubernetes.io/de/docs/concepts/overview/what-is-kubernetes/) ##### [Kubernetes Komponenten](https://kubernetes.io/de/docs/concepts/overview/components/) Feedback -------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Zuletzt geändert May 21, 2023 at 2:52 PM PST: [Change style of German Concepts index page (d524178a60)](https://github.com/kubernetes/website/commit/d524178a60ce1ad541db6bdfcb446476416d04d0) --- # Kubernetes Architektur | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Cluster Architecture](https://kubernetes.io/docs/concepts/architecture/) Kubernetes Architektur ====================== Hier werden die architektonischen Konzepte von Kubernetes beschrieben. * * * ##### [Nodes](https://kubernetes.io/de/docs/concepts/architecture/nodes/) ##### [Control-Plane-Node Kommunikation](https://kubernetes.io/de/docs/concepts/architecture/control-plane-node-communication/) ##### [Controller](https://kubernetes.io/de/docs/concepts/architecture/controller/) ##### [Zugrunde liegende Konzepte des Cloud Controller Manager](https://kubernetes.io/de/docs/concepts/architecture/cloud-controller/) ##### [Über cgroup v2](https://kubernetes.io/de/docs/concepts/architecture/cgroups/) Feedback -------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Zuletzt geändert June 10, 2023 at 8:12 PM PST: [Fix incorrect translation for 'Architecture' (dcef1e6fea)](https://github.com/kubernetes/website/commit/dcef1e6fea06dd9866e5bd2db20b118eea75d71b) --- # Workloads | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Workloads](https://kubernetes.io/docs/concepts/workloads/) Workloads ========= Informationen über Pods, die kleinsten Einheiten, die in Kubernetes bereitgestellt werden können und über Abstraktionen, die hierbei behilflich sind. * * * ##### [Deployments](https://kubernetes.io/de/docs/concepts/workloads/controllers/deployment/) ##### [Pods](https://kubernetes.io/de/docs/concepts/workloads/pods/) ##### [ReplicaSet](https://kubernetes.io/de/docs/concepts/workloads/controllers/replicaset/) ##### [Jobs](https://kubernetes.io/de/docs/concepts/workloads/controllers/job/) Feedback -------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Zuletzt geändert May 21, 2023 at 2:52 PM PST: [Change style of German Concepts index page (d524178a60)](https://github.com/kubernetes/website/commit/d524178a60ce1ad541db6bdfcb446476416d04d0) --- # 混合版本代理 | Kubernetes 混合版本代理 ====== 特性状态： `Kubernetes v1.28 [alpha]`（默认禁用） Kubernetes 1.35 包含了一个 Alpha 特性，可以让 [API 服务器](https://kubernetes.io/zh-cn/docs/concepts/architecture/#kube-apiserver "提供 Kubernetes API 服务的控制面组件。") 代理指向其他**对等** API 服务器的资源请求。 它还允许客户通过发现功能全面了解整个集群提供的资源。 当一个集群中运行着多个 API 服务器，且各服务器的 Kubernetes 版本不同时 （例如在上线 Kubernetes 新版本的时间跨度较长时），这一特性非常有用。 这使得集群管理员能够配置高可用性集群，并能更安全地进行升级，具体方式如下： 1. 将资源请求（在升级期间发起）导向正确的 kube-apiserver。这种代理防止用户看到由升级过程导致的意外的 404 未找到错误。此机制被称为 **混合版本代理（Mixed Version Proxy）**。 2. 将升级过程中产生的资源请求定向到正确的 kube-apiserver。 这种代理机制可以防止用户看到因升级过程导致的意外 404 Not Found 错误。 这种机制称为混合版本代理。 启用对等聚合发现和混合版本代理 --------------- 当你启动 [API 服务器](https://kubernetes.io/zh-cn/docs/concepts/architecture/#kube-apiserver "提供 Kubernetes API 服务的控制面组件。") 时， 确保启用了 `UnknownVersionInteroperabilityProxy` [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#UnknownVersionInteroperabilityProxy) ： kube-apiserver \ --feature-gates=UnknownVersionInteroperabilityProxy=true \ # 需要为此特性添加的命令行参数 --peer-ca-file=<指向 kube-apiserver CA 证书的路径> --proxy-client-cert-file=<指向聚合器代理证书的路径>, --proxy-client-key-file=<指向聚合器代理密钥的路径>, --requestheader-client-ca-file=<指向聚合器 CA 证书的路径>, # requestheader-allowed-names 可设置为空以允许所有 Common Name --requestheader-allowed-names=<验证代理客户端证书的合法 Common Name>, # 此特性的可选标志 --peer-advertise-ip=`应由对等方用于代理请求的 kube-apiserver IP` --peer-advertise-port=`应由对等方用于代理请求的 kube-apiserver 端口` # ... 和其他常规标志 ### API 服务器之间的代理传输和身份验证 * 源 kube-apiserver 重用[现有的 API 服务器客户端身份验证标志](https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/#kubernetes-apiserver-client-authentication) `--proxy-client-cert-file` 和 `--proxy-client-key-file` 来表明其身份，供对等（目标 kube-apiserver）验证。 目标 API 服务器根据你使用 `--requestheader-client-ca-file` 命令行参数指定的配置来验证对等连接。 * 要对目标服务器所用的证书进行身份验证，必须通过指定 `--peer-ca-file` 命令行参数来为**源** API 服务器配置一个证书机构包。 ### 对等 API 服务器连接的配置 要设置 kube-apiserver 的网络位置以供对等方来代理请求， 使用为 kube-apiserver 设置的 `--peer-advertise-ip` 和 `--peer-advertise-port` 命令行参数， 或在 API 服务器配置文件中指定这些字段。如果未指定这些参数，对等方将使用 `--advertise-address` 或 `--bind-address` 命令行参数的值。如果这些也未设置，则使用主机的默认接口。 对等聚合发现 ------ 当你启用该特性时，默认情况下，发现请求会自动提供一个全面的发现文档 （列出集群中任何 API 服务器提供的所有资源）。 如果你想要请求一个非对等聚合的发现文档，可以通过在发现请求中添加以下 Accept 标头来表明： application/json;g=apidiscovery.k8s.io;v=v2;as=APIGroupDiscoveryList;profile=nopeer #### 说明： 对等聚合发现仅支持向 `/apis` 端点发出的[聚合发现](https://kubernetes.io/zh-cn/docs/concepts/overview/kubernetes-api/#aggregated-discovery) 请求， 而不支持[未聚合（旧版）发现](https://kubernetes.io/zh-cn/docs/concepts/overview/kubernetes-api/#unaggregated-discovery) 请求。 混合版本代理 ------ 启用混合版本代理时， [聚合层](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 会加载一个特殊的过滤器， 完成以下操作： * 当资源请求到达无法提供该 API 的 API 服务器时 （可能的原因是服务器早于该 API 的正式引入日期或该 API 在 API 服务器上被关闭）， API 服务器会尝试将请求发送到能够提供所请求 API 的对等 API 服务器。 API 服务器通过发现本地服务器无法识别的 API 组/版本/资源来实现这一点， 并尝试将这些请求代理到能够处理这些请求的对等 API 服务器。 * 如果对等 API 服务器无法响应，则**源** API 服务器将以 503（"Service Unavailable"）错误进行响应。 ### 内部工作原理 当 API 服务器收到一个资源请求时，它首先检查哪些 API 服务器可以提供所请求的资源。 此检查是使用非对等聚合的发现文档进行的。 * 如果请求中的资源列在从接收请求的 API 服务器（例如，`GET /api/v1/pods/some-pod`） 检索到的非对等聚合发现文档中，则该请求将在本地处理。 * 如果请求中的资源（例如，`GET /apis/resource.k8s.io/v1beta1/resourceclaims`） 未在尝试处理该请求的 API 服务器（即处理请求的 API 服务器）检索到的非对等聚合发现文档中找到， 可能是因为 `resource.k8s.io/v1beta1` API 是在较新的 Kubernetes 版本中引入的， 而处理请求的 API 服务器运行的是不支持该 API 的旧版本， 则处理请求的 API 服务器会检查所有对等 API 服务器的非对等聚合发现文档， 以获取提供相关 API 组/版本/资源（在本例中为 `resource.k8s.io/v1beta1/resourceclaims`） 的对等 API 服务器。 然后，处理 API 服务器将请求代理到已知所请求资源的匹配对等 kube-apiserver 之一。 * 如果没有对等方了解所给的 API 组/版本/资源，则处理请求的 API 服务器将请求传递给自己的处理程序链， 最终应返回 404（"Not Found"）响应。 * 如果处理请求的 API 服务器已经识别并选择了一个对等 API 服务器，但该对等方无法响应 （原因可能是网络连接问题或正接收的请求与向控制平面注册对等信息的控制器之间存在数据竞争等）， 则处理请求的 API 服务器会以 503（"Service Unavailable"）错误进行响应。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 December 18, 2025 at 9:50 PM PST: [\[zh-cn\]sync mixed-version-proxy (b7ca4c6dcc)](https://github.com/kubernetes/website/commit/b7ca4c6dcce6cfce9cab13b371ed578049fc96ca) --- # 端口和协议 | Kubernetes 端口和协议 ===== 当你在一个有严格网络边界的环境里运行 Kubernetes，例如拥有物理网络防火墙或者拥有公有云中虚拟网络的自有数据中心， 了解 Kubernetes 组件使用了哪些端口和协议是非常有用的。 控制面 --- | 协议 | 方向 | 端口范围 | 目的 | 使用者 | | --- | --- | --- | --- | --- | | TCP | 入站 | 6443 | Kubernetes API 服务器 | 所有 | | TCP | 入站 | 2379-2380 | etcd 服务器客户端 API | kube-apiserver、etcd | | TCP | 入站 | 10250 | kubelet API | 自身、控制面 | | TCP | 入站 | 10259 | kube-scheduler | 自身 | | TCP | 入站 | 10257 | kube-controller-manager | 自身 | 尽管 etcd 的端口也列举在控制面的部分，但你也可以在外部自己托管 etcd 集群或者自定义端口。 工作节点 ---- | 协议 | 方向 | 端口范围 | 目的 | 使用者 | | --- | --- | --- | --- | --- | | TCP | 入站 | 10250 | kubelet API | 自身、控制面 | | TCP | 入站 | 10256 | kube-proxy | 自身、负载均衡器 | | TCP | 入站 | 30000-32767 | NodePort Services† | 所有 | | UDP | 入站 | 30000-32767 | NodePort Services† | 所有 | † [NodePort Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 的默认端口范围。 所有默认端口都可以重新配置。当使用自定义的端口时，你需要打开这些端口来代替这里提到的默认端口。 一个常见的例子是 API 服务器的端口有时会配置为 443。或者你也可以使用默认端口， 把 API 服务器放到一个监听 443 端口的负载均衡器后面，并且路由所有请求到 API 服务器的默认端口。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 May 14, 2025 at 12:48 AM PST: [\[zh\] Update ports-and-protocols.md (053d2ce2f1)](https://github.com/kubernetes/website/commit/053d2ce2f194c03f203e2003081f3d5a0bd7636c) --- # Runtime Container | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Container Runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) Runtime Container ================= FEATURE STATE: `Kubernetes v1.6 [stable]` Untuk menjalankan Container di Pod, Kubernetes menggunakan _runtime_ Container (Container runtimes). Berikut ini adalah petunjuk instalasi untuk berbagai macam _runtime_. #### Perhatian: Sebuah kekurangan ditemukan dalam cara `runc` menangani pendeskripsi berkas (_file_) sistem ketika menjalankan Container. Container yang berbahaya dapat menggunakan kekurangan ini untuk menimpa konten biner `runc` dan akibatnya Container tersebut dapat menjalankan perintah yang sewenang-wenang pada sistem host dari Container tersebut. Silahkan merujuk pada [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736) untuk informasi lebih lanjut tentang masalah ini. ### Penerapan #### Catatan: Dokumen ini ditulis untuk pengguna yang memasang CRI (Container Runtime Interface) pada sistem operasi Linux. Untuk sistem operasi yang lain, silahkan cari dokumentasi khusus untuk platform kamu. Kamu harus menjalankan semua perintah dalam panduan ini sebagai `root`. Sebagai contoh, awali perintah dengan `sudo`, atau masuk sebagai `root` dan kemudian baru menjalankan perintah sebagai pengguna `root`. ### _Driver_ cgroup Ketika systemd dipilih sebagai sistem init untuk sebuah distribusi Linux, proses init menghasilkan dan menggunakan grup kontrol root (`cgroup`) dan proses ini akan bertindak sebagai manajer cgroup. Systemd memiliki integrasi yang ketat dengan cgroup dan akan mengalokasikan cgroups untuk setiap proses. Kamu dapat mengonfigurasi _runtime_ Container dan kubelet untuk menggunakan `cgroupfs`. Menggunakan `cgroupfs` bersama dengan systemd berarti akan ada dua manajer cgroup yang berbeda. Cgroup digunakan untuk membatasi sumber daya yang dialokasikan untuk proses. Sebuah manajer cgroup tunggal akan menyederhanakan pandangan tentang sumber daya apa yang sedang dialokasikan dan secara bawaan (_default_) akan memiliki pandangan yang lebih konsisten tentang sumber daya yang tersedia dan yang sedang digunakan. Ketika kita punya memiliki dua manajer maka kita pun akan memiliki dua pandangan berbeda tentang sumber daya tersebut. Kita telah melihat kasus di lapangan di mana Node yang dikonfigurasi menggunakan `cgroupfs` untuk kubelet dan Docker, dan `systemd` untuk semua sisa proses yang berjalan pada Node maka Node tersebut akan menjadi tidak stabil di bawah tekanan sumber daya. Mengubah aturan sedemikian rupa sehingga _runtime_ Container dan kubelet kamu menggunakan `systemd` sebagai _driver_ cgroup akan menstabilkan sistem. Silahkan perhatikan opsi `native.cgroupdriver=systemd` dalam pengaturan Docker di bawah ini. #### Perhatian: Mengubah driver cgroup dari Node yang telah bergabung kedalam sebuah Cluster sangat tidak direkomendasikan. Jika kubelet telah membuat Pod menggunakan semantik dari sebuah _driver_ cgroup, mengubah _runtime_ Container ke _driver_ cgroup yang lain dapat mengakibatkan kesalahan pada saat percobaan untuk membuat kembali PodSandbox untuk Pod yang sudah ada. Menjalankan ulang (_restart_) kubelet mungkin tidak menyelesaikan kesalahan tersebut. Rekomendasi yang dianjurkan adalah untuk menguras Node dari beban kerjanya, menghapusnya dari Cluster dan menggabungkannya kembali. Docker ------ Pada setiap mesin kamu, mari menginstall Docker. Versi yang direkomendasikan adalah 19.03.11, tetapi versi 1.13.1, 17.03, 17.06, 17.09, 18.06 dan 18.09 juga diketahui bekerja dengan baik. Jagalah versi Docker pada versi terbaru yang sudah terverifikasi pada catatan rilis Kubernetes. Gunakan perintah berikut untuk menginstal Docker pada sistem kamu: * [Ubuntu 16.04+](https://kubernetes.io/id/docs/setup/production-environment/container-runtimes/#tab-cri-docker-installation-0) * [CentOS/RHEL 7.4+](https://kubernetes.io/id/docs/setup/production-environment/container-runtimes/#tab-cri-docker-installation-1) # (Menginstal Docker CE) ## Mengatur repositori: ### Menginstal packet untuk mengijinkan apt untuk menggunakan repositori melalui HTTPS apt-get update && apt-get install -y \ apt-transport-https ca-certificates curl software-properties-common gnupg2 # Menambahkan key GPG resmi dari Docker: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - # Menambahkan repositori apt dari Docker: add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" # Menginstal Docker CE apt-get update && apt-get install -y \ containerd.io=1.2.13-2 \ docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) # Mengatur daemon Docker cat > /etc/docker/daemon.json < /etc/docker/daemon.json < /etc/sysctl.d/99-kubernetes-cri.conf < /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - # Debian Testing echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - # Debian 10 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - # Raspbian 10 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - dan kemudian install CRI-O: sudo apt-get install cri-o-1.17 # Mengatur repositori paket . /etc/os-release sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - sudo apt-get update # Menginstal CRI-O sudo apt-get install cri-o-1.17 # Menginstal prasyarat curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:1.35.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:1.35/CentOS_7/devel:kubic:libcontainers:stable:cri-o:1.35.repo # Menginstal CRI-O yum install -y cri-o sudo zypper install cri-o ### Memulai CRI-O systemctl daemon-reload systemctl start crio Silahkan merujuk pada [Panduan instalasi CRI-O](https://github.com/kubernetes-sigs/cri-o#getting-started) untuk informasi lanjut. Containerd ---------- Bagian ini berisi langkah-langkah yang diperlukan untuk menggunakan `containerd` sebagai _runtime_ CRI. Gunakan perintah-perintah berikut untuk menginstal containerd pada sistem kamu: ### Prasyarat cat > /etc/modules-load.d/containerd.conf < /etc/sysctl.d/99-kubernetes-cri.conf <`. ### _Fanout_ sederhana Sebuah konfigurasi fanout akan melakukan _route_ trafik dari sebuah alamat IP ke banyak Service, berdasarkan URI HTTP yang diberikan. Sebuah Ingress memungkinkan kamu untuk memiliki jumlah _loadbalancer_ minimum. Contohnya, konfigurasi seperti di bawah ini: foo.bar.com -> 178.91.123.132 -> / foo service1:4200 / bar service2:8080 akan memerlukan konfigurasi Ingress seperti: apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: simple-fanout-example annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: foo.bar.com http: paths: - path: /foo backend: serviceName: service1 servicePort: 4200 - path: /bar backend: serviceName: service2 servicePort: 8080 Ketika kamu membuat Ingress dengan perintah `kubectl apply -f`: kubectl describe ingress simple-fanout-example Name: simple-fanout-example Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo service1:4200 (10.8.0.90:4200) /bar service2:8080 (10.8.0.91:8080) Annotations: nginx.ingress.kubernetes.io/rewrite-target: / Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 22s loadbalancer-controller default/test Kontroler Ingress akan menyediakan _loadbalancer_ (implementasinya tergantung dari jenis Ingress yang digunakan), selama _service-service_ yang didefinisikan (`s1`, `s2`) ada. Apabila _Ingress_ selesai dibuat, maka kamu dapat melihat alamat IP dari berbagai _loadbalancer_ pada kolom `address`. #### Catatan: Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](https://kubernetes.io/id/docs/concepts/services-networking/service/) bergantung pada [kontroler Ingress](https://kubernetes.io/id/docs/concepts/services-networking/ingress-controllers) yang kamu pakai. ### Virtual Host berbasis Nama Virtual Host berbasis Nama memungkinkan mekanisme _routing_ berdasarkan trafik HTTP ke beberapa _host name_ dengan alamat IP yang sama. foo.bar.com --| |-> foo.bar.com s1:80 | 178.91.123.132 | bar.foo.com --| |-> bar.foo.com s2:80 Ingress di bawah ini memberikan perintah pada _loadbalancer_ untuk melakukan mekanisme _routing_ berdasarkan [header host](https://tools.ietf.org/html/rfc7230#section-5.4) . apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: name-virtual-host-ingress spec: rules: - host: foo.bar.com http: paths: - backend: serviceName: service1 servicePort: 80 - host: bar.foo.com http: paths: - backend: serviceName: service2 servicePort: 80 Jika kamu membuat sebuah Ingress tanpa mendefinisikan _host_ apa pun, maka trafik web ke alamat IP dari kontroler Ingress tetap dapat dilakukan tanpa harus menyesuaikan aturan _name based virtual host_. Sebagai contoh, _resource_ Ingress di bawah ini akan melakukan pemetaan trafik dari `first.bar.com` ke `service1`, `second.foo.com` ke `service2`, dan trafik lain ke alamat IP tanpa _host name_ yang didefinisikan di dalam _request_ (yang tidak memiliki _request header_) ke `service3`. apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: name-virtual-host-ingress spec: rules: - host: first.bar.com http: paths: - backend: serviceName: service1 servicePort: 80 - host: second.foo.com http: paths: - backend: serviceName: service2 servicePort: 80 - http: paths: - backend: serviceName: service3 servicePort: 80 ### TLS Kamu dapat mengamankan _Ingress_ yang kamu miliki dengan memberikan spesifikasi [secret](https://kubernetes.io/id/docs/concepts/configuration/secret) yang mengandung _private key_ dan sertifikat TLS. Saat ini, Ingress hanya memiliki fitur untuk melakukan konfigurasi _single TLS port_, yaitu 443, serta melakukan terminasi TLS. Jika _section_ TLS pada Ingress memiliki spesifikasi _host_ yang berbeda, _rules_ yang ada akan dimultiplekskan pada _port_ yang sama berdasarkan _hostname_ yang dispesifikasikan melalui ekstensi TLS SNI. _Secret_ TLS harus memiliki `key` bernama `tls.crt` dan `tls.key` yang mengandung _private key_ dan sertifikat TLS, contohnya: apiVersion: v1 data: tls.crt: base64 encoded cert tls.key: base64 encoded key kind: Secret metadata: name: testsecret-tls namespace: default type: kubernetes.io/tls Ketika kamu menambahkan _secret_ pada Ingress maka kontroler Ingress akan memberikan perintah untuk memproteksi _channel_ dari klien ke _loadbalancer_ menggunakan TLS. Kamu harus memastikan _secret_ TLS yang digunakan memiliki sertifikat yang mengandung CN untuk `sslexample.foo.com`. apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: tls-example-ingress spec: tls: - hosts: - sslexample.foo.com secretName: testsecret-tls rules: - host: sslexample.foo.com http: paths: - path: / backend: serviceName: service1 servicePort: 80 #### Catatan: Terdapat perbedaan di antara beberapa fitur TLS yang disediakan oleh berbagai kontroler Ingress. Perhatikan dokumentasi [nginx](https://git.k8s.io/ingress-nginx/README.md#https) , [GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https) , atau kontroler Ingress spesifik _platform_ lainnya untuk memahami cara kerja TLS pada **environment** yang kamu miliki. ### _Loadbalancing_ Sebuah kontroler Ingress sudah dibekali dengan beberapa _policy_ terkait mekanisme _load balance_ yang nantinya akan diterapkan pada semua Ingress, misalnya saja algoritma _load balancing_, _backend weight scheme_, dan lain sebagainya. Beberapa konsep _load balance_ yang lebih _advance_ (misalnya saja _persistent sessions_, _dynamic weights_) belum diekspos melalui Ingress. Meskipun begitu, kamu masih bisa menggunakan fitur ini melalui [loadbalancer service](https://github.com/kubernetes/ingress-nginx) . Perlu diketahui bahwa meskipun _health check_ tidak diekspos secara langsung melalui Ingress, terdapat beberapa konsep di Kubernetes yang sejalan dengan hal ini, misalnya [readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) yang memungkinkan kamu untuk memperoleh hasil yang sama. Silahkan pelajari lebih lanjut dokumentasi kontroler yang kamu pakai untuk mengetahui bagaimana implementasi _health checks_ pada kontroler yang kamu pilih ([nginx](https://git.k8s.io/ingress-nginx/README.md) , [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks) ). Mengubah Ingress ---------------- Untuk mengubah Ingress yang sudah ada dan menambahkan _host_ baru, kamu dapat mengubahnya dengan mode _edit_: kubectl describe ingress test Name: test Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo s1:80 (10.8.0.90:80) Annotations: nginx.ingress.kubernetes.io/rewrite-target: / Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 35s loadbalancer-controller default/test kubectl edit ingress test Sebuah editor akan muncul dan menampilkan konfigurasi Ingress kamu dalam format YAML apabila kamu telah menjalankan perintah di atas. Ubah untuk menambahkan _host_: spec: rules: - host: foo.bar.com http: paths: - backend: serviceName: s1 servicePort: 80 path: /foo - host: bar.baz.com http: paths: - backend: serviceName: s2 servicePort: 80 path: /foo .. Menyimpan konfigurasi dalam bentuk YAML ini akan mengubah _resource_ pada API server, yang kemudian akan memberi tahu kontroler Ingress untuk mengubah konfigurasi _loadbalancer_. kubectl describe ingress test Name: test Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo s1:80 (10.8.0.90:80) bar.baz.com /foo s2:80 (10.8.0.91:80) Annotations: nginx.ingress.kubernetes.io/rewrite-target: / Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 45s loadbalancer-controller default/test Kamu juga dapat mengubah Ingress dengan menggunakan perintah `kubectl replace -f` pada berkas konfigurasi Ingress yang ingin diubah. Mekanisme _failing_ pada beberapa zona _availability_ ----------------------------------------------------- Teknik untuk menyeimbangkan persebaran trafik pada _failure domain_ berbeda antar penyedia layanan _cloud_. Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](https://kubernetes.io/id/docs/concepts/services-networking/ingress-controllers) untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](https://kubernetes.io/id/docs/concepts/cluster-administration/federation/) untuk informasi lebih detail soal bagaimana melakukan _deploy_ untuk federasi klaster. Pengembangan selanjutnya ------------------------ Silahkan amati [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) untuk detail lebih lanjut mengenai perubahan Ingress dan _resource_ terkait lainnya. Kamu juga bisa melihat [repositori Ingress](https://github.com/kubernetes/ingress/tree/master) untuk informasi yang lebih detail soal perubahan berbagai kontroler. Alternatif lain --------------- Kamu dapat mengekspos sebuah _Service_ dalam berbagai cara, tanpa harus menggunakan _resource_ Ingress, dengan menggunakan: * [Service.Type=LoadBalancer](https://kubernetes.io/id/docs/concepts/services-networking/service/#loadbalancer) * [Service.Type=NodePort](https://kubernetes.io/id/docs/concepts/services-networking/service/#type-nodeport) * [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service) Selanjutnya ----------- * [Melakukan konfigurasi Ingress pada Minikube dengan kontroler NGINX](https://kubernetes.io/docs/tasks/access-application-cluster/ingress-minikube) Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified April 25, 2024 at 1:20 AM PST: [\[id\] Fix link (4ac8a22273)](https://github.com/kubernetes/website/commit/4ac8a222731ccc34342e11f1abbf5e2949f08e5a) --- # ノードのセットアップの検証 | Kubernetes **このページに記載されている情報は古い可能性があります** このページの更新日は英語版よりも古いため、記載されている情報が古い可能性があります。最新の情報をご覧になりたい方は英語版のページをご覧ください: [Validate node setup](https://kubernetes.io/docs/setup/best-practices/node-conformance/) ノードのセットアップの検証 ============= ノード適合テスト -------- _ノード適合テスト_ は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスターに参加する資格があることになります。 ノードの前提条件 -------- 適合テストを実行するにはノードは通常のKubernetesノードと同じ前提条件を満たしている必要があります。 最低でもノードに以下のデーモンがインストールされている必要があります: * コンテナランタイム (Docker) * Kubelet ノード適合テストの実行 ----------- ノード適合テストを実行するには、以下の手順に従います: 1. kubeletの`--kubeconfig`オプションの値を調べます。例:`--kubeconfig=/var/lib/kubelet/config.yaml`。 このテストフレームワークはKubeletのテスト用にローカルコントロールプレーンを起動するため、APIサーバーのURLとして`http://localhost:8080`を使用します。 他にも使用できるkubeletコマンドラインパラメーターがいくつかあります: * `--cloud-provider`: `--cloud-provider=gce`を指定している場合は、テストを実行する前にこのフラグを取り除いてください。 2. 以下のコマンドでノード適合テストを実行します: # $CONFIG_DIRはKubeletのPodのマニフェストパスです。 # $LOG_DIRはテスト出力のパスです。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ registry.k8s.io/node-test:0.2 他アーキテクチャ向けのノード適合テストの実行 ---------------------- Kubernetesは他のアーキテクチャ用のノード適合テストのdockerイメージを提供しています: | Arch | Image | | --- | --- | | amd64 | node-test-amd64 | | arm | node-test-arm | | arm64 | node-test-arm64 | 選択したテストの実行 ---------- 特定のテストを実行するには、環境変数`FOCUS`を実行したいテストの正規表現で上書きします。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e FOCUS=MirrorPod \ # MirrorPodテストのみを実行します registry.k8s.io/node-test:0.2 特定のテストをスキップするには、環境変数`SKIP`をスキップしたいテストの正規表現で上書きします。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e SKIP=MirrorPod \ # MirrorPodテスト以外のすべてのノード適合テストを実行します registry.k8s.io/node-test:0.2 ノード適合テストは、[node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md) のコンテナ化されたバージョンです。 デフォルトでは、すべての適合テストが実行されます。 理論的には、コンテナを構成し必要なボリュームを適切にマウントすれば、どのノードのe2eテストも実行できます。しかし、不適合テストを実行するためにはより複雑な設定が必要となるため、**適合テストのみを実行することを強く推奨します**。 注意事項 ---- * このテストでは、ノード適合テストイメージや機能テストで使用されるコンテナのイメージなど、いくつかのdockerイメージがノード上に残ります。 * このテストでは、ノード上にデッドコンテナが残ります。これらのコンテナは機能テスト中に作成されます。 フィードバック ------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最終更新 March 31, 2023 at 1:44 AM PST: [\[ja\] s/クラスタ/クラスター/g (26a4e5fd41)](https://github.com/kubernetes/website/commit/26a4e5fd41dbf1fcaff21a3943f60f778fe68e99) --- # Сборщик мусора | Kubernetes **Информация этой страницы может быть устаревшей** Оригинальная (английская) версия этого документа обновлялась с момента последнего перевода, поэтому информация может быть устаревшей. Если вы читаете на английском, посмотрите на оригинальную версию с наиболее актуальной информацией: [Garbage Collection](https://kubernetes.io/docs/concepts/architecture/garbage-collection/) Сборщик мусора ============== Сбор мусора — это собирательный термин для различных механизмов, используемых Kubernetes для очистки ресурсов кластера. Это позволить очистить ресурсы, такие как: * [Неудачные pod-ы](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) * [Завершенные задания](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/) * [Объекты без ссылок на владельца Objects](https://kubernetes.io/ru/docs/concepts/architecture/garbage-collection/#owners-dependents) * [Не используемые контейнеры и образы контейнеров](https://kubernetes.io/ru/docs/concepts/architecture/garbage-collection/#containers-images) * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#delete) * [Устаревшие или просроченные запросы подписания сертификатов (CSR)](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) * [Nodes](https://kubernetes.io/ru/docs/concepts/architecture/nodes/ "Узел — рабочая машина в Kubernetes.") удалено в следующих сценариях: * В облаке, когда кластер использует [диспетчер облачных контроллеров](https://kubernetes.io/ru/docs/concepts/architecture/cloud-controller/) * Локально когда кластер использует дополнение, аналогичное диспетчер облачных контроллеров * [Объекты аренды узлов](https://kubernetes.io/ru/docs/concepts/architecture/nodes/#heartbeats) Владельцы и зависимости ----------------------- Многие объекты в Kubernetes ссылаются друг на друга через [_ссылки владельцев_](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) . Ссылки владельцев сообщают управляющему слою, какие объекты зависят от других. Kubernetes использует ссылки владельцев, чтобы предоставить управляющему слою и другим API клиентам, возможность очистить связанные ресурсы перед удалением объекта. В большинстве случаев, Kubernetes автоматически управляет ссылками владельцев. Владелец отличается от [меток и селекторов](https://kubernetes.io/ru/docs/concepts/overview/working-with-objects/labels/) которые также используют некоторые ресурсы. Например, рассмотрим [Службу](https://kubernetes.io/ru/docs/concepts/services-networking/service/ "Способ представления приложения, запущенного в наборе подов, в виде сетевого сервиса.") которая создает объект `EndpointSlice`. Служба использует _метки_ чтобы позволить управляющему слою определить, какие `EndpointSlice` объекты используются для этой службы. В дополнение к меткам, каждый `EndpointSlice` управляет ои имени службы, имеет ссылку владельца. Ссылки владельцев помогают различным частям Kubernetes избегать вмешательства в объекты, которые они не контролируют. #### Примечание: Ссылки на владельцев перекрестных пространств имен запрещены по дизайну. Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен. Владелец пространства имен **должен** быть в том же пространстве имен, что и зависимости. Если это не возможно, ссылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев. Зависимости области действия кластер может указывать только владельцев области действия кластера. В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец, тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора. В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен `ownerReference`, или зависящие от области действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающее о недействительной зависимости. Вы можете проверить наличие такого рода событий, выполнив `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. Каскадное удаление ------------------ Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова _каскадного удаления_. Существует два типа каскадного удаления, а именно: * Каскадное удаление Foreground * Каскадное удаление Background Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes [finalizers](https://kubernetes.io/ru/docs/concepts/overview/working-with-objects/finalizers/ "A namespaced key that tells Kubernetes to wait until specific conditions are met before it fully deletes an object marked for deletion.") . ### Каскадное удаление Foreground В Каскадном удалении Foreground, объект владельца, который вы удаляете, сначала переходить в состояние _в процессе удаления_. В этом состоянии с объектом-владельцем происходить следующее: * Сервер Kubernetes API устанавливает полю объекта `metadata.deletionTimestamp` время, когда объект был помечен для удаления. * Сервер Kubernetes API так же устанавливает метку `metadata.finalizers`для поля `foregroundDeletion`. * Объект остается видимым благодаря Kubernetes API пока процесс удаления не завершиться После того как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле `ownerReference.blockOwnerDeletion=true`. Чтобы узнать больше. Смотрите [Использование каскадного удаления foreground](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) . ### Каскадное удаление Background В каскадном удалении background, сервер Kubernetes API немедленно удаляет владельца объекта, а контроллер очищает зависимые объекты в фоновом режиме. По умолчанию, Kubernetes использует каскадное удаление background, если вы в ручную не используете удаление foreground или не решите отключить зависимые объекты. Чтобы узнать больше. Смотрите [Использование каскадного удаления background](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion) . ### Осиротевшие зависимости Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются _осиротевшими_ объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это поведение смотрите [Удаление объектов владельца и осиротевших зависимостей](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy) . Сбор мусора из неиспользуемых контейнеров и образов --------------------------------------------------- [kubelet](https://kubernetes.io/ru/docs/reference/command-line-tools-reference/kubelet "Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.") выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут нарушить поведение kubelet и удалить контейнеры, которые должны существовать. Чтобы настроить параметры для сборщика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте kubelet использую [конфигурационный файл](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/) и измените параметры, связанные со сборщиком мусора используя тип ресурса [`KubeletConfiguration`](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) . ### Жизненный цикл контейнерных образов Container image lifecycle Kubernetes управляет жизненным циклом всех образов с помощью своего _менеджера образов_, которые являются частью kubelet, в сотрудничестве с cadvisor. При принятии решений о сборке мусора, kubelet учитывает следующие ограничения использования диска: * `HighThresholdPercent` * `LowThresholdPercent` Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. Kubelet удаляет образы до тех пор, пока использование диска не достигнет значения `LowThresholdPercent`. ### Сборщик мусора контейнерных образов Kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: * `MinAge`: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение `0`. * `MaxPerPodContainer`: максимальное количество неактивных контейнеров, которое может быть у каждой пары Pod-ов. Отключить, установив значение меньше чем `0`. * `MaxContainers`: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем `0`. В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого. `MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. Наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры. Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем `MinAge`. #### Примечание: Kubelet собирает мусор только у контейнеров, которыми он управляет. Настройка сборщик мусора ------------------------ Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показано, как настроить сборку мусора: * [Настройка каскадного удаления объектов Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/) * [Настройка очистки завершенных заданий](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/) Что дальше ---------- * Узнайте больше о [ownership of Kubernetes objects](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) . * Узнайте больше о Kubernetes [finalizers](https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/) . * Узнать о [TTL контроллере](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs. Обратная связь -------------- Эта страница была полезна? Да Нет Спасибо за обратную связь! Если у вас есть конкретный вопрос об использовании Kubernetes, спросите на [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Создайте issue в репозитории GitHub, если вы хотите [сообщить о проблеме](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) или [предложить улучшение](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Изменено November 20, 2024 at 4:15 PM PST: [Fix control plane translation in Russian (7e45783196)](https://github.com/kubernetes/website/commit/7e45783196b7ebc0061b12dca9a5b05150c21d20) --- # ওভারভিউ | Kubernetes **এই ডকুমেন্টে তথ্য পুরানো হতে পারে** এই ডকুমেন্টটির আসলটির চেয়ে পুরানো আপডেটের তারিখ রয়েছে, তাই এতে থাকা তথ্য পুরানো হতে পারে৷ আপনি ইংরেজি পড়তে সক্ষম হলে, সবচেয়ে আপ-টু-ডেট তথ্যের জন্য ইংরেজি ভার্সনটি দেখুন: [Overview](https://kubernetes.io/docs/concepts/overview/) ওভারভিউ ======= কুবারনেটিস হল একটি পোর্টেবল, এক্সটেনসিবল, ওপেন সোর্স প্ল্যাটফর্ম যা কন্টেইনারাইজড ওয়ার্কলোড এবং সার্ভিসগুলি পরিচালনা করার জন্য, ঘোষণামূলক কনফিগারেশন এবং অটোমেশন উভয়কেই সহজতর করে। এটির একটি বড়, দ্রুত বর্ধনশীল ইকোসিস্টেম রয়েছে। কুবারনেটিস সার্ভিসগুলি, সাপোর্ট, এবং টুলস ব্যাপকভাবে সহজলভ্য। এই পৃষ্ঠাটি কুবারনেটিসের একটি পরিপূর্ণ ধারণা প্রদান করে । কুবারনেটিস নামটি গ্রীক থেকে এসেছে, যার অর্থ হেলমসম্যান বা পাইলট। "K" এবং "s" এর মধ্যে আটটি অক্ষর গণনা করার ফলে একটি সংক্ষিপ্ত রূপ K8s। গুগল ২০১৪ সালে কুবারনেটিস প্রজেক্টটি ওপেন সোর্স করেছে। কুবারনেটিস [15 বছরেরও বেশি সময় ধরে Google-এর অভিজ্ঞতাকে](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/) একত্রিত করেছে যা কমিউনিটির সেরা আইডিয়া এবং অনুশীলনের সাথে স্কেলে উৎপাদন কাজের চাপ চালানোর। আপনার কেন কুবারনেটিস দরকার এবং এটি কী করতে পারে ----------------------------------------------- কন্টেইনারসমূহ অ্যাপ্লিকেশন একত্রকরণ এবং চালানোর একটি ভালো উপায়৷ একটি উৎপাদন পরিবেশে, কন্টেইনারসমূহ এমন ভাবে পরিচালনা করতে হবে যা অ্যাপ্লিকেশনগুলি চালানোর সময় যেন কোনো ডাউনটাইম না থাকে তা নিশ্চিত করবে। উদাহরণস্বরূপ, যদি একটি কন্টেইনার ডাউন হয়, তাহলে অন্য কন্টেইনার কে সেই মুহূর্তে চালু হতে হবে। আর এই অবস্থাটি একটি সিস্টেম দ্বারা পরিচালিত হলে এটি কি সহজ হবে না? এভাবেই কুবারনেটস উদ্ধারে আসে!। কুবারনেটিস একটি কাঠামো প্রদান করে আপনাকে সিস্টেমগুলিকে স্থিতিস্থাপকভাবে চালানোর জন্য । এটি আপনার অ্যাপ্লিকেশনের জন্য স্কেলিং এবং ফেইলওভারের যত্ন নেয়, ডিপ্লয়মেন্টের নিদর্শন প্রদান করে এবং আরও অনেক কিছু করে। উদাহরণস্বরূপ, কুবারনেটিস সহজেই আপনার সিস্টেমের জন্য একটি ক্যানারি ডিপ্লয়মেন্ট পরিচালনা করতে পারে। কুবারনেটিস আপনাকে সরবরাহ করে: * **পরিষেবা আবিষ্কার এবং লোড ব্যালেন্সিং** কুবারনেটিস ডিএনএস নাম ব্যবহার করে বা তাদের নিজস্ব আইপি ঠিকানা ব্যবহার করে একটি ধারক প্রকাশ করতে পারে। একটি কন্টেইনারে ট্রাফিক বেশি হলে, কুবারনেটিস লোড ব্যালেন্স এবং নেটওয়ার্ক ট্র্যাফিক বিতরণ করতে সক্ষম হয় যাতে ডিপ্লয়মেন্ট স্থিতিশীল থাকে। * **স্টোরেজ অর্কেস্ট্রেশন** কুবারনেটিস আপনাকে স্বয়ংক্রিয়ভাবে আপনার পছন্দের একটি স্টোরেজ সিস্টেম মাউন্ট করার অনুমতি দেয়, যেমন স্থানীয় স্টোরেজ, পাবলিক ক্লাউড প্রদানকারী এবং আরও অনেক কিছু। * **স্বয়ংক্রিয় রোলআউট এবং রোলব্যাক** আপনি কুবারনেটিস ব্যবহার করে আপনার স্থাপন করা কন্টেইনার জন্য পছন্দসই অবস্থা বর্ণনা করতে পারেন এবং এটি একটি নিয়ন্ত্রিত হারে প্রকৃত অবস্থাকে পছন্দসই অবস্থায় পরিবর্তন করতে পারে। উদাহরণস্বরূপ, আপনি কুবারনেটিস দিয়ে স্বয়ংক্রিয়ভাবে আপনার ডিপ্লয়মেন্টের জন্য নতুন কন্টেইনার তৈরি, বিদ্যমান কন্টেইনারগুলি সরাতে এবং নতুন কন্টেইনারে তাদের সমস্ত রিসোর্স গ্রহণ করতে পারেন। * **স্বয়ংক্রিয় বিন প্যাকিং** আপনি কুবারনেটিসকে নোডের একটি ক্লাস্টার প্রদান করেন যা এটি কন্টেইনারাইজড কাজ চালাতে ব্যবহার করতে পারে। আপনি কুবারনেটিসকেে বলুন প্রতিটি কন্টেইনারের কত CPU এবং মেমরি (RAM) প্রয়োজন। কুবারনেটিস আপনার সম্পদের সর্বোত্তম ব্যবহার করতে আপনার নোডগুলিতে কন্টেইনারে মানানসই করতে পারে। * **স্ব-নিরাময়** কুবারনেটিস ব্যর্থ কন্টেইনারগুলি পুনরায় চালু করে, কন্টেইনারগুলিকে প্রতিস্থাপন করে, এমন কন্টেইনারগুলিকে বন্ধ করে যেটি আপনার ব্যবহারকারী-সংজ্ঞায়িত স্বাস্থ্য পরীক্ষায় সাড়া দেয় না এবং ক্লায়েন্টদের কাছে তাদের বিজ্ঞাপন দেবেন না যতক্ষণ না এটি পরিবেশন করার জন্য প্রস্তুত। * **গোপন এবং কনফিগারেশন ব্যবস্থাপনা** কুবারনেটিস আপনাকে সংবেদনশীল তথ্য সংরক্ষণ এবং পরিচালনা করতে দেয়, যেমন পাসওয়ার্ড, ওঅথ (OAuth) টোকেন এবং এসএসএইচ (SSH) কী। আপনি গোপনীয়তা এবং অ্যাপ্লিকেশনের কনফিগারেশন স্থাপন এবং আপডেট করতে পারবেন আপনার কন্টেইনার চিত্রগুলি পুনর্নির্মাণ করা ছাড়াই, এবং আপনার স্ট্যাক কনফিগারেশনের গোপনীয়তা প্রকাশ না করে। * **ব্যাচ এক্সেকিউশন** পরিষেবাগুলি ছাড়াও, কুবারনেটস আপনার ব্যাচ এবং সিআই ওয়ার্কলোডগুলি পরিচালনা করতে পারে, যদি ইচ্ছা হয় তবে ব্যর্থ কন্টেইনারগুলি প্রতিস্থাপন করতে পারে। * **অনুভূমিক স্কেলিং** একটি সাধারণ কমান্ডের সাহায্যে, একটি UI সহ, বা স্বয়ংক্রিয়ভাবে CPU ব্যবহারের উপর ভিত্তি করে আপনার অ্যাপ্লিকেশনকে উপরে এবং নীচে স্কেল করুন। * **IPv4/IPv6 ডুয়াল-স্ট্যাক** পড এবং পরিষেবাগুলিতে IPv4 এবং IPv6 ঠিকানাগুলির বরাদ্দ৷ * **এক্সটেনসিবিলিটির জন্য ডিজাইন** আপস্ট্রিম (upstream) সোর্স কোড পরিবর্তন না করে আপনার কুবারনেটিস ক্লাস্টারে বৈশিষ্ট্য যোগ করুন। কুবারনেটিস কি নয় ---------------- কুবারনেটিস একটি ঐতিহ্যগত, সর্ব-অন্তর্ভুক্ত PaaS (পরিষেবা হিসাবে প্ল্যাটফর্ম) সিস্টেম নয়। যেহেতু Kubernetes হার্ডওয়্যার স্তরের পরিবর্তে কন্টেইনার স্তরে কাজ করে, তাই এটি PaaS অফারগুলির জন্য সাধারণভাবে কিছু প্রযোজ্য বৈশিষ্ট্য প্রদান করে, যেমন ডিপ্লয়মেন্ট, স্কেলিং, লোড ব্যালেন্সিং, এবং ব্যবহারকারীদের তাদের লগিং, পর্যবেক্ষণ এবং সতর্কতা সমাধানগুলিকে একীভূত করতে দেয়৷ যাইহোক, কুবারনেটিস একচেটিয়া নয়, এবং এই ডিফল্ট সমাধান ঐচ্ছিক এবং প্লাগযোগ্য। কুবারনেটিস বিকাশকারী প্ল্যাটফর্ম তৈরির জন্য বিল্ডিং ব্লক সরবরাহ করে, কিন্তু যেখানে এটি গুরুত্বপূর্ণ সেখানে ব্যবহারকারীর পছন্দ এবং নমনীয়তা সংরক্ষণ করে। কুবারনেটিস: * সমর্থিত অ্যাপ্লিকেশনের ধরন সীমাবদ্ধ করে না। কুবারনেটিস একটি লক্ষ্য হল স্টেটলেস, স্টেটফুল এবং ডেটা-প্রসেসিং সহ অত্যন্ত বৈচিত্র্যময় কাজের চাপ কাজের ভার সমর্থন করা। যদি একটি অ্যাপ্লিকেশন একটি কন্টেইনারে চলতে পারে তবে কুবারনেটিসেও দুর্দান্ত চলা উচিত। * সোর্স কোড স্থাপন করে না এবং আপনার অ্যাপ্লিকেশন তৈরি করে না। একটানা ইন্টিগ্রেশন, ডেলিভারি, এবং ডিপ্লোয়মেন্ট (CI/CD) ওয়ার্কফ্লোগুলি প্রতিষ্ঠানের সংস্কৃতি এবং পছন্দের পাশাপাশি প্রযুক্তিগত প্রয়োজনীয়তা দ্বারা নির্ধারিত হয়। * অ্যাপ্লিকেশন-স্তরের পরিষেবা প্রদান করে না, যেমন মিডলওয়্যার (উদাহরণস্বরূপ, বার্তা বাস), ডেটা-প্রসেসিং ফ্রেমওয়ার্ক (উদাহরণস্বরূপ, স্পার্ক), ডাটাবেস (উদাহরণস্বরূপ, মাইএসকিউএল), ক্যাশে, বা বিল্ট-ইন পরিষেবা হিসাবে ক্লাস্টার স্টোরেজ সিস্টেম (উদাহরণস্বরূপ, Ceph)। এই ধরনের উপাদান চলতে পারে কুবারনেটিসে, এবং/অথবা পোর্টেবল মেকানিজমের মাধ্যমে কুবারনেটিস এ চলমান অ্যাপ্লিকেশন দ্বারা অ্যাক্সেস করা যেতে পারে, যেমন [ওপেন সার্ভিস ব্রোকার](https://openservicebrokerapi.org/) । * লগিং, মনিটরিং বা সতর্কতা সমাধান নির্দেশ করে না। এটি ধারণার প্রমাণ হিসাবে কিছু ইন্টিগ্রেশন প্রদান করে, এবং মেট্রিক্স সংগ্রহ এবং রপ্তানি করার প্রক্রিয়া। * এটি কনফিগারেশন ভাষা/সিস্টেম প্রদান বা আদেশ দেয় না (উদাহরণস্বরূপ, Jsonnet)। এটি একটি ঘোষণামূলক এপিআই প্রদান করে যা ঘোষণামূলক স্পেসিফিকেশনের নির্বিচারে ফর্ম দ্বারা লক্ষ্য করা যেতে পারে। * কোন ব্যাপক মেশিন কনফিগারেশন, রক্ষণাবেক্ষণ, ব্যবস্থাপনা প্রদান বা গ্রহণ করে না, বা স্ব-নিরাময় সিস্টেম। * উপরন্তু, কুবারনেটিস একটি নিছক অর্কেস্ট্রেশন সিস্টেম নয়। আসলে, এটি অর্কেস্ট্রেশনের জন্য প্রয়োজনীয়তা দূর করে। অর্কেস্ট্রেশনের প্রযুক্তিগত সংজ্ঞা হল একটি সংজ্ঞায়িত ওয়ার্কফ্লো কার্যকর করা: প্রথমে A, তারপর B, তারপর C করুন। বিপরীতে, কুবারনেটিস স্বাধীন, কম্পোজযোগ্য একটি সেট নিয়ে গঠিত নিয়ন্ত্রণ প্রক্রিয়া যা ক্রমাগত বর্তমান অবস্থাকে প্রদত্ত পছন্দসই অবস্থার দিকে চালিত করে। আপনি A থেকে C পর্যন্ত কিভাবে যাবেন তা বিবেচ্য নয়। কেন্দ্রীভূত নিয়ন্ত্রণেরও প্রয়োজন নেই। এই সিস্টেমের ফলাফল যা ব্যবহার করা সহজ এবং আরও শক্তিশালী, মজবুত, স্থিতিস্থাপক এবং এক্সটেনসিবল। কুবারনেটিসের জন্য ঐতিহাসিক প্রেক্ষাপট ------------------------------------- চলুন অতিতে যেয়ে এক নজরে দেখে নেওয়া যাক কেন কুবারনেটিস এতটা কাজে লাগে। ![ডিপ্লয়মেন্টের বিবর্তন](https://kubernetes.io/images/docs/Container_Evolution.svg) **ঐতিহ্যবাহী ডিপ্লয়মেন্টের যুগ:** প্রথম দিকে, সংস্থাগুলি ফিজিক্যাল সার্ভারগুলিতে অ্যাপ্লিকেশন চালাত। একটি ফিজিক্যাল সার্ভারে অ্যাপ্লিকেশনের জন্য রিসোর্স সীমানা নির্ধারণ করার কোন উপায় ছিল না, এবং এর ফলে রিসোর্স বরাদ্দ সমস্যা হয়েছে। উদাহরণস্বরূপ, যদি একটি ফিজিক্যাল সার্ভারে একাধিক অ্যাপ্লিকেশান চালিত হয়, এমন উদাহরণ হতে পারে যেখানে একটি অ্যাপ্লিকেশন বেশিরভাগ সংস্থান গ্রহণ করবে, এবং ফলস্বরূপ, অন্যান্য অ্যাপ্লিকেশনগুলি কম পারফর্ম করবে। এই জন্য একটি সমাধান একটি ভিন্ন ফিজিক্যাল সার্ভারে প্রতিটি অ্যাপ্লিকেশন চালানো হবে। কিন্তু সম্পদের অব্যবহৃত হওয়ার কারণে এটির মাপকাঠিি ঠিক করা যায়নি এবং অনেকগুলি ফিজিক্যাল সার্ভার বজায় রাখা সংস্থাগুলির জন্য ব্যয়বহুল ছিল। **ভার্চুয়ালাইজড ডিপ্লয়মেন্টর যুগ:** একটি সমাধান হিসাবে, ভার্চুয়ালাইজেশন চালু করা হয়েছিল। এটি আপনাকে একটি একক ফিজিক্যাল সার্ভারের CPU-তে একাধিক ভার্চুয়াল মেশিন (VMs) চালানো যায়। ভার্চুয়ালাইজেশন অ্যাপ্লিকেশনগুলিকে VM-এর মধ্যে বিচ্ছিন্ন করার অনুমতি দেয় এবং একটি স্তরের নিরাপত্তা প্রদান করে কারণ একটি অ্যাপ্লিকেশনের তথ্য অন্য অ্যাপ্লিকেশন দ্বারা অবাধে অ্যাক্সেস করা যায় না। ভার্চুয়ালাইজেশন একটি ফিজিক্যাল সার্ভারে রিসোর্সগুলির আরও ভালো ব্যবহারের অনুমতি দেয় এবং আরও ভাল স্কেলেবিলিটির অনুমতি দেয় কারণ একটি অ্যাপ্লিকেশন সহজে যোগ বা আপডেট করা যায়, হার্ডওয়্যার খরচ কমায় এবং আরও অনেক কিছু। ভার্চুয়ালাইজেশনের মাধ্যমে আপনি ডিসপোজেবল ভার্চুয়াল মেশিনের একটি ক্লাস্টার হিসাবে ফিজিক্যাল সম্পদের একটি সেট উপস্থাপন করতে পারেন। প্রতিটি VM হল একটি সম্পূর্ণ মেশিন যা ভার্চুয়ালাইজড হার্ডওয়্যারের উপরে নিজস্ব অপারেটিং সিস্টেম সহ সমস্ত উপাদান চালায়। **কন্টেইনার স্থাপনের যুগ:** কনটেইনারগুলি VM-এর মতোই, তবে অ্যাপ্লিকেশনগুলির মধ্যে অপারেটিং সিস্টেম (OS) ভাগ করার জন্য তাদের শিথিল বিচ্ছিন্নতা বৈশিষ্ট্য রয়েছে৷ অতএব, কন্টেইনারগুলোকে হালকা বলে মনে করা হয়। একটি VM-এর মতো, একটি কনটেইনারের নিজস্ব ফাইল সিস্টেম, CPU ভাগ, মেমরি, প্রক্রিয়া স্থান এবং আরও অনেক কিছু রয়েছে। যেহেতু এগুলি অন্তর্নিহিত অবকাঠামো থেকে আলাদা করা হয়েছে, তারা ক্লাউড এবং OS ডিস্ট্রিবিউশন জুড়ে বহনযোগ্য। কন্টেইনারগুলো জনপ্রিয় হয়ে উঠেছে কারণ তারা অতিরিক্ত সুবিধা প্রদান করে, যেমন: * এজাইল (Agile) অ্যাপ্লিকেশন তৈরি এবং ডিপ্লয়মেন্টয়: ভিএম ইমেজ (VM Image) ব্যবহারের তুলনায় কন্টেইনার ইমেজ (Container Image) তৈরির সহজতা এবং দক্ষতা বেশি। * ক্রমাগত বিকাশ, একীকরণ এবং ডিপ্লয়মেন্ট: নির্ভরযোগ্য এবং ঘন ঘন কন্টেইনার ইমেজ তৈরি এবং ডিপ্লয়মেন্টের জন্য প্রদান করে দ্রুত এবং দক্ষ রোলব্যাকের (ইমেজ অপরিবর্তনীয়তার কারণে) সাথে । * ডেভ (Dev) এবং অপস (Ops) উদ্বেগের বিচ্ছেদ: বিল্ড/রিলিজের সময়ে অ্যাপ্লিকেশন কন্টেইনার ইমেজ তৈরি করে ডিপ্লয়মেন্টের সময়ের তুলনায়, ফলস্বরূপ অ্যাপ্লিকেশনগুলি অবকাঠামো থেকে বিচ্ছিন্ন হয়। * পর্যবেক্ষণযোগ্যতা: শুধুমাত্র OS-স্তরের তথ্য এবং মেট্রিক্সই নয়, প্রয়োগের স্বাস্থ্য এবং অন্যান্য সংকেতও। * ডেভেলপমেন্ট, টেস্টিং এবং প্রোডাকশন জুড়ে পরিবেশগত সামঞ্জস্য: একটি ল্যাপটপে ক্লাউডের মতোই চলে। * ক্লাউড এবং ওএস ডিস্ট্রিবিউশন পোর্টেবিলিটি: উবুন্টু (Ubuntu), রেল (RHEL), কোরওস (CoreOS), অন-প্রিমিসেস (on-premises), প্রধান পাবলিক ক্লাউডসর উপর, এবং অন্য কোথাও চলে। * অ্যাপ্লিকেশন-কেন্দ্রিক ব্যবস্থাপনা: ভার্চুয়াল হার্ডওয়্যারে একটি OS চালানো থেকে লজিক্যাল রিসোর্স ব্যবহার করে একটি OS-এ একটি অ্যাপ্লিকেশন চালানো পর্যন্ত বিমূর্ততার স্তর বাড়ায়। * ঢিলেঢালাভাবে সংযুক্ত, বিতরণ করা, স্থিতিস্থাপক, মুক্ত মাইক্রো-পরিষেবা: অ্যাপ্লিকেশনগুলিকে ছোট, স্বাধীন টুকরোগুলিতে বিভক্ত করা হয় এবং গতিশীলভাবে স্থাপন ও পরিচালনা করা যায় – একটি বড় একক-উদ্দেশ্য মেশিনে চলমান একটি মনোলিথিক স্ট্যাক নয়।. * রিসোর্স আইসোলেশন: অনুমানযোগ্য অ্যাপ্লিকেশন কর্মক্ষমতা। * রিসোর্স ব্যবহার: উচ্চ দক্ষতা এবং ঘনত্ব। এর পরের কি ---------- * [কুবারনেটিস উপাদান](https://kubernetes.io/bn/docs/concepts/overview/components/) একবার দেখুন * [কুবারনেটিস এপিআই](https://kubernetes.io/bn/docs/concepts/overview/kubernetes-api/) একবার দেখুন * [ক্লাস্টার আর্কিটেকচার](https://kubernetes.io/bn/docs/concepts/architecture/) একবার দেখুন * [শুরু করতে](https://kubernetes.io/bn/docs/setup/) প্রস্তুত আপনি? ফিডব্যাক -------- এই পেজটি কি সহায়ক ছিল? হ্যাঁ না সাহায্য করার জন্য ধন্যবাদ. কুবারনেটিস কীভাবে ব্যবহার করবেন সে সম্পর্কে আপনার যদি একটি নির্দিষ্ট, উত্তরযোগ্য প্রশ্ন থাকে তবে এটি জিজ্ঞাসা করুন [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . আপনি যদি চান তবে [গিটহাব রিপোতে](https://www.github.com/kubernetes/website/) এ একটি ইস্যু খুলুন [একটি সমস্যা রিপোর্ট করুন](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) অথবা [উন্নতির পরামর্শ দিন](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . সর্বশেষ পরিবর্তিত September 11, 2024 at 10:04 PM PST: [Update \_index.md (645d8b7723)](https://github.com/kubernetes/website/commit/645d8b7723a13dc08acc9a0ee3c1842b12cfd6c4) --- # 容器运行时 | Kubernetes 容器运行时 ===== **说明：** 自 1.24 版起，Dockershim 已从 Kubernetes 项目中移除。阅读 [Dockershim 移除的常见问题](https://kubernetes.io/zh-cn/dockershim) 了解更多详情。 你需要在集群内每个节点上安装一个 [容器运行时](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes "容器运行时是负责运行容器的软件。") 以使 Pod 可以运行在上面。本文概述了所涉及的内容并描述了与节点设置相关的任务。 Kubernetes 1.35 要求你使用符合[容器运行时接口](https://kubernetes.io/zh-cn/docs/concepts/architecture/cri "在 kubelet 和本地容器运行时之间通讯的协议") （CRI）的运行时。 有关详细信息，请参阅 [CRI 版本支持](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#cri-versions) 。 本页简要介绍在 Kubernetes 中几个常见的容器运行时的用法。 * [containerd](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#containerd) * [CRI-O](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#cri-o) * [Docker Engine](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#docker) * [Mirantis Container Runtime](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#mcr) #### 说明： v1.24 之前的 Kubernetes 版本直接集成了 Docker Engine 的一个组件，名为 **dockershim**。 这种特殊的直接整合不再是 Kubernetes 的一部分 （这次删除被作为 v1.20 发行版本的一部分[宣布](https://kubernetes.io/zh-cn/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) ）。 你可以阅读[检查 Dockershim 移除是否会影响你](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 以了解此删除可能会如何影响你。 要了解如何使用 dockershim 进行迁移， 请参阅[从 dockershim 迁移](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/) 。 如果你正在运行 v1.35 以外的 Kubernetes 版本，查看对应版本的文档。 安装和配置先决条件 --------- ### 网络配置 默认情况下，Linux 内核不允许 IPv4 数据包在接口之间路由。 大多数 Kubernetes 集群网络实现都会更改此设置（如果需要），但有些人可能希望管理员为他们执行此操作。 （有些人可能还期望设置其他 sysctl 参数、加载内核模块等；请参阅你的特定网络实施的文档。） ### 启用 IPv4 数据包转发 手动启用 IPv4 数据包转发： # 设置所需的 sysctl 参数，参数在重新启动后保持不变 cat < /etc/containerd/config.toml` 重置 containerd 配置，然后相应地设置上述配置参数。 如果你应用此更改，请确保重新启动 containerd： sudo systemctl restart containerd 当使用 kubeadm 时，请手动配置 [kubelet 的 cgroup 驱动](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver) 。 在 Kubernetes v1.28 中，你可以启用 Cgroup 驱动程序的自动检测的 Alpha 级别特性。 详情参阅 [systemd cgroup 驱动](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#systemd-cgroup-driver) 。 #### 重载沙箱（pause）镜像 在你的 [containerd 配置](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) 中， 你可以通过设置以下选项重载沙箱镜像： [plugins."io.containerd.grpc.v1.cri"] sandbox_image = "registry.k8s.io/pause:3.10" 一旦你更新了这个配置文件，可能就同样需要重启 `containerd`：`systemctl restart containerd`。 ### CRI-O 本节包含安装 CRI-O 作为容器运行时的必要步骤。 要安装 CRI-O，请按照 [CRI-O 安装说明](https://github.com/cri-o/packaging/blob/main/README.md#usage) 执行操作。 #### cgroup 驱动 CRI-O 默认使用 systemd cgroup 驱动，这对你来说可能工作得很好。 要切换到 `cgroupfs` cgroup 驱动，请编辑 `/etc/crio/crio.conf` 或在 `/etc/crio/crio.conf.d/02-cgroup-manager.conf` 中放置一个插入式配置，例如： [crio.runtime] conmon_cgroup = "pod" cgroup_manager = "cgroupfs" 你还应该注意当使用 CRI-O 时，并且 CRI-O 的 cgroup 设置为 `cgroupfs` 时，必须将 `conmon_cgroup` 设置为值 `pod`。 通常需要保持 kubelet 的 cgroup 驱动配置（通常通过 kubeadm 完成）和 CRI-O 同步。 在 Kubernetes v1.28 中，你可以启用 Cgroup 驱动程序的自动检测的 Alpha 级别特性。 详情参阅 [systemd cgroup 驱动](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#systemd-cgroup-driver) 。 对于 CRI-O，CRI 套接字默认为 `/var/run/crio/crio.sock`。 #### 重载沙箱（pause）镜像 在你的 [CRI-O 配置](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md) 中， 你可以设置以下配置值： [crio.image] pause_image="registry.k8s.io/pause:3.10" 这一设置选项支持动态配置重加载来应用所做变更：`systemctl reload crio`。 也可以通过向 `crio` 进程发送 `SIGHUP` 信号来实现。 ### Docker Engine #### 说明： 以下操作假设你使用 [`cri-dockerd`](https://mirantis.github.io/cri-dockerd/) 适配器来将 Docker Engine 与 Kubernetes 集成。 1. 在你的每个节点上，遵循[安装 Docker Engine](https://docs.docker.com/engine/install/#server) 指南为你的 Linux 发行版安装 Docker。 2. 请按照文档中的安装部分指示来安装 [`cri-dockerd`](https://mirantis.github.io/cri-dockerd/usage/install) 。 对于 `cri-dockerd`，默认情况下，CRI 套接字是 `/run/cri-dockerd.sock`。 ### Mirantis 容器运行时 [Mirantis Container Runtime](https://docs.mirantis.com/mcr/25.0/overview.html) (MCR) 是一种商用容器运行时，以前称为 Docker 企业版。 你可以使用 MCR 中包含的开源 [`cri-dockerd`](https://mirantis.github.io/cri-dockerd/) 组件将 Mirantis Container Runtime 与 Kubernetes 一起使用。 要了解有关如何安装 Mirantis Container Runtime 的更多信息， 请访问 [MCR 部署指南](https://docs.mirantis.com/mcr/25.0/install.html) 。 检查名为 `cri-docker.socket` 的 systemd 单元以找出 CRI 套接字的路径。 #### 重载沙箱（pause）镜像 `cri-dockerd` 适配器能够接受指定用作 Pod 的基础容器的容器镜像（“pause 镜像”）作为命令行参数。 要使用的命令行参数是 `--pod-infra-container-image`。 接下来 --- 除了容器运行时，你的集群还需要有效的[网络插件](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model) 。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 March 13, 2026 at 10:56 AM PST: [\[zh-cn\] container-runtime is missing network-configuration header (f5835ea4f5)](https://github.com/kubernetes/website/commit/f5835ea4f55a3ea7ef1b03b7626707934d03bf9e) 本页面中的条目引用了第三方产品或项目，这些产品（项目）提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品（项目）负责。请参阅[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) 了解更多细节。 在提交更改建议，向本页添加新的第三方链接之前，你应该先阅读[内容指南。](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) --- # ネットワーキングのリファレンス | Kubernetes ネットワーキングのリファレンス =============== このセクションでは、Kubernetesネットワーキングの詳細を提供します。 * * * ##### [ポートとプロトコル](https://kubernetes.io/ja/docs/reference/networking/ports-and-protocols/) フィードバック ------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最終更新 March 13, 2023 at 11:16 PM PST: [sed s/networking/ネットワーキング/ (d9e2c47bd1)](https://github.com/kubernetes/website/commit/d9e2c47bd167bfe1bb1577b127ffe785eccde875) --- # 콘텐츠 개선 제안하기 | Kubernetes 콘텐츠 개선 제안하기 =========== 쿠버네티스 문서에서 문제를 발견하거나 새로운 콘텐츠에 대한 아이디어가 있다면, 이슈를 열어 제안한다. 필요한 것은 [GitHub 계정](https://github.com/join) 과 웹 브라우저뿐이다. 대부분의 경우, 쿠버네티스 문서에 대한 새로운 작업은 GitHub 이슈에서 시작된다. 쿠버네티스 기여자들은 필요에 따라 이슈를 검토하고 분류하며 태그를 지정한다. 그런 다음 여러분이나 다른 쿠버네티스 커뮤니티 구성원이 이슈를 해결할 변경 사항이 담긴 풀 리퀘스트를 연다. 이슈 열기 ----- 기존 콘텐츠를 개선하고 싶거나 오류를 발견했다면, 이슈를 연다. 1. 오른쪽 사이드바에서 **이슈 생성** 링크를 클릭한다. 그러면 헤더가 미리 채워진 GitHub 이슈 페이지로 이동한다. 2. 문제나 개선 제안을 설명한다. 가능한 한 많은 세부 정보를 제공한다. 3. **Submit new issue** 버튼을 클릭한다. 이슈를 제출한 뒤에는 가끔 확인하거나 GitHub 알림을 켠다. 리뷰어와 다른 커뮤니티 구성원이 이슈에 조치를 취하기 전에 질문을 남길 수 있다. 새로운 콘텐츠 제안 ---------- 새로운 콘텐츠에 대한 아이디어는 있지만 어디에 추가해야 할지 확신이 없다면, 이슈를 열어도 된다. 다음 중 하나를 선택한다. * 콘텐츠가 속한다고 생각되는 섹션의 기존 페이지에서 **이슈 생성** 링크를 클릭한다. * [GitHub](https://github.com/kubernetes/website/issues/new/) 으로 이동해 이슈를 직접 생성한다. 좋은 이슈 작성 방법 ----------- 이슈를 작성할 때 다음 사항을 명심한다. * 명확하게 이슈에 대한 설명을 제공한다. 구체적으로 무엇이 누락되었거나, 오래되었거나, 잘못되었거나, 개선이 필요한 사항인지를 설명한다. * 이 이슈가 사용자에게 미치는 영향을 설명한다. * 주어진 이슈의 범위를 합리적인 작업 단위로 제한한다. 넓은 범위에 대한 이슈의 경우 더 작은 이슈로 분류한다. 예를 들어, "보안 문서 수정"은 너무 광범위하지만, "'네트워크 접근 제한' 주제에 세부 사항 추가"는 실행할 수 있을 정도로 구체적이다. * 기존 이슈를 검색하여 새로운 이슈와 관련이 있거나 비슷한 것이 있는지 확인한다. * 새로운 이슈가 다른 이슈나 풀 리퀘스트와 관련이 있는 경우, 전체 URL이나 `#` 문자로 시작하는 이슈나 풀 리퀘스트 번호로 참고한다. 예를 들면, `Introduced by #987654` 와 같이 작성한다. * [행동 강령](https://kubernetes.io/ko/community/code-of-conduct/) 을 따른다. 동료 기여자를 존중한다. 예를 들어, "문서가 끔찍하다"는 도움이 되지 않거나 예의 바르지 않은 피드백이다. 피드백 --- 이 페이지가 도움이 되었나요? 네 아니요 피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 원한다면 GitHub 리포지터리에 이슈를 열어서 [문제 리포트](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 또는 [개선 제안이 가능합니다.](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 최종 수정 February 13, 2026 at 9:42 PM PST: [Update Korean translation of suggesting improvements doc (#53419) (5d42b92ed4)](https://github.com/kubernetes/website/commit/5d42b92ed4dabceda7805ef58f3b2f60535f766d) --- # Coleta de Lixo | Kubernetes Coleta de Lixo ============== Coleta de lixo (Garbage collection) é um termo coletivo para os vários mecanismos que o Kubernetes usa para limpar os recursos do cluster. Isso permite a limpeza de recursos como os seguintes: * [Pods terminados](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) * [Jobs completados](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/) * [Objetos sem referências de proprietário](https://kubernetes.io/pt-br/docs/concepts/architecture/garbage-collection/#owners-dependents) * [Contêineres e imagens de contêiner não utilizados](https://kubernetes.io/pt-br/docs/concepts/architecture/garbage-collection/#containers-images) * [PersistentVolumes provisionados dinamicamente com uma política de recuperação de StorageClass de Delete](https://kubernetes.io/pt-br/docs/concepts/storage/persistent-volumes/#delete) * [CertificateSigningRequests (CSRs) obsoletos ou expirados](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) * [Nodes](https://kubernetes.io/pt-br/docs/concepts/architecture/nodes/ "Um Nó é uma máquina de trabalho no Kubernetes.") excluídos nos seguintes cenários: * Na nuvem quando o cluster usa um [gerenciador de controlador de nuvem](https://kubernetes.io/pt-br/docs/concepts/architecture/cloud-controller/) * On-premises quando o cluster usa um addon similar a um gerenciador de controlador de nuvem * [Objetos Node Lease](https://kubernetes.io/pt-br/docs/concepts/architecture/nodes/#heartbeats) Proprietários e dependentes --------------------------- Muitos objetos no Kubernetes se vinculam uns aos outros através de [_referências de proprietário_](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) . As referências de proprietário informam à camada de gerenciamento quais objetos são dependentes de outros. O Kubernetes usa referências de proprietário para dar à camada de gerenciamento, e outros clientes da API, a oportunidade de limpar recursos relacionados antes de excluir um objeto. Na maioria dos casos, o Kubernetes gerencia referências de proprietário automaticamente. A propriedade é diferente do mecanismo de [labels e seletores](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) que alguns recursos também usam. Por exemplo, considere um [Service](https://kubernetes.io/pt-br/docs/concepts/services-networking/service/ "Uma forma abstrata de expor uma aplicação que está executando em um conjunto de Pods como um serviço de rede.") que cria objetos `EndpointSlice`. O Service usa _labels_ para permitir que a camada de gerenciamento determine quais objetos `EndpointSlice` são usados para esse Service. Além das labels, cada `EndpointSlice` que é gerenciado em nome de um Service tem uma referência de proprietário. As referências de proprietário ajudam diferentes partes do Kubernetes a evitar interferir com objetos que elas não controlam. #### Nota: Referências de proprietário entre namespaces são proibidas por design. Dependentes com namespace podem especificar proprietários com escopo de cluster ou com namespace. Um proprietário com namespace **deve** existir no mesmo namespace que o dependente. Se não existir, a referência de proprietário é tratada como ausente, e o dependente está sujeito à exclusão uma vez que todos os proprietários são verificados como ausentes. Dependentes com escopo de cluster só podem especificar proprietários com escopo de cluster. Nas versões 1.20 e superiores, se um dependente com escopo de cluster especificar um tipo com namespace como proprietário, ele é tratado como tendo uma referência de proprietário não resolvível, e não pode ser coletado como lixo. Nas versões v1.20 e superiores, se o coletor de lixo detectar uma `ownerReference` inválida entre namespaces, ou um dependente com escopo de cluster com uma `ownerReference` referenciando um tipo com namespace, um Event de aviso com um motivo de `OwnerRefInvalidNamespace` e um `involvedObject` do dependente inválido é reportado. Você pode verificar esse tipo de Event executando `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. Exclusão em cascata ------------------- O Kubernetes verifica e exclui objetos que não têm mais referências de proprietário, como os Pods deixados para trás quando você exclui um ReplicaSet. Quando você exclui um objeto, pode controlar se o Kubernetes exclui os dependentes do objeto automaticamente, em um processo chamado _exclusão em cascata_. Existem dois tipos de exclusão em cascata, como segue: * Exclusão em cascata em primeiro plano * Exclusão em cascata em segundo plano Você também pode controlar como e quando a coleta de lixo exclui recursos que têm referências de proprietário usando [finalizadores](https://kubernetes.io/pt-br/docs/concepts/overview/working-with-objects/finalizers/ "A namespaced key that tells Kubernetes to wait until specific conditions are met before it fully deletes an object marked for deletion.") do Kubernetes. ### Exclusão em cascata em primeiro plano Na exclusão em cascata em primeiro plano, o objeto proprietário que você está excluindo primeiro entra em um estado de _exclusão em progresso_. Neste estado, o seguinte acontece com o objeto proprietário: * O servidor de API do Kubernetes define o campo `metadata.deletionTimestamp` do objeto para o momento em que o objeto foi marcado para exclusão. * O servidor de API do Kubernetes também define o campo `metadata.finalizers` para `foregroundDeletion`. * O objeto permanece visível através da API do Kubernetes até que o processo de exclusão seja concluído. Depois que o objeto proprietário entra no estado de _exclusão em progresso_, o controlador exclui dependentes que conhece. Após excluir todos os objetos dependentes que conhece, o controlador exclui o objeto proprietário. Neste ponto, o objeto não é mais visível na API do Kubernetes. Durante a exclusão em cascata em primeiro plano, os únicos dependentes que bloqueiam a exclusão do proprietário são aqueles que têm o campo `ownerReference.blockOwnerDeletion=true` e estão no cache do controlador de coleta de lixo. O cache do controlador de coleta de lixo pode não conter objetos cujo tipo de recurso não pode ser listado/observado com sucesso, ou objetos que são criados simultaneamente com a exclusão de um objeto proprietário. Veja [Usar exclusão em cascata em primeiro plano](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) para saber mais. ### Exclusão em cascata em segundo plano Na exclusão em cascata em segundo plano, o servidor de API do Kubernetes exclui o objeto proprietário imediatamente e o controlador de coleta de lixo (personalizado ou padrão) limpa os objetos dependentes em segundo plano. Se um finalizador existir, ele garante que os objetos não sejam excluídos até que todas as tarefas de limpeza necessárias sejam concluídas. Por padrão, o Kubernetes usa exclusão em cascata em segundo plano, a menos que você use manualmente a exclusão em primeiro plano ou escolha tornar órfãos os objetos dependentes. Veja [Usar exclusão em cascata em segundo plano](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion) para saber mais. ### Dependentes órfãos Quando o Kubernetes exclui um objeto proprietário, os dependentes deixados para trás são chamados de objetos _órfãos_. Por padrão, o Kubernetes exclui objetos dependentes. Para aprender como sobrescrever este comportamento, veja [Excluir objetos proprietários e tornar órfãos os dependentes](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy) . Coleta de lixo de contêineres e imagens não utilizados ------------------------------------------------------ O [kubelet](https://kubernetes.io/pt-br/docs/reference/command-line-tools-reference/kubelet "Um agente que é executado em cada nó no cluster. Ele garante que os contêineres estejam sendo executados em um Pod.") executa coleta de lixo em imagens não utilizadas a cada cinco minutos e em contêineres não utilizados a cada minuto. Você deve evitar usar ferramentas externas de coleta de lixo, pois estas podem quebrar o comportamento do kubelet e remover contêineres que deveriam existir. Para configurar opções para coleta de lixo de contêineres e imagens não utilizados, ajuste o kubelet usando um [arquivo de configuração](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/) e altere os parâmetros relacionados à coleta de lixo usando o tipo de recurso [`KubeletConfiguration`](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/) . ### Ciclo de vida da imagem de contêiner O Kubernetes gerencia o ciclo de vida de todas as imagens através do seu _gerenciador de imagens_, que é parte do kubelet, com a cooperação do [cadvisor](https://github.com/google/cadvisor/ "Ferramenta que fornece o entendimento do uso de recursos e características de desempenho para contêineres") . O kubelet considera os seguintes limites de uso de disco ao tomar decisões de coleta de lixo: * `HighThresholdPercent` * `LowThresholdPercent` O uso de disco acima do valor `HighThresholdPercent` configurado aciona a coleta de lixo, que exclui imagens em ordem baseada na última vez que foram usadas, começando com a mais antiga primeiro. O kubelet exclui imagens até que o uso de disco atinja o valor `LowThresholdPercent`. #### Coleta de lixo para imagens de contêiner não utilizadas ESTADO DA FUNCIONALIDADE: `Kubernetes v1.35 [stable]`(habilitado por padrão) Como uma funcionalidade beta, você pode especificar o tempo máximo que uma imagem local pode ficar não utilizada, independentemente do uso de disco. Esta é uma configuração do kubelet que você configura para cada node. Para configurar a definição, você precisa definir um valor para o campo `imageMaximumGCAge` no arquivo de configuração do kubelet. O valor é especificado como uma [duração](https://kubernetes.io/pt-br/docs/reference/glossary/?all=true#term-duration "Um valor em forma de string que representa uma quantidade de tempo.") do Kubernetes. Veja [duração](https://kubernetes.io/pt-br/docs/reference/glossary/?all=true#term-duration) no glossário para mais detalhes. Por exemplo, você pode definir o campo de configuração para `12h45m`, o que significa 12 horas e 45 minutos. #### Nota: Esta funcionalidade não rastreia o uso de imagens através de reinicializações do kubelet. Se o kubelet for reinicializado, a idade da imagem rastreada é redefinida, fazendo com que o kubelet espere toda a duração `imageMaximumGCAge` antes de qualificar imagens para coleta de lixo baseada na idade da imagem. ### Coleta de lixo de contêineres O kubelet coleta lixo de contêineres não utilizados baseado nas seguintes variáveis, que você pode definir: * `MinAge`: a idade mínima na qual o kubelet pode coletar lixo de um contêiner. Desabilite definindo como `0`. * `MaxPerPodContainer`: o número máximo de contêineres mortos que cada Pod pode ter. Desabilite definindo como menor que `0`. * `MaxContainers`: o número máximo de contêineres mortos que o cluster pode ter. Desabilite definindo como menor que `0`. Além dessas variáveis, o kubelet coleta lixo de containers não identificados e excluídos, tipicamente começando com o mais antigo primeiro. `MaxPerPodContainer` e `MaxContainers` podem potencialmente entrar em conflito um com o outro em situações onde manter o número máximo de contêineres por Pod (`MaxPerPodContainer`) iria além do total permitido de contêineres mortos globais (`MaxContainers`). Nesta situação, o kubelet ajusta `MaxPerPodContainer` para resolver o conflito. Um cenário de pior caso seria rebaixar `MaxPerPodContainer` para `1` e despejar os containers mais antigos. Adicionalmente, contêineres pertencentes a Pods que foram excluídos são removidos uma vez que são mais antigos que `MinAge`. #### Nota: O coletor de lixo do kubelet só remove contêineres que gerencia. Configurando coleta de lixo --------------------------- Você pode ajustar a coleta de lixo de recursos configurando opções específicas para os controladores que gerenciam esses recursos. As seguintes páginas mostram como configurar coleta de lixo: * [Configurando exclusão em cascata de objetos Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/) * [Configurando limpeza de Jobs finalizados](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/) Próximos passos --------------- * Saiba mais sobre [propriedade de objetos Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) . * Saiba mais sobre [finalizadores](https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/) do Kubernetes. * Saiba sobre o [controlador TTL](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/) que limpa Jobs finalizados. Comentários ----------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Última modificação November 09, 2025 at 2:56 PM PST: [\[pt-br\] Standardize translation for container (be92352bc5)](https://github.com/kubernetes/website/commit/be92352bc57fa89ac003cd8c1cbd7edda9a16729) --- # 存储 | Kubernetes 存储 == 为集群中的 Pods 提供长期和临时存储的方法。 * * * ##### [卷](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/) ##### [持久卷](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/) ##### [投射卷](https://kubernetes.io/zh-cn/docs/concepts/storage/projected-volumes/) ##### [临时卷](https://kubernetes.io/zh-cn/docs/concepts/storage/ephemeral-volumes/) ##### [存储类](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/) ##### [卷属性类](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-attributes-classes/) ##### [动态卷制备](https://kubernetes.io/zh-cn/docs/concepts/storage/dynamic-provisioning/) ##### [卷快照](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-snapshots/) ##### [卷快照类](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-snapshot-classes/) ##### [CSI 卷克隆](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-pvc-datasource/) ##### [存储容量](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-capacity/) ##### [特定于节点的卷数限制](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-limits/) ##### [卷健康监测](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-health-monitoring/) ##### [Windows 存储](https://kubernetes.io/zh-cn/docs/concepts/storage/windows-storage/) 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 June 10, 2022 at 8:25 PM PST: [Switch language name 'zh' to 'zh-cn' (c52818c03d)](https://github.com/kubernetes/website/commit/c52818c03d6bb8d6bf76b09ad20de3a823dc8e0a) --- # 动态卷制备 | Kubernetes 动态卷制备 ===== 动态卷制备允许按需创建存储卷。 如果没有动态制备，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷， 然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/) 来表示这些卷。 动态制备功能消除了集群管理员预先配置存储的需要。相反，它在用户创建 [`PersistentVolumeClaim` 对象](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/) 时自动制备存储。 背景 -- 动态卷制备的实现基于 `storage.k8s.io` API 组中的 `StorageClass` API 对象。 集群管理员可以根据需要定义多个 `StorageClass` 对象，每个对象指定一个**卷插件**（又名 **provisioner**）， 卷插件向卷制备商提供在创建卷时需要的数据卷信息及相关参数。 集群管理员可以在集群中定义和公开多种存储（来自相同或不同的存储系统），每种都具有自定义参数集。 该设计也确保终端用户不必担心存储制备的复杂性和细微差别，但仍然能够从多个存储选项中进行选择。 有关更多详细信息，请参阅[存储类](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/) 概念。 启用动态卷制备 ------- 要启用动态制备功能，集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。 `StorageClass` 对象定义当动态制备被调用时，哪一个驱动将被使用和哪些参数将被传递给驱动。 StorageClass 对象的名字必须是一个合法的 [DNS 子域名](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) 。 以下清单创建了一个 `StorageClass` 存储类 "slow"，它提供类似标准磁盘的永久磁盘。 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: slow provisioner: kubernetes.io/gce-pd parameters: type: pd-standard 以下清单创建了一个 "fast" 存储类，它提供类似 SSD 的永久磁盘。 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast provisioner: kubernetes.io/gce-pd parameters: type: pd-ssd 使用动态卷制备 ------- 用户通过在 `PersistentVolumeClaim` 中包含存储类来请求动态制备的存储。 在 Kubernetes v1.9 之前，这通过 `volume.beta.kubernetes.io/storage-class` 注解实现。 然而，这个注解自 v1.6 起就不被推荐使用了。 用户现在能够而且应该使用 `PersistentVolumeClaim` 对象的 `storageClassName` 字段。 这个字段的值必须能够匹配到集群管理员配置的 `StorageClass` 名称（见[启用动态卷制备](https://kubernetes.io/zh-cn/docs/concepts/storage/dynamic-provisioning/#enabling-dynamic-provisioning) ）。 例如，要选择 “fast” 存储类，用户将创建如下的 PersistentVolumeClaim： apiVersion: v1 kind: PersistentVolumeClaim metadata: name: claim1 spec: accessModes: - ReadWriteOnce storageClassName: fast resources: requests: storage: 30Gi 该声明会自动制备一块类似 SSD 的永久磁盘。 在删除该声明后，这个卷也会被销毁。 设置默认值的行为 -------- 可以在集群上启用动态卷制备，以便在未指定存储类的情况下动态设置所有声明。 集群管理员可以通过以下方式启用此行为： * 标记一个 `StorageClass` 为 **默认**， * 确保 [`DefaultStorageClass` 准入控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) 在 API 服务器端被启用。 管理员可以通过向其添加 [`storageclass.kubernetes.io/is-default-class` 注解](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) 来将特定的 `StorageClass` 标记为默认。 当集群中存在默认的 `StorageClass` 并且用户创建了一个未指定 `storageClassName` 的 `PersistentVolumeClaim` 时， `DefaultStorageClass` 准入控制器会自动向其中添加指向默认存储类的 `storageClassName` 字段。 请注意，如果你在集群的多个 StorageClass 设置 `storageclass.kubernetes.io/is-default-class` 注解为 true， 并之后创建了未指定 `storageClassName` 的 `PersistentVolumeClaim`， Kubernetes 会使用最新创建的默认 StorageClass。 拓扑感知 ---- 在[多可用区](https://kubernetes.io/zh-cn/docs/setup/best-practices/multiple-zones/) 集群中，Pod 可以被分散到某个区域的多个可用区。 单可用区存储后端应该被制备到 Pod 被调度到的可用区。 这可以通过设置[卷绑定模式](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode) 来实现。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 October 31, 2025 at 3:59 PM PST: [\[zh-cn\] Sync dynamic-provisioning.md (4f49680cb3)](https://github.com/kubernetes/website/commit/4f49680cb3bc0e01dad2fabfefc9fa75ad5c88d9) --- # Unknown ```json {"_kubernetes_io":{"feed_refresh_job":"https://testgrid.k8s.io/sig-security-cve-feed#auto-refreshing-official-cve-feed","updated_at":"2026-03-20T12:45:52Z"},"authors":[{"name":"Kubernetes Community","url":"https://www.kubernetes.dev"}],"description":"Auto-refreshing official CVE feed for Kubernetes repository","feed_url":"https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json","home_page_url":"https://kubernetes.io","items":[{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2026-4342","issue_number":137893},"content_text":"CVSS Rating: 8.8 (Medium) [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)\n\nA security issue was discovered in ingress-nginx where a combination of Ingress annotations can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx`.\n\n#### Affected Versions\n\n- ingress-nginx: \u003c v1.13.9\n- ingress-nginx: \u003c v1.14.5\n- ingress-nginx: \u003c v1.15.1\n\n### How do I mitigate this vulnerability?\n\n\n\n#### How to upgrade?\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nSuspicious data within the `rules.http.paths.path` field of an Ingress resource could indicate an attempt to exploit this vulnerability.\n\nIf you find evidence that this vulnerability has been exploited, please contact **security@kubernetes.io**\n\n#### Acknowledgements\n\nThis vulnerability was reported by wooseokdotkim.\n\n/triage accepted\n/lifecycle frozen\n/area security\n/kind bug\n/committee security-response\n\n\u003cdetails\u003e\n\u003csummary\u003eOSV format\u003c/summary\u003e\n\n```json osv\n{\n \"schema_version\": \"1.6.0\",\n \"id\": \"CVE-2026-4342\",\n \"modified\": \"2026-03-19T17:11:29Z\",\n \"summary\": \"ingress-nginx comment-based nginx configuration injection\",\n \"details\": \"A security issue was discovered in ingress-nginx where a combination of Ingress annotations can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\",\n \"severity\": [\n {\n \"type\": \"CVSS_V3\",\n \"score\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"\n }\n ],\n \"affected\": [\n {\n \"package\": {\n \"ecosystem\": \"Kubernetes\",\n \"name\": \"ingress-nginx\"\n },\n \"ranges\": [\n {\n \"type\": \"SEMVER\",\n \"events\": [\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.13.9\"\n },\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.14.5\"\n },\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.15.1\"\n }\n ]\n }\n ]\n }\n ],\n \"references\": [\n {\n \"type\": \"ADVISORY\",\n \"url\": \"https://www.cve.org/cverecord?id=CVE-2026-4342\"\n },\n {\n \"type\": \"ADVISORY\",\n \"url\": \"https://github.com/kubernetes/kubernetes/issues/137893\"\n },\n {\n \"type\": \"WEB\",\n \"url\": \"https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"\n }\n ],\n \"credits\": [\n {\n \"name\": \"This vulnerability was reported by wooseokdotkim.\",\n \"type\": \"FINDER\"\n }\n ]\n}\n```\n\n\u003c/details\u003e\n\n\u003c!-- generated by srctl v1.0.1 (277a81449bef-dirty, 2026-03-02T21:32:55Z, go1.25.6) --\u003e","date_published":"2026-03-19T14:32:54Z","external_url":"https://www.cve.org/cverecord?id=CVE-2026-4342","id":"CVE-2026-4342","status":"fixed","summary":"ingress-nginx comment-based nginx configuration injection","url":"https://github.com/kubernetes/kubernetes/issues/137893"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2026-3864","issue_number":137797},"content_text":"**CVSS Rating:** \n[CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H) — **Medium (6.5)**\n\nA vulnerability was discovered in the Kubernetes CSI Driver for NFS where the subDir parameter in volume identifiers was insufficiently validated. Attackers with the ability to create PersistentVolumes referencing the NFS CSI driver could craft volume identifiers containing path traversal sequences (../). During volume deletion or cleanup operations, the driver could operate on unintended directories outside the intended managed path within the NFS export.\n\nThis may lead to deletion or modification of directories on the NFS server.\n\n### Am I vulnerable?\n\nYou may be vulnerable if:\nYou run the CSI Driver for NFS (nfs.csi.k8s.io)\nYour cluster allows users to create PersistentVolumes referencing the NFS CSI driver\nYour CSI driver version does not validate traversal sequences in the subDir field\n\n\n#### Affected Versions\nAll versions of the CSI Driver for NFS prior to the v4.13.1 release containing the fix for traversal validation are affected.\n\n### How do I mitigate this vulnerability?\n\nThis issue can be mitigated by:\nUpgrading the CSI Driver for NFS to a patched version\nRestricting PersistentVolume creation privileges to trusted administrators\nReviewing NFS exports to ensure only intended directories are writable by the driver\n\nAs a best practice, untrusted users should not be granted permission to create arbitrary PersistentVolumes referencing external storage drivers.\n\n\n#### Fixed Versions\n\nCSI Driver for NFS versions \u003e= v4.13.1\n\n### Detection\n\nTo determine if your cluster may be affected:\nInspect PersistentVolumes using the NFS CSI driver and review the volumeHandle field.\nLook for traversal sequences such as: `../`\nReview CSI controller logs for unexpected directory operations. e.g. “Removing subPath: /tmp/mount-uuid/legitimate/../../../exports/subdir”\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by @Shaul Ben Hai, Senior Staff Security Researcher from SentinelOne.\n\nThe issue was fixed by the CSI Driver for NFS maintainers and the Kubernetes Security Response Committee. \n\nAndy Zhang @andyzhangx\nRita Zhang @ritazh\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n","date_published":"2026-03-17T05:54:49Z","external_url":"https://www.cve.org/cverecord?id=CVE-2026-3864","id":"CVE-2026-3864","status":"fixed","summary":"CSI Driver for NFS path traversal via subDir may delete unintended directories on the NFS server","url":"https://github.com/kubernetes/kubernetes/issues/137797"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-15566","issue_number":136789},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)\n\nA security issue was discovered in ingress-nginx where the nginx.ingress.kubernetes.io/auth-proxy-set-headers Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx`.\n\n#### Affected Versions\n\n- ingress-nginx: \u003c v1.12.5\n- ingress-nginx: \u003c v1.13.1\n\n### How do I mitigate this vulnerability?\n\nACTION REQUIRED: The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.12.5, v1.13.1, or any later version.\n\n#### How to upgrade?\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nSuspicious data within a configmap passed to the `nginx.ingress.kubernetes.io/auth-proxy-set-headers` annotation of an Ingress resource could indicate an attempt to exploit this vulnerability.\n\nIf you find evidence that this vulnerability has been exploited, please contact **security@kubernetes.io**\n\n#### Acknowledgements\n\nThis issue was discovered **and patched** by Jan-Otto Kröpke.\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig network\n\n\u003cdetails\u003e\n\u003csummary\u003eOSV format\u003c/summary\u003e\n\n```json osv\n{\n \"schema_version\": \"1.6.0\",\n \"id\": \"CVE-2025-15566\",\n \"modified\": \"2026-02-06T02:46:50Z\",\n \"summary\": \"ingress-nginx auth-proxy-set-headers nginx configuration injection\",\n \"details\": \"A security issue was discovered in ingress-nginx where the nginx.ingress.kubernetes.io/auth-proxy-set-headers Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\",\n \"severity\": [\n {\n \"type\": \"CVSS_V3\",\n \"score\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"\n }\n ],\n \"affected\": [\n {\n \"package\": {\n \"ecosystem\": \"Kubernetes\",\n \"name\": \"ingress-nginx\"\n },\n \"ranges\": [\n {\n \"type\": \"SEMVER\",\n \"events\": [\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.12.5\"\n },\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.13.1\"\n }\n ]\n }\n ]\n }\n ],\n \"references\": [\n {\n \"type\": \"WEB\",\n \"url\": \"https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"\n }\n ],\n \"credits\": [\n {\n \"name\": \"This issue was discoverd **and patched** by Jan-Otto Kröpke.\",\n \"type\": \"FINDER\"\n }\n ]\n}\n```\n\n\u003c/details\u003e\n\n\u003c!-- generated by srctl v1.0.0 (2665728667a5-dirty, 2026-01-31T19:18:07Z, go1.25.6) --\u003e\n","date_published":"2026-02-06T02:54:24Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-15566","id":"CVE-2025-15566","status":"fixed","summary":"ingress-nginx auth-proxy-set-headers nginx configuration injection","url":"https://github.com/kubernetes/kubernetes/issues/136789"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2026-24514","issue_number":136680},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)\n\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the validating admission controller feature is subject to a denial of service condition. By sending large requests to the validating admission controller, an attacker can cause memory consumption, which may result in the ingress-nginx controller pod being killed or the node running out of memory.\n\n### Am I vulnerable?\n\n* This issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector [app.kubernetes.io/name=ingress-nginx](http://app.kubernetes.io/name=ingress-nginx)\\`.\n\n#### Affected Versions\n\n- ingress-nginx: \u003c 1.13.7\n- ingress-nginx: \u003c 1.14.3\n\n### How do I mitigate this vulnerability?\n\nACTION REQUIRED: The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.13.7, v1.14.3, or any later version.\n\n#### How to upgrade?\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nRequests larger than a few megabytes being sent to the ingress-nginx admission controller may indicate an attempt to exploit this vulnerability.\n\n### Acknowledgements\n\nThis issue was discovered by Matan Shabtay.\nThe issue was fixed and coordinated by Steven Jin, Marco Ebert, and Tabitha Sable\n\nIf you find evidence that this vulnerability has been exploited, please contact **security@kubernetes.io**\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig network\n\n\u003cdetails\u003e\n\u003csummary\u003eOSV format\u003c/summary\u003e\n\n```json osv\n{\n \"schema_version\": \"1.6.0\",\n \"id\": \"CVE-2026-24514\",\n \"modified\": \"2026-02-02T16:00:10Z\",\n \"summary\": \"ingress-nginx Admission Controller denial of service\",\n \"details\": \"A security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the validating admission controller feature is subject to a denial of service condition. By sending large requests to the validating admission controller, an attacker can cause memory consumption, which may result in the ingress-nginx controller pod being killed or the node running out of memory.\",\n \"severity\": [\n {\n \"type\": \"CVSS_V3\",\n \"score\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\"\n }\n ],\n \"affected\": [\n {\n \"package\": {\n \"ecosystem\": \"Kubernetes\",\n \"name\": \"ingress-nginx\"\n },\n \"ranges\": [\n {\n \"type\": \"SEMVER\",\n \"events\": [\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"1.13.7\"\n },\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"1.14.3\"\n }\n ]\n }\n ]\n }\n ],\n \"references\": [\n {\n \"type\": \"WEB\",\n \"url\": \"https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\"\n }\n ]\n}\n```\n\n\u003c/details\u003e\n\n\u003c!-- generated by srctl v1.0.0 (2665728667a5-dirty, 2026-01-31T19:18:07Z, go1.25.6) --\u003e\n","date_published":"2026-02-02T03:06:14Z","external_url":"https://www.cve.org/cverecord?id=CVE-2026-24514","id":"CVE-2026-24514","status":"fixed","summary":"ingress-nginx Admission Controller denial of service","url":"https://github.com/kubernetes/kubernetes/issues/136680"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2026-24513","issue_number":136679},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N)\n\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the protection afforded by the `auth-url` Ingress annotation may not be effective in the presence of a specific misconfiguration.\n\nIf the ingress-nginx controller is configured with a default custom-errors configuration that includes HTTP errors 401 or 403, and if the configured default custom-errors backend is defective and fails to respect the X-Code HTTP header, then an Ingress with the `auth-url` annotation may be accessed even when authentication fails.\n\nNote that the built-in custom-errors backend works correctly. To trigger this issue requires an administrator to specifically configure ingress-nginx with a broken external component.\n\n### Am I vulnerable?\n\n* This issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector [app.kubernetes.io/name=ingress-nginx](http://app.kubernetes.io/name=ingress-nginx)\\`.\n* This issue only affects Ingresses using the `auth-url` annotation. If you are not adding authentication to your Ingresses using the `auth-url` annotation, then you are not at risk.\n* This issue only affects ingress-nginx controllers that have been configured with default custom-errors settings via editing the controller command-line arguments and configuration map. If you are using per-Ingress custom-errors set via Ingress annotations, then you are not at risk.\n\n#### Affected Versions\n\n- ingress-nginx: \u003c 1.13.7\n- ingress-nginx: \u003c 1.14.3\n\n### How do I mitigate this vulnerability?\n\nACTION REQUIRED: The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.13.7, v1.14.3, or any later version.\n\nPrior to upgrading, this vulnerability can be mitigated by checking to confirm your custom errors backend correctly respects the `X-Code` HTTP header.\n\n#### How to upgrade?\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nIf you are able to load a URL protected by the `auth-url` annotation despite failing authentication, then you are affected by this vulnerability.\n\n### Acknowledgements\nThis issue was discovered by Aurelia Schittler.\nThe issue was fixed and coordinated by Tabitha Sable and Marco Ebert.\n\nIf you find evidence that this vulnerability has been exploited, please contact **security@kubernetes.io**\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig network\n\n\u003cdetails\u003e\n\u003csummary\u003eOSV format\u003c/summary\u003e\n\n```json osv\n{\n \"schema_version\": \"1.6.0\",\n \"id\": \"CVE-2026-24513\",\n \"modified\": \"2026-02-02T16:00:06Z\",\n \"summary\": \"ingress-nginx auth-url protection bypass\",\n \"details\": \"A security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the protection afforded by the `auth-url` Ingress annotation may not be effective in the presence of a specific misconfiguration.\\n\\nIf the ingress-nginx controller is configured with a default custom-errors configuration that includes HTTP errors 401 or 403, and if the configured default custom-errors backend is defective and fails to respect the X-Code HTTP header, then an Ingress with the `auth-url` annotation may be accessed even when authentication fails.\\n\\nNote that the built-in custom-errors backend works correctly. To trigger this issue requires an administrator to specifically configure ingress-nginx with a broken external component.\",\n \"severity\": [\n {\n \"type\": \"CVSS_V3\",\n \"score\": \"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N\"\n }\n ],\n \"affected\": [\n {\n \"package\": {\n \"ecosystem\": \"Kubernetes\",\n \"name\": \"ingress-nginx\"\n },\n \"ranges\": [\n {\n \"type\": \"SEMVER\",\n \"events\": [\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"1.13.7\"\n },\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"1.14.3\"\n }\n ]\n }\n ]\n }\n ],\n \"references\": [\n {\n \"type\": \"WEB\",\n \"url\": \"https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N\"\n }\n ]\n}\n```\n\n\u003c/details\u003e\n\n\u003c!-- generated by srctl v1.0.0 (2665728667a5-dirty, 2026-01-31T19:18:07Z, go1.25.6) --\u003e\n","date_published":"2026-02-02T03:06:04Z","external_url":"https://www.cve.org/cverecord?id=CVE-2026-24513","id":"CVE-2026-24513","status":"fixed","summary":"ingress-nginx auth-url protection bypass","url":"https://github.com/kubernetes/kubernetes/issues/136679"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2026-24512","issue_number":136678},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)\n\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the `rules.http.paths.path` Ingress field can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector app.kubernetes.io/name=ingress-nginx\\`.\n\n#### Affected Versions\n\n- ingress-nginx: \u003c v1.13.7\n- ingress-nginx: \u003c v1.14.3\n\n### How do I mitigate this vulnerability?\n\nACTION REQUIRED: The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.13.7, v1.14.3, or any later version.\n\nPrior to upgrading, this vulnerability can be mitigated by using a validating admission controller to reject Ingress resources with the `ImplementationSpecific` path type.\n\n#### How to upgrade?\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nSuspicious data within the rules.http.paths.path field of an Ingress resource could indicate an attempt to exploit this vulnerability.\n\n### Acknowledgements\nThis issue was discovered by Maxime Escourbiac and Yassine Bengana (Michelin CERT).\nThe issue was fixed and coordinated by Steven Jin, Tabitha Sable, and Marco Ebert.\n\nIf you find evidence that this vulnerability has been exploited, please contact **security@kubernetes.io**\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig network\n\n\u003cdetails\u003e\n\u003csummary\u003eOSV format\u003c/summary\u003e\n\n```json osv\n{\n \"schema_version\": \"1.6.0\",\n \"id\": \"CVE-2026-24512\",\n \"modified\": \"2026-02-02T16:00:01Z\",\n \"summary\": \"ingress-nginx rules.http.paths.path nginx configuration injection\",\n \"details\": \"A security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the `rules.http.paths.path` Ingress field can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\",\n \"severity\": [\n {\n \"type\": \"CVSS_V3\",\n \"score\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"\n }\n ],\n \"affected\": [\n {\n \"package\": {\n \"ecosystem\": \"Kubernetes\",\n \"name\": \"ingress-nginx\"\n },\n \"ranges\": [\n {\n \"type\": \"SEMVER\",\n \"events\": [\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.13.7\"\n },\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.14.3\"\n }\n ]\n }\n ]\n }\n ],\n \"references\": [\n {\n \"type\": \"WEB\",\n \"url\": \"https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"\n }\n ]\n}\n```\n\n\u003c/details\u003e\n\n\u003c!-- generated by srctl v1.0.0 (2665728667a5-dirty, 2026-01-31T19:18:07Z, go1.25.6) --\u003e\n","date_published":"2026-02-02T03:05:54Z","external_url":"https://www.cve.org/cverecord?id=CVE-2026-24512","id":"CVE-2026-24512","status":"fixed","summary":"ingress-nginx rules.http.paths.path nginx configuration injection","url":"https://github.com/kubernetes/kubernetes/issues/136678"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2026-1580","issue_number":136677},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)\n\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the `nginx.ingress.kubernetes.io/auth-method` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector app.kubernetes.io/name=ingress-nginx\\`.\n\n#### Affected Versions\n\n- ingress-nginx: \u003c v1.13.7\n- ingress-nginx: \u003c v1.14.3\n\n### How do I mitigate this vulnerability?\n\nACTION REQUIRED: The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.13.7, v1.14.3, or any later version.\n\nPrior to upgrading, this vulnerability can be mitigated by using a validating admission controller to reject Ingress resources with the `nginx.ingress.kubernetes.io/auth-method` annotation.\n\n#### How to upgrade?\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nSuspicious data within the `nginx.ingress.kubernetes.io/auth-method` annotation of an Ingress resource could indicate an attempt to exploit this vulnerability.\n\n### Acknowledgements\nThis issue was discovered by Volcengine Security Team.\nThe issue was fixed and coordinated by Steven Jin, Marco Ebert, and Tabitha Sable.\n\nIf you find evidence that this vulnerability has been exploited, please contact **security@kubernetes.io**\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig network\n\u003cdetails\u003e\n\u003csummary\u003eOSV format\u003c/summary\u003e\n\n```json osv\n{\n \"schema_version\": \"1.6.0\",\n \"id\": \"CVE-2026-1580\",\n \"modified\": \"2026-02-02T15:59:49Z\",\n \"summary\": \"ingress-nginx auth-method nginx configuration injection\",\n \"details\": \"A security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the `nginx.ingress.kubernetes.io/auth-method` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\",\n \"severity\": [\n {\n \"type\": \"CVSS_V3\",\n \"score\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"\n }\n ],\n \"affected\": [\n {\n \"package\": {\n \"ecosystem\": \"Kubernetes\",\n \"name\": \"ingress-nginx\"\n },\n \"ranges\": [\n {\n \"type\": \"SEMVER\",\n \"events\": [\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.13.7\"\n },\n {\n \"introduced\": \"0\"\n },\n {\n \"fixed\": \"v1.14.3\"\n }\n ]\n }\n ]\n }\n ],\n \"references\": [\n {\n \"type\": \"WEB\",\n \"url\": \"https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"\n }\n ]\n}\n```\n\n\u003c/details\u003e\n\n\u003c!-- generated by srctl v1.0.0 (2665728667a5-dirty, 2026-01-31T19:18:07Z, go1.25.6) --\u003e\n","date_published":"2026-02-02T03:05:43Z","external_url":"https://www.cve.org/cverecord?id=CVE-2026-1580","id":"CVE-2026-1580","status":"fixed","summary":"ingress-nginx auth-method nginx configuration injection","url":"https://github.com/kubernetes/kubernetes/issues/136677"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-14269","issue_number":135798},"content_text":"Original tracking issue: https://github.com/kubernetes-sigs/headlamp/issues/4282\n\nCVSS Rating: High (8.8) [CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)\n\n_Description of vulnerability_\n\nA security issue was discovered in the in-cluster version of Headlamp where unauthenticated users may be able to reuse cached credentials to access Helm functionality through the Headlamp UI. Kubernetes clusters are only affected if Headlamp is installed, is configured with config.enableHelm: true, and an authorized user has previously accessed the Helm functionality.\n\n### Am I vulnerable?\n\nKubernetes clusters with an in-cluster installation of Headlamp \u003c= v0.38.0 and config.enableHelm set to true are affected. The Headlamp desktop version is not affected.\n\n#### Affected Versions\n\n- Headlamp \u003c= v0.38.0\n\n### How do I mitigate this vulnerability?\n\nUpgrade to the fixed version. Prior to upgrading, this vulnerability can be mitigated by ensuring Headlamp is not publicly exposed with an ingress server to limit exposure.\n\n\n#### Fixed Versions\n\n- Headlamp v0.39.0 https://github.com/kubernetes-sigs/headlamp/releases/tag/v0.39.0 \n\nTo upgrade, refer to the documentation: https://headlamp.dev/docs/latest/ \n\n### Detection\n\nReview logs for unexpected access to clusters/main/helm/releases/list and other Helm related endpoints.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by [brndstrp](https://hackerone.com/brndstrp).\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n\n","date_published":"2025-12-17T19:23:10Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-14269","id":"CVE-2025-14269","status":"fixed","summary":"Credential caching in Headlamp with Helm enabled","url":"https://github.com/kubernetes/kubernetes/issues/135798"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-13281","issue_number":135525},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N) - Medium (5.8)\n\nA half-blind Server Side Request Forgery (SSRF) vulnerability exists in kube-controller-manager when using the in-tree Portworx StorageClass. This was patched for other in-tree StorageClasses (GlusterFS, Quobyte, StorageOS, and ScaleIO) as part of[ CVE-2020-8555](https://github.com/kubernetes/kubernetes/issues/91542). This vulnerability allows authorized users to leak arbitrary information from unprotected endpoints in the control plane’s host network (including link-local or loopback services). \n\nAn attacker with permissions to create a pod using the built-in Portworx StorageClass can cause kube-controller-manager to make GET requests (without an attacker controlled request body) from within the control plane’s host network and make the corresponding HTTP response body visible as part of event objects created by kube-controller-manager.\n\nThe in-tree Portworx StorageClass has been disabled by default starting in version v1.31 from the CSIMigrationPortworx feature gate. As a result, currently supported versions greater than or equal to v1.32 are not impacted unless the CSIMigrationPortworx feature gate is disabled with an override.\n\n### Am I vulnerable?\n\nYou may be vulnerable if all of the following are true:\n- You are running a vulnerable version and have manually disabled the CSIMigrationPortworx feature gate.\n- There are unprotected endpoints normally only visible from the control plane’s host network (including link-local metadata endpoints, unauthenticated services listening on localhost, or other services in the control plane’s private network).\n- Untrusted users can create pods with the affected Portworx volume type.\n\n#### Affected Versions\n\nThe CSIMigrationPortworx feature gate was enabled by default starting on version v1.31. As a result, EOL versions \u003c= v1.30 are more likely to be vulnerable because the CSIMigrationPortworx feature is disabled by default.\n- kube-controller-manager: \u003c= v1.30.14\n- kube-controller-manager: \u003c= v1.31.14 \n- kube-controller-manager: \u003c= v1.32.9 \n- kube-controller-manager: \u003c= v1.33.5 \n- kube-controller-manager: \u003c= v1.34.1 \n\n\n### How do I mitigate this vulnerability?\n\nThis issue can be mitigated by upgrading to a fixed kube-controller-manager version or by enabling the CSIMigrationPortworx feature gate (if it was overridden from its default value in versions greater than equal to v1.31).\n\n#### Fixed Versions\n- kube-controller-manager: \u003e= v1.32.10\n- kube-controller-manager: \u003e= v1.33.6\n- kube-controller-manager: \u003e= v1.34.2\n\n### Detection\n\nThis issue can be detected on clusters which have the CSIMigrationPortworx feature gate disabled on impacted versions by analyzing ProvisioningFailed events from kube-controller-manager which may contain sensitive information from the control plane’s host network.\n\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\n\n#### Acknowledgements\nThis vulnerability was reported by:\n- Xingyu Liu (xingyu@stu.xidian.edu.cn)\n- Jinku Li (jkli@xidian.edu.cn)\n\nThe issue was fixed and coordinated by:\n- Ankit Gohil @gohilankit","date_published":"2025-11-30T23:08:37Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-13281","id":"CVE-2025-13281","status":"fixed","summary":"Portworx Half-Blind SSRF in kube-controller-manager","url":"https://github.com/kubernetes/kubernetes/issues/135525"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-9708","issue_number":134063},"content_text":"**CVSS Rating:** \n[CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) — **Medium (6.8)**\n\n\nA vulnerability exists in the Kubernetes C# client where the certificate validation logic accepts properly constructed certificates from any Certificate Authority (CA) without properly verifying the trust chain. This flaw allows a malicious actor to present a forged certificate and potentially intercept or manipulate communication with the Kubernetes API server, leading to possible man-in-the-middle attacks and API impersonation.\n\n### Am I vulnerable?\n\nYou are vulnerable if:\n- You use the Kubernetes C# client to connect to a Kubernetes API server over TLS/HTTPS with custom CA certificates in your kubeconfig file and your connection occurs over an untrusted network.\n\n#### Affected Versions\n- All versions of the Kubernetes C# client prior to the next release \u003c=17.0.13\n\n### How do I mitigate this vulnerability?\n\nThis issue can be mitigated by:\n- Deploy the patch version of the Kubernetes C# client as soon as possible.\n- Moving the CA certificates into the system trust store instead of specifying them in the kubeconfig file. Note: This approach may introduce new risks, as all processes on the system will begin to trust certificates signed by that CA. If you must use an affected version, you can disable custom CA and add the CA to the machine's trusted root.\n\n\n#### Fixed Versions\n\n- Kubernetes C# client \u003e= v17.0.14\n\n### Detection\n\nTo determine if your applications are affected:\n- Review your usage of the Kubernetes C# client and inspect certificate validation logic.\n- Review your kubeconfig files and determine if you use a custom CA certificate (the certificate-authority field in the clusters section).\n- Review client logs for unexpected or untrusted certificate connections.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by @elliott-beach\n\nThe issue was fixed and coordinated by: \n\nBoshi Lian @tg123\nBrendan Burns @brendandburns\nRita Zhang @ritazh\n","date_published":"2025-09-15T04:59:12Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-9708","id":"CVE-2025-9708","status":"fixed","summary":"Kubernetes C# Client: improper certificate validation in custom CA mode may lead to man-in-the-middle attacks","url":"https://github.com/kubernetes/kubernetes/issues/134063"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-7445","issue_number":133897},"content_text":"A security issue was discovered in [secrets-store-sync-controller](https://github.com/kubernetes-sigs/secrets-store-sync-controller) where an actor with access to the controller logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when there is a specific error marshaling the `parameters` sent to the providers.\n\nThis issue has been rated MEDIUM [CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) (6.5), and assigned CVE-2025-7445\n\n### Am I vulnerable?\n\nTo check if tokens are being logged, examine the manager container log:\n\n```bash\nkubectl logs -l 'app.kubernetes.io/part-of=secrets-store-sync-controller' -c manager -f | grep --line-buffered \"csi.storage.k8s.io/serviceAccount.tokens\"\n```\n\n### Affected Versions\n\n- secrets-store-sync-controller \u003c v0.0.2\n\n### How do I mitigate this vulnerability?\n\nUpgrade to secrets-store-sync-controller v0.0.2+\n\n### Fixed Versions\n\n- secrets-store-sync-controller \u003e= v0.0.2\n\n\n### Detection\n\nExamine cloud provider logs for unexpected token exchanges, as well as unexpected access to cloud vault secrets.\n\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](https://groups.google.com/)\n\n### Acknowledgements\n\nThis vulnerability was reported by Reem Rotenberg and [Kas Dekel](https://github.com/privmickas) from Microsoft.\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig auth\n\n/triage accepted","date_published":"2025-09-04T21:40:42Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-7445","id":"CVE-2025-7445","status":"fixed","summary":"secrets-store-sync-controller discloses service account tokens in logs","url":"https://github.com/kubernetes/kubernetes/issues/133897"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-5187","issue_number":133471},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L) - Medium (6.7)\n\nA vulnerability exists in the NodeRestriction admission controller where node users can delete their corresponding node object by patching themselves with an OwnerReference to a cluster-scoped resource. If the OwnerReference resource does not exist or is subsequently deleted, the given node object will be deleted via garbage collection. By default, node users are authorized for create and patch requests but not delete requests against their node object. Since the NodeRestriction admission controller does not prevent patching OwnerReferences, a compromised node could leverage this vulnerability to delete and then recreate its node object. This would permit the node object to be recreated with modified taints or labels which are normally rejected by this plugin. Modifying taints or labels on a node could allow an attacker to control which pods are running on the compromised node.\n\n### Am I vulnerable?\n\nAll clusters that have enabled the NodeRestriction but not the OwnerReferencesPermissionEnforcement admission controller are vulnerable. The OwnerReferencesPermissionEnforcement controller protects access to the OwnerReferences of an object so that only users with delete permission to the object can change it.\n\n#### Affected Versions\nkube-apiserver: \u003c= v1.31.11\nkube-apiserver: \u003c= v1.32.7\nkube-apiserver: \u003c= v1.33.3\n### How do I mitigate this vulnerability?\n\nThis issue can be mitigated by upgrading to a kube-apiserver binary running one of patched minor versions for 1.31 through 1.33 listed below. These fixed versions have added functionality to the NodeRestriction admission controller to prevent node users from modifying their own OwnerReferences. \n\nAlternatively, this vulnerability can be mitigated by enabling the OwnerReferencesPermissionEnforcement admission controller, which will prevent any user without delete permissions on an object from modifying the OwnerReferences on that object. Note that this admission controller will apply to all users and object types.\n\n#### Fixed Versions\nkube-apiserver: \u003e= v1.31.12\nkube-apiserver: \u003e= v1.32.8\nkube-apiserver: \u003e= v1.33.4\n\n### Detection\n\nThis issue can be detected on clusters which have NodeRestriction but not OwnerReferencesPermissionEnforcement enabled by analyzing API audit logs for node patch requests issued by node users which modify OwnerReferences. In normal operation, a Kubelet will never issue a patch request which modifies its own OwnerReferences.\n\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\n\n#### Acknowledgements\n\nThis vulnerability was reported by Paul Viossat.\n\nThe issue was fixed and coordinated by: \n\nSergey Kanzhelev @SergeyKanzhelev\nJordan Liggitt @liggitt\nMarko Mudrinić @xmudrii","date_published":"2025-08-11T16:29:36Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-5187","id":"CVE-2025-5187","status":"fixed","summary":"Nodes can delete themselves by adding an OwnerReference","url":"https://github.com/kubernetes/kubernetes/issues/133471"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-7342","issue_number":133115},"content_text":"CVSS Rating High 7.5: [CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H)\n\nA security issue was discovered in the Kubernetes Image Builder where default credentials are enabled during the Windows image build process when using the Nutanix or VMware OVA providers. These credentials, which allow root access, are disabled at the conclusion of the build. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project and the vulnerability was exploited during the build process, which requires an attacker to access the build VM and modify the image while the build is in progress.\n\n### Am I vulnerable?\n\nClusters using virtual machine Windows images built with Kubernetes Image Builder (https://github.com/kubernetes-sigs/image-builder) version v0.1.44 or earlier are affected if built with the Nutanix or OVA provider.\n\nVMs using images built with all other providers are not affected by this issue.\n\nTo determine the version of Image Builder you are using, use one of the following methods:\n- For git clones of the image builder repository:\n```\n cd \u003clocal path to image builder repo\u003e\n make version\n```\n- For installations using a tarball download:\n```\n cd \u003clocal path to install location\u003e\n grep -o v0\\\\.[0-9.]* RELEASE.md | head -1\n```\n- For a container image release:\n `docker run --rm \u003cimage pull spec\u003e version`\n or\n `podman run --rm \u003cimage pull spec\u003e version`\n or look at the image tag specified, in the case of an official image such as `registry.k8s.io/scl-image-builder/cluster-node-image-builder-amd64:v0.1.44`\n\n\n#### Affected Versions\n\n- Kubernetes Image Builder versions \u003c= v0.1.44\n\n### How do I mitigate this vulnerability?\nRebuild any affected images using a fixed version of Image Builder. Fixed in Kubernetes Image Builder release v0.1.45\nRe-deploy the fixed images to any affected VMs or use image-builder v0.1.41 (February 2025) or later, and set the `admin_password` JSON variable.\nPrior to upgrading, this vulnerability can be mitigated by changing the password of the Administrator account on affected VMs:\n`net user Administrator \u003cnew-password\u003e`\n\n#### Fixed Versions\n\nFixed in Kubernetes Image Builder release v0.1.45 https://github.com/kubernetes-sigs/image-builder/pull/1800\n\n\n### Detection\n\n`Get-LocalUser -Name Administrator | Select-Object Name,Enabled,SID,Lastlogon | Format-List`\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n## Additional Details\n\nThe fixed version requires users to specify a password in the WINDOWS_ADMIN_PASSWORD environment variable or in the `admin_password` JSON variable. If both are empty, then the image builder would not build the image and return an error.\n\n#### Acknowledgements\n\nThis vulnerability was reported by Abdel Adim Oisfi, Davide Silvetti, Nicolò Daprelà, Paolo Cavaglià, Pietro Tirenna from Shielder.\n\nThe issue was fixed and coordinated by Matt Boersma of the Image Builder project.\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig cluster-lifecycle\n","date_published":"2025-07-21T23:22:19Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-7342","id":"CVE-2025-7342","status":"fixed","summary":"VM images built with Kubernetes Image Builder Nutanix or OVA providers use default credentials for Windows images if user did not override","url":"https://github.com/kubernetes/kubernetes/issues/133115"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-4563","issue_number":132151},"content_text":"CVSS Rating:\n[CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L) - **Low** (2.7)\n\nA vulnerability exists in the NodeRestriction admission controller where nodes can bypass dynamic resource allocation authorization checks. When the DynamicResourceAllocation feature gate is enabled, the controller properly validates resource claim statuses during pod status updates but fails to perform equivalent validation during pod creation. This allows a compromised node to create mirror pods that access unauthorized dynamic resources, potentially leading to privilege escalation. In practice, sanity checks in the kubelet prevent starting those mirror pods after they have been created. Even if they were started, an attacker probably already has gained full access to the node and with most dynamic resources won’t be able to gain additional privileges.\n\n### Am I vulnerable?\n\nAll clusters that are using the DynamicResourceAllocation feature (disabled by default) and static pods together may be vulnerable.\n\n#### Affected Versions\n\nkube-apiserver: v1.32.0 - v1.32.5\nkube-apiserver: v1.33.0 - 1.33.1\n\n### How do I mitigate this vulnerability?\n\nThis issue can be mitigated by:\nIf you're not actively using the DynamicResourceAllocation features, the safest and simplest action is to turn off the feature on the API server.\n\n\n#### Fixed Versions\n\nkube-apiserver \u003e= v1.32.6 \nkube-apiserver \u003e= v1.33.2\n\n### Detection\n\nAll clusters that are using the DynamicResourceAllocation feature and static pods may be vulnerable. Run the following command to see if the feature is in use:\n\n`kubectl get ResourceClaim --all-namespaces`\n\nand \n\n`kubectl get pods --all-namespaces -o json | jq -r '\n .items[] \n | select(.metadata.annotations[\"kubernetes.io/config.mirror\"] == \"true\") \n | \"\\(.metadata.namespace)/\\(.metadata.name)\"'`\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by Amit Schendel @amitschendel ARMO\n\nThe issue was fixed and coordinated by: \n\nPatrick Ohly @pohly\nJordan Liggitt @liggitt\nBalaji @SaranBalaji90\nRita Zhang @ritazh\nMarko Mudrinić @xmudrii\n\n\n/triage accepted\n/lifecycle frozen","date_published":"2025-06-06T15:48:26Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-4563","id":"CVE-2025-4563","status":"fixed","summary":"Nodes can bypass dynamic resource allocation authorization checks","url":"https://github.com/kubernetes/kubernetes/issues/132151"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-1974","issue_number":131009},"content_text":"CVSS Rating: ([CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)) (Score: 9.8, Critical)\n\nA security issue was discovered in Kubernetes where under certain conditions, an unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector app.kubernetes.io/name=ingress-nginx\\`.\n\n#### Affected Versions\n\n- \u003c v1.11.0\n- v1.11.0 \\- 1.11.4 \n- v1.12.0\n\n### How do I mitigate this vulnerability?\n\n**ACTION REQUIRED:** The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.11.5, v1.12.1, or any later version.\n\nBefore applying the patch, this issue can be mitigated by disabling the Validating Admission Controller functionality of ingress-nginx.\n\n#### Fixed Versions\n\n- ingress-nginx [main@0ccf4ca](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/0ccf4caaadec919680c455d221e53d97970d527d)\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nThere are no known indicators of compromise that prove this vulnerability has been exploited.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by Nir Ohfeld, Ronen Shustin, Sagi Tzadik, and Hillai Ben Sasson from Wiz\n\nThe issue was fixed and coordinated by Marco Ebert, James Strong, Tabitha Sable, and the Kubernetes Security Response Committee\n","date_published":"2025-03-23T17:38:57Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-1974","id":"CVE-2025-1974","status":"fixed","summary":"ingress-nginx admission controller RCE escalation","url":"https://github.com/kubernetes/kubernetes/issues/131009"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-1098","issue_number":131008},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) (Score: 8.8, High)\n\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the \\`mirror-target\\` and \\`mirror-host\\` Ingress annotations can be used to inject arbitrary configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector app.kubernetes.io/name=ingress-nginx\\`.\n\n#### Affected Versions\n\n- \u003c v1.11.0\n- v1.11.0 \\- 1.11.4 \n- v1.12.0\n\n### How do I mitigate this vulnerability?\n\n**ACTION REQUIRED:** The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.11.5, v1.12.1, or any later version.\n\n#### Fixed Versions\n\n- ingress-nginx [main@2e9f373](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/2e9f37380afb7853fa6daa1c3e6659550aadfd90)\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nSuspicious data within the \\`mirror-target\\` or \\`mirror-host\\` annotations of an Ingress resource could indicate an attempt to exploit this vulnerability.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by Nir Ohfeld, Ronen Shustin, Sagi Tzadik and Hillai Ben Sasson from Wiz\n\nThe issue was fixed and coordinated by Marco Ebert, James Strong, Tabitha Sable, and the Kubernetes Security Response Committee\n","date_published":"2025-03-23T17:38:53Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-1098","id":"CVE-2025-1098","status":"fixed","summary":"ingress-nginx controller configuration injection via unsanitized mirror annotations","url":"https://github.com/kubernetes/kubernetes/issues/131008"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-1097","issue_number":131007},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) (Score: 8.8, High)\n\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the \\`auth-tls-match-cn\\` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector app.kubernetes.io/name=ingress-nginx\\`.\n\n#### Affected Versions\n\n- \u003c v1.11.0\n- v1.11.0 \\- 1.11.4 \n- v1.12.0\n\n### How do I mitigate this vulnerability?\n\n**ACTION REQUIRED:** The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.11.5, v1.12.1, or any later version.\n\n#### Fixed Versions\n\n- ingress-nginx [main@06c992a](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/06c992abd8eef9710359a236c443c613d29fdfad)\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nSuspicious data within the \\`auth-tls-match-cn\\` annotation of an Ingress resource could indicate an attempt to exploit this vulnerability.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by Nir Ohfeld, Ronen Shustin, Sagi Tzadik and Hillai Ben Sasson from Wiz\n\nThe issue was fixed and coordinated by Marco Ebert, James Strong, Tabitha Sable, and the Kubernetes Security Response Committee\n","date_published":"2025-03-23T17:38:49Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-1097","id":"CVE-2025-1097","status":"fixed","summary":"ingress-nginx controller configuration injection via unsanitized auth-tls-match-cn annotation","url":"https://github.com/kubernetes/kubernetes/issues/131007"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-24514","issue_number":131006},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) (Score: 8.8, High)\n\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the \\`auth-url\\` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)\n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector app.kubernetes.io/name=ingress-nginx\\`.\n\nThis issue does not affect you if you have the \\`enable-annotation-validation\\` CLI argument enabled. (This option is enabled by default starting from ingress-nginx v1.12.0.)\n\n#### Affected Versions\n\n- \u003c v1.11.0\n- v1.11.0 \\- 1.11.4 \n- v1.12.0\n\n### How do I mitigate this vulnerability?\n\n**ACTION REQUIRED:** The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.11.5, v1.12.1, or any later version.\n\nPrior to upgrading, this vulnerability can be mitigated by setting the \\`enable-annotation-validation\\` CLI argument to “true”.\n\n#### Fixed Versions\n\n- ingress-nginx [main@ab470eb](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/ab470eb920924d62a197ebddd8a4cc3031a77ddf)\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nSuspicious data within the \\`auth-url\\` annotation of an Ingress resource could indicate an attempt to exploit this vulnerability.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by Nir Ohfeld, Ronen Shustin and Sagi Tzadik from Wiz\n\nThe issue was fixed and coordinated by Marco Ebert, James Strong, Tabitha Sable, and the Kubernetes Security Response Committee\n","date_published":"2025-03-23T17:38:44Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-24514","id":"CVE-2025-24514","status":"fixed","summary":"ingress-nginx controller configuration injection via unsanitized auth-url annotation","url":"https://github.com/kubernetes/kubernetes/issues/131006"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-24513","issue_number":131005},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L)) (Score: 4.8, Medium)\n\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where attacker-provided data are included in a filename by the ingress-nginx Admission Controller feature, resulting in directory traversal within the container. This could result in denial of service, or when combined with other vulnerabilities, limited disclosure of Secret objects from the cluster. \n\n### Am I vulnerable?\n\nThis issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running \\`kubectl get pods \\--all-namespaces \\--selector app.kubernetes.io/name=ingress-nginx\\`.\n\n#### Affected Versions\n\n- \u003c v1.11.0\n- v1.11.0 \\- 1.11.4 \n- v1.12.0\n\n### How do I mitigate this vulnerability?\n\n**ACTION REQUIRED:** The following steps must be taken to mitigate this vulnerability: Upgrade ingress-nginx to v1.11.5, v1.12.1, or any later version.\n\nBefore applying the patch, this issue can be mitigated by disabling the Validating Admission Controller functionality of ingress-nginx. \n\n#### Fixed Versions\n\n- ingress-nginx [main@cbc1590](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/cbc159094f6d1b1bf8cf1761eb119138d1f95df1)\n\nTo upgrade, refer to the documentation: [Upgrading Ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\n\n### Detection\n\nThere are no known indicators of compromise that prove this vulnerability has been exploited.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by Nir Ohfeld and Ronen Shustin from Wiz\n\nThe issue was fixed and coordinated by Marco Ebert, James Strong, Tabitha Sable, and the Kubernetes Security Response Committee","date_published":"2025-03-23T17:38:28Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-24513","id":"CVE-2025-24513","status":"fixed","summary":"ingress-nginx controller auth secret file path traversal vulnerability","url":"https://github.com/kubernetes/kubernetes/issues/131005"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-1767","issue_number":130786},"content_text":"**Issue Details**\nA security vulnerability was discovered in Kubernetes that could allow a user with create pod permission to exploit gitRepo volumes to access local git repositories belonging to other pods on the same node.\nThis issue has been rated Medium ([CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N)) (score: 6.5), and assigned CVE-2025-1767.\n\n**Am I vulnerable?**\n\nThis CVE only affects Kubernetes clusters that utilize the in-tree gitRepo volume to clone git repositories from other pods within the same node. Since the in-tree gitRepo volume feature has been deprecated and will not receive security updates upstream, any cluster still using this feature remains vulnerable. \nAffected Components\nkubelet\n\n**Affected Versions**\nAll versions of Kubernetes\n\n**How do I mitigate this vulnerability?**\n\nTo mitigate this vulnerability, you must use an init container to perform git clone operation and then mount the directory into the Pod's container. An example of this approach is provided [here](https://gist.github.com/tallclair/849601a16cebeee581ef2be50c351841).\n\nNote: You can also restrict the use of gitRepo volumes in your cluster using policies such as ValidatingAdmissionPolicy or through Restricted pod security standard policy. You can use the following Common Expression Language (CEL) expression as part of a policy to reject use of gitRepo volumes: `has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo))`\n\n**Detection**\n\nTo detect whether this vulnerability has been exploited, you can use the following command to list all pods that use the in-tree gitRepo volume and clones to a .git subdirectory. \n`kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.volumes[].gitRepo.repository | test(\"^/\")) | {name: .metadata.name, namespace: .metadata.namespace, repository: (.spec.volumes[] | select(.gitRepo) | .gitRepo.repository)}'`\n\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io) \n\n**Acknowledgements**\nThis vulnerability was reported by Christophe Hauquiert.\n","date_published":"2025-03-13T16:08:20Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-1767","id":"CVE-2025-1767","status":"fixed","summary":"GitRepo Volume Inadvertent Local Repository Access","url":"https://github.com/kubernetes/kubernetes/issues/130786"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2025-0426","issue_number":130016},"content_text":"CVSS Rating: [CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)\n\nA security issue was discovered in Kubernetes where a large number of container checkpoint requests made to the unauthenticated kubelet read-only HTTP endpoint may cause a Node Denial of Service by filling the Node's disk. \n\n### Am I vulnerable?\n\nAll clusters running an affected version listed below with the kubelet read-only HTTP port enabled and using a container runtime that supports the container checkpointing feature, such as CRI-O v1.25.0+ (with `enable_criu_support` set to true) or containerd v2.0+ with `criu` installed, are affected.\n\n#### Affected Versions\n\n- kubelet v1.32.0 to v1.32.1\n- kubelet v1.31.0 to v1.31.5\n- kubelet v1.30.0 to v1.30.9\n\n### How do I mitigate this vulnerability?\n\nThis issue can be mitigated by setting the `ContainerCheckpoint` feature gate to `false` in your kubelet configuration, disabling the kubelet read-only port, and limiting access to the kubelet API, or upgrading to a fixed version listed below, which enforces authentication for the kubelet Checkpoint API.\n\n#### Fixed Versions\n\n- kubelet master - fixed by #129739\n- kubelet v1.32.2 - fixed by #130010\n- kubelet v1.31.6 - fixed by #130011\n- kubelet v1.30.10 - fixed by #130012\n- kubelet v1.29.14 - fixed by #130014\n - Note: Container checkpoint support was an off by default Alpha feature in v1.25-v1.29\n\n### Detection\n\nA large number of requests to the kubelet read-only HTTP server's `/checkpoint` endpoint, or a large number of checkpoints stored (by default) under `/var/lib/kubelet/checkpoints` on a Node may indicate an attempted Denial of Service attack using this bug.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported and fixed by Tim Allclair @tallclair from Google.\n\nThe issue was coordinated by: \n\nTim Allclair @tallclair\nSascha Grunert saschagrunert@\nCraig Ingram @cji\nJordan Liggitt liggitt@\n\n/triage accepted\n/lifecycle frozen\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig node\n/area kubelet","date_published":"2025-02-06T20:03:44Z","external_url":"https://www.cve.org/cverecord?id=CVE-2025-0426","id":"CVE-2025-0426","status":"fixed","summary":"Node Denial of Service via kubelet Checkpoint API","url":"https://github.com/kubernetes/kubernetes/issues/130016"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-9042","issue_number":129654},"content_text":"Hello Kubernetes Community,\n\nA security vulnerability has been discovered in Kubernetes windows nodes that could allow a user with the ability to query a node's '/logs' endpoint to execute arbitrary commands on the host. \n \nThis issue has been rated Medium with a CVSS v3.1 score of 5.9 ([CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N)) and assigned CVE-2024-9042.\n \n### Am I vulnerable?\nThis CVE affects only Windows worker nodes. Your worker node is vulnerable to this issue if it is running one of the affected versions listed below.\n \n#### Affected Components\nKubelet\n \n#### Affected Versions\nv1.32.0\nv1.31.0 to v1.31.4\nv1.30.0 to v1.30.8\n\u003c=v1.29.12\n \n### How do I mitigate this vulnerability?\nTo mitigate this vulnerability, you need to upgrade the Kubelet on your Windows worker nodes to one of the fixed versions listed below.\n \n### Fixed Versions\nv1.32.1\nv1.31.5\nv1.30.9\nv1.29.13\n \n### Detection\nTo detect whether this vulnerability has been exploited, you can examine your cluster's audit logs to search for node 'logs' queries with suspicious inputs.\n \nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io) \n \n### Acknowledgements\nThis vulnerability was reported by Peled, Tomer and mitigated by Aravindh Puthiyaprambil.","date_published":"2025-01-15T22:28:29Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-9042","id":"CVE-2024-9042","status":"fixed","summary":"Command Injection affecting Windows nodes via nodes/*/logs/query API","url":"https://github.com/kubernetes/kubernetes/issues/129654"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-10220","issue_number":128885},"content_text":"A security vulnerability was discovered in Kubernetes that could allow a user with the ability to create a pod and associate a gitRepo volume to execute arbitrary commands beyond the container boundary. This vulnerability leverages the hooks folder in the target repository to run arbitrary commands outside of the container's boundary.\r\n\r\nPlease note that this issue was originally publicly disclosed with a fix in July (#124531), and we are retroactively assigning it a CVE to assist in awareness and tracking.\r\n\r\nThis issue has been rated High ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)) (score: 8.1), and assigned CVE-2024-10220.\r\n\r\n### Am I vulnerable?\r\n\r\nThis CVE affects Kubernetes clusters where pods use the in-tree gitRepo volume to clone a repository to a subdirectory. If the Kubernetes cluster is running one of the affected versions listed below, then it is vulnerable to this issue.\r\n\r\n#### Affected Versions\r\n\r\n- kubelet v1.30.0 to v1.30.2\r\n- kubelet v1.29.0 to v1.29.6\r\n- kubelet \u003c= v1.28.11\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nTo mitigate this vulnerability, you must upgrade your Kubernetes cluster to one of the fixed versions listed below. \r\n\r\nAdditionally, since the gitRepo volume has been deprecated, the recommended solution is to perform the Git clone operation using an init container and then mount the directory into the Pod's container. An example of this approach is provided [here](https://gist.github.com/tallclair/849601a16cebeee581ef2be50c351841).\r\n\r\n#### Fixed Versions\r\n\r\n* kubelet master/v1.31.0 - fixed by #124531\r\n* kubelet v1.30.3 - fixed by #125988\r\n* kubelet v1.29.7 - fixed by #125989\r\n* kubelet v1.28.12 - fixed by #125990\r\n\r\n### Detection\r\n\r\nTo detect whether this vulnerability has been exploited, you can use the following command to list all pods that use the in-tree gitRepo volume and clones to a .git subdirectory. \r\n\r\n```\r\nkubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.volumes[].gitRepo.directory | endswith(\"/.git\")) | {name: .metadata.name, namespace: .metadata.namespace}\r\n```\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported and mitigated by Imre Rad.\r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig node\r\n/area kubelet","date_published":"2024-11-20T15:30:44Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-10220","id":"CVE-2024-10220","status":"fixed","summary":"Arbitrary command execution through gitRepo volume","url":"https://github.com/kubernetes/kubernetes/issues/128885"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-9594","issue_number":128007},"content_text":"CVSS Rating: [CVSS:3.1/AV:A/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H)\r\n\r\nA security issue was discovered in the Kubernetes Image Builder where default credentials are enabled during the image build process when using the Nutanix, OVA, QEMU or raw providers. The credentials can be used to gain root access. The credentials are disabled at the conclusion of the image build process. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project. \r\n\r\n### Am I vulnerable?\r\n\r\nClusters using virtual machine images built with Kubernetes Image Builder (https://github.com/kubernetes-sigs/image-builder) version v0.1.37 or earlier are affected if built with the Nutanix, OVA, QEMU or raw providers. These images were vulnerable during the image build process and are affected only if an attacker was able to reach the VM where the image build was happening and used the vulnerability to modify the image at the time the image build was occurring.\r\n\r\nVMs using images built with the Proxmox provider are affected by a related, but much more serious vulnerability (see #128006).\r\n\r\nVMs using images built with all other providers are not affected by this issue.\r\n\r\nTo determine the version of Image Builder you are using, use one of the following methods:\r\n- For git clones of the image builder repository:\r\n```\r\n cd \u003clocal path to image builder repo\u003e\r\n make version\r\n```\r\n- For installations using a tarball download:\r\n```\r\n cd \u003clocal path to install location\u003e\r\n grep -o v0\\\\.[0-9.]* RELEASE.md | head -1\r\n```\r\n- For a container image release:\r\n `docker run --rm \u003cimage pull spec\u003e version`\r\n or\r\n `podman run --rm \u003cimage pull spec\u003e version`\r\n or look at the image tag specified, in the case of an official image such as `registry.k8s.io/scl-image-builder/cluster-node-image-builder-amd64:v0.1.37`\r\n\r\n\r\n#### Affected Versions\r\n\r\n- Kubernetes Image Builder versions \u003c= v0.1.37\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nRebuild any affected images using a fixed version of Image Builder. Re-deploy the fixed images to any affected VMs.\r\n\r\n#### Fixed Versions\r\n\r\n- Kubernetes Image Builder master - fixed by https://github.com/kubernetes-sigs/image-builder/pull/1596\r\n- Fixed in Kubernetes Image Builder release v0.1.38\r\n\r\n### Detection\r\n\r\nThe linux command `last builder` can be used to view logins to the affected `builder` account.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n## Additional Details\r\n\r\nThe fixed version sets a randomly-generated password for the duration of the image build\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Nicolai Rybnikar @rybnico from Rybnikar Enterprises GmbH.\r\n\r\nThe issue was fixed and coordinated by Marcus Noble of the Image Builder project.\r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig cluster-lifecycle","date_published":"2024-10-11T18:04:50Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-9594","id":"CVE-2024-9594","status":"fixed","summary":"VM images built with Image Builder with some providers use default credentials during builds","url":"https://github.com/kubernetes/kubernetes/issues/128007"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-9486","issue_number":128006},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)\r\n\r\nA security issue was discovered in the Kubernetes Image Builder where default credentials are enabled during the image build process. Additionally, virtual machine images built using the Proxmox provider do not disable these default credentials, and nodes using the resulting images may be accessible via these default credentials. The credentials can be used to gain root access. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project with its Proxmox provider. \r\n\r\n### Am I vulnerable?\r\n\r\nClusters using virtual machine images built with Kubernetes Image Builder (https://github.com/kubernetes-sigs/image-builder) version v0.1.37 or earlier are affected if built with the Proxmox provider.\r\n\r\nVMs using images built with all other providers are not affected by this issue. See #128007 for a related issue which affects some other providers.\r\n\r\nTo determine the version of Image Builder you are using, use one of the following methods:\r\n- For git clones of the image builder repository:\r\n```\r\n cd \u003clocal path to image builder repo\u003e\r\n make version\r\n```\r\n- For installations using a tarball download:\r\n```\r\n cd \u003clocal path to install location\u003e\r\n grep -o v0\\\\.[0-9.]* RELEASE.md | head -1\r\n```\r\n- For a container image release:\r\n `docker run --rm \u003cimage pull spec\u003e version`\r\n or\r\n `podman run --rm \u003cimage pull spec\u003e version`\r\n or look at the image tag specified, in the case of an official image such as `registry.k8s.io/scl-image-builder/cluster-node-image-builder-amd64:v0.1.37`\r\n\r\n\r\n#### Affected Versions\r\n\r\n- Kubernetes Image Builder versions \u003c= v0.1.37\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nRebuild any affected images using a fixed version of Image Builder. Re-deploy the fixed images to any affected VMs.\r\n\r\nPrior to upgrading, this vulnerability can be mitigated by disabling the builder account on affected VMs:\r\nusermod -L builder\r\n\r\n#### Fixed Versions\r\n\r\n- Kubernetes Image Builder master - fixed by https://github.com/kubernetes-sigs/image-builder/pull/1595\r\n- Fixed in Kubernetes Image Builder release v0.1.38\r\n\r\n### Detection\r\n\r\nThe linux command `last builder` can be used to view logins to the affected `builder` account.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n## Additional Details\r\n\r\nThe fixed version makes two changes to remedy this bug:\r\n- It sets a randomly-generated password for the duration of the image build\r\n- It disables the builder account at the conclusion of the image build\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Nicolai Rybnikar @rybnico from Rybnikar Enterprises GmbH.\r\n\r\nThe issue was fixed and coordinated by Marcus Noble of the Image Builder project.\r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig cluster-lifecycle\r\n","date_published":"2024-10-11T18:04:31Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-9486","id":"CVE-2024-9486","status":"fixed","summary":"VM images built with Image Builder and Proxmox provider use default credentials","url":"https://github.com/kubernetes/kubernetes/issues/128006"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-7646","issue_number":126744},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)\r\n\r\nA security issue was discovered in ingress-nginx where an actor with permission to create Ingress objects (in the `networking.k8s.io` or `extensions` API group) can bypass annotation validation to inject arbitrary commands and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.\r\n\r\nThis issue has been rated **High** (8.8) [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and assigned **CVE-2024-7646**.\r\n\r\n### Am I vulnerable?\r\n\r\nThis bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -A` and looking for `ingress-nginx-controller`.\r\n\r\nMulti-tenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.\r\n\r\n### Affected Versions\r\n\r\ningress-nginx controller \u003c v1.11.2\r\ningress-nginx controller \u003c v1.10.4\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThis issue can be mitigated by upgrading to the fixed version. \r\n\r\n### Fixed Versions\r\n\r\ningress-nginx controller v1.11.2 - fixed by https://github.com/kubernetes/ingress-nginx/pull/11719 and https://github.com/kubernetes/ingress-nginx/pull/11721\r\ningress-nginx controller v1.10.4 - fixed by https://github.com/kubernetes/ingress-nginx/pull/11718 and https://github.com/kubernetes/ingress-nginx/pull/11722\r\n\r\n### Detection\r\n\r\nReview your Kubernetes audit logs for Ingress objects created with annotations (e.g. `nginx.ingress.kubernetes.io/auth-tls-verify-client`) that contain carriage returns (`\\r`).\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n### Additional Details\r\n\r\nSee the GitHub issue for more details: \r\nhttps://github.com/kubernetes/kubernetes/issues/126744 \r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by André Storfjord Kristiansen @dev-bio. \r\n\r\nThe issue was fixed and coordinated by the fix team:\r\nAndré Storfjord Kristiansen @dev-bio\r\nJintao Zhang @tao12345666333\r\nMarco Ebert @Gacko\r\n\r\n/triage accepted\r\n/lifecycle frozen\r\n/area security\r\n/kind bug\r\n/committee security-response","date_published":"2024-08-16T16:10:31Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-7646","id":"CVE-2024-7646","status":"fixed","summary":"Ingress-nginx Annotation Validation Bypass","url":"https://github.com/kubernetes/kubernetes/issues/126744"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-7598","issue_number":126587},"content_text":"CVSS Rating: [CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) - **Low** (3.1)\n\nA security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running and accepting network connections, but the network policies restrictions are not applied.\n\n### Am I vulnerable?\n\nAll clusters that rely on network policies may be vulnerable. Run the following command to see if network policies are in use:\n\n```\nkubectl get networkpolicies.networking.k8s.io --all-namespaces\n```\n\n#### Affected Versions\n\nkube-apiserver \u003e= v1.3\n\n### How do I mitigate this vulnerability?\n\nThis issue can be mitigated by:\n\n- Manually deleting pods and workload resources that orchestrate pods before starting namespace deletion\n\n- Adding finalizers to network policies to prevent them from being deleted until the pods that they protect have been deleted first. The following proof-of-concept controller automates this process:\n\nhttps://github.com/kubernetes-sigs/network-policy-finalizer \n\n#### Fixed Versions\n\n- None. A longer term comprehensive fix is proposed in the following KEP: https://github.com/kubernetes/enhancements/pull/5095 \n\n### Detection\n\nUsers of network policies may be able to detect abuse via network logs. The exact details of this process are environment specific.\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Acknowledgements\n\nThis vulnerability was reported by John McGuinness @s1xtw03 and Aaron Coffey @aaroncoffey.\n\nThe issue was coordinated by: \n\nAntonio Ojea @aojea\nTim Hockin @thockin\nDan Winship @danwinship\nShane Utt @shaneutt\nDavid Eads @deads2k\nClayton Colemon @smarterclayton\nMo Khan @enj\nCraig Ingram @cji\n\n/label official-cve-feed\n/triage accepted\n/lifecycle frozen\n/area security\n/kind bug\n/committee security-response","date_published":"2024-08-07T21:30:11Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-7598","id":"CVE-2024-7598","status":"fixed","summary":"Network restriction bypass via race condition during namespace termination","url":"https://github.com/kubernetes/kubernetes/issues/126587"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-5321","issue_number":126161},"content_text":"CVSS Rating: [CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N) - **MEDIUM** (6.1)\r\n\r\nA security issue was discovered in Kubernetes clusters with Windows nodes where `BUILTIN\\Users` may be able to read container logs and `NT AUTHORITY\\Authenticated Users` may be able to modify container logs.\r\n\r\nThis issue has been rated **Medium** ([CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N)), and assigned **CVE-2024-5321**.\r\n\r\n### Am I vulnerable?\r\n\r\nAny Kubernetes environment with Windows nodes is affected. Run `kubectl get nodes -l kubernetes.io/os=windows` to see if any Windows nodes are in use.\r\n\r\n#### Affected Versions\r\n\r\n- kubelet \u003c= 1.27.15\r\n- kubelet \u003c= 1.28.11\r\n- kubelet \u003c= 1.29.6\r\n- kubelet \u003c= 1.30.2 \r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThis issue can be mitigated by applying the patch provided. The patch includes changes to `pkg/util/filesystem` that set file permissions on Windows and hardens the permissions for container logs for containers running on Windows.\r\n\r\n#### Fixed Versions\r\n\r\n- kubelet 1.27.16\r\n- kubelet 1.28.12\r\n- kubelet 1.29.7\r\n- kubelet 1.30.3 \r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/ \r\n\r\n### Detection\r\n\r\nAny Kubernetes environment with Windows nodes is affected. Run `kubectl get nodes -l kubernetes.io/os=windows` to see if any Windows nodes are in use.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Paulo Gomes @pjbgf from SUSE.\r\n\r\nThe issue was fixed and coordinated by the fix team: \r\nMark Rossetti @marosset \r\nJames Sturtevant @jsturtevant \r\nCraig Ingram @cji \r\nRita Zhang @ritazh\r\n\r\nand release managers:\r\nSascha Grunert @saschagrunert\r\nJeremy Rickard @jeremyrickard\r\nCarlos Panato @cpanato\r\nJim Angel @jimangel\r\n\r\n\u003c!-- labels --\u003e\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/sig windows\r\n/area kubelet\r\n/triage accepted\r\n/lifecycle frozen\r\n","date_published":"2024-07-17T13:06:48Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-5321","id":"CVE-2024-5321","status":"fixed","summary":"Incorrect permissions on Windows containers logs","url":"https://github.com/kubernetes/kubernetes/issues/126161"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-3744","issue_number":124759},"content_text":"CVSS Rating: [CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) - **MEDIUM** (6.5)\r\n\r\nA security issue was discovered in azure-file-csi-driver where an actor with access to the driver logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag.\r\n\r\nThis issue has been rated **MEDIUM** [CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) (6.5), and assigned **CVE-2024-3744**\r\n\r\n### Am I vulnerable?\r\n\r\nYou may be vulnerable if [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag.\r\n\r\nTo check if token requests are configured, run the following command:\r\n\r\nkubectl get csidriver file.csi.azure.com -o jsonpath=\"{.spec.tokenRequests}\"\r\n\r\nTo check if tokens are being logged, examine the secrets-store container log:\r\n\r\nkubectl logs csi-azurefile-controller-56bfddd689-dh5tk -c azurefile -f | grep --line-buffered \"csi.storage.k8s.io/serviceAccount.tokens\"\r\n\r\n#### Affected Versions\r\n\r\n- azure-file-csi-driver \u003c= v1.29.3\r\n- azure-file-csi-driver v1.30.0\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nPrior to upgrading, this vulnerability can be mitigated by running azure-file-csi-driver at log level 0 or 1 via the -v flag.\r\n\r\n#### Fixed Versions\r\n\r\n- azure-file-csi-driver v1.29.4\r\n- azure-file-csi-driver v1.30.1\r\n\r\nTo upgrade, refer to the documentation: https://github.com/kubernetes-sigs/azurefile-csi-driver?tab=readme-ov-file#install-driver-on-a-kubernetes-cluster \r\n\r\n### Detection\r\n\r\nExamine cloud provider logs for unexpected token exchanges, as well as unexpected access to cloud resources.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was patched by Weizhi Chen @cvvz from Microsoft.\r\n\r\nThank You,\r\nRita Zhang on behalf of the Kubernetes Security Response Committee\r\n\r\n/triage accepted\r\n/lifecycle frozen\r\n/area security\r\n/kind bug\r\n/committee security-response","date_published":"2024-05-08T16:02:57Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-3744","id":"CVE-2024-3744","status":"fixed","summary":"azure-file-csi-driver discloses service account tokens in logs","url":"https://github.com/kubernetes/kubernetes/issues/124759"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2024-3177","issue_number":124336},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N) - **Low** (2.7)\r\n\r\nA security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the `kubernetes.io/enforce-mountable-secrets` annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated. \r\n\r\n### Am I vulnerable?\r\n\r\nThe ServiceAccount admission plugin is used. Most cluster should have this on by default as recommended in https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount\r\nThe kubernetes.io/enforce-mountable-secrets annotation is used by a service account. This annotation is not added by default. Pods using containers, init containers, and ephemeral containers with the envFrom field populated.\r\n\r\n#### Affected Versions\r\n\r\nkube-apiserver v1.29.0 - v1.29.3\r\nkube-apiserver v1.28.0 - v1.28.8\r\nkube-apiserver \u003c= v1.27.12\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThis issue can be mitigated by applying the patch provided for the kube-apiserver component. The patch prevents containers, init containers, and ephemeral containers with the envFrom field populated from bypassing the mountable secrets policy enforced by the ServiceAccount admission plugin.\r\n\r\nOutside of applying the provided patch, there are no known mitigations to this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- kube-apiserver master - fixed by #124322\r\n- kube-apiserver v1.29.4 - fixed by #124325\r\n- kube-apiserver v1.28.9 - fixed by #124326\r\n- kube-apiserver v1.27.13 - fixed by #124327\r\n\r\nTo upgrade, refer to the documentation:\r\nhttps://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/ \r\n\r\n### Detection\r\n\r\nPod update requests using a container, init container, or ephemeral container with the envFrom field populated that exploits this vulnerability with unintended secret will be captured in API audit logs. You can also use the following kubectl command to find active pods using the `kubernetes.io/enforce-mountable-secrets` annotation. \r\n\r\n`kubectl get serviceaccounts --all-namespaces -o jsonpath=\"{range .items[?(@.metadata.annotations['kubernetes\\.io/enforce-mountable-secrets']=='true')]}{.metadata.namespace}{'\\t'}{.metadata.name}{'\\n'}{end}\"` \r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by tha3e1vl. \r\n\r\nThe issue was fixed and coordinated by the fix team: \r\n\r\nRita Zhang @ritazh\r\nJoel Smith @joelsmith\r\nMo Khan @enj\r\n\r\nand release managers:\r\nSascha Grunert @saschagrunert\r\nJeremy Rickard @jeremyrickard\r\n\r\n/triage accepted\r\n/lifecycle frozen\r\n/area security\r\n/kind bug\r\n/committee security-response","date_published":"2024-04-16T14:04:09Z","external_url":"https://www.cve.org/cverecord?id=CVE-2024-3177","id":"CVE-2024-3177","status":"fixed","summary":"Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin","url":"https://github.com/kubernetes/kubernetes/issues/124336"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-5528","issue_number":121879},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) - **HIGH** (7.2)\r\n\r\nA security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.\r\n\r\n### Am I vulnerable?\r\n\r\nAny kubernetes environment with Windows nodes is impacted. Run `kubectl get nodes -l kubernetes.io/os=windows` to see if any Windows nodes are in use.\r\n\r\n#### Affected Versions\r\n\r\n- kubelet \u003e= v1.8.0 (including all later minor versions)\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThe provided patch fully mitigates the vulnerability.\r\n\r\nOutside of applying the provided patch, there are no known mitigations to this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- kubelet master - fixed by #121881\r\n- kubelet v1.28.4 - fixed by #121882\r\n- kubelet v1.27.8 - fixed by #121883\r\n- kubelet v1.26.11 - fixed by #121884\r\n- kubelet v1.25.16 - fixed by #121885\r\n\r\nTo upgrade, refer to the documentation:\r\nhttps://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n### Detection\r\n\r\nKubernetes audit logs can be used to detect if this vulnerability is being exploited. Persistent Volume create events with local path fields containing special characters are a strong indication of exploitation.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Tomer Peled [@tomerpeled92](https://github.com/tomerpeled92)\r\n\r\nThe issue was fixed and coordinated by the fix team: \r\n\r\nJames Sturtevant @jsturtevant\r\nMark Rossetti @marosset\r\nMichelle Au @msau42 \r\nJan Šafránek @jsafrane \r\nMo Khan @enj \r\nRita Zhang @ritazh\r\nMicah Hausler @micahhausler\r\nSri Saran Balaji @SaranBalaji90\r\nCraig Ingram @cji \r\n\r\nand release managers:\r\nJeremy Rickard @jeremyrickard\r\nMarko Mudrinić @xmudrii \r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig windows\r\n/sig storage\r\n/area kubelet","date_published":"2023-11-14T15:54:16Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-5528","id":"CVE-2023-5528","status":"fixed","summary":"Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes","url":"https://github.com/kubernetes/kubernetes/issues/121879"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-5044","issue_number":126817},"content_text":"### Issue Details\r\nA security issue was identified in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the nginx.ingress.kubernetes.io/permanent-redirect annotation on an Ingress object (in the `networking.k8s.io` or `extensions` API group) can be used to inject arbitrary commands, and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.\r\n\r\nThis issue has been rated **High** ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)), and assigned **CVE-2023-5044**.\r\n\r\n### Affected Components and Configurations\r\n\r\nThis bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`.\r\n\r\nIf you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), command execution is possible but credential extraction is not, so the High severity does not apply.\r\n\r\nMulti-tenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.\r\n\r\n#### Affected Versions\r\n\r\n- \u003cv1.9.0\r\n\r\n#### Versions allowing mitigation\r\n\r\n- v1.9.0\r\n\r\n### Mitigation\r\n\r\nIngress Administrators should set the --enable-annotation-validation flag to enforce restrictions on the contents of ingress-nginx annotation fields.\r\n\r\n### Detection\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n### Additional Details\r\n\r\nSee ingress-nginx Issue [#10572](https://github.com/kubernetes/kubernetes/issues/126817) for more details.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Jan-Otto Kröpke (Cloudeteer GmbH)\r\n\r\nThank You,\r\nCJ Cullen on behalf of the Kubernetes Security Response Committee","date_published":"2023-10-25T15:48:28Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-5044","id":"CVE-2023-5044","status":"fixed","summary":"Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation","url":"https://github.com/kubernetes/kubernetes/issues/126817"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-5043","issue_number":126816},"content_text":"### Issue Details\r\n\r\nA security issue was identified in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the nginx.ingress.kubernetes.io/configuration-snippet annotation on an Ingress object (in the `networking.k8s.io` or `extensions` API group) can be used to inject arbitrary commands, and obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.\r\n\r\nThis issue has been rated **High** ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)), and assigned **CVE-2023-5043**.\r\n\r\n### Affected Components and Configurations\r\nThis bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`.\r\n\r\nIf you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), command execution is possible but credential extraction is not, so the High severity does not apply.\r\n\r\nMulti-tenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.\r\n\r\n#### Affected Versions\r\n\r\n- \u003cv1.9.0\r\n\r\n#### Versions allowing mitigation\r\n\r\n- v1.9.0\r\n\r\n### Mitigation\r\nIngress Administrators should set the --enable-annotation-validation flag to enforce restrictions on the contents of ingress-nginx annotation fields.\r\n\r\n### Detection\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n### Additional Details\r\nSee ingress-nginx Issue[ kubernetes/kubernetes#126816](https://github.com/kubernetes/kubernetes/issues/126816) for more details.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by suanve\r\n\r\nThank You,\r\nCJ Cullen on behalf of the Kubernetes Security Response Committee","date_published":"2023-10-25T15:48:20Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-5043","id":"CVE-2023-5043","status":"fixed","summary":"Ingress nginx annotation injection causes arbitrary command execution","url":"https://github.com/kubernetes/kubernetes/issues/126816"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2022-4886","issue_number":126815},"content_text":"### Issue Details\r\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where a user that can create or update ingress objects can use directives to bypass the sanitization of the `spec.rules[].http.paths[].path` field of an Ingress object (in the `networking.k8s.io` or `extensions` API group) to obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.\r\n\r\nThis issue has been rated **High** ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)), and assigned CVE-2022-4886.\r\n\r\n### Affected Components and Configurations\r\nThis bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`.\r\n\r\nIf you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), command execution is possible but credential extraction is not, so the High severity does not apply.\r\n\r\nMulti-tenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.\r\n\r\n#### Affected Versions\r\n\r\n- \u003cv1.8.0\r\n\r\n#### Versions allowing mitigation\r\n\r\n- v1.8.0\r\n\r\n### Mitigation\r\nIngress objects contain a field called pathType that defines the proxy behavior. It can be Exact, Prefix and ImplementationSpecific.\r\n\r\nWhen pathType is configured as Exact or Prefix, there is more strict validation, allowing only paths starting with \"/\" and containing only alphanumeric characters and \"-\", \"_\" and additional \"/\".\r\n\r\nWhen this option is enabled, the validation happens in the Admission Webhook, denying creation of any Ingress containing invalid characters (unless pathType is ImplementationSpecific).\r\n\r\nhttps://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#strict-validate-path-type\r\n\r\nIngress Admins should enable this validation by default. If you still need to allow implementation specific paths due to the usage of features like Regex/rewrite on path, we recommend implementing countermeasures to allow just trusted users to consume this feature, as an example with OPA: https://kubernetes.github.io/ingress-nginx/examples/openpolicyagent/\r\n\r\n### Detection\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n### Additional Details\r\nSee ingress-nginx Issue [#10570](https://github.com/kubernetes/kubernetes/issues/126815) for more details.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Ginoah, working with the DEVCORE Internship Program.\r\n\r\nThank You,\r\nCJ Cullen on behalf of the Kubernetes Security Response Committee","date_published":"2023-10-25T15:48:08Z","external_url":"https://www.cve.org/cverecord?id=CVE-2022-4886","id":"CVE-2022-4886","status":"fixed","summary":"ingress-nginx path sanitization can be bypassed","url":"https://github.com/kubernetes/kubernetes/issues/126815"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-3955","issue_number":119595},"content_text":"CVSS Rating: [CVSS:3.1/av:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) - **HIGH** (8.8)\r\n\r\nA security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.\r\n\r\n### Am I vulnerable?\r\n\r\nAny kubernetes environment with Windows nodes is impacted. Run `kubectl get nodes -l kubernetes.io/os=windows` to see if any Windows nodes are in use.\r\n\r\n#### Affected Versions\r\n\r\n- kubelet \u003c= v1.28.0\r\n- kubelet \u003c= v1.27.4\r\n- kubelet \u003c= v1.26.7\r\n- kubelet \u003c= v1.25.12\r\n- kubelet \u003c= v1.24.16\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThe provided patch fully mitigates the vulnerability (see fix impact below). Full mitigation for this class of issues requires patches applied for CVE-2023-3676, CVE-2023-3955, and CVE-2023-3893.\r\n\r\nOutside of applying the provided patch, there are no known mitigations to this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- kubelet master - fixed by #120128\r\n- kubelet v1.28.1 - fixed by #120134\r\n- kubelet v1.27.5 - fixed by #120135\r\n- kubelet v1.26.8 - fixed by #120136\r\n- kubelet v1.25.13 - fixed by #120137\r\n- kubelet v1.24.17 - fixed by #120138\r\n\r\n**Fix impact:** Passing Windows Powershell disk format options to in-tree volume plugins will result in an error during volume provisioning on the node. There are no known use cases for this functionality, nor is this functionality supported by any known out-of-tree CSI driver.\r\n\r\nTo upgrade, refer to the documentation:\r\nhttps://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/\r\n\r\n### Detection\r\n\r\nKubernetes audit logs can be used to detect if this vulnerability is being exploited. Pod create events with embedded powershell commands are a strong indication of exploitation.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was discovered by James Sturtevant @jsturtevant and Mark Rossetti @marosset during the process of fixing CVE-2023-3676 (that original CVE was reported by Tomer Peled @tomerpeled92)\r\n\r\nThe issue was fixed and coordinated by the fix team: \r\n\r\nJames Sturtevant @jsturtevant\r\nMark Rossetti @marosset\r\nAndy Zhang @andyzhangx\r\nJustin Terry @jterry75\r\nKulwant Singh @KlwntSingh\r\nMicah Hausler @micahhausler\r\nRita Zhang @ritazh\r\n\r\nand release managers:\r\n\r\nJeremy Rickard @jeremyrickard","date_published":"2023-07-26T15:30:50Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-3955","id":"CVE-2023-3955","status":"fixed","summary":"Insufficient input sanitization on Windows nodes leads to privilege escalation","url":"https://github.com/kubernetes/kubernetes/issues/119595"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-3893","issue_number":119594},"content_text":"CVSS Rating: [CVSS:3.1/av:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) - **HIGH** (8.8)\r\n\r\nA security issue was discovered in Kubernetes where a user that can create pods on Windows nodes running kubernetes-csi-proxy may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes running kubernetes-csi-proxy.\r\n\r\n### Am I vulnerable?\r\n\r\nAny kubernetes environment with Windows nodes that are running kubernetes-csi-proxy is impacted. This is a common default configuration on Windows nodes. Run `kubectl get nodes -l kubernetes.io/os=windows` to see if any Windows nodes are in use.\r\n\r\n#### Affected Versions\r\n\r\n- kubernetes-csi-proxy \u003c= v2.0.0-alpha.0\r\n- kubernetes-csi-proxy \u003c= v1.1.2\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThe provided patch fully mitigates the vulnerability and has no known side effects. Full mitigation for this class of issues requires patches applied for CVE-2023-3676, CVE-2023-3955, and CVE-2023-3893.\r\n\r\nOutside of applying the provided patch, there are no known mitigations to this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- kubernetes-csi-proxy master - fixed by https://github.com/kubernetes-csi/csi-proxy/pull/306\r\n- kubernetes-csi-proxy v2.0.0-alpha.1 - fixed by https://github.com/kubernetes-csi/csi-proxy/pull/307\r\n- kubernetes-csi-proxy v1.1.3 - fixed by https://github.com/kubernetes-csi/csi-proxy/pull/306\r\n\r\nTo upgrade: cordon the node, stop the associated Windows service, replace the csi-proxy.exe binary, restart the associated Windows service, and un-cordon the node. See the installation docs for more details: https://github.com/kubernetes-csi/csi-proxy#installation\r\n\r\nIf a Windows host process daemon set is used to run kubernetes-csi-proxy such as https://github.com/kubernetes-csi/csi-driver-smb/blob/master/charts/latest/csi-driver-smb/templates/csi-proxy-windows.yaml, simply upgrade the image to a fixed version such as ghcr.io/kubernetes-sigs/sig-windows/csi-proxy:v1.1.3\r\n\r\n### Detection\r\n\r\nKubernetes audit logs can be used to detect if this vulnerability is being exploited. Pod create events with embedded powershell commands are a strong indication of exploitation.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was discovered by James Sturtevant @jsturtevant and Mark Rossetti @marosset during the process of fixing CVE-2023-3676 (that original CVE was reported by Tomer Peled @tomerpeled92)\r\n\r\nThe issue was fixed and coordinated by the fix team: \r\n\r\nJames Sturtevant @jsturtevant\r\nMark Rossetti @marosset\r\nAndy Zhang @andyzhangx\r\nJustin Terry @jterry75\r\nKulwant Singh @KlwntSingh\r\nMicah Hausler @micahhausler\r\nRita Zhang @ritazh\r\n\r\nand release managers:\r\n\r\nMauricio Poppe @mauriciopoppe","date_published":"2023-07-26T15:30:26Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-3893","id":"CVE-2023-3893","status":"fixed","summary":"Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation","url":"https://github.com/kubernetes/kubernetes/issues/119594"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-3676","issue_number":119339},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) - **HIGH** (8.8)\r\n\r\nA security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.\r\n\r\n### Am I vulnerable?\r\n\r\nAny kubernetes environment with Windows nodes is impacted. Run `kubectl get nodes -l kubernetes.io/os=windows` to see if any Windows nodes are in use.\r\n\r\n#### Affected Versions\r\n\r\n- kubelet \u003c= v1.28.0\r\n- kubelet \u003c= v1.27.4\r\n- kubelet \u003c= v1.26.7\r\n- kubelet \u003c= v1.25.12\r\n- kubelet \u003c= v1.24.16\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThe provided patch fully mitigates the vulnerability and has no known side effects. Full mitigation for this class of issues requires patches applied for CVE-2023-3676, CVE-2023-3955, and CVE-2023-3893.\r\n\r\nOutside of applying the provided patch, there are no known mitigations to this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- kubelet master - fixed by #120127\r\n- kubelet v1.28.1 - fixed by #120129\r\n- kubelet v1.27.5 - fixed by #120130\r\n- kubelet v1.26.8 - fixed by #120131\r\n- kubelet v1.25.13 - fixed by #120132\r\n- kubelet v1.24.17 - fixed by #120133\r\n\r\nTo upgrade, refer to the documentation:\r\nhttps://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/\r\n\r\n### Detection\r\n\r\nKubernetes audit logs can be used to detect if this vulnerability is being exploited. Pod create events with embedded powershell commands are a strong indication of exploitation. Config maps and secrets that contain embedded powershell commands and are mounted into pods are also a strong indication of exploitation.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Tomer Peled @tomerpeled92\r\n\r\nThe issue was fixed and coordinated by the fix team: \r\n\r\nJames Sturtevant @jsturtevant\r\nMark Rossetti @marosset\r\nAndy Zhang @andyzhangx\r\nJustin Terry @jterry75\r\nKulwant Singh @KlwntSingh\r\nMicah Hausler @micahhausler\r\nRita Zhang @ritazh\r\n\r\nand release managers:\r\n\r\nJeremy Rickard @jeremyrickard\r\n\r\n\r\n/triage accepted\r\n/lifecycle frozen\r\n/area security\r\n/kind bug\r\n/committee security-response","date_published":"2023-07-14T18:27:48Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-3676","id":"CVE-2023-3676","status":"fixed","summary":"Insufficient input sanitization on Windows nodes leads to privilege escalation","url":"https://github.com/kubernetes/kubernetes/issues/119339"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-2431","issue_number":118690},"content_text":"### What happened?\r\n\r\nA security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. This issue has been rated LOW ([CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N)) (score: 3.4).\r\n\r\nIf you have pods in your cluster that use [localhost type](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#seccompprofile-v1-core) for seccomp profile but specify an empty profile field, then you are affected by this issue. In this scenario, this vulnerability allows the pod to run in “unconfined” (seccomp disabled) mode. This bug affects Kubelet.\r\n\r\n### How can we reproduce it (as minimally and precisely as possible)?\r\n\r\nThis can be reproduced by creating a pod with following sample seccomp Localhost profile - \r\n\r\n```\r\n localhostProfile: \"\"\r\n```\r\n\r\nhttps://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#seccompprofile-v1-core\r\n\r\n### Kubernetes version\r\n\r\n**Affected Versions**\r\nv1.27.0 - v1.27.1\r\nv1.26.0 - v1.26.4\r\nv1.25.0 - v1.25.9\r\n\u003c= v1.24.13\r\n\r\n**Fixed Versions**\r\nv1.27.2\r\nv1.26.5\r\nv1.25.10\r\nV1.24.14\r\n\r\n### Anything else we need to know?\r\n\r\nHow do I remediate this vulnerability?\r\nTo remediate this vulnerability you should upgrade your Kubelet to one of the below mentioned versions.\r\n\r\nAcknowledgements\r\nThis vulnerability was reported by Tim Allclair, and fixed by Craig Ingram.","date_published":"2023-06-15T14:42:32Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-2431","id":"CVE-2023-2431","status":"fixed","summary":"Bypass of seccomp profile enforcement","url":"https://github.com/kubernetes/kubernetes/issues/118690"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-2728","issue_number":118640},"content_text":"### CVE-2023-2727: Bypassing policies imposed by the ImagePolicyWebhook admission plugin\r\nCVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N)\r\n\r\nA security issue was discovered in Kubernetes where users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers.\r\n\r\n### Am I vulnerable?\r\nClusters are impacted by this vulnerability if all of the following are true:\r\n\r\n1. The ImagePolicyWebhook admission plugin is used to restrict use of certain images\r\n2. Pods are using ephemeral containers.\r\n\r\n### Affected Versions\r\n\r\n- kube-apiserver v1.27.0 - v1.27.2\r\n- kube-apiserver v1.26.0 - v1.26.5\r\n- kube-apiserver v1.25.0 - v1.25.10\r\n- kube-apiserver \u003c= v1.24.14\r\n\r\n### How do I mitigate this vulnerability?\r\nThis issue can be mitigated by applying the patch provided for the kube-apiserver component. This patch prevents ephemeral containers from using an image that is restricted by ImagePolicyWebhook. \r\n\r\nNote: Validation webhooks (such as [Gatekeeper](https://open-policy-agent.github.io/gatekeeper-library/website/validation/allowedrepos/) and [Kyverno](https://kyverno.io/policies/other/allowed-image-repos/allowed-image-repos/)) can also be used to enforce the same restrictions.\r\n\r\n### Fixed Versions\r\n\r\n- kube-apiserver v1.27.3\r\n- kube-apiserver v1.26.6\r\n- kube-apiserver v1.25.11\r\n- kube-apiserver v1.24.15\r\n\r\n### Detection\r\nPod update requests using an ephemeral container with an image that should have been restricted by an ImagePolicyWebhook will be captured in API audit logs. You can also use `kubectl get pods` to find active pods with ephemeral containers running an image that should have been restricted in your cluster with this issue.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Stanislav Láznička, and fixed by Rita Zhang.\r\n\r\n### CVE-2023-2728: Bypassing enforce mountable secrets policy imposed by the ServiceAccount admission plugin\r\nCVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N)\r\n\r\nA security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the `kubernetes.io/enforce-mountable-secrets` annotation are used together with ephemeral containers.\r\n\r\n### Am I vulnerable?\r\nClusters are impacted by this vulnerability if all of the following are true:\r\n\r\n1. The ServiceAccount admission plugin is used. Most cluster should have this on by default as recommended in [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount)\r\n2. The `kubernetes.io/enforce-mountable-secrets` annotation is used by a service account. This annotation is not added by default.\r\n3. Pods are using ephemeral containers.\r\n\r\n### Affected Versions\r\n\r\n- kube-apiserver v1.27.0 - v1.27.2\r\n- kube-apiserver v1.26.0 - v1.26.5\r\n- kube-apiserver v1.25.0 - v1.25.10\r\n- kube-apiserver \u003c= v1.24.14\r\n\r\n### How do I mitigate this vulnerability?\r\nThis issue can be mitigated by applying the patch provided for the kube-apiserver component. The patch prevents ephemeral containers from bypassing the mountable secrets policy enforced by the ServiceAccount admission plugin.\r\n\r\n### Fixed Versions\r\n- kube-apiserver v1.27.3\r\n- kube-apiserver v1.26.6\r\n- kube-apiserver v1.25.11\r\n- kube-apiserver v1.24.15\r\n\r\n### Detection\r\nPod update requests using an ephemeral container that exploits this vulnerability with unintended secret will be captured in API audit logs. You can also use kubectl get pods to find active pods with ephemeral containers running with a secret that is not referenced by the service account in your cluster.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Rita Zhang, and fixed by Rita Zhang.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig auth\r\n/area apiserver\r\n","date_published":"2023-06-13T14:42:06Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-2728","id":"CVE-2023-2728","status":"fixed","summary":"Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin","url":"https://github.com/kubernetes/kubernetes/issues/118640"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-2727","issue_number":118640},"content_text":"### CVE-2023-2727: Bypassing policies imposed by the ImagePolicyWebhook admission plugin\r\nCVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N)\r\n\r\nA security issue was discovered in Kubernetes where users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers.\r\n\r\n### Am I vulnerable?\r\nClusters are impacted by this vulnerability if all of the following are true:\r\n\r\n1. The ImagePolicyWebhook admission plugin is used to restrict use of certain images\r\n2. Pods are using ephemeral containers.\r\n\r\n### Affected Versions\r\n\r\n- kube-apiserver v1.27.0 - v1.27.2\r\n- kube-apiserver v1.26.0 - v1.26.5\r\n- kube-apiserver v1.25.0 - v1.25.10\r\n- kube-apiserver \u003c= v1.24.14\r\n\r\n### How do I mitigate this vulnerability?\r\nThis issue can be mitigated by applying the patch provided for the kube-apiserver component. This patch prevents ephemeral containers from using an image that is restricted by ImagePolicyWebhook. \r\n\r\nNote: Validation webhooks (such as [Gatekeeper](https://open-policy-agent.github.io/gatekeeper-library/website/validation/allowedrepos/) and [Kyverno](https://kyverno.io/policies/other/allowed-image-repos/allowed-image-repos/)) can also be used to enforce the same restrictions.\r\n\r\n### Fixed Versions\r\n\r\n- kube-apiserver v1.27.3\r\n- kube-apiserver v1.26.6\r\n- kube-apiserver v1.25.11\r\n- kube-apiserver v1.24.15\r\n\r\n### Detection\r\nPod update requests using an ephemeral container with an image that should have been restricted by an ImagePolicyWebhook will be captured in API audit logs. You can also use `kubectl get pods` to find active pods with ephemeral containers running an image that should have been restricted in your cluster with this issue.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Stanislav Láznička, and fixed by Rita Zhang.\r\n\r\n### CVE-2023-2728: Bypassing enforce mountable secrets policy imposed by the ServiceAccount admission plugin\r\nCVSS Rating: [CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N)\r\n\r\nA security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the `kubernetes.io/enforce-mountable-secrets` annotation are used together with ephemeral containers.\r\n\r\n### Am I vulnerable?\r\nClusters are impacted by this vulnerability if all of the following are true:\r\n\r\n1. The ServiceAccount admission plugin is used. Most cluster should have this on by default as recommended in [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount)\r\n2. The `kubernetes.io/enforce-mountable-secrets` annotation is used by a service account. This annotation is not added by default.\r\n3. Pods are using ephemeral containers.\r\n\r\n### Affected Versions\r\n\r\n- kube-apiserver v1.27.0 - v1.27.2\r\n- kube-apiserver v1.26.0 - v1.26.5\r\n- kube-apiserver v1.25.0 - v1.25.10\r\n- kube-apiserver \u003c= v1.24.14\r\n\r\n### How do I mitigate this vulnerability?\r\nThis issue can be mitigated by applying the patch provided for the kube-apiserver component. The patch prevents ephemeral containers from bypassing the mountable secrets policy enforced by the ServiceAccount admission plugin.\r\n\r\n### Fixed Versions\r\n- kube-apiserver v1.27.3\r\n- kube-apiserver v1.26.6\r\n- kube-apiserver v1.25.11\r\n- kube-apiserver v1.24.15\r\n\r\n### Detection\r\nPod update requests using an ephemeral container that exploits this vulnerability with unintended secret will be captured in API audit logs. You can also use kubectl get pods to find active pods with ephemeral containers running with a secret that is not referenced by the service account in your cluster.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Rita Zhang, and fixed by Rita Zhang.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig auth\r\n/area apiserver\r\n","date_published":"2023-06-13T14:42:06Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-2727","id":"CVE-2023-2727","status":"fixed","summary":"Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin","url":"https://github.com/kubernetes/kubernetes/issues/118640"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2023-2878","issue_number":118419},"content_text":"A security issue was discovered in [secrets-store-csi-driver](https://github.com/kubernetes-sigs/secrets-store-csi-driver) where an actor with access to the driver logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag.\r\n\r\nThis issue has been rated **MEDIUM** [CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) (6.5), and assigned **CVE-2023-2878**\r\n\r\n**Am I vulnerable?**\r\n\r\nYou may be vulnerable if [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag.\r\n\r\nTo check if token requests are configured, run the following command:\r\n\r\n```shell\r\nkubectl get csidriver secrets-store.csi.k8s.io -o jsonpath=\"{.spec.tokenRequests}\"\r\n```\r\n\r\nTo check if tokens are being logged, examine the secrets-store container log:\r\n\r\n```shell\r\nkubectl logs -l app=secrets-store-csi-driver -c secrets-store -f | grep --line-buffered \"csi.storage.k8s.io/serviceAccount.tokens\"\r\n```\r\n\r\n**Affected Versions**\r\n\r\n- secrets-store-csi-driver \u003c 1.3.3\r\n\r\n**How do I mitigate this vulnerability?**\r\n\r\nPrior to upgrading, this vulnerability can be mitigated by running secrets-store-csi-driver at log level 0 or 1 via the -v flag.\r\n\r\n**Fixed Versions**\r\n\r\n- secrets-store-csi-driver \u003e= 1.3.3\r\n\r\nTo upgrade, refer to the documentation: [https://secrets-store-csi-driver.sigs.k8s.io/getting-started/upgrades.html#upgrades](https://secrets-store-csi-driver.sigs.k8s.io/getting-started/upgrades.html#upgrades)\r\n\r\n**Detection**\r\n\r\nExamine cloud provider logs for unexpected token exchanges, as well as unexpected access to cloud vault secrets.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n**Acknowledgements**\r\n\r\nThis vulnerability was reported by Tomer Shaiman `@tshaiman` from Microsoft.\r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig auth","date_published":"2023-06-02T19:03:54Z","external_url":"https://www.cve.org/cverecord?id=CVE-2023-2878","id":"CVE-2023-2878","status":"fixed","summary":"secrets-store-csi-driver discloses service account tokens in logs","url":"https://github.com/kubernetes/kubernetes/issues/118419"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2022-3294","issue_number":113757},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)\r\n\r\nA security issue was discovered in Kubernetes where users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them.\r\n\r\nKubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. Bypassing this validation could allow authenticated requests destined for Nodes to to the API server's private network.\r\n\r\n### Am I vulnerable?\r\n\r\nClusters are affected by this vulnerability if there are endpoints that the kube-apiserver has connectivity to that users should not be able to access. This includes:\r\n\r\n- kube-apiserver is in a separate network from worker nodes\r\n- localhost services\r\n\r\nmTLS services that accept the same client certificate as nodes may be affected. The severity of this issue depends on the privileges \u0026 sensitivity of the exploitable endpoints.\r\n\r\nClusters that configure the egress selector to use a proxy for cluster traffic may not be affected.\r\n\r\n\r\n#### Affected Versions\r\n\r\n- Kubernetes kube-apiserver \u003c= v1.25.3\r\n- Kubernetes kube-apiserver \u003c= v1.24.7\r\n- Kubernetes kube-apiserver \u003c= v1.23.13\r\n- Kubernetes kube-apiserver \u003c= v1.22.15\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nUpgrading the **kube-apiserver** to a fixed version mitigates this vulnerability.\r\n\r\nAside from upgrading, configuring an [egress proxy for egress to the cluster network](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) can mitigate this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- Kubernetes kube-apiserver v1.25.4\r\n- Kubernetes kube-apiserver v1.24.8\r\n- Kubernetes kube-apiserver v1.23.14\r\n- Kubernetes kube-apiserver v1.22.16\r\n\r\n**Fix impact:** In some cases, the fix can break clients that depend on the nodes/proxy subresource, specifically if a kubelet advertises a localhost or link-local address to the Kubernetes control plane.\r\n\r\n### Detection\r\n\r\nNode create \u0026 update requests may be included in the Kubernetes audit log, and can be used to identify requests for IP addresses that should not be permitted. Node proxy requests may also be included in audit logs.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Yuval Avrahami of Palo Alto Networks.\r\n\r\n\u003c!-- labels --\u003e\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig api-machinery\r\n/area apiserver","date_published":"2022-11-08T21:33:26Z","external_url":"https://www.cve.org/cverecord?id=CVE-2022-3294","id":"CVE-2022-3294","status":"fixed","summary":"Node address isn't always verified when proxying","url":"https://github.com/kubernetes/kubernetes/issues/113757"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2022-3162","issue_number":113756},"content_text":"CVSS Rating: [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)\r\n\r\nA security issue was discovered in Kubernetes where users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization.\r\n\r\n### Am I vulnerable?\r\n\r\nClusters are impacted by this vulnerability if all of the following are true:\r\n- There are 2+ CustomResourceDefinitions sharing the same API group\r\n- Users have cluster-wide list or watch authorization on one of those custom resources.\r\n- The same users are not authorized to read another custom resource in the same API group.\r\n\r\n#### Affected Versions\r\n\r\n- Kubernetes kube-apiserver \u003c= v1.25.3\r\n- Kubernetes kube-apiserver \u003c= v1.24.7\r\n- Kubernetes kube-apiserver \u003c= v1.23.13\r\n- Kubernetes kube-apiserver \u003c= v1.22.15\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nUpgrading the kube-apiserver to a fixed version mitigates this vulnerability.\r\n\r\nPrior to upgrading, this vulnerability can be mitigated by avoiding granting cluster-wide list and watch permissions.\r\n\r\n#### Fixed Versions\r\n\r\n- Kubernetes kube-apiserver v1.25.4\r\n- Kubernetes kube-apiserver v1.24.8\r\n- Kubernetes kube-apiserver v1.23.14\r\n- Kubernetes kube-apiserver v1.22.16\r\n\r\n### Detection\r\n\r\nRequests containing `..` in the request path are a likely indicator of exploitation. Request paths may be captured in API audit logs, or in kube-apiserver HTTP logs.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Richard Turnbull of NCC Group as part of the Kubernetes Audit.\r\n\r\n\u003c!-- labels --\u003e\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig api-machinery\r\n/area apiserver\r\n","date_published":"2022-11-08T21:33:07Z","external_url":"https://www.cve.org/cverecord?id=CVE-2022-3162","id":"CVE-2022-3162","status":"fixed","summary":"Unauthorized read of Custom Resources","url":"https://github.com/kubernetes/kubernetes/issues/113756"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2022-3172","issue_number":112513},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:L/A:L) (5.1, medium)\r\n\r\nA security issue was discovered in kube-apiserver that allows an aggregated API server to redirect client traffic to any URL. This could lead to the client performing unexpected actions as well as forwarding the client's API server credentials to third parties.\r\n\r\nThis issue has been rated medium and assigned CVE-2022-3172\r\n\r\n### Am I vulnerable?\r\n\r\nAll Kubernetes clusters with the following versions that are running aggregated API servers are impacted. To identify if you have aggregated API servers configured, run the following command:\r\n\r\n```shell\r\nkubectl get apiservices.apiregistration.k8s.io -o=jsonpath='{range .items[?(@.spec.service)]}{.metadata.name}{\"\\n\"}{end}'\r\n```\r\n\r\n#### Affected Versions\r\n\r\n- kube-apiserver v1.25.0\r\n- kube-apiserver v1.24.0 - v1.24.4\r\n- kube-apiserver v1.23.0 - v1.23.10\r\n- kube-apiserver v1.22.0 - v1.22.13\r\n- kube-apiserver \u003c= v1.21.14\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nAside from upgrading, no direct mitigation is available.\r\n\r\nAggregated API servers are a trusted part of the Kubernetes control plane, and configuring them is a privileged administrative operation. Ensure that only trusted cluster administrators are allowed to create or modify `APIService` configuration, and follow security best practices with any aggregated API servers that may be in use.\r\n\r\n#### Fixed Versions\r\n\r\n- kube-apiserver v1.25.1 - fixed by #112330\r\n- kube-apiserver v1.24.5 - fixed by #112331\r\n- kube-apiserver v1.23.11 - fixed by #112358\r\n- kube-apiserver v1.22.14 - fixed by #112359\r\n\r\n**Fix impact:** The fix blocks all 3XX responses from aggregated API servers by default. This may disrupt an aggregated API server that relies on redirects as part of its normal function. If all current and future aggregated API servers are considered trustworthy and redirect functionality is required, set the `--aggregator-reject-forwarding-redirect` Kubernetes API server flag to `false` to restore the previous behavior.\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade\r\n\r\n### Detection\r\n\r\nKubernetes audit log events indicate the HTTP status code sent to the client via the `responseStatus.code` field. This can be used to detect if an aggregated API server is redirecting clients.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Nicolas Joly \u0026 Weinong Wang @weinong from Microsoft.\r\n\r\nThe issue was fixed and coordinated by Di Jin @jindijamie @enj @liggitt @lavalamp @deads2k and @puerco.\r\n\r\n/area security\r\n/kind bug\r\n/committee security-response\r\n/label official-cve-feed\r\n/sig api-machinery\r\n/area apiserver\r\n/triage accepted","date_published":"2022-09-16T13:14:50Z","external_url":"https://www.cve.org/cverecord?id=CVE-2022-3172","id":"CVE-2022-3172","status":"fixed","summary":"Aggregated API server can cause clients to be redirected (SSRF)","url":"https://github.com/kubernetes/kubernetes/issues/112513"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25749","issue_number":112192},"content_text":"A security issue was discovered in Kubernetes that could allow Windows workloads to run as `ContainerAdministrator` even when those workloads set the `runAsNonRoot` option to `true`.\r\n\r\nThis issue has been rated low and assigned CVE-2021-25749\r\n\r\n### Am I vulnerable?\r\n\r\nAll Kubernetes clusters with following versions, running Windows workloads with `runAsNonRoot` are impacted\r\n\r\n#### Affected Versions\r\n\r\n- kubelet v1.20 - v1.21\r\n- kubelet v1.22.0 - v1.22.13\r\n- kubelet v1.23.0 - v1.23.10\r\n- kubelet v1.24.0 - v1.24.4\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThere are no known mitigations to this vulnerability.\r\n\r\n#### Fixed Versions\r\n\r\n- kubelet v1.22.14\r\n- kubelet v1.23.11\r\n- kubelet v1.24.5\r\n- kubelet v1.25.0\r\n\r\n\r\nTo upgrade, refer to this documentation _For core Kubernetes:_ https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/\r\n\r\n### Detection\r\n\r\nKubernetes Audit logs may indicate if the user name was misspelled to bypass the restriction placed on which user is a pod allowed to run as.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Additional Details\r\n\r\nSee the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/112192 \r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported and fixed by Mark Rosetti (@marosset)\r\n","date_published":"2022-09-01T21:02:01Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25749","id":"CVE-2021-25749","status":"fixed","summary":"`runAsNonRoot` logic bypass for Windows containers","url":"https://github.com/kubernetes/kubernetes/issues/112192"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25748","issue_number":126814},"content_text":"### Issue Details\r\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where a user that can create or update ingress objects can use a newline character to bypass the sanitization of the `spec.rules[].http.paths[].path` field of an Ingress object (in the `networking.k8s.io` or `extensions` API group) to obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.\r\n\r\nThis issue has been rated High ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)), and assigned CVE-2021-25748.\r\n\r\n### Affected Components and Configurations\r\nThis bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`.\r\n\r\nIf you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), you are not affected.\r\n\r\nMultitenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.\r\n\r\n#### Affected Versions\r\n\u003cv1.2.1\r\n\r\n#### Fixed Versions\r\nv1.2.1\r\n\r\n### Mitigation\r\nIf you are unable to roll out the fix, this vulnerability can be mitigated by implementing an admission policy that restricts the `spec.rules[].http.paths[].path` field on the networking.k8s.io/Ingress resource to known safe characters (see the newly added [rules](https://github.com/kubernetes/ingress-nginx/blame/main/internal/ingress/inspector/rules.go), or the suggested value for [annotation-value-word-blocklist](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#annotation-value-word-blocklist)).\r\n\r\n### Detection\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n### Additional Details\r\nSee ingress-nginx Issue [#8686](https://github.com/kubernetes/kubernetes/issues/126814) for more details.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Gafnit Amiga.\r\n\r\nThank You,\r\nCJ Cullen on behalf of the Kubernetes Security Response Committee","date_published":"2022-06-10T16:01:41Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25748","id":"CVE-2021-25748","status":"fixed","summary":"Ingress-nginx `path` sanitization can be bypassed with newline character","url":"https://github.com/kubernetes/kubernetes/issues/126814"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25746","issue_number":126813},"content_text":"### Issue Details\r\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where a user that can create or update ingress objects can use `.metadata.annotations` in an Ingress object (in the `networking.k8s.io` or `extensions` API group) to obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.\r\n\r\nThis issue has been rated **High** ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)), and assigned **CVE-2021-25746**.\r\n\r\n### Affected Components and Configurations\r\nThis bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`.\r\n\r\nMultitenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.\r\n\r\n#### Affected Versions\r\n- \u003cv1.2.0\r\n\r\n#### Fixed Versions\r\n- v1.2.0-beta.0\r\n- v1.2.0\r\n\r\n### Mitigation\r\nIf you are unable to roll out the fix, this vulnerability can be mitigated by implementing an admission policy that restricts the `metadata.annotations` values to known safe (see the newly added [rules](https://github.com/kubernetes/ingress-nginx/blame/main/internal/ingress/inspector/rules.go), or the suggested value for [annotation-value-word-blocklist](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#annotation-value-word-blocklist)).\r\n\r\n### Detection\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\n\r\n### Additional Details\r\nSee ingress-nginx Issue [#8503](https://github.com/kubernetes/kubernetes/issues/126813) for more details.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Anthony Weems, and separately by jeffrey\u0026oliver.\r\n\r\nThank You,\r\nCJ Cullen on behalf of the Kubernetes Security Response Committee","date_published":"2022-04-22T16:18:27Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25746","id":"CVE-2021-25746","status":"fixed","summary":"Ingress-nginx directive injection via annotations","url":"https://github.com/kubernetes/kubernetes/issues/126813"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25745","issue_number":126812},"content_text":"### Issue Details\r\nA security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where a user that can create or update ingress objects can use the `spec.rules[].http.paths[].path` field of an Ingress object (in the `networking.k8s.io` or `extensions` API group) to obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.\r\n\r\nThis issue has been rated **High** ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)), and assigned **CVE-2021-25745**.\r\n\r\n### Affected Components and Configurations\r\nThis bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running `kubectl get po -n ingress-nginx`.\r\n\r\nMultitenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.\r\n\r\n#### Affected Versions\r\n- \u003cv1.2.0\r\n\r\n#### Fixed Versions\r\n- v1.2.0-beta.0\r\n- v1.2.0\r\n\r\n### Mitigation\r\nIf you are unable to roll out the fix, this vulnerability can be mitigated by implementing an admission policy that restricts the `spec.rules[].http.paths[].path` field on the `networking.k8s.io/Ingress` resource to known safe characters (see the newly added [rules](https://github.com/kubernetes/ingress-nginx/blame/main/internal/ingress/inspector/rules.go), or the suggested value for [annotation-value-word-blocklist](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#annotation-value-word-blocklist)).\r\n\r\n### Detection\r\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](mailto:security@kubernetes.io)\r\nAdditional Details\r\nSee ingress-nginx Issue [#8502](https://github.com/kubernetes/kubernetes/issues/126812) for more details.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Gafnit Amiga.\r\n\r\nThank You,\r\nCJ Cullen on behalf of the Kubernetes Security Response Committee","date_published":"2022-04-22T16:18:21Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25745","id":"CVE-2021-25745","status":"fixed","summary":"Ingress-nginx `path` can be pointed to service account token file","url":"https://github.com/kubernetes/kubernetes/issues/126812"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25742","issue_number":126811},"content_text":"### Issue Details\r\nA security issue was discovered in ingress-nginx where a user that can create or update ingress objects can use the custom snippets feature to obtain all secrets in the cluster.\r\n\r\nThis issue has been rated **High** ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L)), and assigned **CVE-2021-25742**.\r\n\r\n### Affected Components and Configurations\r\nThis bug affects ingress-nginx.\r\n\r\nMultitenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.\r\n\r\n#### Affected Versions with no mitigation\r\n\r\n- v1.0.0\r\n- \u003c= v0.49.0\r\n\r\n#### Versions allowing mitigation\r\nThis issue cannot be fixed solely by upgrading ingress-nginx. It can be mitigated in the following versions:\r\n- v1.0.1\r\n- v0.49.1\r\n\r\n### Mitigation\r\nTo mitigate this vulnerability:\r\n1. Upgrade to a version that allows mitigation, (\u003e= v0.49.1 or \u003e= v1.0.1)\r\n2. Set [allow-snippet-annotations](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#allow-snippet-annotations) to false in your ingress-nginx ConfigMap based on how you deploy ingress-nginx:\r\n\r\n **Static Deploy Files** \r\n Edit the ConfigMap for ingress-nginx **after** deployment:\r\n ```\r\n kubectl edit configmap -n ingress-nginx ingress-nginx-controller\r\n ```\r\n Add directive:\r\n ````\r\n data:\r\n allow-snippet-annotations: “false”\r\n ````\r\n More information on the ConfigMap [here](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/) \r\n\r\n **Deploying Via Helm**\r\n Set `controller.allowSnippetAnnotations` to `false` in the Values.yaml or add the directive to the helm deploy:\r\n ```\r\n helm install [RELEASE_NAME] --set controller.allowSnippetAnnotations=false ingress-nginx/ingress-nginx\r\n ````\r\n\r\n [https://github.com/kubernetes/ingress-nginx/blob/controller-v1.0.1/charts/ingress-nginx/values.yaml#L76](https://github.com/kubernetes/ingress-nginx/blob/controller-v1.0.1/charts/ingress-nginx/values.yaml#L76)\r\n\r\n### Detection\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\nAdditional Details\r\nSee ingress-nginx Issue kubernetes/kubernetes#126811 for more details.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Mitch Hulscher.\r\n\r\nThank You,\r\nCJ Cullen on behalf of the Kubernetes Security Response Committee\r\n","date_published":"2021-10-21T16:08:21Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25742","id":"CVE-2021-25742","status":"fixed","summary":"Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces","url":"https://github.com/kubernetes/kubernetes/issues/126811"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25741","issue_number":104980},"content_text":"A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files \u0026 directories outside of the volume, including on the host filesystem.\r\n\r\nThis issue has been rated **High** ([CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)), and assigned **CVE-2021-25741**.\r\n\r\n### Affected Components and Configurations\r\nThis bug affects kubelet.\r\n\r\n\r\nEnvironments where cluster administrators have restricted the ability to create hostPath mounts are the most seriously affected. Exploitation allows hostPath-like access without use of the hostPath feature, thus bypassing the restriction. \r\n\r\n\r\nIn a default Kubernetes environment, exploitation could be used to obscure misuse of already-granted privileges.\r\n\r\n#### Affected Versions\r\nv1.22.0 - v1.22.1\r\n\r\nv1.21.0 - v1.21.4\r\n\r\nv1.20.0 - v1.20.10\r\n\r\n\u003c= v1.19.14\r\n\r\n#### Fixed Versions\r\nThis issue is fixed in the following versions:\r\n\r\nv1.22.2\r\n\r\nv1.21.5\r\n\r\nv1.20.11\r\n\r\nv1.19.15\r\n\r\n### Mitigation\r\nTo mitigate this vulnerability without upgrading kubelet, you can disable the VolumeSubpath feature gate on kubelet and kube-apiserver, and remove any existing Pods making use of the feature.\r\n\r\n\r\nYou can also use admission control to prevent less-trusted users from running containers as root to reduce the impact of successful exploitation.\r\n\r\n### Detection\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n### Additional Details\r\nSee Kubernetes Issue #104980 for more details.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Fabricio Voznika and Mark Wolters of Google.\r\n\r\n\r\nThanks as well to Ian Coldwater, Duffie Cooley, Brad Geesaman, and Rory McCune for the thorough security research that led to the discovery of this vulnerability.","date_published":"2021-09-13T20:58:56Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25741","id":"CVE-2021-25741","status":"fixed","summary":"Symlink Exchange Can Allow Host Filesystem Access","url":"https://github.com/kubernetes/kubernetes/issues/104980"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8561","issue_number":104720},"content_text":"A security issue was discovered in Kubernetes where actors that control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the apiserver. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.\r\n\r\nThis issue has been rated **Medium** (https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) (4.1), and assigned **CVE-2020-8561**\r\n\r\n### Am I vulnerable?\r\n\r\nYou may be vulnerable if `--profiling` is enabled on the kube-apiserver and actors who control a validating or mutating webhook can access the kube-apiserver process logs.\r\n\r\n#### Affected Versions\r\n\r\nThis issue affects all known versions of kube-apiserver. \r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nThis issue can be mitigated by not allowing kube-apiserver access to sensitive resources or networks, or to reduce the “-v” flag value to less than 10 and set the “--profiling” flag value to “false” (default value is “true”). Setting the profiling flag to “false” prevents users from dynamically modifying the kube-apiserver log level, and the flag value Webhook requests may still be redirected to private networks with a log level less than 10, but the response body will not be logged.\r\n\r\n### Fixed Versions\r\nThere is no fix for this issue at this time.\r\n\r\n### Detection\r\n\r\nExamining kube-apiserver log responses is the only known method of detection for this issue.\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by QiQi Xu\r\n\r\n\r\n/triage accepted\r\n/lifecycle frozen\r\n/area security\r\n/kind bug\r\n/committee security-response","date_published":"2021-09-01T20:18:50Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8561","id":"CVE-2020-8561","status":"open","summary":"Webhook redirect in kube-apiserver","url":"https://github.com/kubernetes/kubernetes/issues/104720"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25740","issue_number":103675},"content_text":"A security issue was discovered with Kubernetes that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack. \r\n\r\nThis issue has been rated **Low** severity ([CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N)), and assigned **CVE-2021-25740**.\r\n### Am I vulnerable?\r\nIf a potential attacker can create or edit Endpoints or EndpointSlices in the Kubernetes API, they can potentially direct a LoadBalancer or Ingress implementation to expose backend IPs the attacker should not have access to.\r\nImportantly, if the target’s NetworkPolicy already trusts the Load Balancer or Ingress implementation, NetworkPolicy can not be used to prevent exposure from other namespaces, potentially bypassing any security controls such as LoadBalancerSourceRanges.\r\nThis issue is a design flaw that cannot be fully mitigated without user-facing changes. With this public announcement, we can begin conversations about a long-term fix.\r\n#### Affected Versions\r\nAll Kubernetes versions are affected. \r\n### How do I mitigate this vulnerability?\r\nThere is no patch for this issue, and it can currently only be mitigated by restricting access to the vulnerable features. To mitigate the exposure, we recommend restricting write access to Endpoints and EndpointSlices by updating the system:aggregate-to-edit role using the [attached file](https://github.com/kubernetes/kubernetes/files/6823580/aggregate_to_edit_no_endpoints.yaml.txt). This will remove write access to Endpoints from the admin and edit roles:\r\n\r\n```shell\r\n# Allow kubectl auth reconcile to work\r\nkubectl annotate --overwrite clusterrole/system:aggregate-to-edit rbac.authorization.kubernetes.io/autoupdate=true\r\n\r\n# Test reconcile, then run for real if happy\r\nkubectl auth reconcile --remove-extra-permissions -f aggregate_to_edit_no_endpoints.yaml.txt --dry-run\r\nkubectl auth reconcile --remove-extra-permissions -f aggregate_to_edit_no_endpoints.yaml.txt\r\n\r\n# Prevent autoreconciliation back to old state\r\nkubectl annotate --overwrite clusterrole/system:aggregate-to-edit rbac.authorization.kubernetes.io/autoupdate=false\r\n```\r\n\r\nNote: This will prevent new versions of Kubernetes from reconciling new default permissions to this role. No new default permissions have been added to this role since v1.14.0, but we recommend you remove the autoupdate=false annotation as soon as a fix or other mitigation is possible.\r\n\r\nFor use-cases that need to edit these resources, we recommend creating a new purpose-built Role with the desired permissions, and using it only for those cases.\r\n### Detection\r\nServices with an empty selector rely on custom endpoints and are vulnerable to the attack described above. We recommend manually auditing any such usage. The following kubectl command will list all Services in a cluster with their selector:\r\n```\r\nkubectl get svc --all-namespaces -o=custom-columns='NAME:metadata.name,NAMESPACE:metadata.namespace,SELECTOR:spec.selector'\r\n```\r\n\r\nNote: Some Services without selectors specified may have their Endpoints managed by other controllers or tools. For example, endpoints for the default/kubernetes Service are managed by the Kubernetes API Server. \r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io \r\n#### Additional Advisory\r\nA similar attack is possible using Ingress implementations that support forwarding to ExternalName Services. This can be used to forward to Services in other namespaces or, in some cases, sensitive endpoints within the Ingress implementation. If you are using the Ingress API, we recommend confirming that the implementation you’re using either does not support forwarding to ExternalName Services or supports disabling the functionality.\r\n#### Additional Details\r\nSee the GitHub issue for more updates: https://github.com/kubernetes/kubernetes/issues/103675 \r\n \r\nThank You,\r\nRob Scott on behalf of Kubernetes SIG Network and CJ Cullen on behalf of the Kubernetes Product Security Committee\r\n","date_published":"2021-07-14T03:30:07Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25740","id":"CVE-2021-25740","status":"unknown","summary":"Endpoint \u0026 EndpointSlice permissions allow cross-Namespace forwarding","url":"https://github.com/kubernetes/kubernetes/issues/103675"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25737","issue_number":102106},"content_text":"#### Issue Details\r\nA security issue was discovered in Kubernetes where a user may be able to redirect pod traffic to private networks on a Node. Kubernetes already prevents creation of Endpoint IPs in the localhost or link-local range, but the same validation was not performed on EndpointSlice IPs. \r\nThis issue has been rated Low ([CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N)), and assigned CVE-2021-25737.\r\nAffected Component\r\nkube-apiserver\r\n\r\n#### Affected Versions\r\nv1.21.0\r\nv1.20.0 - v1.20.6\r\nv1.19.0 - v1.19.10\r\nv1.16.0 - v1.18.18 (Note: EndpointSlices were not enabled by default in 1.16-1.18)\r\n#### Fixed Versions\r\nThis issue is fixed in the following versions:\r\nv1.21.1\r\nv1.20.7\r\nv1.19.11\r\nv1.18.19\r\n#### Mitigation\r\nTo mitigate this vulnerability without upgrading kube-apiserver, you can create a validating admission webhook that prevents EndpointSlices with endpoint addresses in the 127.0.0.0/8 and 169.254.0.0/16 ranges. If you have an existing admission policy mechanism (like OPA Gatekeeper) you can create a policy that enforces this restriction.\r\n#### Detection\r\nTo detect whether this vulnerability has been exploited, you can list EndpointSlices and check for endpoint addresses in the 127.0.0.0/8 and 169.254.0.0/16 ranges.\r\n \r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n#### Acknowledgements\r\nThis vulnerability was reported by John Howard of Google.\r\n","date_published":"2021-05-18T19:14:27Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25737","id":"CVE-2021-25737","status":"fixed","summary":"Holes in EndpointSlice Validation Enable Host Network Hijack","url":"https://github.com/kubernetes/kubernetes/issues/102106"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8562","issue_number":101493},"content_text":"CVSS Rating: **Low** ([CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N))\r\n\r\nA security issue was discovered in Kubernetes where an authorized user may be able to access private networks on the Kubernetes control plane components. Kubernetes clusters are only affected if an untrusted user can create or modify Node objects and proxy to them, or an untrusted user can create or modify StorageClass objects and access KubeControllerManager logs. \r\n\r\nThis issue has been rated Low (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N) and assigned CVE-2020-8562.\r\n \r\nAs mitigations to a report from 2019 and CVE-2020-8555, Kubernetes attempts to prevent proxied connections from accessing link-local or localhost networks when making user-driven connections to Services, Pods, Nodes, or StorageClass service providers. As part of this mitigation Kubernetes does a DNS name resolution check and validates that response IPs are not in the link-local (169.254.0.0/16) or localhost (127.0.0.0/8) range. Kubernetes then performs a second DNS resolution without validation for the actual connection. If a non-standard DNS server returns different non-cached responses, a user may be able to bypass the proxy IP restriction and access private networks on the control plane.\r\n\r\n### Affected Versions:\r\nAll versions of Kubernetes are affected\r\n\r\n### Fixed Versions\r\nThere is no fix for this issue at this time.\r\n\r\n### Mitigations\r\nIf this issue affects your clusters’ control planes, you can use dnsmasq for name resolution and configure the min-cache-ttl and neg-ttl parameters to a low non-zero value to enforce cached replies for proxied connections. \r\n\r\n### Detection\r\nThis issue is not known to be directly detectable, but proxied calls will appear in the Kubernetes API Audit log. Kubernetes will respond with “address not allowed” when the validation successfully prevents a connection.\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by Javier Provecho (Telefonica).\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/triage accepted","date_published":"2021-04-26T19:18:04Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8562","id":"CVE-2020-8562","status":"unknown","summary":"Bypass of Kubernetes API Server proxy TOCTOU","url":"https://github.com/kubernetes/kubernetes/issues/101493"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-3121","issue_number":101435},"content_text":"### Issue Details\r\n\r\nA security issue was discovered in code generated by the gogo protobuf compiler used by Kubernetes. The gogo protobuf compiler issue has been assigned CVE-2021-3121 and is also known as the “skippy peanut butter bug”.\r\n\r\nA program which uses affected code to handle a malicious protobuf message could panic.\r\nThe Kubernetes Product Security Committee has tested the API server using a malicious message, and we believe that **there is no security impact to Kubernetes**. When an authenticated user sent the malicious message to the API server, a panic occurred. However, the panic handler recovered and the API server continued without interruption (except to the malicious requestor, who received no response).\r\n\r\nGenerated protobuf files are part of several Kubernetes repositories, and any downstream projects which vendor in these repos should evaluate whether there is any security impact to their project.\r\n\r\n### Affected Components and Configurations\r\n\r\nAny golang components which use handler code created by the gogo protbuf compiler, which accept protobuf messages and do not gracefully handle panics in the unmarshalling codepath may be affected.\r\n\r\nThe following Linux command can be used to detect affected generated code within a codebase:\r\n\r\n```\r\nfind . -name '*.pb.go' | \\\r\nxargs -r grep -l 'if skippy \u003c 0' | \\\r\nxargs -r awk -e '/if skippy \u003c 0/ {a=4} /if \\(iNdEx \\+ skippy\\) \u003e postIndex/ \u0026\u0026' \\\r\n \t -e 'a\u003e0 {print FILENAME \" \" FNR \": \" $0 \" // vulnerable to CVE-2021-3121\"} {a--}'\r\n```\r\n\r\nAlthough we do not believe there is any security impact to Kubernetes, we have updated all generated protobufs out of an abundance of caution and as a courtesy to any downstream consumers who may be affected. The following PRs addressed this issue in Kubernetes:\r\n\r\nMaster branch: #98477, #101306\r\n1.21 branch: #98477 (in 1.21.0), #101325 (in 1.21.1)\r\n1.20 branch: #100501 (in 1.20.6), #101326 (in 1.20.7)\r\n1.19 branch: #100515 (in 1.19.10), #101327 (in 1.19.11)\r\n1.18 branch: #100514 (in 1.18.18), #101335 (in 1.18.19)\r\n\r\nFor other generated protobuf go handlers, the issue can be remediated by upgrading the gogo protobuf compiler to a fixed version (v1.3.2 or later), then regenerating affected protobuf code with the updated protobuf compiler. \r\n\r\n### Mitigations\r\n\r\nDisabling support for protobuf messages may be one possible mitigation for any affected product.\r\n\r\nAlso, graceful panic handling in message handlers mitigates the bug.\r\n\r\n### Detection\r\n\r\nIf you use generated protobuf code in a product and you observe a process exiting with messages similar to the following, a malicious user may be exploiting this defect:\r\n\r\n```\r\npanic: runtime error: index out of range [-9223372036854775804]\r\n \r\ngoroutine 1 [running]:\r\nv1.(*MessageName).Unmarshal(0xc000057ef8, 0xc0000161a0, 0xa, 0x10, 0xc000057ec8, 0x1)\r\n .../protofile.pb.go:250 +0xb86\r\n```\r\n\r\n### References\r\n- CVE-2021-3121: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3121\r\n- GoGo Protobuf v1.3.2: https://github.com/gogo/protobuf/releases/tag/v1.3.2\r\n","date_published":"2021-04-23T18:07:32Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-3121","id":"CVE-2021-3121","status":"fixed","summary":"Processes may panic upon receipt of malicious protobuf messages","url":"https://github.com/kubernetes/kubernetes/issues/101435"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2021-25735","issue_number":100096},"content_text":"A security issue was discovered in kube-apiserver that could allow node updates to bypass a Validating Admission Webhook. You are only affected by this vulnerability if you run a Validating Admission Webhook for Nodes that denies admission based at least partially on the old state of the Node object.\r\n\r\nThis issue has been rated **Medium** ([CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H)), and assigned **CVE-2021-25735**.\r\n\r\n**Note:** This only impacts validating admission plugins that rely on old values in certain fields, and does not impact calls from kubelets that go through the built-in NodeRestriction admission plugin.\r\n\r\n#### Affected Versions\r\n\r\n- kube-apiserver v1.20.0 - v1.20.5\r\n- kube-apiserver v1.19.0 - v1.19.9\r\n- kube-apiserver \u003c= v1.18.17\r\n\r\n#### Fixed Versions\r\n\r\nThis issue is fixed in the following versions:\r\n- kube-apiserver v1.21.0 - Fixed by https://github.com/kubernetes/kubernetes/pull/99946\r\n- kube-apiserver v1.20.6 - Fixed by https://github.com/kubernetes/kubernetes/pull/100315\r\n- kube-apiserver v1.19.10 - Fixed by https://github.com/kubernetes/kubernetes/pull/100316\r\n- kube-apiserver v1.18.18 - Fixed by https://github.com/kubernetes/kubernetes/pull/100317\r\n\r\n#### Detection\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Rogerio Bastos \u0026 Ari Lima from RedHat\r\n","date_published":"2021-03-10T18:18:01Z","external_url":"https://www.cve.org/cverecord?id=CVE-2021-25735","id":"CVE-2021-25735","status":"fixed","summary":"Validating Admission Webhook does not observe some previous fields","url":"https://github.com/kubernetes/kubernetes/issues/100096"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8554","issue_number":97076},"content_text":"CVSS Rating: **Medium** ([CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L))\r\n \r\nThis issue affects multitenant clusters. If a potential attacker can already create or edit services and pods, then they may be able to intercept traffic from other pods (or nodes) in the cluster.\r\n \r\nAn attacker that is able to create a ClusterIP service and set the spec.externalIPs field can intercept traffic to that IP. An attacker that is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.\r\nThis issue is a design flaw that cannot be mitigated without user-facing changes.\r\n### Affected Components and Configurations\r\n\r\nAll Kubernetes versions are affected. Multi-tenant clusters that grant tenants the ability to create and update services and pods are most vulnerable.\r\n### Mitigations\r\n\r\nThere is no patch for this issue, and it can currently only be mitigated by restricting access to the vulnerable features. Because an in-tree fix would require a breaking change, we will open a conversation about a longer-term fix or built-in mitigation after the embargo is lifted\r\n\r\nTo restrict the use of external IPs we are providing an admission webhook container: k8s.gcr.io/multitenancy/externalip-webhook:v1.0.0. The source code and deployment instructions are published at https://github.com/kubernetes-sigs/externalip-webhook.\r\n\r\nAlternatively, external IPs can be restricted using [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper). A sample ConstraintTemplate and Constraint can be found here: https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/general/externalip.\r\n\r\nNo mitigations are provided for LoadBalancer IPs since we do not recommend granting users *patch service/status* permission. If LoadBalancer IP restrictions are required, the approach for the external IP mitigations can be copied.\r\n### Detection\r\n\r\nExternalIP services are not widely used, so we recommend manually auditing any external IP usage. Users should not patch service status, so audit events for patch service status requests authenticated to a user may be suspicious.\r\n \r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Etienne Champetier (@champtar) of Anevia.\r\n \r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig network\r\n","date_published":"2020-12-04T20:02:15Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8554","id":"CVE-2020-8554","status":"unknown","summary":"Man in the middle using LoadBalancer or ExternalIPs","url":"https://github.com/kubernetes/kubernetes/issues/97076"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8566","issue_number":95624},"content_text":"CVSS Rating: 4.7 CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (Medium)\r\n\r\nIn Kubernetes clusters using Ceph RBD as a storage provisioner, with logging level of at least 4, Ceph RBD admin secrets can be written to logs. This occurs in kube-controller-manager's logs during provisioning of Ceph RBD persistent claims.\r\n\r\n### Am I vulnerable?\r\nIf Ceph RBD volumes are in use and kube-controller-manager is using a log level of at least 4.\r\n\r\n#### Affected Versions\r\nkubernetes v1.19.0 - v1.19.2\r\nkubernetes v1.18.0 - v1.18.9\r\nkubernetes v1.17.0 - v1.17.12\r\n\r\n### How do I mitigate this vulnerability?\r\nDo not enable verbose logging in production, limit access to logs.\r\n\r\n#### Fixed Versions\r\nv1.19.3\r\nv1.18.10\r\nv1.17.13\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by: Kaizhe Huang (derek0405)\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n","date_published":"2020-10-15T22:07:53Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8566","id":"CVE-2020-8566","status":"fixed","summary":"Ceph RBD adminSecrets exposed in logs when loglevel \u003e= 4","url":"https://github.com/kubernetes/kubernetes/issues/95624"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8565","issue_number":95623},"content_text":"CVSS Rating: 4.7 CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (Medium)\r\n\r\nIn Kubernetes, if the logging level is to at least 9, authorization and bearer tokens will be written to log files. This can occur both in API server logs and client tool output like `kubectl`.\r\n\r\n### Am I vulnerable?\r\nIf kube-apiserver is using a log level of at least 9.\r\n\r\n#### Affected Versions\r\nkubernetes v1.19.0 - v1.19.5\r\nkubernetes v1.18.0 - v1.18.13\r\nkubernetes v1.17.0 - v1.17.15\r\n\r\n### How do I mitigate this vulnerability?\r\nDo not enable verbose logging in production, limit access to logs.\r\n\r\n#### Fixed Versions\r\nkubernetes v1.20.0\r\nkubernetes v1.19.6 \r\nkubernetes v1.18.14 \r\nkubernetes v1.17.16\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by: Patrick Rhomberg (purelyapplied)\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n","date_published":"2020-10-15T22:05:32Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8565","id":"CVE-2020-8565","status":"fixed","summary":"Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel \u003e= 9","url":"https://github.com/kubernetes/kubernetes/issues/95623"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8564","issue_number":95622},"content_text":"CVSS Rating: 4.7 CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (Medium)\r\n\r\nIn Kubernetes clusters using a logging level of at least 4, processing a malformed docker config file will result in the contents of the docker config file being leaked, which can include pull secrets or other registry credentials.\r\n\r\n### Am I vulnerable?\r\nIf kubernetes.io/dockerconfigjson type secrets are used, and a log level of 4 or higher is used. Third party tools using k8s.io/kubernetes/pkg/credentialprovider to read docker config files may also be vulnerable.\r\n\r\n#### Affected Versions\r\nkubernetes v1.19.0 - v1.19.2\r\nkubernetes v1.18.0 - v1.18.9\r\nkubernetes v1.17.0 - v1.17.12\r\n\r\n### How do I mitigate this vulnerability?\r\nDo not enable verbose logging in production, limit access to logs.\r\n\r\n#### Fixed Versions\r\nv1.19.3\r\nv1.18.10\r\nv1.17.13\r\n\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n#### Acknowledgements\r\nThis vulnerability was reported by: Nikolaos Moraitis (Red Hat)\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n","date_published":"2020-10-15T22:03:19Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8564","id":"CVE-2020-8564","status":"fixed","summary":"Docker config secrets leaked when file is malformed and log level \u003e= 4","url":"https://github.com/kubernetes/kubernetes/issues/95622"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8563","issue_number":95621},"content_text":"CVSS Rating: 5.6 CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N (Medium)\r\n\r\nIn Kubernetes clusters using VSphere as a cloud provider, with a logging level set to 4 or above, VSphere cloud credentials will be leaked in the cloud controller manager's log.\r\n\r\n### Am I vulnerable?\r\nIf you are using VSphere as a cloud provider, have verbose logging enabled, and an attacker can access cluster logs, then you may be vulnerable to this.\r\n\r\n#### Affected Versions\r\nkube-controller-manager v1.19.0 - v1.19.2\r\n\r\n#### How do I mitigate this vulnerability?\r\nDo not enable verbose logging in production, limit access to cluster logs.\r\n\r\n#### Fixed Versions\r\nv1.19.3\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n### Acknowledgements\r\nThis vulnerability was reported by: Kaizhe Huang (derek0405)\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n","date_published":"2020-10-15T22:00:44Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8563","id":"CVE-2020-8563","status":"fixed","summary":"Secret leaks in kube-controller-manager when using vSphere provider","url":"https://github.com/kubernetes/kubernetes/issues/95621"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8557","issue_number":93032},"content_text":"CVSS Rating: Medium (5.5)  [CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/CR:H/IR:H/AR:M](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/CR:H/IR:H/AR:M)\r\n\r\nThe `/etc/hosts` file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the `/etc/hosts` file, it could fill the storage space of the node and cause the node to fail.\r\n\r\n### Am I vulnerable?\r\n\r\nAny clusters allowing pods with sufficient privileges to write to their own `/etc/hosts` files are affected. This includes containers running with `CAP_DAC_OVERRIDE` in their capabilities bounding set (true by default) and either UID 0 (root) or a security context with `allowPrivilegeEscalation: true` (true by default).\r\n\r\n#### Affected Versions\r\n\r\n- kubelet v1.18.0-1.18.5\r\n- kubelet v1.17.0-1.17.8\r\n- kubelet \u003c v1.16.13\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nPrior to upgrading, this vulnerability can be mitigated by using PodSecurityPolicies or other admission webhooks to force containers to drop CAP_DAC_OVERRIDE or to prohibit privilege escalation and running as root, but these measures may break existing workloads that rely upon these privileges to function properly.\r\n\r\n#### Fixed Versions\r\n\r\n- kubelet master - fixed by #92916\r\n- kubelet v1.18.6 - fixed by #92921\r\n- kubelet v1.17.9 - fixed by #92923\r\n- kubelet v1.16.13 - fixed by #92924\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n### Detection\r\n\r\nLarge pod `etc-hosts` files may indicate that a pod is attempting to perform a Denial of Service attack using this bug. A command such as\r\n\r\n```\r\nfind /var/lib/kubelet/pods/*/etc-hosts -size +1M\r\n```\r\n\r\nrun on a node can be used to find abnormally large pod etc-hosts files.\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Kebe Liu of DaoCloud, via the Kubernetes bug bounty program.\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig node\r\n/area kubelet","date_published":"2020-07-13T18:39:08Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8557","id":"CVE-2020-8557","status":"fixed","summary":"Node disk DOS by writing to container /etc/hosts","url":"https://github.com/kubernetes/kubernetes/issues/93032"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8559","issue_number":92914},"content_text":"CVSS Rating: Medium (6.4) [CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H)\r\n\r\nIf an attacker is able to intercept certain requests to the Kubelet, they can send a redirect response that may be followed by a client using the credentials from the original request. This can lead to compromise of other nodes.\r\n\r\nIf multiple clusters share the same certificate authority trusted by the client, and the same authentication credentials, this vulnerability may allow an attacker to redirect the client to another cluster. In this configuration, this vulnerability should be considered **High** severity.\r\n\r\n### Am I vulnerable?\r\n\r\nYou are only affected by this vulnerability if you treat the node as a security boundary, or if clusters share certificate authorities and authentication credentials.\r\n\r\nNote that this vulnerability requires an attacker to first compromise a node through separate means.\r\n\r\n#### Affected Versions\r\n\r\n- kube-apiserver v1.18.0-1.18.5\r\n- kube-apiserver v1.17.0-1.17.8\r\n- kube-apiserver v1.16.0-1.16.12\r\n- all kube-apiserver versions prior to v1.16.0\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nTo mitigate this vulnerability you must upgrade the kube-apiserver to a patched version.\r\n\r\n#### Fixed Versions\r\n\r\n- kube-apiserver master - fixed by https://github.com/kubernetes/kubernetes/pull/92941\r\n- kube-apiserver v1.18.6 - fixed by https://github.com/kubernetes/kubernetes/pull/92969\r\n- kube-apiserver v1.17.9 - fixed by https://github.com/kubernetes/kubernetes/pull/92970\r\n- kube-apiserver v1.16.13 - fixed by https://github.com/kubernetes/kubernetes/pull/92971\r\n\r\n\r\n**Fix impact:** Proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code may be broken by this patch.\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n### Detection\r\n\r\nUpgrade requests should never respond with a redirect. If any of the following requests have a response code in the 300-399 range, it may be evidence of exploitation. This information can be found in the Kubernetes audit logs.\r\n\r\n- pods/exec\r\n- pods/attach\r\n- pods/portforward\r\n- any resource: proxy\r\n\r\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Wouter ter Maat of Offensi, via the Kubernetes bug bounty.\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig api-machinery\r\n/area apiserver","date_published":"2020-07-08T17:03:16Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8559","id":"CVE-2020-8559","status":"fixed","summary":"Privilege escalation from compromised node to cluster","url":"https://github.com/kubernetes/kubernetes/issues/92914"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8558","issue_number":92315},"content_text":"CVSS Rating:\r\n\r\nIn typical clusters: medium (5.4) [CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N)\r\n\r\nIn clusters where API server insecure port has not been disabled: high (8.8) [CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)\r\n\r\nA security issue was discovered in `kube-proxy` which allows adjacent hosts to reach TCP and UDP services bound to `127.0.0.1` running on the node or in the node's network namespace. For example, if a cluster administrator runs a TCP service on a node that listens on `127.0.0.1:1234`, because of this bug, that service would be potentially reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service. If the example service on port `1234` required no additional authentication (because it assumed that only other localhost processes could reach it), then it could be vulnerable to attacks that make use of this bug.\r\n\r\nThe Kubernetes API Server's default insecure port setting causes the API server to listen on `127.0.0.1:8080` where it will accept requests without authentication. Many Kubernetes installers explicitly disable the API Server's insecure port, but in clusters where it is not disabled, an attacker with access to another system on the same LAN or with control of a container running on the master may be able to reach the API server and execute arbitrary API requests on the cluster. This port is deprecated, and will be removed in Kubernetes v1.20.\r\n\r\n### Am I vulnerable?\r\n\r\nYou may be vulnerable if:\r\n\r\n- You are running a vulnerable version (see below)\r\n- Your cluster nodes run in an environment where untrusted hosts share the same layer 2 domain (i.e. same LAN) as nodes\r\n- Your cluster allows untrusted pods to run containers with `CAP_NET_RAW` (the Kubernetes default is to allow this capability).\r\n- Your nodes (or hostnetwork pods) run any localhost-only services which do not require any further authentication. To list services that are potentially affected, run the following commands on nodes:\r\n   - `lsof +c 15 -P -n -i4TCP@127.0.0.1 -sTCP:LISTEN`\r\n  - `lsof +c 15 -P -n -i4UDP@127.0.0.1`\r\n\r\n On a master node, an lsof entry like this indicates that the API server may be listening with an insecure port:\r\n\r\n```\r\nCOMMAND        PID  USER FD   TYPE DEVICE SIZE/OFF NODE NAME\r\nkube-apiserver 123  root  7u  IPv4  26799      0t0  TCP 127.0.0.1:8080 (LISTEN)\r\n```\r\n\r\n#### Affected Versions\r\n- kubelet/kube-proxy v1.18.0-1.18.3\r\n- kubelet/kube-proxy v1.17.0-1.17.6\r\n- kubelet/kube-proxy \u003c=1.16.10\r\n\r\n### How do I mitigate this vulnerability?\r\nPrior to upgrading, this vulnerability can be mitigated by manually adding an iptables rule on nodes. This rule will reject traffic to 127.0.0.1 which does not originate on the node.\r\n\r\n` iptables -I INPUT --dst 127.0.0.0/8 ! --src 127.0.0.0/8 -m conntrack ! --ctstate RELATED,ESTABLISHED,DNAT -j DROP`\r\n\r\nAdditionally, if your cluster does not already have the API Server insecure port disabled, we strongly suggest that you disable it. Add the following flag to your kubernetes API server command line: `--insecure-port=0`\r\n#### Detection\r\nPackets on the wire with an IPv4 destination in the range 127.0.0.0/8 and a layer-2 destination MAC address of a node may indicate that an attack is targeting this vulnerability.\r\n\r\n#### Fixed Versions\r\nAlthough the issue is caused by `kube-proxy`, the current fix for the issue is in `kubelet` (although future versions may have the fix in `kube-proxy` instead). We recommend updating both `kubelet` and `kube-proxy` to be sure the issue is addressed.\r\n\r\nThe following versions contain the fix:\r\n \r\n- kubelet/kube-proxy master - fixed by #91569\r\n- kubelet/kube-proxy v1.18.4+ - fixed by #92038\r\n- kubelet/kube-proxy v1.17.7+ - fixed by #92039\r\n- kubelet/kube-proxy v1.16.11+ - fixed by #92040\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n\r\n## Additional Details\r\nThis issue was originally raised in issue #90259 which details how the `kube-proxy` sets `net.ipv4.conf.all.route_localnet=1` which causes the system not to reject traffic to localhost which originates on other hosts.\r\n\r\nIPv6-only services that bind to a `localhost` address are not affected. \r\n\r\nThere may be additional attack vectors possible in addition to those fixed by #91569 and its cherry-picks. For those attacks to succeed, the target service would need to be UDP and the attack could only rely upon sending UDP datagrams since it wouldn't receive any replies. Finally, the target node would need to have reverse-path filtering disabled for an attack to have any effect. Work is ongoing to determine whether and how this issue should be fixed. See #91666 for up-to-date status on this issue.  \r\n\r\n#### Acknowledgements\r\nThis vulnerability was reported by János Kövér, Ericsson with additional impacts reported by Rory McCune, NCC Group and Yuval Avrahami and Ariel Zelivansky, Palo Alto Networks.\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig network\r\n/sig node\r\n/area kubelet","date_published":"2020-06-19T18:38:58Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8558","id":"CVE-2020-8558","status":"fixed","summary":"Node setting allows for neighboring hosts to bypass localhost boundary","url":"https://github.com/kubernetes/kubernetes/issues/92315"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8555","issue_number":91542},"content_text":"CVSS Rating: [CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N)\r\n\r\nThere exists a Server Side Request Forgery (SSRF) vulnerability in kube-controller-manager that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master's host network (such as link-local or loopback services).\r\n \r\nAn attacker with permissions to create a pod with certain built-in Volume types (GlusterFS, Quobyte, StorageOS, ScaleIO) or permissions to create a StorageClass can cause kube-controller-manager to make GET requests or POST requests without an attacker controlled request body from the master's host network.\r\n \r\n### Am I vulnerable?\r\n\r\nYou may be vulnerable if:\r\n\r\n- You are running a vulnerable version (see below)\r\n- There are unprotected endpoints normally only visible from the Kubernetes master (including link-local metadata endpoints, unauthenticated services listening on localhost, or other services in the master's private network)\r\n- Untrusted users can create pods with an affected volume type or modify storage classes.\r\n\r\n#### Affected Versions\r\n\r\n- kube-controller-manager v1.18.0\r\n- kube-controller-manager v1.17.0 - v1.17.4\r\n- kube-controller-manager v1.16.0 - v1.16.8\r\n- kube-controller-manager \u003c= v1.15.11\r\n \r\nThe affected volume types are: GlusterFS, Quobyte, StorageOS, ScaleIO\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nPrior to upgrading, this vulnerability can be mitigated by adding endpoint protections on the master or restricting usage of the vulnerable volume types (for example by constraining usage with a [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) or third-party admission controller such as [Gatekeeper](https://github.com/open-policy-agent/gatekeeper)) and restricting StorageClass write permissions through RBAC.\r\n\r\n#### Fixed Versions\r\n\r\nThe information leak was patched in the following versions:\r\n\r\n- kube-controller-manager master - fixed by https://github.com/kubernetes/kubernetes/pull/89794\r\n- kube-controller-manager v1.18.1+ - fixed by https://github.com/kubernetes/kubernetes/pull/89796\r\n- kube-controller-manager v1.17.5+ - fixed by https://github.com/kubernetes/kubernetes/pull/89837\r\n- kube-controller-manager v1.16.9+ - fixed by https://github.com/kubernetes/kubernetes/pull/89838\r\n- kube-controller-manager v1.15.12+ - fixed by https://github.com/kubernetes/kubernetes/pull/89839\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n## Additional Details\r\n\r\nExploitation of this vulnerability causes the kube-controller-manager to make a request to a user-supplied, unvalidated URL. The request does not include any kube-controller-manager client credentials.\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Brice Augras from Groupe-Asten and Christophe Hauquiert from Nokia.\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig storage\r\n/area controller-manager","date_published":"2020-05-28T16:13:34Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8555","id":"CVE-2020-8555","status":"fixed","summary":"Half-Blind SSRF in kube-controller-manager","url":"https://github.com/kubernetes/kubernetes/issues/91542"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-10749","issue_number":91507},"content_text":"CVSS Rating: [CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L) (6.0 Medium)\r\n\r\nA cluster configured to use an affected container networking implementation is susceptible to man-in-the-middle (MitM) attacks. By sending “rogue” router advertisements, a malicious container can reconfigure the host to redirect part or all of the IPv6 traffic of the host to the attacker-controlled container. Even if there was no IPv6 traffic before, if the DNS returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to connect via IPv6 first then fallback to IPv4, giving an opportunity to the attacker to respond.\r\n\r\n### Am I vulnerable?\r\n\r\nKubernetes itself is not vulnerable. A Kubernetes cluster using an affected networking implementation is vulnerable.\r\n\r\nBinary releases of the kubelet installed from upstream Kubernetes Community repositories hosted at https://packages.cloud.google.com/ may have also installed the `kubernetes-cni` package containing the [containernetworking CNI plugins](https://github.com/containernetworking/plugins), which are affected by CVE-2020-10749.\r\n\r\n#### Affected Versions\r\nThe following official kubelet package versions have an affected `kubernetes-cni` package as a dependency: \r\n- kubelet v1.18.0-v1.18.3\r\n- kubelet v1.17.0-v1.17.6\r\n- kubelet \u003c v1.16.11\r\n\r\nA cluster having an affected `kubernetes-cni` package installed is only affected if configured to use it.\r\n#### Third-party components and versions\r\nMany container networking implementations are affected, including:\r\n\r\n- CNI Plugins maintained by the containernetworking team, prior to version 0.8.6 (CVE-2020-10749) (See https://github.com/containernetworking/plugins/pull/484)\r\n- Calico and Calico Enterprise (CVE-2020-13597) Please refer to the Tigera Advisory TTA-2020-001 at https://www.projectcalico.org/security-bulletins/ for details\r\n- Docker versions prior to 19.03.11 (see https://github.com/docker/docker-ce/releases/v19.03.11) (CVE-2020-13401)\r\n- Flannel, all current versions\r\n- Weave Net, prior to version 2.6.3\r\n\r\nIt is believed that the following are not affected:\r\n\r\n- Cilium\r\n- Juniper Contrail Networking\r\n- OpenShift SDN\r\n- OVN-Kubernetes\r\n- Tungsten Fabric\r\n\r\nInformation about the vulnerability status of any plugins or implementations not listed above is currently unavailable. Please contact the provider directly with questions about their implementation.\r\n\r\n### How do I mitigate this vulnerability?\r\n- Set the host default to reject router advertisements. This should prevent attacks from succeeding, but may break legitimate traffic, depending upon the networking implementation and the network where the cluster is running. To change this setting, set the sysctl `net.ipv6.conf.all.accept_ra` to 0.\r\n- Use TLS with proper certificate validation\r\n- Disallow `CAP_NET_RAW` for untrusted workloads or users. For example, a Pod Security Policy with a `RequiredDropCapabilities` that includes `NET_RAW` will prevent this attack for controlled workloads.\r\n\r\n#### Fixed Versions\r\n\r\nThe following packages will bundle fixed versions of the containernetworking CNI plugins that were formerly installed via the `kubernetes-cni` package.\r\n- kubelet v1.19.0+ (master branch #91370)\r\n- kubelet v1.18.4+ (#91387)\r\n- kubelet v1.17.7+ (#91386)\r\n- kubelet v1.16.11+ (#91388)\r\n\r\nBecause these versions are not yet available, cluster administrators using packages from the Kubernetes repositories may choose to manually upgrade CNI plugins by retrieving the relevant arch tarball from the containernetworking/plugins [v0.8.6 release](https://github.com/containernetworking/plugins/releases/tag/v0.8.6). The patch versions are [expected to be released on June 17th](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md#timelines), subject to change.\r\n\r\n## Additional Details\r\n#### Detection\r\n\r\n- The IPv6 routing table on nodes will show any attacker-created entries. For example, a host with IPv6 disabled might show no default route when running `ip -6 route` but the same host with an attack in progress might show an updated default route or a route to the target address(es). Any IPv6 route with a destination interface of a host-side container network interface should be investigated.\r\n- The host-side of a container network interface may show additional configured IPv6 addresses after receiving a rogue RA packet. For example, given a host-side interface of `cbr0` which might normally have no IPv6 address, a dynamic-configured address on the interface may signal an attack in progress. Use this command to view interface addresses: `ip a show dynamic cbr0`\r\n\r\n#### Affected configurations\r\n\r\n- Clusters using an affected networking implementation and allowing workloads to run with `CAP_NET_RAW privileges`. The default Kubernetes security context runs workloads with a capabilities bounding set that includes `CAP_NET_RAW`. \r\n\r\n#### Vulnerability impact\r\n\r\n- A user able to create containers with `CAP_NET_RAW` privileges on an affected cluster can intercept traffic from other containers on the host or from the host itself.\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Etienne Champetier (@champtar).\r\n\r\nThe issue was fixed by Casey Callendrello (@squeed) and maintainers of various container networking implementations. Updates to Kubernetes builds were coordinated by Stephen Augustus (@justaugustus) and Tim Pepper (@tpepper).\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig network\r\n","date_published":"2020-05-27T19:32:29Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-10749","id":"CVE-2020-10749","status":"fixed","summary":"IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements","url":"https://github.com/kubernetes/kubernetes/issues/91507"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11254","issue_number":89535},"content_text":"CVE-2019-11254 is a denial of service vulnerability in the kube-apiserver, allowing authorized users sending malicious YAML payloads to cause kube-apiserver to consume excessive CPU cycles while parsing YAML.\r\n \r\nThe issue was discovered via the fuzz test kubernetes/kubernetes#83750.\r\n \r\n**Affected components:**\r\nKubernetes API server\r\n \r\n**Affected versions:**\r\n\u003c= v1.15.9, resolved in 1.15.10 by https://github.com/kubernetes/kubernetes/pull/87640\r\nv1.16.0-v1.16.7, resolved in 1.16.8 by https://github.com/kubernetes/kubernetes/pull/87639\r\nv1.17.0-v1.17.2, resolved in 1.17.3 by https://github.com/kubernetes/kubernetes/pull/87637\r\nFixed in master by https://github.com/kubernetes/kubernetes/pull/87467\r\n \r\n**How do I mitigate this vulnerability?**\r\nPrior to upgrading, these vulnerabilities can be mitigated by preventing unauthenticated or unauthorized access to kube-apiserver.","date_published":"2020-03-26T18:55:26Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11254","id":"CVE-2019-11254","status":"fixed","summary":"kube-apiserver Denial of Service vulnerability from malicious YAML payloads","url":"https://github.com/kubernetes/kubernetes/issues/89535"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8552","issue_number":89378},"content_text":"CVSS Rating: [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) (Medium)\r\n\r\nThe Kubernetes API server has been found to be vulnerable to a denial of service attack via authorized API requests.\r\n\r\n### Am I vulnerable?\r\n\r\nIf an attacker that can make an authorized resource request to an unpatched API server (see below), then you are vulnerable to this. Prior to v1.14, this was possible via unauthenticated requests by default.\r\n\r\n#### Affected Versions\r\n\r\n- kube-apiserver v1.17.0 - v1.17.2\r\n- kube-apiserver v1.16.0 - v1.16.6\r\n- kube-apiserver \u003c v1.15.10\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nPrior to upgrading, this vulnerability can be mitigated by:\r\n- Preventing unauthenticated or unauthorized access to all apis\r\n- The apiserver should auto restart if it OOMs\r\n\r\n#### Fixed Versions\r\n\r\n- v1.17.3\r\n- v1.16.7\r\n- v1.15.10\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by: Gus Lees (Amazon)\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig api-machinery","date_published":"2020-03-23T18:35:34Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8552","id":"CVE-2020-8552","status":"fixed","summary":"apiserver DoS (oom)","url":"https://github.com/kubernetes/kubernetes/issues/89378"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8551","issue_number":89377},"content_text":"CVSS Rating: [CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) (Medium)\r\n\r\nThe Kubelet has been found to be vulnerable to a denial of service attack via the kubelet API, including the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250.\r\n\r\n### Am I vulnerable?\r\n\r\nIf an attacker can make a request to an unpatched kubelet, then you may be vulnerable to this.\r\n\r\n#### Affected Versions\r\n\r\n- kubelet v1.17.0 - v1.17.2\r\n- kubelet v1.16.0 - v1.16.6\r\n- kubelet v1.15.0 - v1.15.9\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nLimit access to the Kubelet API or patch the Kubelet.\r\n\r\n#### Fixed Versions\r\n\r\n- v1.17.3\r\n- v1.16.7\r\n- v1.15.10\r\n\r\nTo upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by: Henrik Schmidt\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig node\r\n/area kubelet","date_published":"2020-03-23T18:34:40Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8551","id":"CVE-2020-8551","status":"fixed","summary":"Kubelet DoS via API","url":"https://github.com/kubernetes/kubernetes/issues/89377"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2020-8553","issue_number":126818},"content_text":"A security issue was discovered in ingress-nginx versions older than v0.28.0. The issue is of medium severity, and upgrading is encouraged to fix the vulnerability.\r\n\r\n**Am I vulnerable?**\r\n\r\nThe vulnerability exists only if the annotation [nginx.ingress.kubernetes.io/auth-type: basic](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#authentication) is used.\r\n\r\n**How do I upgrade?**\r\n\r\nFollow installation instructions [here](https://kubernetes.github.io/ingress-nginx/deploy/upgrade/)\r\n\r\n**Vulnerability Details**\r\n\r\nA vulnerability has been discovered where a malicious user could create a new Ingress definition resulting in the replacement of the password file. The vulnerability requires that the victim namespace and/or secret use a hyphen in the name.\r\n\r\nThis scenario requires privileges in the cluster to create and read ingresses and also create secrets.\r\n\r\nThis issue is filed as CVE-2020-8553.\r\n\r\n/close\r\n","date_published":"2020-02-19T19:00:32Z","external_url":"https://www.cve.org/cverecord?id=CVE-2020-8553","id":"CVE-2020-8553","status":"fixed","summary":"ingress-nginx auth-type basic annotation vulnerability","url":"https://github.com/kubernetes/kubernetes/issues/126818"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11251","issue_number":87773},"content_text":"A security issue was discovered in kubectl versions v1.13.10, v1.14.6, and v1.15.3. The issue is of a medium severity and upgrading of kubectl is encouraged to fix the vulnerability.\r\n\r\n**Am I vulnerable?**\r\n\r\nRun kubectl version --client and if it returns versions v1.13.10, v1.14.6, and v1.15.3, you are running a vulnerable version.\r\n\r\n**How do I upgrade?**\r\n\r\nFollow installation instructions [here](https://kubernetes.io/docs/tasks/tools/install-kubectl/)\r\n\r\n**Vulnerability Details**\r\n\r\nThe details for this vulnerability are very similar to CVE-2019-1002101 and CVE-2019-11246.\r\nA vulnerability has been discovered in kubectl cp that allows a combination of two symlinks to copy a file outside of its destination directory. This could be used to allow an attacker to place a nefarious file using a symlink, outside of the destination tree.\r\n\r\nThis issue is filed as CVE-2019-11251.\r\n\r\nTwo fixes were formulated, one fix to remove symlink support going forwards and a fix with cherry picks made to ensure backwards compatibility.\r\n\r\nSee https://github.com/kubernetes/kubernetes/pull/82143 for the primary fix in v1.16.0 which removes the support of symlinks in kubectl cp. After version 1.16.0, symlink support with kubectl cp is removed, it is recommended instead to use a combination of exec+tar.\r\n\r\nA second fix has been made to 1.15.4 and backported to 1.14.7 and 1.13.11. This changes the kubectl cp un-tar symlink logic, by unpacking the symlinks after all the regular files have been unpacked. This then guarantees that a file can’t be written through a symlink.\r\n\r\nSee https://github.com/kubernetes/kubernetes/pull/82384 for the fix to version 1.15.4. The following Cherry picks were made from this fix to earlier versions of v1.14.7 and v1.13.11:\r\n\r\nSee https://github.com/kubernetes/kubernetes/pull/82502 for version 1.14.7\r\nSee https://github.com/kubernetes/kubernetes/pull/82503 for version 1.13.11\r\n\r\nThank you to Erik Sjölund (@eriksjolund) for discovering this issue, Tim Allclair and Maciej Szulik for both fixes and the patch release managers for including the fix in their releases.\r\n\r\n/close","date_published":"2020-02-03T15:12:22Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11251","id":"CVE-2019-11251","status":"fixed","summary":"kubectl cp symlink vulnerability","url":"https://github.com/kubernetes/kubernetes/issues/87773"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2018-1002102","issue_number":85867},"content_text":"CVSS Rating: [CVSS:3.0/AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:N/A:N/E:F (Low)](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:N/A:N/E:F)\r\n\r\nAn attacker-controlled Kubelet can return an arbitrary redirect when responding to certain apiserver requests. Impacted kube-apiservers will follow the redirect as a GET request with client-cert credentials for authenticating to the Kubelet.\r\n\r\n### Am I vulnerable?\r\n\r\nKubernetes API servers with the `StreamingProxyRedirects` [feature](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) enabled AND without the `ValidateProxyRedirects` feature are affected.\r\n\r\nAPI servers using SSH tunnels (--ssh-user / --ssh-keyfile) are not affected.\r\n\r\nUsing the default feature gate values, kube-apiserver versions before v1.14 are affected.\r\n\r\n### How do I mitigate this vulnerability?\r\n\r\nFor Kubernetes versions \u003e= v1.10.0, the `ValidateProxyRedirects` can be manually enabled with the `kube-apiserver` flag `--feature-gates=ValidateProxyRedirects=true`.\r\n\r\n#### Fix impact\r\nThe `ValidateProxyRedirects` feature will cause the kube-apiserver to check that redirects go to the same host. If nodes are configured to respond to CRI streaming requests on a different host interface than what the apiserver makes requests on (only the case if not using the built-in dockershim \u0026 setting the kubelet flag `--redirect-container-streaming=true`), then these requests will be broken. In that case, the feature can be temporarily disabled until the node configuration is corrected. We suggest setting `--redirect-container-streaming=false` on the kubelet to avoid issues.\r\n\r\n#### Fixed Versions\r\n\r\n- Kubernetes v1.14+ - Fixed by default in https://github.com/kubernetes/kubernetes/pull/72552\r\n- Kubernetes v1.10-v1.14 - Fix available as alpha in https://github.com/kubernetes/kubernetes/pull/66516\r\n\r\n## Additional Details\r\n\r\nIn a future release, we plan to deprecate the `StreamingProxyRedirects` feature, instead opting to handle the redirection locally through the Kubelet. Once the deprecation is complete, we can completely remove apiserver redirect handling (at least for Kubelet requests).\r\n\r\n#### Acknowledgements\r\n\r\nThis vulnerability was reported by Alban Crequy.\r\n\r\n/area security\r\n/kind bug\r\n/committee product-security\r\n/sig api-machinery node\r\n/area apiserver\r\n\r\n/close","date_published":"2019-12-03T22:58:37Z","external_url":"https://www.cve.org/cverecord?id=CVE-2018-1002102","id":"CVE-2018-1002102","status":"fixed","summary":"Unvalidated redirect","url":"https://github.com/kubernetes/kubernetes/issues/85867"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11255","issue_number":85233},"content_text":"\u003c!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!\r\n\r\nIf the matter is security related, please disclose it privately via https://kubernetes.io/security/\r\n--\u003e\r\n\r\n**Am I vulnerable?**\r\n\r\nCSI snapshot, cloning and resizing features are affected. Prior to Kubernetes 1.16, these features were all alpha and disabled by default. Starting in Kubernetes 1.16, CSI cloning and resizing features are beta and enabled by default. \r\n\r\nThese features also require CSI drivers to be installed in a Kubernetes cluster and the CSI driver also has to support those features. An unofficial list of CSI drivers and their supported features is available [here](https://kubernetes-csi.github.io/docs/drivers.html), however it is best to check with the CSI driver vendor for the latest information.\r\n\r\nCheck if you have the following Kubernetes feature gates enabled:\r\n\r\n```\r\nVolumeSnapshotDataSource: alpha starting with K8s 1.12\r\nExpandCSIVolumes: alpha starting with K8s 1.14, beta starting with K8s 1.16\r\nVolumePVCDataSource: alpha starting with K8s 1.15, beta starting with K8s 1.16\r\n```\r\n\r\nCheck if you are using CSI drivers in your cluster. If so, the following command’s output will be non-empty:\r\n\r\n```\r\n$ kubectl get nodes -o jsonpath='{.items[*].metadata.annotations.csi\\.volume\\.kubernetes\\.io\\/nodeid}'\r\n {\"my-csi-plugin\":\"kubernetes-minion-group-433q\"}\r\n```\r\n\r\nThen, check the CSI driver’s pod specifications to see if they are using the following vulnerable versions of sidecars:\r\n\r\n```\r\nexternal-provisioner: v0.4.1-0.4.2, v1.0.0-1.0.1, v1.1.0-1.2.1, v1.3.0\r\nexternal-snapshotter: v0.4.0-0.4.1, v1.0.0-1.0.1, v1.1.0-v1.2.1\r\nexternal-resizer: v0.1.0-0.2.0\r\n```\r\n\r\nAn example query:\r\n```\r\n$ kubectl get pods --all-namespaces -o jsonpath='{..image}' | tr ' ' $'\\n' | grep \"csi-provisioner\\|csi-snapshotter\\|csi-resizer\"\r\n image: quay.io/k8scsi/csi-provisioner:v1.2.0\r\n```\r\n\r\nNote that the exact container image name may vary across CSI driver vendors. It is recommended to inspect the Pod specifications directly.\r\n\r\n**How do I mitigate the vulnerability?**\r\n\r\nAs a short term mitigation, disable the `VolumeSnapshotDataSource`, `ExpandCSIVolumes`, and `VolumePVCDataSource` Kubernetes feature gates in kube-apiserver and kube-controller-manager. This will cause new PersistentVolumeClaims to be provisioned ignoring the DataSource and resizing requests will also be ignored. Note that this will cause new PVCs that are intended to be provisioned from a snapshot or clone to instead provision a blank disk.\r\n\r\nAlso, to disable taking volume snapshots, either remove the external-snapshotter sidecar from any CSI drivers or revoke the CSI driver’s RBAC permissions on the `snapshot.storage.k8s.io` API group.\r\n\r\nLonger term, upgrade your CSI driver with patched versions of the affected sidecars. Fixes are available in the following sidecar versions:\r\n\r\nexternal-provisioner: \r\nv0.4.3\r\nv1.0.2\r\nv1.2.2\r\nv1.3.1\r\nv1.4.0 \r\n\r\nexternal-snapshotter:\r\nv0.4.2\r\nv1.0.2\r\nv1.2.2\r\n\r\nexternal-resizer\r\nv0.3.0\r\n\r\nFixes for each of the sidecars can be tracked by:\r\nhttps://github.com/kubernetes-csi/external-provisioner/issues/380\r\nhttps://github.com/kubernetes-csi/external-snapshotter/issues/193\r\nhttps://github.com/kubernetes-csi/external-resizer/issues/63\r\n\r\n**How do I upgrade?**\r\n\r\nCheck with your CSI driver vendor for upgrade instructions. No Kubernetes control plane or node upgrades are required unless the CSI driver is bundled into the Kubernetes distribution.\r\n\r\n**Vulnerability details**\r\n\r\nThere are two different vulnerabilities impacting the same features.\r\n\r\nWhen PersistentVolumeClaim and PersistentVolume objects are bound, they have bidirectional references to each other. When dereferencing a PersistentVolumeClaim to get a PersistentVolume, the impacted sidecar controllers were not validating that the PersistentVolume referenced back to the same PersistentVolumeClaim, potentially operating on unauthorized PersistentVolumes for snapshot, cloning and resizing operations.\r\n\r\nA similar issue exists for VolumeSnapshot and VolumeSnapshotContent objects when creating a new PersistentVolumeClaim from a snapshot.\r\n\r\nThe second issue is related to the property that CSI volume and snapshot ids are only required to be unique within a single CSI driver. Impacted sidecar controllers were not validating that the requested source VolumeSnapshot or PersistentVolumeClaim specified were from the same driver processing the request, potentially operating on unauthorized volumes during snapshot, restore from snapshot, or cloning operations.\r\n\r\n","date_published":"2019-11-13T20:57:31Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11255","id":"CVE-2019-11255","status":"fixed","summary":"CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation","url":"https://github.com/kubernetes/kubernetes/issues/85233"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11253","issue_number":83253},"content_text":"CVE-2019-11253 is a denial of service vulnerability in the kube-apiserver, allowing authorized users sending malicious YAML or JSON payloads to cause kube-apiserver to consume excessive CPU or memory, potentially crashing and becoming unavailable. This vulnerability has been given an initial severity of High, with a score of 7.5 ([CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)).\r\n\r\nPrior to v1.14.0, default RBAC policy authorized anonymous users to submit requests that could trigger this vulnerability. Clusters upgraded from a version prior to v1.14.0 keep the more permissive policy by default for backwards compatibility. See the mitigation section below for instructions on how to install the more restrictive v1.14+ policy.\r\n\r\n**Affected versions:**\r\n* Kubernetes v1.0.0-1.12.x\r\n* Kubernetes v1.13.0-1.13.11, resolved in v1.13.12 by https://github.com/kubernetes/kubernetes/pull/83436\r\n* Kubernetes v1.14.0-1.14.7, resolved in v1.14.8 by https://github.com/kubernetes/kubernetes/pull/83435\r\n* Kubernetes v1.15.0-1.15.4, resolved in v1.15.5 by https://github.com/kubernetes/kubernetes/pull/83434\r\n* Kubernetes v1.16.0-1.16.1, resolved in v1.16.2 by https://github.com/kubernetes/kubernetes/pull/83433\r\n\r\nAll four patch releases are now available.\r\n\r\nFixed in master by #83261\r\n\r\n**Mitigation:**\r\n\r\nRequests that are rejected by authorization do not trigger the vulnerability, so managing authorization rules and/or access to the Kubernetes API server mitigates which users are able to trigger this vulnerability.\r\n\r\nTo manually apply the more restrictive v1.14.x+ policy, either as a pre-upgrade mitigation, or as an additional protection for an upgraded cluster, save the [attached file](https://github.com/kubernetes/kubernetes/files/3735508/rbac.yaml.txt) as `rbac.yaml`, and run:\r\n\r\n```sh\r\nkubectl auth reconcile -f rbac.yaml --remove-extra-subjects --remove-extra-permissions \r\n```\r\n\r\n**Note: this removes the ability for unauthenticated users to use `kubectl auth can-i`**\r\n\r\nIf you are running a version prior to v1.14.0:\r\n* in addition to installing the restrictive policy, turn off autoupdate for this clusterrolebinding so your changes aren’t replaced on an API server restart:\r\n ```sh\r\n kubectl annotate --overwrite clusterrolebinding/system:basic-user rbac.authorization.kubernetes.io/autoupdate=false\r\n ```\r\n* after upgrading to v1.14.0 or greater, you can remove this annotation to reenable autoupdate:\r\n ```sh\r\n kubectl annotate --overwrite clusterrolebinding/system:basic-user rbac.authorization.kubernetes.io/autoupdate=true\r\n ```\r\n\r\n=============\r\n\r\n**Original description follows:**\r\n\r\n**Introduction** \r\n\r\nPosting this as an issue following report to the security list who suggested putting it here as it's already public in a Stackoverflow question [here](https://stackoverflow.com/questions/58129150/security-yaml-bomb-user-can-restart-kube-api-by-sending-configmap/58133282#58133282)\r\n\r\n**What happened**:\r\n\r\nWhen creating a ConfigMap object which has recursive references contained in it, excessive CPU usage can occur. This appears to be an instance of a [\"Billion Laughs\" attack](https://en.wikipedia.org/wiki/Billion_laughs_attack) which is quite well known as an XML parsing issue.\r\n\r\nApplying this manifest to a cluster causes the client to hang for some time with considerable CPU usage.\r\n\r\n```\r\napiVersion: v1\r\ndata:\r\n a: \u0026a [\"web\",\"web\",\"web\",\"web\",\"web\",\"web\",\"web\",\"web\",\"web\"]\r\n b: \u0026b [*a,*a,*a,*a,*a,*a,*a,*a,*a]\r\n c: \u0026c [*b,*b,*b,*b,*b,*b,*b,*b,*b]\r\n d: \u0026d [*c,*c,*c,*c,*c,*c,*c,*c,*c]\r\n e: \u0026e [*d,*d,*d,*d,*d,*d,*d,*d,*d]\r\n f: \u0026f [*e,*e,*e,*e,*e,*e,*e,*e,*e]\r\n g: \u0026g [*f,*f,*f,*f,*f,*f,*f,*f,*f]\r\n h: \u0026h [*g,*g,*g,*g,*g,*g,*g,*g,*g]\r\n i: \u0026i [*h,*h,*h,*h,*h,*h,*h,*h,*h]\r\nkind: ConfigMap\r\nmetadata:\r\n name: yaml-bomb\r\n namespace: default\r\n```\r\n**What you expected to happen**:\r\n\r\nIdeally it would be good for a maximum size of entity to be defined, or perhaps some limit on recursive references in YAML parsed by kubectl.\r\n\r\nOne note is that the original poster on Stackoverflow indicated that the resource consumption was in `kube-apiserver` but both tests I did (1.16 client against 1.15 Kubeadm cluster and 1.16 client against 1.16 kubeadm cluster) showed the CPU usage client-side.\r\n\r\n**How to reproduce it (as minimally and precisely as possible)**:\r\n\r\nGet the manifest above and apply to a cluster as normal with `kubectl create -f \u003cmanifest\u003e`. Use `top` or another CPU monitor to observe the quantity of CPU time used.\r\n\r\n**Anything else we need to know?**:\r\n\r\n**Environment**:\r\n- Kubernetes version (use `kubectl version`):\r\n\r\n**test 1** (linux AMD64 client, Kubeadm cluster running in kind)\r\n```\r\nClient Version: version.Info{Major:\"1\", Minor:\"16\", GitVersion:\"v1.16.0\", GitCommit:\"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77\", GitTreeState:\"clean\", BuildDate:\"2019-09-18T14:36:53Z\", GoVersion:\"go1.12.9\", Compiler:\"gc\", Platform:\"linux/amd64\"}\r\nServer Version: version.Info{Major:\"1\", Minor:\"15\", GitVersion:\"v1.15.0\", GitCommit:\"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529\", GitTreeState:\"clean\", BuildDate:\"2019-06-25T23:41:27Z\", GoVersion:\"go1.12.5\", Compiler:\"gc\", Platform:\"linux/amd64\"}\r\n```\r\n\r\n**test 2** (Linux AMD64 client, Kubeadm cluster running in VMWare Workstation)\r\n```\r\nClient Version: version.Info{Major:\"1\", Minor:\"16\", GitVersion:\"v1.16.0\", GitCommit:\"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77\", GitTreeState:\"clean\", BuildDate:\"2019-09-18T14:36:53Z\", GoVersion:\"go1.12.9\", Compiler:\"gc\", Platform:\"linux/amd64\"}\r\nServer Version: version.Info{Major:\"1\", Minor:\"16\", GitVersion:\"v1.16.0\", GitCommit:\"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77\", GitTreeState:\"clean\", BuildDate:\"2019-09-18T14:27:17Z\", GoVersion:\"go1.12.9\", Compiler:\"gc\", Platform:\"linux/amd64\"}\r\n```\r\n\r\n","date_published":"2019-09-27T16:53:31Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11253","id":"CVE-2019-11253","status":"fixed","summary":"Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack","url":"https://github.com/kubernetes/kubernetes/issues/83253"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11250","issue_number":81114},"content_text":"This issue was reported in the [Kubernetes Security Audit Report](https://github.com/kubernetes/community/blob/master/wg-security-audit/findings/Kubernetes%20Final%20Report.pdf)\r\n\r\n**Description**\r\nKubernetes requires an authentication mechanism to enforce users’ privileges. One method of authentication, bearer tokens, are opaque strings used to associate a user with their having successfully authenticated previously. Any user with possession of this token may masquerade as the original user (the “bearer”) without further authentication.\r\n\r\nWithin Kubernetes, the bearer token is captured within the hyperkube kube-apiserver system logs at high verbosity levels (--v 10). A malicious user with access to the system logs on such a system could masquerade as any user who has previously logged into the system.\r\n\r\n**Exploit Scenario**\r\nAlice logs into a Kubernetes cluster and is issued a Bearer token. The system logs her token. Eve, who has access to the logs but not the production Kubernetes cluster, replays Alice’s Bearer token, and can masquerade as Alice to the cluster.\r\n\r\n**Recommendation**\r\nShort term, remove the Bearer token from the log. Do not log any authentication credentials within the system, including tokens, private keys, or passwords that may be used to authenticate to the production Kubernetes cluster, regardless of the logging level.\r\n\r\nLong term, either implement policies that enforce code review to ensure that sensitive data is not exposed in logs, or implement logging filters that check for sensitive data and remove it prior to outputting the log. In either case, ensure that sensitive data cannot be trivially stored in logs. \r\n\r\n**Anything else we need to know?**:\r\n\r\nSee #81146 for current status of all issues created from these findings.\r\n\r\nThe vendor gave this issue an ID of TOB-K8S-001 and it was finding 6 of the report.\r\n\r\nThe vendor considers this issue Medium Severity.\r\n\r\nTo view the original finding, begin on page 31 of the [Kubernetes Security Review Report](https://github.com/kubernetes/community/blob/master/wg-security-audit/findings/Kubernetes%20Final%20Report.pdf)\r\n\r\n**Environment**:\r\n\r\n- Kubernetes version: 1.13.4","date_published":"2019-08-08T02:03:04Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11250","id":"CVE-2019-11250","status":"fixed","summary":"Bearer tokens are revealed in logs (audit finding TOB-K8S-001)","url":"https://github.com/kubernetes/kubernetes/issues/81114"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11248","issue_number":81023},"content_text":"The debugging endpoint `/debug/pprof` is exposed over the unauthenticated Kubelet healthz port. Versions prior to 1.15.0, 1.14.4, 1.13.8, and 1.12.10 are affected. The issue is of medium severity, but not exposed by the default configuration. If you are exposed we recommend upgrading to at least one of the versions listed.\r\n\r\n**Am I vulnerable?**\r\nBy default, the Kubelet exposes unauthenticated healthz endpoints on port :10248, but only over localhost. If your nodes are using a non-localhost healthzBindAddress (--health-bind-address), and an older version, you may be vulnerable. If your nodes are using the default localhost healthzBindAddress, it is only exposed to pods or processes running in the host network namespace.\r\n\r\nRun `kubectl get nodes` to see whether nodes are running a vulnerable version.\r\n\r\nRun `kubectl get --raw /api/v1/nodes/${NODE_NAME}/proxy/configz` to check whether the \"healthzBindAddress\" is non-local.\r\n\r\n**How do I mitigate the vulnerability?**\r\n* Upgrade to a patched version (1.15.0+, 1.14.4+, 1.13.8+, or 1.12.10+)\r\n* or, update node configurations to set the \"healthzBindAddress\" to \"127.0.0.1\".\r\n\r\nhttps://github.com/kubernetes/kubernetes/pull/79184 fixed in 1.12.10\r\nhttps://github.com/kubernetes/kubernetes/pull/79183 fixed in 1.13.8\r\nhttps://github.com/kubernetes/kubernetes/pull/79182 fixed in 1.14.4\r\nhttps://github.com/kubernetes/kubernetes/pull/78313 fixed in 1.15.0\r\n\r\n**Vulnerability Details**\r\nThe `go pprof` endpoint is exposed over the Kubelet's healthz port. This debugging endpoint can potentially leak sensitive information such as internal Kubelet memory addresses and configuration, or for limited denial of service.\r\n\r\nThanks to Jordan Zebor of F5 Networks for reporting this problem.\r\n\r\n/area security\r\n/close","date_published":"2019-08-06T14:34:33Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11248","id":"CVE-2019-11248","status":"fixed","summary":"/debug/pprof exposed on kubelet's healthz port","url":"https://github.com/kubernetes/kubernetes/issues/81023"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11249","issue_number":80984},"content_text":"[CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N)\r\n\r\nA third issue was discovered with the Kubernetes `kubectl cp` command that could enable a directory traversal such that a malicious container could replace or create files on a user’s workstation. The vulnerability is a client-side defect and requires user interaction to be exploited.\r\n \r\n**Vulnerable versions:**\r\nKubernetes 1.0.x-1.12.x\r\nKubernetes 1.13.0-1.13.8\r\nKubernetes 1.14.0-1.14.4\r\nKubernetes 1.15.0-1.15.1\r\n \r\n**Vulnerable configurations:**\r\nAll `kubectl` clients running a vulnerable version and using the `cp` operation.\r\n \r\n**Vulnerability impact:**\r\nA malicious user can potentially create or overwrite files outside of the destination directory of the `kubectl cp` operation.\r\n \r\n**Mitigations prior to upgrading:**\r\nAvoid using `kubectl cp` with any untrusted workloads.\r\n \r\n**Fixed versions:**\r\nFixed in v1.13.9 by #80871\r\nFixed in v1.14.5 by #80870\r\nFixed in v1.15.2 by #80869\r\nFixed in master by #80436\r\n \r\n**Fix impact:**\r\nThe `kubectl cp` function is prevented from creating or modifying files outside the destination directory.\r\n\r\n**Acknowledgements:**\r\nThis issue was discovered by Yang Yang of Amazon, who also provided a patch. Thanks also to the release managers for creating the security releases.","date_published":"2019-08-05T12:44:23Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11249","id":"CVE-2019-11249","status":"fixed","summary":"Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal","url":"https://github.com/kubernetes/kubernetes/issues/80984"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11247","issue_number":80983},"content_text":"[CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L)\r\n \r\nThe API server mistakenly allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced. Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges).\r\n \r\n**Vulnerable versions:**\r\nKubernetes 1.7.x-1.12.x\r\nKubernetes 1.13.0-1.13.8\r\nKubernetes 1.14.0-1.14.4\r\nKubernetes 1.15.0-1.15.1\r\n \r\n**Vulnerable configurations:**\r\nAll clusters that have rolebindings to roles and clusterroles that include authorization rules for cluster-scoped custom resources.\r\n \r\n**Vulnerability impact:**\r\nA user with access to custom resources in a single namespace can access custom resources with cluster scope.\r\n \r\n**Mitigations prior to upgrading:**\r\nTo mitigate, remove authorization rules that grant access to cluster-scoped resources within namespaces. For example, RBAC roles and clusterroles intended to be referenced by namespaced rolebindings should not grant access to `resources:[*], apiGroups:[*]`, or grant access to cluster-scoped custom resources.\r\n \r\n \r\n**Fixed versions:**\r\nFixed in v1.13.9 by #80852\r\nFixed in v1.14.5 by #80851\r\nFixed in v1.15.2 by #80850\r\nFixed in master by #80750\r\n \r\n**Fix impact:**\r\nPermission to the correct scope will be required to access cluster-scoped custom resources.\r\n\r\n**Acknowledgements:**\r\nThis issue was discovered by Prabu Shyam of Verizon Media. Thanks to Stefan Schimanski for the fix, to David Eads for the fix review, and to the release managers for creating the security releases.\r\n","date_published":"2019-08-05T12:44:08Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11247","id":"CVE-2019-11247","status":"fixed","summary":"API server allows access to custom resources via wrong scope","url":"https://github.com/kubernetes/kubernetes/issues/80983"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11245","issue_number":78308},"content_text":"[CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L), 4.9 (medium)\r\n\r\nIn kubelet v1.13.6 and v1.14.2, containers for pods that do not specify an explicit `runAsUser` attempt to run as uid 0 (root) on container restart, or if the image was previously pulled to the node. If the pod specified `mustRunAsNonRoot: true`, the kubelet will refuse to start the container as root. If the pod did not specify `mustRunAsNonRoot: true`, the kubelet will run the container as uid 0.\r\n\r\nCVE-2019-11245 will be **fixed** in the following Kubernetes releases:\r\n\r\n* v1.13.7 in https://github.com/kubernetes/kubernetes/pull/78320\r\n* v1.14.3 in https://github.com/kubernetes/kubernetes/pull/78316\r\n\r\nFixed by #78261 in master\r\n\r\n### Affected components:\r\n\r\n* Kubelet\r\n\r\n### Affected versions:\r\n\r\n* Kubelet v1.13.6\r\n* Kubelet v1.14.2\r\n\r\n### Affected configurations:\r\n\r\nClusters with:\r\n* Kubelet versions v1.13.6 or v1.14.2\r\n* Pods that do not specify an explicit `runAsUser: \u003cuid\u003e` or `mustRunAsNonRoot:true`\r\n\r\n### Impact:\r\n\r\nIf a pod is run without any user controls specified in the pod spec (like `runAsUser: \u003cuid\u003e` or `mustRunAsNonRoot:true`), a container in that pod that would normally run as the USER specified in the container image manifest can sometimes be run as root instead (on container restart, or if the image was previously pulled to the node)\r\n\r\n* pods that specify an explicit `runAsUser` are unaffected and continue to work properly\r\n* podSecurityPolicies that force a `runAsUser` setting are unaffected and continue to work properly\r\n* pods that specify `mustRunAsNonRoot:true` will refuse to start the container as uid 0, which can affect availability\r\n* pods that do not specify `runAsUser` or `mustRunAsNonRoot:true` will run as uid 0 on restart or if the image was previously pulled to the node\r\n\r\n### Mitigations:\r\n\r\nThis section lists possible mitigations to use prior to upgrading.\r\n\r\n* Specify `runAsUser` directives in pods to control the uid a container runs as\r\n* Specify `mustRunAsNonRoot:true` directives in pods to prevent starting as root (note this means the attempt to start the container will fail on affected kubelet versions)\r\n* Downgrade kubelets to v1.14.1 or v1.13.5 as instructed by your Kubernetes distribution.\r\n\r\n**original issue description follows**\r\n\r\n**What happened**:\r\n\r\nWhen I launch a pod from a docker image that specifies a USER in the Dockerfile, the container only runs as that user on its first launch. After that the container runs as UID=0.\r\n\r\n**What you expected to happen**:\r\nI expect the container to act consistently every launch, and probably with the USER specified in the container.\r\n\r\n**How to reproduce it (as minimally and precisely as possible)**:\r\nTesting with minikube (same test specifying v1.14.1, `kubectl logs test` always returns 11211):\r\n```\r\n$ minikube start --kubernetes-version v1.14.2\r\n😄 minikube v1.1.0 on linux (amd64)\r\n💿 Downloading Minikube ISO ...\r\n 131.28 MB / 131.28 MB [============================================] 100.00% 0s\r\n🔥 Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...\r\n🐳 Configuring environment for Kubernetes v1.14.2 on Docker 18.09.6\r\n💾 Downloading kubeadm v1.14.2\r\n💾 Downloading kubelet v1.14.2\r\n🚜 Pulling images ...\r\n🚀 Launching Kubernetes ... \r\n⌛ Verifying: apiserver proxy etcd scheduler controller dns\r\n🏄 Done! kubectl is now configured to use \"minikube\"\r\n$ cat test.yaml\r\n---\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: test\r\nspec:\r\n containers:\r\n - name: test\r\n image: memcached:latest\r\n imagePullPolicy: IfNotPresent\r\n command: [\"/bin/bash\"]\r\n args:\r\n - -c\r\n - 'id -u; sleep 30'\r\n$ kubectl apply -f test.yaml \r\npod/test created\r\n\r\n# as soon as pod starts\r\n$ kubectl logs test\r\n11211\r\n# Wait 30 seconds for container to restart\r\n$ kubectl logs test\r\n0\r\n# Try deleting/recreating the pod\r\n$ kubectl delete pod test\r\npod \"test\" deleted\r\n$ kubectl apply -f test.yaml \r\npod/test created\r\n$ kubectl logs test\r\n0\r\n```\r\n\r\n**Anything else we need to know?**:\r\n\r\n**Environment**:\r\n- Kubernetes version (use `kubectl version`): I get the results I expect in v1.13.5 and v1.14.1. The problem exists in v1.13.6 and v1.14.2\r\n- Cloud provider or hardware configuration: minikube v1.1.0 using VirtualBox\r\n- OS (e.g: `cat /etc/os-release`):\r\n- Kernel (e.g. `uname -a`):\r\n- Install tools:\r\n- Network plugin and version (if this is a network-related bug):\r\n- Others:\r\n","date_published":"2019-05-24T16:14:49Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11245","id":"CVE-2019-11245","status":"fixed","summary":"container uid changes to root after first restart or if image is already pulled to the node","url":"https://github.com/kubernetes/kubernetes/issues/78308"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11243","issue_number":76797},"content_text":"CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N\r\n\r\nThe `rest.AnonymousClientConfig()` method returns a copy of the provided config, with credentials removed (bearer token, username/password, and client certificate/key data).\r\n\r\nIn the following versions, `rest.AnonymousClientConfig()` did not effectively clear service account credentials loaded using `rest.InClusterConfig()`:\r\n* v1.12.0-v1.12.4\r\n* v1.13.0\r\n\r\n**What is the impact?**\r\n* `k8s.io/client-go` users that use the `rest.AnonymousClientConfig()` method directly with client config loaded with `rest.InClusterConfig()` receive back a client config which can still send the loaded service account token with requests.\r\n\r\n**How was the issue fixed?**\r\n* In 1.12.5+ and 1.13.1+, `rest.InClusterConfig()` was modified to return a client config that is safe to use with the `rest.AnonymousClientConfig()` method (https://github.com/kubernetes/kubernetes/pull/71713)\r\n* In v1.15.0, the `rest.AnonymousClientConfig()` will also exclude the `config.Transport` and `config.WrapTransport` fields, in addition to the explicit credential-carrying fields. (https://github.com/kubernetes/kubernetes/pull/75771)\r\n\r\n**How do I resolve the issue?**\r\n* Upgrade `k8s.io/client-go` to `kubernetes-1.12.5`, `kubernetes-1.13.1`, `kubernetes-1.14.0`, or higher\r\n* or manually clear the `config.WrapTransport` and `config.Transport` fields in addition to calling `rest.AnonymousClientConfig()`\r\n\r\nThanks to Oleg Bulatov of Red Hat for reporting this issue.\r\n\r\n/area security\r\n/kind bug\r\n/sig auth\r\n/sig api-machinery\r\n/assign\r\n/close","date_published":"2019-04-18T21:31:53Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11243","id":"CVE-2019-11243","status":"fixed","summary":"rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig()","url":"https://github.com/kubernetes/kubernetes/issues/76797"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-11244","issue_number":76676},"content_text":"In kubectl v1.8.0+, schema info is cached in the location specified by `--cache-dir` (defaulting to `$HOME/.kube/http-cache`), written with world-writeable permissions (rw-rw-rw-).\r\n\r\nIf `--cache-dir` is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.\r\n\r\nCVSS score: CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N (3.3, low)\r\n\r\n**What versions are affected?**\r\nkubectl v1.8.0+\r\n\r\n**What configurations are affected?**\r\nInvocations that point `--cache-dir` at world-writeable locations\r\n\r\n**Impact**\r\nMalformed responses written to the cache directory can disrupt the kubectl invocation\r\n\r\n**Workaround**\r\nUse the default `--http-cache` location in the $HOME directory or point it at a directory that is only accessible to desired users/groups.\r\n\r\n\r\n\r\n(original description follows) ====\r\nWhat happened: The files inside of \".kube/http-cache\" are world writeable (rw-rw-rw-). While the default for these files appears to be the home directory, using the \"--cache-dir\" flag could put these files into a place where world writeable files would allow any user / process to modify the cache files. Modification of the cache files could influence the kubectl utility in a negative way for other users.\r\n\r\nWhat you expected to happen: Apply stricter file permissions to the http-cache files.\r\n\r\nHow to reproduce it (as minimally and precisely as possible): Run any generic kubectl command which is successful and then list the cache directory ~/.kube/http-cache/*\r\n \r\n$ kubectl get pods --all-namespaces\r\n$ ls -la ~/.kube/http-cache/*\r\n\r\nAnything else we need to know?: I estimate this is a low severity security issue with a CVSS score of \"3.3 / CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N\" - https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N\r\n\r\nEnvironment: Linux\r\n \r\nKubernetes version (use kubectl version):Client Version: version.Info{Major:\"1\", Minor:\"12\", GitVersion:\"v1.12.6\", GitCommit:\"ab91afd7062d4240e95e51ac00a18bd58fddd365\", GitTreeState:\"clean\", BuildDate:\"2019-02-26T12:49:28Z\", GoVersion:\"go1.10.8\", Compiler:\"gc\", Platform:\"linux/amd64\"}\r\nServer Version: version.Info{Major:\"1\", Minor:\"12\", GitVersion:\"v1.12.6\", GitCommit:\"ab91afd7062d4240e95e51ac00a18bd58fddd365\", GitTreeState:\"clean\", BuildDate:\"2019-02-26T12:49:28Z\", GoVersion:\"go1.10.8\", Compiler:\"gc\", Platform:\"linux/amd64\"}\r\n\r\nCloud provider or hardware configuration: AWS. Running kube api server in hyperkube.\r\n\r\nOS (e.g: cat /etc/os-release):\r\nNAME=\"CentOS Linux\"\r\nVERSION=\"7.1808 (Core)\"\r\nID=\"centos\"\r\nID_LIKE=\"rhel fedora\"\r\nVERSION_ID=\"7\"\r\nPRETTY_NAME=\"CentOS Linux 7.1808 (Core)\"\r\nANSI_COLOR=\"0;31\"\r\nCPE_NAME=\"cpe:/o:centos:centos:7\"\r\nHOME_URL=\"https://www.centos.org/\"\r\nBUG_REPORT_URL=\"https://bugs.centos.org/\"\r\nCENTOS_MANTISBT_PROJECT=\"CentOS-7\"\r\nCENTOS_MANTISBT_PROJECT_VERSION=\"7\"\r\nREDHAT_SUPPORT_PRODUCT=\"centos\"\r\nREDHAT_SUPPORT_PRODUCT_VERSION=\"7\"\r\nOSTREE_VERSION=7.1808\r\n \r\nKernel (e.g. uname -a): Linux hackit.internal 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux\r\n \r\nInstall tools: Manual installation.\r\n \r\nOthers: n/a\r\n","date_published":"2019-04-16T20:14:25Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-11244","id":"CVE-2019-11244","status":"fixed","summary":"`kubectl --http-cache=\u003cworld-accessible dir\u003e` creates world-writeable cached schema files","url":"https://github.com/kubernetes/kubernetes/issues/76676"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2019-1002100","issue_number":74534},"content_text":"CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) (6.5, medium)\r\n\r\nUsers that are authorized to make patch requests to the Kubernetes API Server can send a specially crafted patch of type “json-patch” (e.g. `kubectl patch --type json` or `\"Content-Type: application/json-patch+json\"`) that consumes excessive resources while processing, causing a Denial of Service on the API Server.\r\n\r\nThanks to Carl Henrik Lunde for reporting this problem.\r\n\r\nCVE-2019-1002100 is **fixed** in the following Kubernetes releases:\r\n\r\n* [v1.11.8](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md/#v1118)\r\n* [v1.12.6](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md/#v1126)\r\n* [v1.13.4](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md/#v1134)\r\n\r\n### Affected components:\r\n* Kubernetes API server\r\n\r\n### Affected versions:\r\n* Kubernetes v1.0.x-1.10.x\r\n* Kubernetes v1.11.0-1.11.7 (fixed in [v1.11.8](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md/#v1118))\r\n* Kubernetes v1.12.0-1.12.5 (fixed in [v1.12.6](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md/#v1126))\r\n* Kubernetes v1.13.0-1.13.3 (fixed in [v1.13.4](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md/#v1134))\r\n\r\n### Mitigations:\r\n* Remove ‘patch’ permissions from untrusted users.\r\n\r\nNote: If you are using binaries or packages provided by a distributor (not the ones provided in the open source release artifacts), you should contact them to determine what versions resolve this CVE. Distributors may choose to provide support for older releases beyond the ones maintained by the open source project.\r\n\r\n### Post-mortem:\r\n* [Document](https://github.com/kubernetes/kubernetes/files/3005552/PM-CVE-2019-1002100.pdf)\r\n","date_published":"2019-02-25T19:39:09Z","external_url":"https://www.cve.org/cverecord?id=CVE-2019-1002100","id":"CVE-2019-1002100","status":"fixed","summary":"json-patch requests can exhaust apiserver resources","url":"https://github.com/kubernetes/kubernetes/issues/74534"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2018-1002105","issue_number":71411},"content_text":"[CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) (9.8, critical)\r\n\r\nWith a specially crafted request, users that are authorized to establish a connection through the Kubernetes API server to a backend server can then send arbitrary requests over the same connection directly to that backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection.\r\n\r\nThanks to Darren Shepherd for reporting this problem.\r\n\r\nCVE-2018-1002105 is **fixed** in the following Kubernetes releases:\r\n\r\n* [v1.10.11](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md/#v11011)\r\n* [v1.11.5](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md/#v1115)\r\n* [v1.12.3](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md/#v1123)\r\n* [v1.13.0-rc.1](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md/#v1130-rc1)\r\n\r\n### Affected components:\r\n\r\n* Kubernetes API server\r\n\r\n### Affected versions:\r\n\r\n* Kubernetes v1.0.x-1.9.x\r\n* Kubernetes v1.10.0-1.10.10 (fixed in [v1.10.11](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md/#v11011))\r\n* Kubernetes v1.11.0-1.11.4 (fixed in [v1.11.5](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md/#v1115))\r\n* Kubernetes v1.12.0-1.12.2 (fixed in [v1.12.3](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md/#v1123))\r\n\r\nNote: If you are using binaries or packages provided by a distributor (not the ones provided in the open source release artifacts), you should contact them to determine what versions resolve this CVE. Distributors may choose to provide support for older releases beyond the ones maintained by the open source project.\r\n\r\n### Affected configurations:\r\n\r\n* Clusters \u003e= 1.6.x that run aggregated API servers (like the metrics server) that are directly accessible from the Kubernetes API server’s network. If there are aggregated API servers configured in a cluster, the following command will return the names of the associated APIService objects (if no names are listed, or the kube-apiserver is an older version that does not have the apiservices API, then the cluster has no aggregated API servers configured):\r\n ```\r\n kubectl get apiservices \\\r\n -o 'jsonpath={range .items[?(@.spec.service.name!=\"\")]}{.metadata.name}{\"\\n\"}{end}'\r\n ```\r\n* Clusters \u003e= 1.0.x that grant pod exec/attach/portforward permissions to users that are not expected to have full access to kubelet APIs\r\n\r\n### Vulnerability impact:\r\n\r\n* An API call to any aggregated API server endpoint can be escalated to perform any API request against that aggregated API server, as long as that aggregated API server is directly accessible from the Kubernetes API server’s network. **[Default RBAC policy](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles) allows all users (authenticated and unauthenticated) to perform discovery API calls that allow this escalation against any aggregated API servers configured in the cluster.**\r\n* A pod exec/attach/portforward API call can be escalated to perform any API request against the kubelet API on the node specified in the pod spec (e.g. listing all pods on the node, running arbitrary commands inside those pods, and obtaining the command output). **Pod exec/attach/portforward permissions are included in the admin/edit RBAC roles intended for namespace-constrained users.**\r\n\r\n### Mitigations:\r\n\r\nThis section lists possible mitigations to use prior to upgrading. Note that many of the mitigations are likely to be disruptive, and upgrading to a fixed version is strongly recommended.\r\n\r\n#### Mitigations for the anonymous user -\u003e aggregated API server escalation include:\r\n* suspend use of aggregated API servers (note that this will disrupt users of the APIs provided by the aggregated server)\r\n* disable anonymous requests by passing `--anonymous-auth=false` to the kube-apiserver (note that this may disrupt load balancer or kubelet health checks of the kube-apiserver, and breaks `kubeadm join` setup flows)\r\n* remove *all* anonymous access to *all* aggregated APIs (including discovery permissions granted by the [default discovery role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles))\r\n\r\n#### Mitigations for the authenticated user -\u003e aggregated API server escalation include:\r\n* suspend use of aggregated API servers (note that this will disrupt users of the APIs provided by the aggregated server)\r\n* remove *all* access to *all* aggregated APIs (including discovery permissions granted by the [default discovery role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles)) from users that should not have full access to the aggregated APIs (note that this may disrupt users and controllers that make use of discovery information to map API types to URLs)\r\n\r\n#### Mitigation for the authorized pod exec/attach/portforward -\u003e kubelet API escalation:\r\n* Remove pod exec/attach/portforward permissions from users that should not have full access to the kubelet API\r\n\r\n### Detection:\r\n\r\nThere is no simple way to detect whether this vulnerability has been used. Because the unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log. The requests do appear in the kubelet or aggregated API server logs, but are indistinguishable from correctly authorized and proxied requests via the Kubernetes API server.\r\n\r\n### Post-mortem:\r\n\r\n* [Document](https://github.com/kubernetes/kubernetes/files/2700818/PM-CVE-2018-1002105.pdf)\r\n* [Recorded meeting](https://youtu.be/1M4oXPgxYyE)","date_published":"2018-11-26T11:07:36Z","external_url":"https://www.cve.org/cverecord?id=CVE-2018-1002105","id":"CVE-2018-1002105","status":"fixed","summary":"proxy request handling in kube-apiserver can leave vulnerable TCP connections","url":"https://github.com/kubernetes/kubernetes/issues/71411"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2018-1002101","issue_number":65750},"content_text":"This issue is tracked under CVE-2018-1002101\r\n\r\n\u003c!-- This form is for bug reports and feature requests ONLY!\r\n\r\nIf you're looking for help check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) and the [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/).\r\n\r\nIf the matter is security related, please disclose it privately via https://kubernetes.io/security/.\r\n--\u003e\r\n\r\n**Is this a BUG REPORT or FEATURE REQUEST?**:\r\n/kind bug\r\n\r\n\u003e Uncomment only one, leave it on its own line:\r\n\u003e\r\n\u003e /kind bug\r\n\u003e /kind feature\r\n\r\n\r\n**What happened**:\r\nuser PowerShell Environment Variables to store user input string to prevent command line injection, the env var in PowerShell would be taken as literal values and not as executable vulnerable code, this kind of fix is common for command line injection issue (called: parameterized way)\r\n\r\n**What you expected to happen**:\r\n\r\n**How to reproduce it (as minimally and precisely as possible)**:\r\n\r\n\r\n**Anything else we need to know?**:\r\n\r\n**Environment**:\r\n- Kubernetes version (use `kubectl version`):\r\n- Cloud provider or hardware configuration:\r\n- OS (e.g. from /etc/os-release):\r\n- Kernel (e.g. `uname -a`):\r\n- Install tools:\r\n- Others:\r\n\r\n/sig windows\r\n/sig storage\r\n/assign","date_published":"2018-07-03T08:06:15Z","external_url":"https://www.cve.org/cverecord?id=CVE-2018-1002101","id":"CVE-2018-1002101","status":"fixed","summary":"smb mount security issue","url":"https://github.com/kubernetes/kubernetes/issues/65750"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2018-1002100","issue_number":61297},"content_text":"**Is this a BUG REPORT or FEATURE REQUEST?**: Bug\r\n\r\n/kind bug\r\n\r\n**What happened**:\r\nkubectl cp \u003cpod-name\u003e:/some/remote/dir /some/local/dir\r\n\r\nIf the container returns a malformed tarfile with paths like:\r\n\r\n'/some/remote/dir/../../../../tmp/foo' kubectl writes this to `/tmp/foo` instead of `/some/local/dir/tmp/foo`\r\n\r\n**What you expected to happen**:\r\n\r\nI expect kubectl to clean up the path and write to `/some/local/dir/tmp/foo`\r\n\r\n**Notes**\r\nOriginal credit to @hansmi (Michael Hanselmann) for originally reporting the bug.\r\n\r\nTracked as CVE-2018-1002100\r\n","date_published":"2018-03-16T19:24:46Z","external_url":"https://www.cve.org/cverecord?id=CVE-2018-1002100","id":"CVE-2018-1002100","status":"fixed","summary":"Kubectl copy doesn't check for paths outside of it's destination directory.","url":"https://github.com/kubernetes/kubernetes/issues/61297"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2017-1002102","issue_number":60814},"content_text":"[CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H)\r\n\r\nThis vulnerability allows containers using a secret, configMap, projected or downwardAPI volume to trigger deletion of arbitrary files and directories on the nodes where they are running.\r\n\r\nThanks to Joel Smith of Red Hat for reporting this problem.\r\n\r\n**Vulnerable versions:**\r\n* Kubernetes 1.3.x-1.6.x\r\n* Kubernetes 1.7.0-1.7.13\r\n* Kubernetes 1.8.0-1.8.8\r\n* Kubernetes 1.9.0-1.9.3\r\n\r\n**Vulnerable configurations:**\r\n* Clusters that run untrusted containers with secret, configMap, downwardAPI or projected volumes mounted (including auto-added service account token mounts).\r\n\r\n**Vulnerability impact:**\r\nA malicious container running in a pod with a secret, configMap, downwardAPI or projected volume mounted (including auto-added service account token mounts) can cause the Kubelet to remove any file or directory on the host filesystem.\r\n\r\n**Mitigations prior to upgrading:**\r\nDo not allow containers to be run with secret, configMap, downwardAPI and projected volumes (note that this prevents use of service account tokens in pods, and requires use of [`automountServiceAccountToken: false`](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server))\r\n\r\n**Fixed versions:**\r\n* Fixed in v1.7.14 by #60516\r\n* Fixed in v1.8.9 by #60515\r\n* Fixed in v1.9.4 by #60258\r\n* Fixed in master by #58720 (included in v1.10.0-beta.1 and up, will be in v1.10.0)\r\n\r\n**Fix impact:**\r\nSecret, configMap, downwardAPI and projected volumes will be mounted as read-only volumes. Applications that attempt to write to these volumes will receive read-only filesystem errors. Previously, applications were allowed to make changes to these volumes, but those changes were reverted at an arbitrary interval by the system. Applications should be re-configured to write derived files to another location.\r\n","date_published":"2018-03-05T20:55:20Z","external_url":"https://www.cve.org/cverecord?id=CVE-2017-1002102","id":"CVE-2017-1002102","status":"fixed","summary":"atomic writer volume handling allows arbitrary file deletion in host filesystem","url":"https://github.com/kubernetes/kubernetes/issues/60814"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2017-1002101","issue_number":60813},"content_text":"[CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)\r\n\r\nThis vulnerability allows containers using [subpath volume mounts](https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath) with any volume type (including non-privileged pods, subject to file permissions) to access files/directories outside of the volume, including the host’s filesystem.\r\n\r\nThanks to Maxim Ivanov for reporting this problem.\r\n\r\n**Vulnerable versions:**\r\n* Kubernetes 1.3.x-1.6.x\r\n* Kubernetes 1.7.0-1.7.13\r\n* Kubernetes 1.8.0-1.8.8\r\n* Kubernetes 1.9.0-1.9.3\r\n\r\n**Vulnerable configurations:**\r\n* Clusters that allow untrusted users to control pod spec content, and prevent host filesystem access via hostPath volumes (or other volume types) using PodSecurityPolicy (or custom admission plugins)\r\n* Clusters that make use of [subpath volume mounts](https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath) with untrusted containers or containers that can be compromised\r\n\r\n**Vulnerability impact:**\r\nA specially crafted pod spec combined with malicious container behavior can allow read/write access to arbitrary files outside volumes specified in the pod, including the host’s filesystem. This can be accomplished with any volume type, including emptyDir, and can be accomplished with a non-privileged pod (subject to file permissions).\r\n\r\n**Mitigations prior to upgrading:**\r\nPrevent untrusted users from creating pods (and pod-creating objects like deployments, replicasets, etc), or [disable all volume types](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) with PodSecurityPolicy (note that this prevents use of service account tokens in pods, and requires use of [`automountServiceAccountToken: false`](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server))\r\n\r\n**Fixed versions:**\r\n* Fixed in v1.7.14 by #61047\r\n* Fixed in v1.8.9 by #61046\r\n* Fixed in v1.9.4 by #61045\r\n* Fixed in master by #61044 (included in v1.10.0-beta.3, will be in v1.10.0)\r\n\r\n**Action Required:**\r\nIn addition to upgrading, PodSecurityPolicy objects designed to limit container permissions must completely [disable hostPath volumes](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems), as the allowedHostPaths feature does not restrict symlink creation and traversal. Future enhancements (tracked in issue #61043) are required to limit hostPath use to read only volumes or exact path matches before a PodSecurityPolicy can effectively restrict hostPath usage to a given subpath.\r\n\r\n**Known issues:**\r\n* Status and availability of fixes for regressions in subPath volume mount handling are tracked in https://github.com/kubernetes/kubernetes/issues/61563","date_published":"2018-03-05T20:53:58Z","external_url":"https://www.cve.org/cverecord?id=CVE-2017-1002101","id":"CVE-2017-1002101","status":"fixed","summary":"subpath volume mount handling allows arbitrary file access in host filesystem","url":"https://github.com/kubernetes/kubernetes/issues/60813"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2017-1002100","issue_number":47611},"content_text":"","date_published":"2017-06-15T18:59:13Z","external_url":"https://www.cve.org/cverecord?id=CVE-2017-1002100","id":"CVE-2017-1002100","status":"fixed","summary":"Azure PV should be Private scope not Container scope","url":"https://github.com/kubernetes/kubernetes/issues/47611"},{"_kubernetes_io":{"google_group_url":"https://groups.google.com/g/kubernetes-announce/search?q=CVE-2017-1000056","issue_number":43459},"content_text":"A PodSecurityPolicy admission plugin vulnerability allows users to make use of any PodSecurityPolicy object, even ones they are not authorized to use.\r\n\r\nCVE: CVE-2017-1000056\r\n\r\n* Fixed in [v1.5.5](https://github.com/kubernetes/kubernetes/releases/tag/v1.5.5) in https://github.com/kubernetes/kubernetes/commit/7fef0a4f6a44ea36f166c39fdade5324eff2dd5e\r\n* Fixed in release-1.5 branch in https://github.com/kubernetes/kubernetes/pull/43491\r\n* Fixed in master in https://github.com/kubernetes/kubernetes/pull/43489\r\n\r\n**Who is affected?**\r\nOnly Kubernetes 1.5.0-1.5.4 installations that do _all_ of the following:\r\n* Enable the PodSecurityPolicy API (which is not enabled by default):\r\n `--runtime-config=extensions/v1beta1/podsecuritypolicy=true`\r\n* Enable the PodSecurityPolicy admission plugin (which is not enabled by default):\r\n `--admission-control=...,PodSecurityPolicy,...`\r\n* Use authorization to limit users' ability to use specific PodSecurityPolicy objects\r\n\r\nkubeadm and GKE do not allow enabling PodSecurityPolicy in 1.5, so are not affected by this vulnerability.\r\n\r\nkube-up.sh and kops do not enable PodSecurityPolicy by default, so are not affected by this vulnerability. A modified kube-up.sh or kops deployment could have enabled it.\r\n\r\n**What is the impact?**\r\nA user that is authorized to create pods can make use of any existing PodSecurityPolicy, even ones they are not authorized to use.\r\n\r\n**How can I mitigate this prior to installing 1.5.5?**\r\n1. Export existing PodSecurityPolicy objects:\r\n `kubectl get podsecuritypolicies -o yaml \u003e psp.yaml`\r\n\r\n2. Review and delete any PodSecurityPolicy objects you do not want all pod-creating users to be able to use (NOTE: Privileged users that were making use of those policies will also lose access to those policies). For example:\r\n `kubectl delete podsecuritypolicies/my-privileged-policy`\r\n\r\n3. After upgrading to 1.5.5, re-create the exported PodSecurityPolicy objects:\r\n `kubectl create -f psp.yaml`","date_published":"2017-03-21T15:22:29Z","external_url":"https://www.cve.org/cverecord?id=CVE-2017-1000056","id":"CVE-2017-1000056","status":"fixed","summary":"PodSecurityPolicy admission plugin authorizes incorrectly","url":"https://github.com/kubernetes/kubernetes/issues/43459"}],"title":"Kubernetes Vulnerability Announcements - CVE Feed","version":"https://jsonfeed.org/version/1.1"} ``` --- # Turnkey 云解决方案 | Kubernetes Turnkey 云解决方案 ============= 本页列示 Kubernetes 认证解决方案供应商。 在每一个供应商分页，你可以学习如何安装和设置生产就绪的集群。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 January 18, 2024 at 10:32 AM PST: [Update references to CNCF landscape (v2) (26e760da6e)](https://github.com/kubernetes/website/commit/26e760da6e76da033d69051a240b58bad9a5fa8f) --- # 使用部署工具安装 Kubernetes | Kubernetes 使用部署工具安装 Kubernetes =================== 搭建你自己的 Kubernetes 生产集群有许多方法和工具。例如： * [kubeadm](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/) * [Cluster API](https://cluster-api.sigs.k8s.io/) ： 一个 Kubernetes 子项目，专注于提供声明式 API 和工具，以简化多个 Kubernetes 集群的安装、升级和操作。 * [kOps](https://kops.sigs.k8s.io/) ：自动化集群制备工具。 有关教程、最佳实践、配置选项和社区联系信息，请查阅 [`kOps` 网站](https://kops.sigs.k8s.io/) 。 * [Kubespray](https://kubespray.io/) ： 提供了 [Ansible](https://docs.ansible.com/) Playbook、 [清单（Inventory）](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible/inventory.md) 、 制备工具和通用操作系统及 Kubernetes 集群配置管理任务领域的知识。 你可以通过 Slack 频道 [#kubespray](https://kubernetes.slack.com/messages/kubespray/) 联系此社区。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 December 10, 2024 at 9:53 AM PST: [\[zh\] Sync production-environment/tools/\_index.md (f1397acd7b)](https://github.com/kubernetes/website/commit/f1397acd7bd19578141d2a76c66b3f32b408f0e7) --- # 配置 | Kubernetes 配置 == Kubernetes 为配置 Pod 所提供的资源。 * * * ##### [ConfigMap](https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/) ##### [Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/) ##### [存活、就绪和启动探针](https://kubernetes.io/zh-cn/docs/concepts/configuration/liveness-readiness-startup-probes/) ##### [为 Pod 和容器管理资源](https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/) ##### [使用 kubeconfig 文件组织集群访问](https://kubernetes.io/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) ##### [Windows 节点的资源管理](https://kubernetes.io/zh-cn/docs/concepts/configuration/windows-resource-management/) 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 July 15, 2024 at 9:32 AM PST: [\[zh\] add liveness-readiness-startup-probes.md (6503adc6d2)](https://github.com/kubernetes/website/commit/6503adc6d25460be1380080149024ff4d9e3acd6) --- # Pengklonaan Volume CSI | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [CSI Volume Cloning](https://kubernetes.io/docs/concepts/storage/volume-pvc-datasource/) Pengklonaan Volume CSI ====================== FEATURE STATE: `Kubernetes v1.16 [beta]` Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](https://kubernetes.io/id/docs/concepts/storage/volumes) disarankan. Introduction ------------ Fitur [CSI](https://kubernetes.io/id/docs/concepts/storage/volumes/#csi "The Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers.") Volume Cloning menambahkan dukungan untuk merinci [PVC](https://kubernetes.io/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims "Mengklaim sumber daya penyimpanan yang didefinisikan di dalam suatu PersistentVolume, sehingga PersistentVolume tersebut dapat dipasang (mounted) sebagai sebuah volume pada suatu Container.") yang telah tersedia pada kolom `dataSource` untuk mengindikasikan bahwa seorang pengguna ingin melakukan pengklonaan terhadap sebuah [Volume](https://kubernetes.io/id/docs/concepts/storage/volumes/ "Sebuah direktori yang mengandung data, dapat diakses o;eh kontainer-kontainer di dalam pod.") . Sebuah klona didefinisikan sebagai sebuah duplikat dari sebuah Volume Kubernetes yang telah tersedia yang dapat digunakan sebagai sebuah Volume standar. Perbedaannya hanyalah pada saat penyediaannya, daripada membuat sebuah Volume kosong yang "baru", peranti penyokongnya membuat sebuah duplikat sama persis dari Volume yang dirinci. Implementasi dari pengklonaan, dari sudut pandang API Kubernetes, secara sederhana menambahkan kemampuan untuk merinci sebuah PVC yang telah tersedia sebagai sebuah dataSource saat pembuatan PVC. PVC sumber harus tertambat (_bound_) dan tersedia (tidak sedang digunakan). Pengguna-pengguna mesti menyadari hal-hal berikut saat menggunakan fitur ini: * Dukungan pengklonaan (`VolumePVCDataSource`) hanya tersedia untuk _driver-driver_ CSI. * Dukungan pengklonaan hanya tersedia untuk penyedia-penyedia dinamis. * _Driver-driver_ CSI mungkin telah atau belum mengimplementasi fungsi pengklonaan Volume. * Kamu hanya dapat mengklonakan sebuah PVC saat ia tersedia pada Namespace yang sama dengan PVC tujuan (sumber dan tujuan harus berada pada Namespace yang sama). * Pengklonaan hanya didukung pada Storage Class yang sama. * Volume tujuan harus memiliki Storage Class yang sama dengan sumbernya. * Storage Class bawaan dapat digunakan dan `storageClassName` dihilangkan dari `spec` Penyediaan ---------- Klona-klona disediakan sama seperti PVC lainnya dengan pengecualian dengan penambahan sebuah `dataSource` yang merujuk pada sebuah PVC yang telah tersedia pada Namespace yang sama. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: clone-of-pvc-1 namespace: myns spec: accessModes: - ReadWriteOnce storageClassName: cloning resources: requests: storage: 5Gi dataSource: kind: PersistentVolumeClaim name: pvc-1 Hasilnya adalah sebuah PVC baru dengan nama `clone-of-pvc-1` yang memiliki isi yang sama dengan sumber yang dirinci `pvc-1`. Penggunaan ---------- Setelah tersedianya PVC baru tersebut, PVC baru yang diklonakan tersebut digunakan sama seperti PVC lainnya. Juga diharapkan pada titik ini bahwa PVC baru tersebut adalah sebuah objek terpisah yang independen. Ia dapat digunakan, diklonakan, di-_snapshot_, atau dihapus secara terpisah dan tanpa perlu memikirkan PVC dataSource aslinya. Hal ini juga berarti bahwa sumber tidak terikat sama sekali dengan klona yang baru dibuat tersebut, dan dapat diubah atau dihapus tanpa memengaruhi klona yang baru dibuat tersebut. Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified July 10, 2020 at 10:24 PM PST: [Replace EN links to ID links (0c799ef757)](https://github.com/kubernetes/website/commit/0c799ef757368c8839a912df5d949fa2603042f5) --- # Service | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Service](https://kubernetes.io/docs/concepts/services-networking/service/) Service ======= [`Pod`](https://kubernetes.io/id/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat _mortal_. Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut tidak akan dihidupkan kembali. [`ReplicaSets`](https://kubernetes.io/id/docs/concepts/workloads/controllers/replicaset/) secara khusus bertugas membuat dan menghapus `Pod` secara dinamis (misalnya, pada proses _scaling out_ atau _scaling in_). Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil. Hal ini kemudian menimbulkan pertanyaan baru: apabila sebuah sekumpulan `Pod` (yang selanjutnya kita sebut _backend_) menyediakan _service_ bagi sebuah sekumpulan `Pod` lain (yang selanjutnya kita sebut _frontend_) di dalam klaster Kubernetes, bagaimana cara _frontend_ menemukan _backend_ mana yang digunakan? Inilah alasan kenapa `Service` ada. Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi set logis yang terdiri beberapa `Pod` serta _policy_ bagaimana cara kamu mengakses sekumpulan `Pod` tadi - seringkali disebut sebagai _microservices_. Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](https://kubernetes.io/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) (lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa sebuah _selector_). Sebagai contoh, misalnya terdapat sebuah _backend_ yang menyediakan fungsionalitas _image-processing_ yang memiliki 3 buah _replica_. _Replica-replica_ tadi sifatnya sepadan - dengan kata lain _frontend_ tidak peduli _backend_ manakah yang digunakan. Meskipun `Pod` penyusun sekumpulan _backend_ bisa berubah, _frontend_ tidak perlu peduli bagaimana proses ini dijalankan atau menyimpan _list_ dari _backend-backend_ yang ada saat itu. `Service` memiliki tujuan untuk _decouple_ mekanisme ini. Untuk aplikasi yang dijalankan di atas Kubernetes, Kubernetes menyediakan API _endpoint_ sederhana yang terus diubah apabila _state_ sebuah sekumpulan `Pod` di dalam suatu `Service` berubah. Untuk aplikasi _non-native_, Kubernetes menyediakan _bridge_ yang berbasis _virtual-IP_ bagi `Service` yang diarahkan pada `Pod` _backend_. Mendefinisikan sebuah `Service` ------------------------------- Sebuah `Service` di Kubernetes adalah sebuah objek REST, layaknya sebuah `Pod`. Seperti semua objek _REST_, definisi `Service` dapat dikirim dengan _method POST_ pada _apiserver_ untuk membuat sebuah instans baru. Sebagai contoh, misalnya saja kamu memiliki satu sekumpulan `Pod` yang mengekspos _port_ 9376 dan memiliki _label_ `"app=MyApp"`. kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 Spesifikasi ini akan ditranslasikan sebagai sebuah objek `Service` baru dengan nama `"my-service"` dengan _target port_ 9376 pada setiap `Pod` yang memiliki _label_ `"app=MyApp"`. `Service` ini juga akan memiliki alamat IP tersendiri (yang terkadang disebut sebagai _"cluster IP"_), yang nantinya akan digunakan oleh _service proxy_ (lihat di bagian bawah). _Selector_ pada `Service` akan selalu dievaluasi dan hasilnya akan kembali dikirim dengan menggunakan _method POST_ ke objek `Endpoints` yang juga disebut `"my-service"`. Perhatikan bahwa sebuah `Service` dapat melakukan pemetaan setiap _incoming port_ pada `targetPort` mana pun. Secara _default_, _field_ `targetPort` akan memiliki _value_ yang sama dengan _value_ dari _field_ `port`. Hal menarik lainnya adalah _value_ dari `targetPort` bisa saja berupa string yang merujuk pada nama dari _port_ yang didefinisikan pada `Pod` _backend_. Nomor _port_ yang diberikan pada _port_ dengan nama tadi bisa saja memiliki nilai yang berbeda di setiap `Pod` _backend_. Hal ini memberikan fleksibilitas pada saat kamu melakukan _deploy_ atau melakukan perubahan terhadap `Service`. Misalnya saja suatu saat kamu ingin mengubah nomor _port_ yang ada pada `Pod` _backend_ pada rilis selanjutnya tanpa menyebabkan permasalahan pada sisi klien. Secara _default_, protokol yang digunakan pada _service_ adalah `TCP`, tapi kamu bisa saja menggunakan [protokol yang tersedia](https://kubernetes.io/id/docs/concepts/services-networking/service/#protokol-yang-tersedia) . Karena banyak `Service` memiliki kebutuhan untuk mengekspos lebih dari sebuah _port_, Kubernetes menawarkan definisi _multiple_ _port_ pada sebuah objek _Service_. Setiap definisi _port_ dapat memiliki protokol yang berbeda. ### `Service` tanpa _selector_ Secara umum, `Service` memberikan abstraksi mekanisme yang dilakukan untuk mengakses `Pod`, tapi mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja: * Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_, kamu ingin menggunakan basis datamu sendiri. * Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada [_Namespace_](https://kubernetes.io/id/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda. * Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih berada di luar klaster Kubernetes. Berdasarkan skenario-skenario di atas, kamu dapat membuat sebuah `Service` tanpa _selector_: kind: Service apiVersion: v1 metadata: name: my-service spec: ports: - protocol: TCP port: 80 targetPort: 9376 Karena `Service` ini tidak memiliki _selector_, objek `Endpoints` bagi `Service` ini tidak akan dibuat. Dengan demikian, kamu bisa membuat `Endpoints` yang kamu inginkan: kind: Endpoints apiVersion: v1 metadata: name: my-service subsets: - addresses: - ip: 1.2.3.4 ports: - port: 9376 #### Catatan: Perhatikan bahwa alamat IP yang kamu buat untuk `Endpoints` tidak boleh berupa _loopback_ (127.0.0.0/8), _link-local_ (169.254.0.0/16), atau _link-local multicast_ (224.0.0.0/24). Alamat IP tersebut juga tidak boleh berupa _cluster IP_ dari `Service` Kubernetes lainnya, karena `kube-proxy` belum menyediakan dukungan IP virtual sebagai _destination_. Cara mengakses suatu `Service` tanpa _selector_ sama saja dengan mengakses suatu `Service` dengan _selector_. Trafik yang ada akan di-_route_ ke `Endpoints` yang dispesifikasikan oleh pengguna (dalam contoh kali ini adalah `1.2.3.4:9376`). Sebuah `ExternalName` `Service` merupakan kasus spesial dari `Service` dimana `Service` tidak memiliki _selector_ dan menggunakan penamaan _DNS_. Untuk informasi lebih lanjut silahkan baca bagian [ExternalName](https://kubernetes.io/id/docs/concepts/services-networking/service/#externalname) . IP Virtual dan _proxy_ `Service` -------------------------------- Setiap _node_ di klaster Kubernetes menjalankan `kube-proxy`. `kube-proxy` bertanggung jawab terhadap implementasi IP virtual bagi _Services_ dengan tipe selain [`ExternalName`](https://kubernetes.io/id/docs/concepts/services-networking/service/#externalname) . Pada Kubernetes versi v1.0, _Services_ adalah "layer 4" (TCP/UDP pada IP), _proxy_ yang digunakan murni berada pada _userspace_. Pada Kubernetes v1.1, API `Ingress` ditambahkan untuk merepresentasikan "layer 7"(HTTP), _proxy_ `iptables` juga ditambahkan dan menjadi mode operasi _default_ sejak Kubernetes v1.2. Pada Kubernetes v1.8.0-beta.0, _proxy_ _ipvs_ juga ditambahkan. ### Mode _Proxy_: _userspace_ Pada mode ini, `kube-proxy` mengamati master Kubernetes apabila terjadi penambahan atau penghapusan objek `Service` dan `Endpoints`. Untuk setiap `Service`, `kube-proxy` akan membuka sebuah _port_ (yang dipilih secara acak) pada _node_ lokal. Koneksi pada _"proxy port"_ ini akan dihubungkan pada salah satu `Pod` _backend_ dari `Service` (yang tercatat pada `Endpoints`). `Pod` _backend_ yang akan digunakan akan diputuskan berdasarkan `SessionAffinity` pada `Service`. Langkah terakhir yang dilakukan oleh `kube-proxy` adalah melakukan instalasi _rules_ `iptables` yang akan mengarahkan trafik yang ada pada `clusterIP` (IP virtual) dan _port_ dari `Service` serta melakukan _redirect_ trafik ke _proxy_ yang memproksikan `Pod` _backend_. Secara _default_, mekanisme _routing_ yang dipakai adalah _round robin_. ![Ikhtisar diagram Services pada proxy userspace](https://kubernetes.io/images/docs/services-userspace-overview.svg) ### Mode _Proxy_: iptables Pada mode ini, `kube-proxy` mengamati master Kubernetes apabila terjadi penambahan atau penghapusan objek `Service` dan `Endpoints`. Untuk setiap `Service`, `kube-proxy` akan melakukan instalasi _rules_ `iptables` yang akan mengarahkan trafik ke `clusterIP` (IP virtual) dan _port_ dari `Service`. Untuk setiap objek `Endpoints`, `kube-proxy` akan melakukan instalasi _rules_ `iptables` yang akan memilih satu buah `Pod` _backend_. Secara _default_, pemilihan _backend_ ini dilakukan secara acak. Tentu saja, `iptables` yang digunakan tidak boleh melakukan _switching_ antara _userspace_ dan _kernelspace_, mekanisme ini harus lebih kokoh dan lebih cepat dibandingkan dengan _userspace_ _proxy_. Meskipun begitu, berbeda dengan mekanisme _proxy_ _userspace_, _proxy_ `iptables` tidak bisa secara langsung menjalankan mekanisme _retry_ ke `Pod` lain apabila `Pod` yang sudah dipilih sebelumnya tidak memberikan respons, dengan kata lain hal ini akan sangat bergantung pada [readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#defining-readiness-probes) . ![Ikhtisar diagram Services pada proxy iptables](https://kubernetes.io/images/docs/services-iptables-overview.svg) ### Mode _Proxy_: ipvs FEATURE STATE: `Kubernetes v1.9 [beta]` Pada mode ini, `kube-proxy` mengamati _Services_ dan `Endpoints`, kemudian memanggil _interface_ _netlink_ untuk membuat _rules_ _ipvs_ yang sesuai serta melakukan sinkronisasi _rules_ _ipvs_ dengan _Services_ dan `Endpoints` Kubernetes secara periodik, untuk memastikan status _ipvs_ konsisten dengan apa yang diharapkan. Ketika sebuah _Services_ diakses, trafik yang ada akan diarahkan ke salah satu `Pod` _backend_. Sama halnya dengan `iptables`, _ipvs_ juga berdasarkan pada fungsi _hook_ _netfilter_, bedanya adalah _ipvs_ menggunakan struktur data _hash table_ dan bekerja di _kernelspace_. Dengan kata lain _ipvs_ melakukan _redirect_ trafik dengan lebih cepat dan dengan performa yang lebih baik ketika melakukan sinkronisasi _rules_ _proxy_. Selain itu, _ipvs_ juga menyediakan lebih banyak opsi algoritma _load balancing_: * `rr`: round-robin * `lc`: least connection * `dh`: destination hashing * `sh`: source hashing * `sed`: shortest expected delay * `nq`: never queue #### Catatan: Mode _ipvs_ menggunakan _module_ _IPVS_ _kernel_ yang diinstal pada _node_ sebelum `kube-proxy` dijalankan. Ketika `kube-proxy` dijalankan dengan mode _proxy_ _ipvs_, `kube-proxy` akan melakukan proses validasi, apakah _module_ _IPVS_ sudah diinstal di _node_, jika _module_ tersebut belum diinstal, maka `kube-proxy` akan menggunakan mode `iptables`. ![Ikhtisar diagram Services pada proxy ipvs](https://kubernetes.io/images/docs/services-ipvs-overview.svg) Dari sekian model _proxy_ yang ada, trafik _inbound_ apa pun yang ada diterima oleh _IP:Port_ pada `Service` akan dilanjutkan melalui _proxy_ pada _backend_ yang sesuai, dan klien tidak perlu mengetahui apa informasi mendetail soal Kubernetes, `Service`, atau `Pod`. afinitas _session_ (_session affinity_) berbasis _Client-IP_ dapat dipilih dengan cara menerapkan nilai _"ClientIP"_ pada `service.spec.sessionAffinity` (nilai _default_ untuk hal ini adalah _"None"_), kamu juga dapat mengatur nilai maximum _session_ _timeout_ yang ada dengan mengatur opsi `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` jika sebelumnya kamu sudah menerapkan nilai _"ClusterIP"_ pada `service.spec.sessionAffinity` (nilai _default_ untuk opsi ini adalah _"10800"_). _Multi-Port Services_ --------------------- Banyak _Services_ dengan kebutuhan untuk mengekspos lebih dari satu _port_. Untuk kebutuhan inilah, Kubernetes mendukung _multiple_ _port_ _definitions_ pada objek `Service`. Ketika menggunakan _multiple_ _port_, kamu harus memberikan nama pada setiap _port_ yang didefinisikan, sehingga _Endpoint_ yang dibentuk tidak ambigu. Contoh: kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - name: http protocol: TCP port: 80 targetPort: 9376 - name: https protocol: TCP port: 443 targetPort: 9377 Perhatikan bahwa penamaan _port_ hanya boleh terdiri dari karakter _alphanumeric_ _lowercase_ dan _\-_, serta harus dimulai dan diakhiri dengan karakter _alphanumeric_, misalnya saja `123-abc` dan `web` merupakan penamaan yang valid, tapi `123_abc` dan `-web` bukan merupakan penamaan yang valid. Memilih sendiri alamat IP yang kamu inginkan -------------------------------------------- Kamu dapat memberikan spesifikasi alamat _cluster IP_ yang kamu inginkan sebagai bagian dari _request_ pembuatan objek `Service`. Untuk melakukan hal ini, kamu harus mengisi _fields_ `.spec.clusterIP` field. Contoh penggunaannya adalah sebagai berikut, misalnya saja kamu sudah memiliki _entry_ DNS yang ingin kamu gunakan kembali, atau sebuah sistem _legacy_ yang sudah diatur pada alamat IP spesifik dan sulit untuk diubah. Alamat IP yang ingin digunakan pengguna haruslah merupakan alamat IP yang valid dan berada di dalam _range_ _CIDR_ `service-cluster-ip-range` yang dispesifikasikan di dalam penanda yang diberikan _apiserver_. Jika _value_ yang diberikan tidak valid, _apiserver_ akan mengembalikan _response_ _code_ HTTP _422_ yang mengindikasikan _value_ yang diberikan tidak valid. ### Mengapa tidak menggunakan DNS _round-robin_? Pertanyaan yang selalu muncul adalah kenapa kita menggunakan IP virtual dan bukan DNS _round-robin_ standar? Terdapat beberapa alasan dibalik semua itu: * Terdapat sejarah panjang dimana _library_ DNS tidak mengikuti _TTL_ DNS dan melakukan _caching_ hasil dari _lookup_ yang dilakukan. * Banyak aplikasi yang melakukan _lookup_ DNS hanya sekali dan kemudian melakukan _cache_ hasil yang diperoleh. * Bahkan apabila aplikasi dan _library_ melakukan resolusi ulang yang _proper_, _load_ dari setiap klien yang melakukan resolusi ulang DNS akan sulit untuk di _manage_. Kami berusaha untuk mengurangi ketertarikan pengguna untuk melakukan yang mungkin akan menyusahkan pengguna. Dengan demikian, apabila terdapat justifikasi yang cukup kuat, kami mungkin saja memberikan implementasi alternatif yang ada. _Discovering services_ ---------------------- Kubernetes mendukung 2 buah mode primer untuk melakukan `Service` - variabel _environment_ dan DNS. ### Variabel _Environment_ Ketika sebuah `Pod` dijalankan pada _node_, _kubelet_ menambahkan seperangkat variabel _environment_ untuk setiap `Service` yang aktif. _Environment_ yang didukung adalah [Docker links compatible](https://docs.docker.com/userguide/dockerlinks/) variabel (perhatikan [makeLinkVariables](http://releases.k8s.io/main/pkg/kubelet/envvars/envvars.go#L49) ) dan variabel `{SVCNAME}_SERVICE_HOST` dan `{SVCNAME}_SERVICE_PORT`, dinama nama `Service` akan diubah menjadi huruf kapital dan tanda _minus_ akan diubah menjadi _underscore_. Sebagai contoh, `Service` `"redis-master"` yang mengekspos _port_ TCP 6379 serta _alamat_ _cluster IP_ _10.0.0.11_ akan memiliki _environment_ sebagai berikut: REDIS_MASTER_SERVICE_HOST=10.0.0.11 REDIS_MASTER_SERVICE_PORT=6379 REDIS_MASTER_PORT=tcp://10.0.0.11:6379 REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379 REDIS_MASTER_PORT_6379_TCP_PROTO=tcp REDIS_MASTER_PORT_6379_TCP_PORT=6379 REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11 Hal ini merupakan kebutuhan yang urutannya harus diperhatikan - `Service` apa pun yang akan diakses oleh sebuah `Pod` harus dibuat sebelum `Pod` tersebut dibuat, jika tidak variabel _environment_ tidak akan diinisiasi. Meskipun begitu, DNS tidak memiliki keterbatasan ini. ### DNS Salah satu [_add-on_](https://kubernetes.io/id/docs/concepts/cluster-administration/addons/) opsional (meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk _Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis dapat melakukan resolusi DNS. Sebagai contoh, apabila kamu memiliki sebuah `Service` dengan nama `"my-service"` pada _Namespace_ _"my-ns"_, maka _record_ DNS `"my-service.my-ns"` akan dibuat. `Pod` yang berada di dalam _Namespace_ _"my-ns"_ dapat langsung melakukan _lookup_ dengan hanya menggunakan `"my-service"`. Sedangkan `Pod` yang berada di luar _Namespace_ _my-ns"_ harus menggunakan `"my-service.my-ns"`. Hasil dari resolusi ini menrupakan _cluster IP_. Kubernetes juga menyediakan _record_ DNS SRV (service) untuk _named ports_. Jika _Service_ `"my-service.my-ns"` memiliki _port_ dengan nama `"http"` dengan protokol `TCP`, kamu dapat melakukan _query_ DNS SRV untuk `"_http._tcp.my-service.my-ns"` untuk mengetahui nomor _port_ yang digunakan oleh _http_. Server DNS Kubernetes adalah satu-satunya cara untuk mengakses _Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di [DNS _Pods_ dan _Services_](https://kubernetes.io/id/docs/concepts/services-networking/dns-pod-service/) . `Service` _headless_ -------------------- Terkadang kamu tidak membutuhkan mekanisme _load-balancing_ dan sebuah _single_ IP _Sevice_. Dalam kasus ini, kamu dapat membuat _"headless"_ `Service` dengan cara memberikan spesifikasi _None_ pada _cluster IP_ (`.spec.clusterIP`). Opsi ini memungkinkan pengguna mengurangi ketergantungan terhadap sistem Kubernetes dengan cara memberikan kebebasan untuk mekanisme _service discovery_. Aplikasi akan tetap membutuhkan mekanisme _self-registration_ dan _adapter service discovery_ lain yang dapat digunakan berdasarkan API ini. Untuk `Service` _"headless"_ alokasi _cluster IP_ tidak dilakukan dan `kube-proxy` tidak me-_manage_ _Service-Service_, serta tidak terdapat mekanisme _load balancing_ yang dilakukan. Bagaimana konfigurasi otomatis bagi DNS dilakukan bergantung pada apakah `Service` tersebut memiliki _selector_ yang dispesifikasikan. ### Dengan _selector_ Untuk `Service` _"headless"_ dengan _selector_, kontroler `Endpoints` akan membuat suatu _record_ `Endpoints` di API, serta melakukan modifikasi konfigurasi DNS untuk mengembalikan _A records (alamat)_ yang merujuk secara langsung pada `Pod` _backend_. ### Tanpa _selector_ Untuk `Service` _"headless"_ tanpa _selector_, kontroler `Endpoints` tidak akan membuat _record_ _Enpoints_. Meskipun demikian, sistem DNS tetap melakukan konfigurasi salah satu dari: * _record_ CNAME untuk [`ExternalName`](https://kubernetes.io/id/docs/concepts/services-networking/service/#externalname) \-tipe services. * _record_ untuk semua `Endpoints` yang memiliki nama `Service` yang sama, untuk tipe lainnya. Mekanisme _publish_ `Service` - jenis-jenis `Service` ----------------------------------------------------- Untuk beberapa bagian dari aplikasi yang kamu miliki (misalnya saja, _frontend_), bisa saja kamu memiliki kebutuhan untuk mengekspos `Service` yang kamu miliki ke alamat IP eksternal (di luar klaster Kubernetes). `ServiceTypes` yang ada pada Kubernetes memungkinkan kamu untuk menentukan jenis `Service` apakah yang kamu butuhkan. Secara _default_, jenis `Service` yang diberikan adalah `ClusterIP`. _Value_ dan perilaku dari tipe `Service` dijelaskan sebagai berikut: * `ClusterIP`: Mengekspos `Service` ke _range_ alamat IP di dalam klaster. Apabila kamu memilih _value_ ini `Service` yang kamu miliki hanya dapat diakses secara internal. tipe ini adalah _default_ _value_ dari _ServiceType_. * [`NodePort`](https://kubernetes.io/id/docs/concepts/services-networking/service/#type-nodeport) : Mengekspos `Service` pada setiap IP _node_ pada _port_ statis atau _port_ yang sama. Sebuah `Service` `ClusterIP`, yang mana `Service` `NodePort` akan di-_route_ , dibuat secara otomatis. Kamu dapat mengakses `Service` dengan tipe ini, dari luar klaster melalui `:`. * [`LoadBalancer`](https://kubernetes.io/id/docs/concepts/services-networking/service/#loadbalancer) : Mengekspos `Service` secara eksternal dengan menggunakan `LoadBalancer` yang disediakan oleh penyedia layanan _cloud_. `Service` dengan tipe `NodePort` dan `ClusterIP`, dimana trafik akan di-_route_, akan dibuat secara otomatis. * [`ExternalName`](https://kubernetes.io/id/docs/concepts/services-networking/service/#externalname) : Melakukan pemetaan `Service` ke konten dari _field_ `externalName` (misalnya: `foo.bar.example.com`), dengan cara mengembalikan catatan `CNAME` beserta _value_\-nya. Tidak ada metode _proxy_ apa pun yang diaktifkan. Mekanisme ini setidaknya membutuhkan `kube-dns` versi 1.7. ### Type NodePort Jika kamu menerapkan _value_ `NodePort` pada _field_ _type_, master Kubernetes akan mengalokasikan _port_ dari _range_ yang dispesifikasikan oleh penanda `--service-node-port-range` (secara _default_, 30000-32767) dan setiap _Node_ akan memproksikan _port_ tersebut (setiap _Node_ akan memiliki nomor _port_ yang sama) ke `Service` yang kamu miliki. `Port` tersebut akan dilaporkan pada _field_ `.spec.ports[*].nodePort` di `Service` kamu. Jika kamu ingin memberikan spesifikasi IP tertentu untuk melakukan _poxy_ pada _port_. kamu dapat mengatur penanda `--nodeport-addresses` pada `kube-proxy` untuk _range_ alamat IP tertentu (mekanisme ini didukung sejak v1.10). Sebuah daftar yang dipisahkan koma (misalnya, _10.0.0.0/8_, _1.2.3.4/32_) digunakan untuk mem-_filter_ alamat IP lokal ke _node_ ini. Misalnya saja kamu memulai `kube-proxy` dengan penanda `--nodeport-addresses=127.0.0.0/8`, maka `kube-proxy` hanya akan memilih _interface_ _loopback_ untuk `Service` dengan tipe `NodePort`. Penanda `--nodeport-addresses` memiliki nilai _default_ kosong (`[]`), yang artinya akan memilih semua _interface_ yang ada dan sesuai dengan perilaku `NodePort` _default_. Jika kamu menginginkan nomor _port_ yang berbeda, kamu dapat memberikan spesifikasi _value_ dari _field_ _nodePort_, dan sistem yang ada akan mengalokasikan _port_ tersebut untuk kamu, jika _port_ tersebut belum digunakan (perhatikan bahwa jika kamu menggunakan teknik ini, kamu perlu mempertimbangkan _collision_ yang mungkin terjadi dan bagaimana cara mengatasi hal tersebut) atau transaksi API yang dilakukan akan gagal. Hal ini memberikan kebebasan bagi pengembang untuk memilih _load balancer_ yang akan digunakan, terutama apabila _load balancer_ yang ingin digunakan belum didukung sepenuhnya oleh Kubernetes. Perhatikan bahwa `Service` dapat diakses baik dengan menggunakan `:spec.ports[*].nodePort` atau `.spec.clusterIP:spec.ports[*].port`. (Jika penanda `--nodeport-addresses` diterapkan, dapat di-_filter_ dengan salah satu atau lebih _NodeIP_.) ### Type LoadBalancer Pada penyedia layanan _cloud_ yang menyediakan pilihan _load balancer_ eksternal, pengaturan _field_ _type_ ke `LoadBalancer` akan secara otomatis melakukan proses _provision_ _load balancer_ untuk `Service` yang kamu buat. Informasi mengenai _load balancer_ yang dibuat akan ditampilkan pada _field_ `.status.loadBalancer` pada `Service` kamu. Contohnya: kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 clusterIP: 10.0.171.239 loadBalancerIP: 78.11.24.19 type: LoadBalancer status: loadBalancer: ingress: - ip: 146.148.47.155 Trafik dari _load balancer_ eksternal akan diarahkan pada `Pod` _backend_, meskipun mekanisme bagaimana hal ini dilakukan bergantung pada penyedia layanan _cloud_. Beberapa penyedia layanan _cloud_ mengizinkan konfigurasi untuk _value_ `loadBalancerIP`. Dalam kasus tersebut, _load balancer_ akan dibuat dengan _loadbalancerIP_ yang dispesifikasikan. Jika _value_ dari `loadBalancerIP` tidak dispesifikasikan. sebuah IP sementara akan diberikan pada _loadBalancer_. Jika `loadBalancerIP` dispesifikasikan, tetapi penyedia layanan _cloud_ tidak mendukung hal ini, maka _field_ yang ada akan diabaikan. **Catatan Khusus untuk Azure**: Untuk spesifikasi `loadBalancerIP` publik yang didefinisikan oleh pengguna, sebuah alamat IP statis publik akan disediakan terlebih dahulu, dan alamat IP tersebut harus berada di _resource group_ dari _resource_ yang secara otomatis dibuat oleh klaster. Misalnya saja, `MC_myResourceGroup_myAKSCluster_eastus`. Berikan spesifikasi alamat IP sebagai `loadBalancerIP`. Pastikan kamu sudah melakukan _update_ pada _securityGroupName_ pada _file_ konfigurasi penyedia layanan _cloud_. Untuk informasi lebih lanjut mengenai _permission_ untuk `CreatingLoadBalancerFailed` kamu dapat membaca _troubleshooting_ untuk [Penggunaan alamat IP statis pada _load balancer_ Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/static-ip) atau [_CreatingLoadBalancerFailed_ pada klaster AKS dengan _advanced networking_](https://github.com/Azure/AKS/issues/357) . #### Catatan: Dukungan untuk SCTP _load balancer_ dari penyedia layanan _cloud_ bergantung pada implementasi _load balancer_ yang disediakan oleh penyedia layanan _cloud_ tersebut. Jika SCTP tidak didukung oleh _load balancer_ penyedia layanan publik maka _request_ pembuatan `Service` akan tetap diterima, meskipun proses pembuatan _load balancer_ itu sendiri gagal. #### _Load balancer_ internal Di dalam _environment_, terkadang terdapat kebutuhan untuk melakukan _route_ trafik antar _Service_ yang berada di dalam satu VPC. Di dalam _environment_ _split-horizon DNS_ kamu akan membutuhkan dua _service_ yang mampu melakukan mekanisme _route_ trafik eskternal maupun internal ke _endpoints_ yang kamu miliki. Hal ini dapat diraih dengan cara menambahkan anotasi berikut untuk _service_ yang disediakan oleh penyedia layanan _cloud_. * [Default](https://kubernetes.io/id/docs/concepts/services-networking/service/#service-tabs-0) * [GCP](https://kubernetes.io/id/docs/concepts/services-networking/service/#service-tabs-1) * [AWS](https://kubernetes.io/id/docs/concepts/services-networking/service/#service-tabs-2) * [Azure](https://kubernetes.io/id/docs/concepts/services-networking/service/#service-tabs-3) * [OpenStack](https://kubernetes.io/id/docs/concepts/services-networking/service/#service-tabs-4) * [Baidu Cloud](https://kubernetes.io/id/docs/concepts/services-networking/service/#service-tabs-5) Pilih salah satu _tab_. [...] metadata: name: my-service annotations: cloud.google.com/load-balancer-type: "Internal" [...] Gunakan _cloud.google.com/load-balancer-type: "internal"_ untuk master dengan versi 1.7.0 to 1.7.3. Untuk informasi lebih lanjut, dilahkan baca [dokumentasi](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing) . [...] metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 [...] [...] metadata: name: my-service annotations: service.beta.kubernetes.io/azure-load-balancer-internal: "true" [...] [...] metadata: name: my-service annotations: service.beta.kubernetes.io/openstack-internal-load-balancer: "true" [...] [...] metadata: name: my-service annotations: service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true" [...] #### Dukungan untuk SSL di AWS Dukungan parsial untuk SSL bagi klaster yang dijalankan di AWS mulai diterapkan, mulai versi 1.3 terdapat 3 anotasi yang dapat ditambahkan pada `Service` dengan tipe `LoadBalancer`: metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 Anotasi pertama memberikan spesifikasi ARN dari sertifikat yang akan digunakan. Sertifikat yang digunakan bisa saja berasal dari _third party_ yang diunggah ke IAM atau sertifikat yang dibuat secara langsung dengan menggunakan sertifikat manajer AWS. metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp) Anotasi kedua memberikan spesifikasi bagi protokol yang digunakan oleh `Pod` untuk saling berkomunikasi. Untuk HTTPS dan SSL, ELB membutuhkan `Pod` untuk melakukan autentikasi terhadap dirinya sendiri melalui koneksi yang dienkripsi. Protokol HTTP dan HTTPS akan memilih mekanisme _proxy_ di tingkatan ke-7: ELB akan melakukan terminasi koneksi dengan pengguna, melakukan proses _parsing_ _headers_, serta memasukkan _value_ bagi _header_ `X-Forwarded-For` dengan alamat IP pengguna (_Pod_ hanya dapat melihat alamat IP dari ELB pada akhir koneksi yang diberikan) ketika melakukan _forwarding_ suatu _request_. Protokol TCP dan SSL akan memilih mekanisme _proxy_ pada tingkatan 4: ELB akan melakukan _forwarding_ trafik tanpa melakukan modifikasi _headers_. Pada _environment_ campuran dimana beberapa _port_ diamankan sementara _port_ lainnya dalam kondisi tidak dienkripsi, anotasi-anotasi berikut dapat digunakan: metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443" Pada contoh di atas, jika `Service` memiliki 3 buah _port_, yaitu: `80`, `443`, dan `8443`, maka `443` adan `8443` akan menggunakan sertifikat SSL, tetapi `80` hanya akan di-_proxy_ menggunakan protokol HTTP. Mulai versi 1.9, `Service` juga dapat menggunakan [_predefined_ _policy_](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) untuk HTTPS atau _listener_ SSL. Untuk melihat _policy_ apa saja yang dapat digunakan, kamu dapat menjalankan perintah _awscli_: aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName' _Policy_ ini kemudian dapat dispesifikasikan menggunakan anotasi "_service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy_", contohnya: metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01" #### Protokol PROXY pada AWS Untuk mengaktifkan dukungan [protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) untuk klaster yang dijalankan di AWS, kamu dapat menggunakan anotasi di bawah ini: metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*" Sejak versi 1.3.0, penggunaan anotasi berlaku untuk semua _port_ yang diproksi oleh ELB dan tidak dapat diatur sebaliknya. #### Akses _Log_ ELB pada AWS Terdapat beberapa anotasi yang digunakan untuk melakukan manajemen akses _log_ untuk ELB pada AWS. Anotasi `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` mengatur akses _log_ mana sajakah yang diaktifkan. Anotasi `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval` mengatur interval (dalam menit) publikasi akses _log_. Kamu dapat memberikan spesifikasi interval diantara _range_ 5-60 menit. Anotasi `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` mengatur nama _bucket_ Amazon S3 dimana akses _log_ _load balancer_ disimpan. Anotasi `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` memberikan spesifikasi hierarki logis yang kamu buat untuk _bucket_ Amazon S3 yang kamu buat. metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true" # Specifies whether access logs are enabled for the load balancer service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60" # The interval for publishing the access logs. You can specify an interval of either 5 or 60 (minutes). service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket" # The name of the Amazon S3 bucket where the access logs are stored service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod" # The logical hierarchy you created for your Amazon S3 bucket, for example _my-bucket-prefix/prod_ #### Mekanisme _Draining_ Koneksi pada AWS Mekanisme _draining_ untuk ELB klasik dapat dilakukan dengan menggunakan anotasi `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` serta mengatur _value_\-nya menjadi `"true"`. Anotasi `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` juga dapat digunakan untuk mengatur _maximum time_ (dalam detik), untuk menjaga koneksi yang ada agar selalu terbuka sebelum melakukan _deregistering_ _instance_. metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true" service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60" #### Anotasi ELB lainnya Terdapat beberapa anotasi lain yang dapat digunakan untuk mengatur ELB klasik sebagaimana dijelaskan seperti di bawah ini: metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60" # The time, in seconds, that the connection is allowed to be idle (no data has been sent over the connection) before it is closed by the load balancer service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true" # Specifies whether cross-zone load balancing is enabled for the load balancer service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops" # A comma-separated list of key-value pairs which will be recorded as # additional tags in the ELB. service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "" # The number of successive successful health checks required for a backend to # be considered healthy for traffic. Defaults to 2, must be between 2 and 10 service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3" # The number of unsuccessful health checks required for a backend to be # considered unhealthy for traffic. Defaults to 6, must be between 2 and 10 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20" # The approximate interval, in seconds, between health checks of an # individual instance. Defaults to 10, must be between 5 and 300 service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5" # The amount of time, in seconds, during which no response means a failed # health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval # value. Defaults to 5, must be between 2 and 60 service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" # A list of additional security groups to be added to ELB #### Dukungan _Network Load Balancer_ (NLB) pada AWS \[alpha\] #### Peringatan: Ini merupakan tingkatan _alpha_ dan tidak direkomendasikan untuk digunakan pada _environment_ _production_. Sejak versi 1.9.0, Kubernetes mendukung _Network Load Balancer_ (NLB). Untuk menggunakan NLB pada AWS, gunakan anotasi `service.beta.kubernetes.io/aws-load-balancer-type` dan atur _value_\-nya dengan `nlb`. metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-type: "nlb" Tidak seperti ELB klasik, NLB, melakukan _forwarding_ IP klien melalui _node_. Jika _field_ `.spec.externalTrafficPolicy` diatur _value_\-nya menjadi `Cluster`, maka alamat IP klien tidak akan diteruskan pada `Pod`. Dengan mengatur _value_ dari _field_ `.spec.externalTrafficPolicy` ke `Local`, alamat IP klien akan diteruskan ke `Pod`, tapi hal ini bisa menyebabkan distribusi trafik yang tidak merata. _Node_ yang tidak memiliki `Pod` untuk `Service` dengan tipe `LoadBalancer` akan menyebabkan kegagalan _health check_ _NLB Target_ pada tahapan _auto-assigned_ `.spec.healthCheckNodePort` dan tidak akan menerima trafik apa pun. Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan _DaemonSet_ atau melakukan spesifikasi [pod anti-affinity](https://kubernetes.io/id/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) agar `Pod` tidak di-_assign_ ke _node_ yang sama. NLB juga dapat digunakan dengan anotasi [internal load balancer](https://kubernetes.io/id/docs/concepts/services-networking/service/#internal-load-balancer) . Agar trafik klien berhasil mencapai _instances_ dibelakang ELB, _security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut: | _Rule_ | Protokol | `Port` | _IpRange(s)_ | Deskripsi _IpRange_ | | --- | --- | --- | --- | --- | | _Health Check_ | TCP | NodePort(s) (`.spec.healthCheckNodePort` for _.spec.externalTrafficPolicy = Local_) | VPC CIDR | kubernetes.io/rule/nlb/health= | | _Client Traffic_ | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client= | | _MTU Discovery_ | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu= | Perhatikan bahwa jika `.spec.loadBalancerSourceRanges` tidak dispesifikasikan, Kubernetes akan mengizinkan trafik dari `0.0.0.0/0` ke _Node Security Group_. Jika _node_ memiliki akses publik, maka kamu harus memperhatikan tersebut karena trafik yang tidak berasal dari NLB juga dapat mengakses semua _instance_ di _security group_ tersebut. Untuk membatasi klien IP mana yang dapat mengakses NLB, kamu harus memberikan spesifikasi _loadBalancerSourceRanges_. spec: loadBalancerSourceRanges: - "143.231.0.0/16" #### Catatan: NLB hanya dapat digunakan dengan beberapa kelas _instance_ tertentu baca [dokumentasi AWS](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets) untuk mengetahui lebih lanjut _intance_ apa saja yang didukung. ### Tipe ExternalName Service dengan tipe `ExternalName` melakukan pemetaan antara `Service` dan DNS, dan bukan ke _selector_ seperti `my-service` atau `cassandra`. Kamu memberikan spesifikasi `spec.externalName` pada `Service` tersebut. Definisi `Service` ini, sebagai contoh, melaukan pemetaan `Service` `my-service` pada _namespace_ `prod` ke DNS `my.database.example.com`: kind: Service apiVersion: v1 metadata: name: my-service namespace: prod spec: type: ExternalName externalName: my.database.example.com #### Catatan: `ExternalName` menerima alamat IPv4 dalam bentuk string, tapi karena DNS tersusun atas angka dan bukan sebagai alamat IP. `ExternalName` yang menyerupai alamat IPv4 tidak bisa di-_resolve_ oleh _CoreDNS_ atau _ingress-nginx_ karena `ExternalName` memang ditujukan bagi penamaan _canonical_ DNS. Untuk melakukan _hardcode_ alamat IP, kamu dapat menggunakan _headless_ `Service` sebagai alternatif. Ketika melakukan pencarian _host_ `my-service.prod.svc.cluster.local`, servis DNS klaster akan mengembalikan _record_ `CNAME` dengan _value_ `my.database.example.com`. Mekanisme akses pada `my-service` bekerja dengan cara yang sama dengan `Service` pada umumnya, perbedaan yang krusial untuk hal ini adalah mekanisme _redirection_ terjadi pada tingkatan DNS dan bukan melalui _proxy forward_. Apabila kamu berniat memindahkan basis data yang kamu pakai ke dalam klaster, kamu hanya perlu mengganti instans basis data kamu dan menjalankannya di dalam `Pod`, menambahkan _selector_ atau _endpoint_ yang sesuai, serta mengupah _type_ dari _Service_ yang kamu gunakan. #### Catatan: Bagian ini berasal dari tulisan [Tips Kubernetes - Bagian 1](https://akomljen.com/kubernetes-tips-part-1/) oleh [Alen Komljen](https://akomljen.com/) . ### IP Eksternal Jika terdapat sebuah alamat IP eksternal yang melakukan mekanisme _route_ ke satu atau lebih _node_ yang ada di klaster, `Service` Kubernetes dapat diekspos dengan menggunakan `externalIP`. Trafik yang diarahkan ke klaster dengan IP eksternal (sebagai destinasi IP), pada _port_ `Service` akan di-_route_ ke salah satu _endpoint_ `Service`. _Value_ dari `externalIP` tidak diatur oleh Kubernetes dan merupakan tanggung jawab dari administrator klaster. Pada _ServiceSpec_, kamu dapat memberikan spesifikasi `externalIP` dan `ServiceTypes`. Pada contoh di bawah ini. `"my-service"` dapat diakses oleh klien pada "`198.51.100.32:80`" (`externalIP:port`). kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - name: http protocol: TCP port: 80 targetPort: 9376 externalIPs: - 80.11.12.10 Kekurangan ---------- Penggunaan _proxy_ _userspace_ untuk VIP dapat digunakan untuk skala kecil hingga menengah, meski begitu hal ini tidak _scalable_ untuk klaster yang sangat besar dan memiliki ribuan `Service`. Perhatikan [Desain proposal orisinil untuk _portal_](http://issue.k8s.io/1107) untuk informasi lebih lanjut. Penggunaan _proxy_ _userspace_ menghilangkan _source-IP_ dari _packet_ yang mengakses sebuah `Service`. Hal ini membuat mekanisme _firewall_ menjadi sulit untuk diterapkan. _Proxy_ `iptables` tidak menghilangkan _source IP_ yang berasal dari dalam klaster, meski begitu, hal ini masih berimbas pada klien yang berasal dari `Service` dengan tipe _load-balancer_ atau _node-port_. _Field_ tipe didesain sebagai fungsionalitas yang berantai - setiap tingkatan menambahkan tambahan pada tingkatansebelumnya. Hal ini tidak selalu berlaku bagi semua penyedia layanan _cloud_ (misalnya saja Google Compute Engine tidak perlu melakukan alokasi `NodePort` untuk membuat `LoadBalancer` bekerja sebagaimana mestinya, hal ini berbeda dengan AWS yang memerlukan hal ini, setidaknya untuk API yang mereka miliki saat ini). Pengerjaan lebih lanjut ----------------------- Di masa mendatang, kami berencana untuk membuat _policy_ _proxy_ menjadi lebih bervariasi dan bukan hanya _round robin_, misalnya saja _master-elected_ atau _sharded_. Kami juga berharap bahwa beberapa `Service` bisa saja memiliki _load balancer_ yang sebenarnya, suatu kasus dimana VIP akan secara langsung mengantarkan paket. Kami ingin meningkatkan dukungan lebih lanjut untuk `Service` dengan tingkatan `Service` L7(HTTP). Kami ingin memiliki mode _ingress_ yang lebih fleksibel untuk `Service` yang mencakup mode `ClusterIP`, `NodePort`, dan `LoadBalancer` dan banyak lagi. Detail mendalam mengenai IP virtual ----------------------------------- Informasi sebelumnya sudah cukup bagi sebagian orang yang hanya ingin menggunakan _Service_. Meskipun begitu, terdapat banyak hal yang sebenarnya terjadi dan akan sangat bermanfaat untuk dipelajari lebih lanjut. ### Menghindari _collison_ Salah satu filosofi Kubernetes adalah pengguna tidak mungkin menghadapi situasi dimana apa yang mereka mengalami kegagalan tanpa adanya alasan yang jelas. Dalam kasus ini, kita akan coba memahami lebih lanjut mengenai _network port_ - pengguna tidak seharusnya memilih nomor _port_ jika hal itu memungkinkan terjadinya _collision_ dengan pengguna lainnya. Hal ini merupakan mekanisme isolasi kegagalan. Agar pengguna dapat menentukan nomor _port_ bagi `Service` mereka, kita harus memastikan bahwa tidak ada dua `Service` yang mengalami _collision_. Kita melakukan hal tersebut dengan cara melakukan alokasi alamat IP pada setiap `Service`. Untuk memastikan setiap `Service` memiliki alamat IP yang unik, sebuah _allocator_ internal akan secara atomik melakukan pemetaan alokasi global di dalam _etcd_ ketika membuat sebuah `Service` baru. Pemetaan objek harus tersedia pada _registry_ `Service` dimana `Service` akan diberikan sebuah IP, jika tidak, proses pembuatan `Service` akan gagal dan sebuah pesan akan memberikan informasi bahwa alamat IP tidak dapat dialokasikan. Sebuah _backgroud_ _controller_ bertanggung jawab terhadap mekanisme pemetaan tersebut (migrasi dari versi Kubernetes yang digunakan dalam _memory locking_) sekaligus melakukan pengecekan terhadap _assignment_ yang tidak valid yang terjadi akibat intervensi administrator dan melakukan penghapusan daftar IP yang dialokasikan tapi tidak digunakan oleh `Service` mana pun. ### IP dan VIP Tidak seperti alamat IP `Pod`, yang akan di _route_ ke destinasi yang "pasti", IP `Service` tidak mengarahkan _request_ hanya pada satu _host_. Sebagai gantinya, kita mneggunakan `iptables` (logika pemrosesan paket pada Linux) untuk melakukan definisi alamat IP virtual yang secara transparan akan diarahkan sesuai kebutuhan. Ketika klien dihubungkan pada VIP, trafik yang ada akan secara otomatis dialihkan pada _endpoint_ yang sesuai. Variabel _environment_ dan DNS untuk `Service` terdiri dalam bentuk VIP dan _port_. Kami mendukung tiga jenis mode _proxy_ - _userspace_, `iptables`, dan _ipvs_ yang memiliki perbedaan cara kerja satu sama lainnya. #### _Userspace_ Sebagai contoh, anggaplah kita memiliki aplikasi _image processing_ seperti yang sudah disebutkan di atas. Ketika `Service` _backend_ dibuat, _master_ Kubernetes akan mengalokasikan sebuah alamat IP virtual, misalnya 10.0.0.1. Dengan asumsi _port_ dari `Service` tersebut adalah _1234_, maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di klaster. Ketika sebuah _proxy_ mendapati sebuah `Service` baru, _proxy_ tersebut akan membuka sebuah _port_ _acak_, menyediakan `iptables` yang mengarahkan VIP pada _port_ yang baru saja dibuat, dan mulai koneksi pada _port_ tersebut. Ketika sebuah klien terhubung ke VIP dan terdapat _rules_ `iptables` yang diterapkan, paket akan diarahkan ke _port_ dari _proxy_ `Service` itu sendiri. _Proxy_ `Service` akan memilih sebuah _backend_, dan mulai melakukan mekanisme _proxy_ trafik dari klien ke _backend_. Dengan demikian, pemilik `Service` dapat memilih _port_ mana pun yang dia inginkan tanpa adanya kemungkinan terjadinya _collision_. Klien dapat dengan mudah mengakses IP dan _port_, tanpa harus mengetahui `Pod` mana yang sebenarnya diakses. #### _Iptables_ Kembali, bayangkan apabila kita memiliki aplikasi _image processing_ seperti yang sudah disebutkan di atas. Ketika `Service` _backend_ dibuat, _master_ Kubernetes akan mengalokasikan sebuah alamat IP virtual, misalnya 10.0.0.1. Dengan asumsi _port_ dari `Service` tersebut adalah _1234_, maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di klaster. Ketika sebuah _proxy_ mendapati sebuah `Service` baru, _proxy_ tersebut akan melakukan instalasi serangkaian _rules_ `iptables` yang akan melakukan _redirect_ VIP ke _rules_ tiap `Service`. _Rules_ untuk tiap `Service` ini terkait dengan _rules_ tiap `Endpoints` yang mengarahkan (destinasi NAT) ke _backend_. Ketika sebuah klien terhubung ke VIP dan terdapat \_rules \_iptables yang diterapkan. Sebuah _backend_ akan dipilih (hal ini dapat dilakukan berdasarkan _session affinity_ maupun secara _acak_) dan paket-paket yang ada akan diarahkan ke _backend_. Tidak seperti mekanisme yang terjadi di _userspace_, paket-paket yang ada tidak pernah disalin ke _userspace_, `kube-proxy` tidak harus aktif untuk menjamin kerja VIP, serta IP klien juga tidak perlu diubah. Tahapan yang dijalankan sama dengan tahapan yang dijalankan ketika trafik masuk melalui sebuah _node-port_ atau _load-balancer_, meskipun pada dua kasus di atas klien IP tidak akan mengalami perubahan. #### _Ipvs_ Operasi `iptables` berlangsung secara lambat pada klaster dengan skala besar (lebih dari 10.000 `Service`). _IPVS_ didesain untuk mekanisme _load balance_ dan berbasis pada _hash tables_ yang berada di dalam _kernel_. Dengan demikian kita dapat mendapatkan performa yang konsisten pada jumlah `Service` yang cukup besar dengan menggunakan `kube-proxy` berbasis _ipvs_. Sementara itu, `kube-proxy` berbasis _ipvs_ memiliki algoritma _load balance_ yang lebih bervariasi (misalnya saja _least conns_, _locality_, _weighted_, _persistence_). Objek API --------- _Service_ merupakan _resource_ _top-level_ pada API Kubernetes. Penjelasan lebih lanjut mengenai objek API dapat ditemukan pada: [objek API `Service`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#service-v1-core) . Protokol yang didukung ---------------------- ### TCP FEATURE STATE: `Kubernetes v1.0 [stable]` Kamu dapat menggunakan TCP untuk `Service` dengan _type_ apa pun, dan protokol ini merupakan protokol _default_ yang digunakan. ### UDP FEATURE STATE: `Kubernetes v1.0 [stable]` Kamu dapat menggunakan UDP untuk sebagian besar `Service`. Untuk `Service` dengan _type=LoadBalancer_, dukungan terhadap UDP bergantung pada penyedia layanan _cloud_ yang kamu gunakan. ### HTTP FEATURE STATE: `Kubernetes v1.1 [stable]` Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, kamu dapat menggunakan _Service_ dengan _type_ `LoadBalancer` untuk melakukan mekanisme _reverse_ _proxy_ bagi HTTP/HTTPS, dan melakukan _forwarding_ ke `Endpoints` dari \_Service. #### Catatan: Kamu juga dapat menggunakan [Ingress](https://kubernetes.io/id/docs/concepts/services-networking/ingress/ "Sebuah obyek API yang mengatur akses eksternal terhadap Service yang ada di dalam klaster, biasanya dalam bentuk request HTTP.") sebagai salah satu alternatif penggunaan `Service` untuk HTTP/HTTPS. ### Protokol PROXY FEATURE STATE: `Kubernetes v1.1 [stable]` Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](https://kubernetes.io/id/docs/concepts/cluster-administration/cloud-providers/#aws) ), _Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_ di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks [protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) . _Load balancer_ akan melakukan serangkaian inisiasi _octet_ yang memberikan deskripsi koneksi yang datang, dengan bentuk yang menyerupai: PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n yang kemudian diikuti data dari klien. ### SCTP FEATURE STATE: `Kubernetes v1.12 [alpha]` Kubernetes memberikan dukungan bagi SCTP sebagai _value_ dari _definition_ yang ada pada _Service_, `Endpoints`, `NetworkPolicy` dan `Pod` sebagai fitur _alpha_. Untuk mengaktifkan fitur ini, administrator klaster harus mengaktifkan _feature gate_ _SCTPSupport_ pada _apiserver_, contohnya `“--feature-gates=SCTPSupport=true,...”`. Ketika _fature gate_ ini diaktifkan, pengguna dapat memberikan _value_ SCTP pada _field_ _protocol_ `Service`, `Endpoints`, `NetworkPolicy` dan `Pod`. Kubernetes kemudian akan melakukan pengaturan agar jaringan yang digunakan agar jaringan tersebut menggunakan SCTP, seperti halnya Kubernetes mengatur jaringan agar menggunakan TCP. #### Perhatian ##### Dukungan untuk asoasiasi _multihomed_ SCTP Dukungan untuk asosiasi _multihomed_ SCTP membutuhkan _plugin_ CNI yang dapat memberikan pengalokasian _multiple interface_ serta alamat IP pada sebuah `Pod`. NAT untuk asosiasi _multihomed_ SCTP membutuhkan logika khusus pada modul kernel terkait. ##### `Service` dengan _type=LoadBalancer_ Sebuah `Service` dengan _type_ `LoadBalancer` dan protokol SCTP dapat dibuat hanya jika implementasi _load balancer_ penyedia layanan _cloud_ menyediakan dukungan bagi protokol SCTP. Apabila hal ini tidak terpenuhi, maka _request_ pembuatan _Servixe_ ini akan ditolak. _Load balancer_ yang disediakan oleh penyedia layanan _cloud_ yang ada saat ini (_Azure_, _AWS_, _CloudStack_, _GCE_, _OpenStack_) tidak mendukung SCTP. ##### Windows SCTP tidak didukung pada _node_ berbasis Windows. ##### _Kube-proxy_ _userspace_ _Kube-proxy_ tidak mendukung manajemen asosiasi SCTP ketika hal ini dilakukan pada mode _userspace_ Selanjutnya ----------- Baca [Bagaimana cara menghubungkan _Front End_ ke _Back End_ menggunakan sebuah `Service`](https://kubernetes.io/docs/tasks/access-application-cluster/connecting-frontend-backend/) . Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified May 09, 2023 at 12:48 AM PST: [\[id\] Fix the description of Service External IPs to match the YAML example (7446feb50a)](https://github.com/kubernetes/website/commit/7446feb50a4920a30a9fad4b9fb969bc1f555f20) --- # Alokasi ClusterIP pada servis (Service ClusterIP allocation) | Kubernetes Alokasi ClusterIP pada servis (Service ClusterIP allocation) ============================================================ Dalam Kubernetes, [Service](https://kubernetes.io/id/docs/concepts/services-networking/service/) adalah cara abstrak untuk mengekspos aplikasi yang berjalan pada sekumpulan Pod. Service dapat memiliki alamat IP virtual yang berlaku dalam skala klaster (menggunakan Service dengan `type: ClusterIP`). Klien dapat terhubung menggunakan alamat IP virtual tersebut, dan Kubernetes kemudian mendistribusikan lalu lintas ke Service tersebut di antara berbagai Pod yang menjadi _backend_\-nya. Bagaimana ClusterIP pada Service dialokasikan? ---------------------------------------------- Ketika Kubernetes perlu menetapkan alamat IP virtual untuk sebuah Service, penetapan tersebut dapat dilakukan dengan dua cara: _dinamis_ _Control plane_ klaster secara otomatis memilih alamat IP yang tersedia dari dalam rentang IP yang telah dikonfigurasi untuk Service dengan `type: ClusterIP`. _statis_ Kamu yang menentukan sendiri alamat IP yang diinginkan, asalkan berada dalam rentang IP yang telah dikonfigurasi untuk Service. Di seluruh klaster kamu, setiap `ClusterIP` untuk Service harus unik. Mencoba membuat Service dengan `ClusterIP` tertentu yang telah dialokasikan sebelumnya akan menghasilkan _error_. Mengapa Kamu Perlu Menetapkan Alamat IP Cluster Service? -------------------------------------------------------- Kamu terkadang ingin memiliki Service yang berjalan dengan alamat IP yang telah dikenal (_well-known IP addresses_), sehingga komponen lain dan pengguna dalam klaster dapat menggunakannya. Contoh terbaiknya adalah Service DNS untuk klaster. Sebagai konvensi lunak, beberapa _installer_ Kubernetes menetapkan alamat IP ke-10 dari rentang IP Service untuk Service DNS. Misalnya, jika kamu mengonfigurasi klaster kamu dengan rentang IP Service 10.96.0.0/16 dan ingin alamat IP Service DNS kamu menjadi 10.96.0.10, kamu harus membuat Service seperti berikut: apiVersion: v1 kind: Service metadata: labels: k8s-app: kube-dns kubernetes.io/cluster-service: "true" kubernetes.io/name: CoreDNS name: kube-dns namespace: kube-system spec: clusterIP: 10.96.0.10 ports: - name: dns port: 53 protocol: UDP targetPort: 53 - name: dns-tcp port: 53 protocol: TCP targetPort: 53 selector: k8s-app: kube-dns type: ClusterIP Namun, seperti yang telah dijelaskan sebelumnya, alamat IP 10.96.0.10 belum digunakan (_reserved_). Jika Service lain dibuat sebelum atau pararel dengan alokasi dinamis, ada kemungkinan mereka dapat menggunakan alamat IP ini. Akibatnya, kamu tidak akan dapat membuat Service DNS karena akan gagal dengan _error_ konflik. Bagaimana Cara Menghindari Konflik Alamat IP ClusterIP pada Service? -------------------------------------------------------------------- Implementasi alokasi dalam Kubernetes untuk menetapkan ClusterIP ke Service mengurangi risiko konflik. rentang IP `ClusterIP` dibagi, berdasarkan rumus `min(max(16, cidrSize / 16), 256)`, yang dijelaskan sebagai _tidak kurang dari 16 atau lebih dari 256 dengan tahap bertingkat di antara keduanya_. Alokasi IP dinamis menggunakan pita atas secara _default_, setelah ini habis, akan menggunakan pita bawah. Ini akan memungkinkan pengguna untuk menggunakan alokasi statis pada pita bawah dengan risiko konflik yang rendah. Contoh ------ ### Contoh 1 Contoh ini menggunakan rentang alamat IP: 10.96.0.0/24 (notasi CIDR) untuk alamat IP dari Service. Ukuran Rentang: 28 - 2 = 254 Offset Pita (band): `min(max(16, 256/16), 256)` = `min(16, 256)` = 16 Awal pita statis: 10.96.0.1 Akhir pita statis: 10.96.0.16 Akhir Rentang: 10.96.0.254 pie showData title 10.96.0.0/24 "Static" : 16 "Dynamic" : 238 ### Contoh 2 Contoh ini menggunakan rentang alamat IP: 10.96.0.0/20 (notasi CIDR) untuk alamat IP dari Service. Ukuran Rentang: 212 - 2 = 4094 Offset Pita (band): `min(max(16, 4096/16), 256)` = `min(256, 256)` = 256 Awal pita statis: 10.96.0.1 Akhir pita statis: 10.96.1.0 Akhir Rentang: 10.96.15.254 pie showData title 10.96.0.0/20 "Static" : 256 "Dynamic" : 3838 ### Contoh 3 Contoh ini menggunakan rentang alamat IP: 10.96.0.0/16 (notasi CIDR) untuk alamat IP dari Service. Ukuran Rentang: 216 - 2 = 65534 Offset Pita (band): `min(max(16, 65536/16), 256)` = `min(4096, 256)` = 256 Awal pita statis: 10.96.0.1 Akhir pita statis: 10.96.1.0 Akhir Rentang: 10.96.255.254 pie showData title 10.96.0.0/16 "Static" : 256 "Dynamic" : 65278 Selanjutnya ----------- * Baca mengenai [Service External Traffic Policy](https://kubernetes.io/id/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) * Baca mengenai [Connecting Applications with Services](https://kubernetes.io/docs/tutorials/services/connect-applications-service/) * Baca mengenai [Services](https://kubernetes.io/id/docs/concepts/services-networking/service/) Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified June 04, 2025 at 12:09 AM PST: [fix: Address feedback from reviewer on choice of word (fe8a990c51)](https://github.com/kubernetes/website/commit/fe8a990c51185ba338ec9060405bb5a7ef20ce84) --- # Visão Geral da Segurança Cloud Native | Kubernetes Visão Geral da Segurança Cloud Native ===================================== Esta visão geral define um modelo para pensar sobre a segurança em Kubernetes no contexto da Segurança em Cloud Native. #### Aviso: Este modelo de segurança no contêiner fornece sugestões, não prova políticas de segurança da informação. Os 4C da Segurança Cloud Native ------------------------------- Você pode pensar na segurança em camadas. Os 4C da segurança Cloud Native são a Cloud, Clusters, Contêineres e Código. #### Nota: Esta abordagem em camadas aumenta a [defesa em profundidade](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) para segurança, que é amplamente considerada como uma boa prática de segurança para software de sistemas. ![](https://kubernetes.io/images/docs/4c.png) #### Os 4C da Segurança Cloud Native Cada camada do modelo de segurança Cloud Native é construída sobre a próxima camada mais externa. A camada de código se beneficia de uma base forte (Cloud, Cluster, Contêiner) de camadas seguras. Você não pode proteger contra padrões ruins de segurança nas camadas de base através de segurança no nível do Código. Cloud ----- De muitas maneiras, a Cloud (ou servidores co-localizados, ou o datacenter corporativo) é a [base de computação confiável](https://en.wikipedia.org/wiki/Trusted_computing_base) de um cluster Kubernetes. Se a camada de Cloud é vulnerável (ou configurado de alguma maneira vulnerável), então não há garantia de que os componentes construídos em cima desta base estejam seguros. Cada provedor de Cloud faz recomendações de segurança para executar as cargas de trabalho com segurança nos ambientes. ### Segurança no provedor da Cloud Se você estiver executando um cluster Kubernetes em seu próprio hardware ou em um provedor de nuvem diferente, consulte sua documentação para melhores práticas de segurança. Aqui estão os links para as documentações de segurança dos provedores mais populares de nuvem: | | | | --- | --- |Cloud provider security | Provedor IaaS | Link | | --- | --- | | Alibaba Cloud | [https://www.alibabacloud.com/trust-center](https://www.alibabacloud.com/trust-center) | | Amazon Web Services | [https://aws.amazon.com/security/](https://aws.amazon.com/security/) | | Google Cloud Platform | [https://cloud.google.com/security/](https://cloud.google.com/security/) | | Huawei Cloud | [https://www.huaweicloud.com/intl/pt-br/securecenter/overallsafety](https://www.huaweicloud.com/intl/pt-br/securecenter/overallsafety) | | IBM Cloud | [https://www.ibm.com/cloud/security](https://www.ibm.com/cloud/security) | | Microsoft Azure | [https://docs.microsoft.com/en-us/azure/security/azure-security](https://docs.microsoft.com/en-us/azure/security/azure-security) | | Oracle Cloud Infrastructure | [https://www.oracle.com/security/](https://www.oracle.com/security/) | | VMWare VSphere | [https://www.vmware.com/solutions/security/hardening-guides](https://www.vmware.com/solutions/security/hardening-guides) | ### Segurança de Infraestrutura Sugestões para proteger sua infraestrutura em um cluster Kubernetes: | | | | --- | --- |Infrastructure security | Área de Interesse para Infraestrutura Kubernetes | Recomendação | | --- | --- | | Acesso de rede ao servidor API (Control plane) | Todo o acesso ao control plane do Kubernetes publicamente na Internet não é permitido e é controlado por listas de controle de acesso à rede restritas ao conjunto de endereços IP necessários para administrar o cluster. | | Acesso de rede aos Nós (nodes) | Os nós devem ser configurados para _só_ aceitar conexões (por meio de listas de controle de acesso à rede) do control plane nas portas especificadas e aceitar conexões para serviços no Kubernetes do tipo NodePort e LoadBalancer. Se possível, esses nós não devem ser expostos inteiramente na Internet pública. | | Acesso do Kubernetes à API do provedor de Cloud | Cada provedor de nuvem precisa conceder um conjunto diferente de permissões para o control plane e nós do Kubernetes. É melhor fornecer ao cluster permissão de acesso ao provedor de nuvem que segue o [princípio do menor privilégio](https://en.wikipedia.org/wiki/Principle_of_least_privilege)
para os recursos que ele precisa administrar. A [documentação do Kops](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)
fornece informações sobre as políticas e roles do IAM. | | Acesso ao etcd | O acesso ao etcd (o armazenamento de dados do Kubernetes) deve ser limitado apenas ao control plane. Dependendo de sua configuração, você deve tentar usar etcd sobre TLS. Mais informações podem ser encontradas na [documentação do etcd](https://github.com/etcd-io/etcd/tree/master/Documentation)
. | | Encriptação etcd | Sempre que possível, é uma boa prática encriptar todas as unidades de armazenamento, mas como o etcd mantém o estado de todo o cluster (incluindo os Secrets), seu disco deve ser criptografado. | Cluster ------- Existem duas áreas de preocupação para proteger o Kubernetes: * Protegendo os componentes do cluster que são configuráveis. * Protegendo as aplicações que correm no cluster. ### Componentes do Cluster Se você deseja proteger seu cluster de acesso acidental ou malicioso e adotar boas práticas de informação, leia e siga os conselhos sobre [protegendo seu cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) . ### Componentes no cluster (sua aplicação) Dependendo da superfície de ataque de sua aplicação, você pode querer se concentrar em tópicos específicos de segurança. Por exemplo: se você estiver executando um serviço (Serviço A) que é crítico numa cadeia de outros recursos e outra carga de trabalho separada (Serviço B) que é vulnerável a um ataque de exaustão de recursos e, por consequência, o risco de comprometer o Serviço A é alto se você não limitar os recursos do Serviço B. A tabela a seguir lista áreas de atenção na segurança e recomendações para proteger cargas de trabalho em execução no Kubernetes: | Área de interesse para a segurança do Workload | Recomendação | | --- | --- | | Autorização RBAC (acesso à API Kubernetes) | [https://kubernetes.io/docs/reference/access-authn-authz/rbac/](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) | | Autenticação | [https://kubernetes.io/docs/concepts/security/controlling-access/](https://kubernetes.io/docs/concepts/security/controlling-access/) | | Gerenciamento de segredos na aplicação (e encriptando-os no etcd em repouso) | [https://kubernetes.io/docs/concepts/configuration/secret/](https://kubernetes.io/docs/concepts/configuration/secret/)

[https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) | | Garantir que os Pods atendem aos padrões de segurança do Pod | [https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation](https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation) | | Qualidade de serviço (e gerenciamento de recursos de cluster) | [https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) | | Políticas de Rede | [https://kubernetes.io/docs/concepts/services-networking/network-policies/](https://kubernetes.io/docs/concepts/services-networking/network-policies/) | | TLS para Kubernetes Ingress | [https://kubernetes.io/docs/concepts/services-networking/ingress/#tls](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) | Contêiner --------- A segurança do contêiner está fora do escopo deste guia. Aqui estão recomendações gerais e links para explorar este tópico: | Área de Interesse para Contêineres | Recomendação | | --- | --- | | Scanners de Vulnerabilidade de Contêiner e Segurança de Dependência de SO | Como parte da etapa de construção de imagem, você deve usar algum scanner em seus contêineres em busca de vulnerabilidades. | | Assinatura Imagem e Enforcement | Assinatura de imagens de contêineres para manter um sistema de confiança para o conteúdo de seus contêineres. | | Proibir Usuários Privilegiados | Ao construir contêineres, consulte a documentação para criar usuários dentro dos contêineres que tenham o menor nível de privilégio no sistema operacional necessário para cumprir o objetivo do contêiner. | | Use o Contêiner em Runtime com Isolamento mais Forte | Selecione [classes de contêiner runtime](https://kubernetes.io/pt-br/docs/concepts/containers/runtime-class/)
com o provedor de isolamento mais forte. | Código ------ O código da aplicação é uma das principais superfícies de ataque sobre a qual você tem maior controle. Embora a proteção do código do aplicativo esteja fora do tópico de segurança do Kubernetes, aqui são recomendações para proteger o código do aplicativo: ### Segurança de código | | | | --- | --- |Code security | Área de Atenção para o Código | Recomendação | | --- | --- | | Acesso só através de TLS | Se seu código precisar se comunicar por TCP, execute um handshake TLS com o cliente antecipadamente. Com exceção de alguns casos, encripte tudo em trânsito. Indo um passo adiante, é uma boa ideia encriptar o tráfego de rede entre os serviços. Isso pode ser feito por meio de um processo conhecido como mutual ou [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)
, que realiza uma verificação bilateral da comunicação mediante os certificados nos serviços. | | Limitando intervalos de porta de comunicação | Essa recomendação pode ser um pouco autoexplicativa, mas, sempre que possível, você só deve expor as portas em seu serviço que são absolutamente essenciais para a comunicação ou coleta de métricas. | | Segurança na Dependência de Terceiros | É uma boa prática verificar regularmente as bibliotecas de terceiros de sua aplicação em busca de vulnerabilidades de segurança. Cada linguagem de programação possui uma ferramenta para realizar essa verificação automaticamente. | | Análise de Código Estático | A maioria das linguagens fornece uma maneira para analisar um extrato do código referente a quaisquer práticas de codificação potencialmente inseguras. Sempre que possível, você deve automatizar verificações usando ferramentas que podem verificar as bases de código em busca de erros de segurança comuns. Algumas das ferramentas podem ser encontradas em [OWASP Source Code Analysis Tools](https://owasp.org/www-community/Source_Code_Analysis_Tools)
. | | Ataques de sondagem dinâmica | Existem algumas ferramentas automatizadas que você pode executar contra seu serviço para tentar alguns dos ataques mais conhecidos. Isso inclui injeção de SQL, CSRF e XSS. Uma das ferramentas de análise dinâmica mais populares é o [OWASP Zed Attack proxy](https://www.zaproxy.org/)
. | Próximos passos --------------- Saiba mais sobre os tópicos de segurança do Kubernetes: * [Padrões de segurança do Pod](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [Políticas de rede para Pods](https://kubernetes.io/pt-br/docs/concepts/services-networking/network-policies/) * [Controle de acesso à API Kubernetes](https://kubernetes.io/pt-br/docs/concepts/security/controlling-access/) * [Protegendo seu cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) * [Criptografia de dados em trânsito](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane * [Criptografia de dados em repouso](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) * [Secrets no Kubernetes](https://kubernetes.io/pt-br/docs/concepts/configuration/secret/) * [Runtime class](https://kubernetes.io/pt-br/docs/concepts/containers/runtime-class/) Comentários ----------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Última modificação March 11, 2025 at 12:31 AM PST: [\[pt\] Fix VMware link (90c624294a)](https://github.com/kubernetes/website/commit/90c624294aedb8b99a254259b81b00a612684fdd) --- # 参与 SIG Docs | Kubernetes 参与 SIG Docs =========== SIG Docs 是 Kubernetes 项目 [特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md) 中的一个，负责编写、更新和维护 Kubernetes 的总体文档。 参见[社区 GitHub 仓库中 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) 以进一步了解该 SIG。 SIG Docs 欢迎所有贡献者提供内容和审阅。任何人可以提交拉取请求（PR）。 欢迎所有人对文档内容创建 Issue 和对正在处理中的 PR 进行评论。 你也可以成为[成员（member）](https://kubernetes.io/zh-cn/docs/contribute/participate/roles-and-responsibilities/#members) 、 [评阅人（reviewer）](https://kubernetes.io/zh-cn/docs/contribute/participate/roles-and-responsibilities/#reviewers) 或者 [批准人（approver）](https://kubernetes.io/zh-cn/docs/contribute/participate/roles-and-responsibilities/#approvers) 。 这些角色拥有更高的权限，且需要承担批准和提交变更的责任。 有关 Kubernetes 社区中的成员如何工作的更多信息，请参见 [社区成员身份](https://github.com/kubernetes/community/blob/master/community-membership.md) 。 本文档的其余部分概述了这些角色在 SIG Docs 中发挥作用的一些独特方式。 SIG Docs 负责维护 Kubernetes 最面向公众的方面之一 —— Kubernetes 网站和文档。 SIG Docs 主席 ----------- 每个 SIG，包括 SIG Docs，都会选出一位或多位成员作为主席。 主席会成为 SIG Docs 和其他 Kubernetes 组织的联络接口人。 他们需要了解整个 Kubernetes 项目的架构，并明白 SIG Docs 如何在其中运作。 如需查询当前的主席名单，请查阅 [领导人员](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) 。 SIG Docs 团队和自动化 --------------- SIG 文档中的自动化服务依赖于两种不同的机制: GitHub 团队和 OWNERS 文件。 ### GitHub 团队 GitHub 上有两类 SIG Docs 团队： * `@sig-docs-{language}-owners` 包含批准人和牵头人 * `@sig-docs-{language}-reviews` 包含评阅人 可以在 GitHub 的评论中使用团队的名称 `@name` 来与团队成员沟通。 有时候 Prow 所定义的团队和 GitHub 团队有所重叠，并不完全一致。 对于指派 Issue、PR 和批准 PR，自动化工具使用来自 `OWNERS` 文件的信息。 ### OWNERS 文件和扉页 Kubernetes 项目使用名为 prow 的自动化工具来自动处理 GitHub issue 和 PR。 [Kubernetes website 仓库](https://github.com/kubernetes/website) 使用了两个 [prow 插件](https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins) ： * blunderbuss * approve 这两个插件使用位于 `kubernetes/website` 仓库顶层的 [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) 文件和 [OWNERS\_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 文件来控制 prow 在仓库范围的工作方式。 OWNERS 文件包含 SIG Docs 评阅人和批准人的列表。 OWNERS 文件也可以存在于子目录中，可以在子目录层级重新设置哪些人可以作为评阅人和 批准人，并将这一设定传递到下层子目录。 关于 OWNERS 的更多信息，请参考 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) 文档。 此外，每个独立的 Markdown 文件都可以在其前言部分列出评阅人和批准人， 每一项可以是 GitHub 用户名，也可以是 GitHub 组名。 结合 OWNERS 文件及 Markdown 文件的前言信息，自动化系统可以给 PR 作者可以就应该 向谁请求技术和文字评阅给出建议。 PR 是怎样被合并的 ---------- 当某个拉取请求（PR）被合并到用来发布内容的分支，对应的内容就会被发布到 [https://kubernetes.io](https://kubernetes.io/) 。 为了确保我们所发布的内容的质量足够好，合并 PR 的权限仅限于 SIG Docs 批准人。下面是合并的工作机制： * 当某个 PR 同时具有 `lgtm` 和 `approve` 标签，没有 `hold` 标签且通过所有测试时， 该 PR 会被自动合并。 * Kubernetes 组织的成员和 SIG Docs 批准人可以添加评论以阻止给定 PR 的自动合并， 即通过 `/hold` 评论或者收回某个 `/lgtm` 评论实现这点。 * 所有 Kubernetes 成员可以通过 `/lgtm` 评论添加 `lgtm` 标签。 * 只有 SIG Docs 批准人可以通过评论 `/approve` 合并 PR。 某些批准人还会执行一些其他角色，例如 [PR 管理者](https://kubernetes.io/zh-cn/docs/contribute/participate/pr-wranglers/) 或 [SIG Docs 主席](https://kubernetes.io/zh-cn/docs/contribute/participate/#sig-docs-chairperson) 等。 接下来 --- 关于贡献 Kubernetes 文档的更多信息，请参考： * [贡献新内容](https://kubernetes.io/zh-cn/docs/contribute/new-content/) * [评阅内容](https://kubernetes.io/zh-cn/docs/contribute/review/reviewing-prs) * [文档样式指南](https://kubernetes.io/zh-cn/docs/contribute/style/) * * * ##### [角色与责任](https://kubernetes.io/zh-cn/docs/contribute/participate/roles-and-responsibilities/) ##### [Issue 管理者](https://kubernetes.io/zh-cn/docs/contribute/participate/issue-wrangler/) ##### [PR 管理者](https://kubernetes.io/zh-cn/docs/contribute/participate/pr-wranglers/) 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 November 04, 2024 at 10:05 PM PST: [\[zh-cn\]sync participate/\_index.md (7fc71749c1)](https://github.com/kubernetes/website/commit/7fc71749c1c1e8dfbcec571418b89db86eec30c8) --- # Kubernetes 指标 (v1beta1) | Kubernetes Kubernetes 指标 (v1beta1) ======================= v1beta1 包是 v1beta1 版本的指标 API。 资源类型 ---- * [NodeMetrics](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-NodeMetrics) * [NodeMetricsList](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-NodeMetricsList) * [PodMetrics](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-PodMetrics) * [PodMetricsList](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-PodMetricsList) `NodeMetrics` ------------- **出现在：** * [NodeMetricsList](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-NodeMetricsList) NodeMetrics 设置节点的资源用量指标。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `metrics.k8s.io/v1beta1` | | `kind`
string | `NodeMetrics` | | `metadata`
[`meta/v1.ObjectMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#objectmeta-v1-meta) | 标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

参阅 Kubernetes API 文档了解 `metadata` 字段。 | | `timestamp` **\[必需\]**
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#time-v1-meta) | 以下字段定义从时间间隔 \[Timestamp-Window，Timestamp\] 中收集指标的时间间隔。 | | `window` **\[必需\]**
[`meta/v1.Duration`](https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration) | 无描述。 | | `usage` **\[必需\]**
[`core/v1.ResourceList`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcelist-v1-core) | 内存用量是内存工作集。 | `NodeMetricsList` ----------------- NodeMetricsList 是 NodeMetrics 的列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `metrics.k8s.io/v1beta1` | | `kind`
string | `NodeMetricsList` | | `metadata` **\[必需\]**
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#listmeta-v1-meta) | 标准的列表元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | `items` **\[必需\]**
[`[]NodeMetrics`](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-NodeMetrics) | 节点指标的列表。 | `PodMetrics` ------------ **出现在：** * [PodMetricsList](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-PodMetricsList) PodMetrics 设置 Pod 的资源用量指标。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `metrics.k8s.io/v1beta1` | | `kind`
string | `PodMetrics` | | `metadata`
[`meta/v1.ObjectMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#objectmeta-v1-meta) | 标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

参阅 Kubernetes API 文档了解 `metadata` 字段。 | | `timestamp` **\[必需\]**
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#time-v1-meta) | 以下字段定义了从时间间隔 \[Timestamp-Window，Timestamp\] 中收集指标的时间间隔。 | | `window` **\[必需\]**
[`meta/v1.Duration`](https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration) | 无描述。 | | `containers` **\[必需\]**
[`[]ContainerMetrics`](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-ContainerMetrics) | 在相同时间窗口内收集所有容器的指标。 | `PodMetricsList` ---------------- PodMetricsList 是 PodMetrics 的列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `metrics.k8s.io/v1beta1` | | `kind`
string | `PodMetricsList` | | `metadata` **\[必需\]**
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#listmeta-v1-meta) | 标准的列表元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | `items` **\[必需\]**
[`[]PodMetrics`](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-PodMetrics) | Pod 指标的列表。 | `ContainerMetrics` ------------------ **出现在：** * [PodMetrics](https://kubernetes.io/zh-cn/docs/reference/external-api/metrics.v1beta1/#metrics-k8s-io-v1beta1-PodMetrics) ContainerMetrics 设置容器的资源用量指标。 | 字段 | 描述 | | --- | --- | | `name` **\[必需\]**
`string` | 与 pod.spec.containers 中某个对应的容器名称。 | | `usage` **\[必需\]**
[`core/v1.ResourceList`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcelist-v1-core) | 内存用量是内容工作集。 | 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 September 22, 2023 at 9:37 AM PST: [\[zh\] Sync metrics.v1beta1.md (1d807f7b1f)](https://github.com/kubernetes/website/commit/1d807f7b1f43b26a9469a0787cf4230d93e9f91f) --- # 官方 CVE 订阅源 | Kubernetes 官方 CVE 订阅源 ========== 特性状态： `Kubernetes v1.27 [beta]` 这是由 Kubernetes 安全响应委员会（Security Response Committee, SRC）公布的经社区维护的官方 CVE 列表。 更多细节请参阅 [Kubernetes 安全和信息披露](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/) 。 Kubernetes 项目以 [JSON Feed](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) 和 [RSS feed](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/feed.xml) 格式就已发布的安全问题提供了可通过程序访问的提要。 你可以通过执行以下命令来查阅这些安全问题： * [JSON feed](https://kubernetes.io/zh-cn/docs/reference/issues-security/official-cve-feed/#cve-feeds-0) * [RSS feed](https://kubernetes.io/zh-cn/docs/reference/issues-security/official-cve-feed/#cve-feeds-1) [链接到 JSON 格式](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json [链接到 RSS 格式](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/feed.xml) curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml | | | | | --- | --- | --- |Kubernetes CVE 列表 （最后更新：2026-03-20 12:45:52 UTC） | CVE ID | 问题描述 | CVE GitHub Issue URL | | --- | --- | --- | | [CVE-2026-4342](https://github.com/kubernetes/kubernetes/issues/137893) | ingress-nginx comment-based nginx configuration injection | [#137893](https://github.com/kubernetes/kubernetes/issues/137893) | | [CVE-2026-3864](https://github.com/kubernetes/kubernetes/issues/137797) | CSI Driver for NFS path traversal via subDir may delete unintended directories on the NFS server | [#137797](https://github.com/kubernetes/kubernetes/issues/137797) | | [CVE-2025-15566](https://github.com/kubernetes/kubernetes/issues/136789) | ingress-nginx auth-proxy-set-headers nginx configuration injection | [#136789](https://github.com/kubernetes/kubernetes/issues/136789) | | [CVE-2026-24514](https://github.com/kubernetes/kubernetes/issues/136680) | ingress-nginx Admission Controller denial of service | [#136680](https://github.com/kubernetes/kubernetes/issues/136680) | | [CVE-2026-24513](https://github.com/kubernetes/kubernetes/issues/136679) | ingress-nginx auth-url protection bypass | [#136679](https://github.com/kubernetes/kubernetes/issues/136679) | | [CVE-2026-24512](https://github.com/kubernetes/kubernetes/issues/136678) | ingress-nginx rules.http.paths.path nginx configuration injection | [#136678](https://github.com/kubernetes/kubernetes/issues/136678) | | [CVE-2026-1580](https://github.com/kubernetes/kubernetes/issues/136677) | ingress-nginx auth-method nginx configuration injection | [#136677](https://github.com/kubernetes/kubernetes/issues/136677) | | [CVE-2025-14269](https://github.com/kubernetes/kubernetes/issues/135798) | Credential caching in Headlamp with Helm enabled | [#135798](https://github.com/kubernetes/kubernetes/issues/135798) | | [CVE-2025-13281](https://github.com/kubernetes/kubernetes/issues/135525) | Portworx Half-Blind SSRF in kube-controller-manager | [#135525](https://github.com/kubernetes/kubernetes/issues/135525) | | [CVE-2025-9708](https://github.com/kubernetes/kubernetes/issues/134063) | Kubernetes C# Client: improper certificate validation in custom CA mode may lead to man-in-the-middle attacks | [#134063](https://github.com/kubernetes/kubernetes/issues/134063) | | [CVE-2025-7445](https://github.com/kubernetes/kubernetes/issues/133897) | secrets-store-sync-controller discloses service account tokens in logs | [#133897](https://github.com/kubernetes/kubernetes/issues/133897) | | [CVE-2025-5187](https://github.com/kubernetes/kubernetes/issues/133471) | Nodes can delete themselves by adding an OwnerReference | [#133471](https://github.com/kubernetes/kubernetes/issues/133471) | | [CVE-2025-7342](https://github.com/kubernetes/kubernetes/issues/133115) | VM images built with Kubernetes Image Builder Nutanix or OVA providers use default credentials for Windows images if user did not override | [#133115](https://github.com/kubernetes/kubernetes/issues/133115) | | [CVE-2025-4563](https://github.com/kubernetes/kubernetes/issues/132151) | Nodes can bypass dynamic resource allocation authorization checks | [#132151](https://github.com/kubernetes/kubernetes/issues/132151) | | [CVE-2025-1974](https://github.com/kubernetes/kubernetes/issues/131009) | ingress-nginx admission controller RCE escalation | [#131009](https://github.com/kubernetes/kubernetes/issues/131009) | | [CVE-2025-1098](https://github.com/kubernetes/kubernetes/issues/131008) | ingress-nginx controller configuration injection via unsanitized mirror annotations | [#131008](https://github.com/kubernetes/kubernetes/issues/131008) | | [CVE-2025-1097](https://github.com/kubernetes/kubernetes/issues/131007) | ingress-nginx controller configuration injection via unsanitized auth-tls-match-cn annotation | [#131007](https://github.com/kubernetes/kubernetes/issues/131007) | | [CVE-2025-24514](https://github.com/kubernetes/kubernetes/issues/131006) | ingress-nginx controller configuration injection via unsanitized auth-url annotation | [#131006](https://github.com/kubernetes/kubernetes/issues/131006) | | [CVE-2025-24513](https://github.com/kubernetes/kubernetes/issues/131005) | ingress-nginx controller auth secret file path traversal vulnerability | [#131005](https://github.com/kubernetes/kubernetes/issues/131005) | | [CVE-2025-1767](https://github.com/kubernetes/kubernetes/issues/130786) | GitRepo Volume Inadvertent Local Repository Access | [#130786](https://github.com/kubernetes/kubernetes/issues/130786) | | [CVE-2025-0426](https://github.com/kubernetes/kubernetes/issues/130016) | Node Denial of Service via kubelet Checkpoint API | [#130016](https://github.com/kubernetes/kubernetes/issues/130016) | | [CVE-2024-9042](https://github.com/kubernetes/kubernetes/issues/129654) | Command Injection affecting Windows nodes via nodes/\*/logs/query API | [#129654](https://github.com/kubernetes/kubernetes/issues/129654) | | [CVE-2024-10220](https://github.com/kubernetes/kubernetes/issues/128885) | Arbitrary command execution through gitRepo volume | [#128885](https://github.com/kubernetes/kubernetes/issues/128885) | | [CVE-2024-9594](https://github.com/kubernetes/kubernetes/issues/128007) | VM images built with Image Builder with some providers use default credentials during builds | [#128007](https://github.com/kubernetes/kubernetes/issues/128007) | | [CVE-2024-9486](https://github.com/kubernetes/kubernetes/issues/128006) | VM images built with Image Builder and Proxmox provider use default credentials | [#128006](https://github.com/kubernetes/kubernetes/issues/128006) | | [CVE-2024-7646](https://github.com/kubernetes/kubernetes/issues/126744) | Ingress-nginx Annotation Validation Bypass | [#126744](https://github.com/kubernetes/kubernetes/issues/126744) | | [CVE-2024-7598](https://github.com/kubernetes/kubernetes/issues/126587) | Network restriction bypass via race condition during namespace termination | [#126587](https://github.com/kubernetes/kubernetes/issues/126587) | | [CVE-2024-5321](https://github.com/kubernetes/kubernetes/issues/126161) | Incorrect permissions on Windows containers logs | [#126161](https://github.com/kubernetes/kubernetes/issues/126161) | | [CVE-2024-3744](https://github.com/kubernetes/kubernetes/issues/124759) | azure-file-csi-driver discloses service account tokens in logs | [#124759](https://github.com/kubernetes/kubernetes/issues/124759) | | [CVE-2024-3177](https://github.com/kubernetes/kubernetes/issues/124336) | Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#124336](https://github.com/kubernetes/kubernetes/issues/124336) | | [CVE-2023-5528](https://github.com/kubernetes/kubernetes/issues/121879) | Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes | [#121879](https://github.com/kubernetes/kubernetes/issues/121879) | | [CVE-2023-5044](https://github.com/kubernetes/kubernetes/issues/126817) | Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation | [#126817](https://github.com/kubernetes/kubernetes/issues/126817) | | [CVE-2023-5043](https://github.com/kubernetes/kubernetes/issues/126816) | Ingress nginx annotation injection causes arbitrary command execution | [#126816](https://github.com/kubernetes/kubernetes/issues/126816) | | [CVE-2022-4886](https://github.com/kubernetes/kubernetes/issues/126815) | ingress-nginx path sanitization can be bypassed | [#126815](https://github.com/kubernetes/kubernetes/issues/126815) | | [CVE-2023-3955](https://github.com/kubernetes/kubernetes/issues/119595) | Insufficient input sanitization on Windows nodes leads to privilege escalation | [#119595](https://github.com/kubernetes/kubernetes/issues/119595) | | [CVE-2023-3893](https://github.com/kubernetes/kubernetes/issues/119594) | Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation | [#119594](https://github.com/kubernetes/kubernetes/issues/119594) | | [CVE-2023-3676](https://github.com/kubernetes/kubernetes/issues/119339) | Insufficient input sanitization on Windows nodes leads to privilege escalation | [#119339](https://github.com/kubernetes/kubernetes/issues/119339) | | [CVE-2023-2431](https://github.com/kubernetes/kubernetes/issues/118690) | Bypass of seccomp profile enforcement | [#118690](https://github.com/kubernetes/kubernetes/issues/118690) | | [CVE-2023-2728](https://github.com/kubernetes/kubernetes/issues/118640) | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#118640](https://github.com/kubernetes/kubernetes/issues/118640) | | [CVE-2023-2727](https://github.com/kubernetes/kubernetes/issues/118640) | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#118640](https://github.com/kubernetes/kubernetes/issues/118640) | | [CVE-2023-2878](https://github.com/kubernetes/kubernetes/issues/118419) | secrets-store-csi-driver discloses service account tokens in logs | [#118419](https://github.com/kubernetes/kubernetes/issues/118419) | | [CVE-2022-3294](https://github.com/kubernetes/kubernetes/issues/113757) | Node address isn't always verified when proxying | [#113757](https://github.com/kubernetes/kubernetes/issues/113757) | | [CVE-2022-3162](https://github.com/kubernetes/kubernetes/issues/113756) | Unauthorized read of Custom Resources | [#113756](https://github.com/kubernetes/kubernetes/issues/113756) | | [CVE-2022-3172](https://github.com/kubernetes/kubernetes/issues/112513) | Aggregated API server can cause clients to be redirected (SSRF) | [#112513](https://github.com/kubernetes/kubernetes/issues/112513) | | [CVE-2021-25749](https://github.com/kubernetes/kubernetes/issues/112192) | \`runAsNonRoot\` logic bypass for Windows containers | [#112192](https://github.com/kubernetes/kubernetes/issues/112192) | | [CVE-2021-25748](https://github.com/kubernetes/kubernetes/issues/126814) | Ingress-nginx \`path\` sanitization can be bypassed with newline character | [#126814](https://github.com/kubernetes/kubernetes/issues/126814) | | [CVE-2021-25746](https://github.com/kubernetes/kubernetes/issues/126813) | Ingress-nginx directive injection via annotations | [#126813](https://github.com/kubernetes/kubernetes/issues/126813) | | [CVE-2021-25745](https://github.com/kubernetes/kubernetes/issues/126812) | Ingress-nginx \`path\` can be pointed to service account token file | [#126812](https://github.com/kubernetes/kubernetes/issues/126812) | | [CVE-2021-25742](https://github.com/kubernetes/kubernetes/issues/126811) | Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces | [#126811](https://github.com/kubernetes/kubernetes/issues/126811) | | [CVE-2021-25741](https://github.com/kubernetes/kubernetes/issues/104980) | Symlink Exchange Can Allow Host Filesystem Access | [#104980](https://github.com/kubernetes/kubernetes/issues/104980) | | [CVE-2020-8561](https://github.com/kubernetes/kubernetes/issues/104720) | Webhook redirect in kube-apiserver | [#104720](https://github.com/kubernetes/kubernetes/issues/104720) | | [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675) | Endpoint & EndpointSlice permissions allow cross-Namespace forwarding | [#103675](https://github.com/kubernetes/kubernetes/issues/103675) | | [CVE-2021-25737](https://github.com/kubernetes/kubernetes/issues/102106) | Holes in EndpointSlice Validation Enable Host Network Hijack | [#102106](https://github.com/kubernetes/kubernetes/issues/102106) | | [CVE-2020-8562](https://github.com/kubernetes/kubernetes/issues/101493) | Bypass of Kubernetes API Server proxy TOCTOU | [#101493](https://github.com/kubernetes/kubernetes/issues/101493) | | [CVE-2021-3121](https://github.com/kubernetes/kubernetes/issues/101435) | Processes may panic upon receipt of malicious protobuf messages | [#101435](https://github.com/kubernetes/kubernetes/issues/101435) | | [CVE-2021-25735](https://github.com/kubernetes/kubernetes/issues/100096) | Validating Admission Webhook does not observe some previous fields | [#100096](https://github.com/kubernetes/kubernetes/issues/100096) | | [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076) | Man in the middle using LoadBalancer or ExternalIPs | [#97076](https://github.com/kubernetes/kubernetes/issues/97076) | | [CVE-2020-8566](https://github.com/kubernetes/kubernetes/issues/95624) | Ceph RBD adminSecrets exposed in logs when loglevel >= 4 | [#95624](https://github.com/kubernetes/kubernetes/issues/95624) | | [CVE-2020-8565](https://github.com/kubernetes/kubernetes/issues/95623) | Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9 | [#95623](https://github.com/kubernetes/kubernetes/issues/95623) | | [CVE-2020-8564](https://github.com/kubernetes/kubernetes/issues/95622) | Docker config secrets leaked when file is malformed and log level >= 4 | [#95622](https://github.com/kubernetes/kubernetes/issues/95622) | | [CVE-2020-8563](https://github.com/kubernetes/kubernetes/issues/95621) | Secret leaks in kube-controller-manager when using vSphere provider | [#95621](https://github.com/kubernetes/kubernetes/issues/95621) | | [CVE-2020-8557](https://github.com/kubernetes/kubernetes/issues/93032) | Node disk DOS by writing to container /etc/hosts | [#93032](https://github.com/kubernetes/kubernetes/issues/93032) | | [CVE-2020-8559](https://github.com/kubernetes/kubernetes/issues/92914) | Privilege escalation from compromised node to cluster | [#92914](https://github.com/kubernetes/kubernetes/issues/92914) | | [CVE-2020-8558](https://github.com/kubernetes/kubernetes/issues/92315) | Node setting allows for neighboring hosts to bypass localhost boundary | [#92315](https://github.com/kubernetes/kubernetes/issues/92315) | | [CVE-2020-8555](https://github.com/kubernetes/kubernetes/issues/91542) | Half-Blind SSRF in kube-controller-manager | [#91542](https://github.com/kubernetes/kubernetes/issues/91542) | | [CVE-2020-10749](https://github.com/kubernetes/kubernetes/issues/91507) | IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements | [#91507](https://github.com/kubernetes/kubernetes/issues/91507) | | [CVE-2019-11254](https://github.com/kubernetes/kubernetes/issues/89535) | kube-apiserver Denial of Service vulnerability from malicious YAML payloads | [#89535](https://github.com/kubernetes/kubernetes/issues/89535) | | [CVE-2020-8552](https://github.com/kubernetes/kubernetes/issues/89378) | apiserver DoS (oom) | [#89378](https://github.com/kubernetes/kubernetes/issues/89378) | | [CVE-2020-8551](https://github.com/kubernetes/kubernetes/issues/89377) | Kubelet DoS via API | [#89377](https://github.com/kubernetes/kubernetes/issues/89377) | | [CVE-2020-8553](https://github.com/kubernetes/kubernetes/issues/126818) | ingress-nginx auth-type basic annotation vulnerability | [#126818](https://github.com/kubernetes/kubernetes/issues/126818) | | [CVE-2019-11251](https://github.com/kubernetes/kubernetes/issues/87773) | kubectl cp symlink vulnerability | [#87773](https://github.com/kubernetes/kubernetes/issues/87773) | | [CVE-2018-1002102](https://github.com/kubernetes/kubernetes/issues/85867) | Unvalidated redirect | [#85867](https://github.com/kubernetes/kubernetes/issues/85867) | | [CVE-2019-11255](https://github.com/kubernetes/kubernetes/issues/85233) | CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation | [#85233](https://github.com/kubernetes/kubernetes/issues/85233) | | [CVE-2019-11253](https://github.com/kubernetes/kubernetes/issues/83253) | Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack | [#83253](https://github.com/kubernetes/kubernetes/issues/83253) | | [CVE-2019-11250](https://github.com/kubernetes/kubernetes/issues/81114) | Bearer tokens are revealed in logs (audit finding TOB-K8S-001) | [#81114](https://github.com/kubernetes/kubernetes/issues/81114) | | [CVE-2019-11248](https://github.com/kubernetes/kubernetes/issues/81023) | /debug/pprof exposed on kubelet's healthz port | [#81023](https://github.com/kubernetes/kubernetes/issues/81023) | | [CVE-2019-11249](https://github.com/kubernetes/kubernetes/issues/80984) | Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal | [#80984](https://github.com/kubernetes/kubernetes/issues/80984) | | [CVE-2019-11247](https://github.com/kubernetes/kubernetes/issues/80983) | API server allows access to custom resources via wrong scope | [#80983](https://github.com/kubernetes/kubernetes/issues/80983) | | [CVE-2019-11245](https://github.com/kubernetes/kubernetes/issues/78308) | container uid changes to root after first restart or if image is already pulled to the node | [#78308](https://github.com/kubernetes/kubernetes/issues/78308) | | [CVE-2019-11243](https://github.com/kubernetes/kubernetes/issues/76797) | rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig() | [#76797](https://github.com/kubernetes/kubernetes/issues/76797) | | [CVE-2019-11244](https://github.com/kubernetes/kubernetes/issues/76676) | \`kubectl --http-cache=\` creates world-writeable cached schema files | [#76676](https://github.com/kubernetes/kubernetes/issues/76676) | | [CVE-2019-1002100](https://github.com/kubernetes/kubernetes/issues/74534) | json-patch requests can exhaust apiserver resources | [#74534](https://github.com/kubernetes/kubernetes/issues/74534) | | [CVE-2018-1002105](https://github.com/kubernetes/kubernetes/issues/71411) | proxy request handling in kube-apiserver can leave vulnerable TCP connections | [#71411](https://github.com/kubernetes/kubernetes/issues/71411) | | [CVE-2018-1002101](https://github.com/kubernetes/kubernetes/issues/65750) | smb mount security issue | [#65750](https://github.com/kubernetes/kubernetes/issues/65750) | | [CVE-2018-1002100](https://github.com/kubernetes/kubernetes/issues/61297) | Kubectl copy doesn't check for paths outside of it's destination directory. | [#61297](https://github.com/kubernetes/kubernetes/issues/61297) | | [CVE-2017-1002102](https://github.com/kubernetes/kubernetes/issues/60814) | atomic writer volume handling allows arbitrary file deletion in host filesystem | [#60814](https://github.com/kubernetes/kubernetes/issues/60814) | | [CVE-2017-1002101](https://github.com/kubernetes/kubernetes/issues/60813) | subpath volume mount handling allows arbitrary file access in host filesystem | [#60813](https://github.com/kubernetes/kubernetes/issues/60813) | | [CVE-2017-1002100](https://github.com/kubernetes/kubernetes/issues/47611) | Azure PV should be Private scope not Container scope | [#47611](https://github.com/kubernetes/kubernetes/issues/47611) | | [CVE-2017-1000056](https://github.com/kubernetes/kubernetes/issues/43459) | PodSecurityPolicy admission plugin authorizes incorrectly | [#43459](https://github.com/kubernetes/kubernetes/issues/43459) | 此订阅源会自动刷新，但从宣布 CVE 到可在此订阅源中找到对应的 CVE 会有一个明显却很小的延迟（几分钟到几小时）。 此订阅源的真实来源是一组 GitHub Issue，通过受控和受限的标签 `official-cve-feed` 进行过滤。 原始数据存放在 Google Cloud Bucket 中，只有社区少数受信任的成员可以写入。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 April 12, 2023 at 3:33 PM PST: [\[zh-cn\] Sync issues-security/official-cve-feed.md (7046c173da)](https://github.com/kubernetes/website/commit/7046c173da64fdc0768b79fcc9cb010d1e6d5b07) --- # プロダクション環境 | Kubernetes **このページに記載されている情報は古い可能性があります** このページの更新日は英語版よりも古いため、記載されている情報が古い可能性があります。最新の情報をご覧になりたい方は英語版のページをご覧ください: [Production environment](https://kubernetes.io/docs/setup/production-environment/) プロダクション環境 ========= プロダクション品質のKubernetesクラスターを作成します。 プロダクション環境向けのKubernetesクラスターには計画と準備が必要です。Kubernetesクラスターが重要なワークロードを動かしている場合、耐障害性のある構成にしなければいけません。このページはプロダクション環境で利用できるクラウターのセットアップをするための手順や既存のクラスターをプロダクション環境で利用できるように昇格するための手順を説明します。 既にプロダクション環境のセットアップを理解している場合、[次の項目](https://kubernetes.io/ja/docs/setup/production-environment/#what-s-next) に進んでください。 プロダクション環境の考慮事項 -------------- 通常、プロダクション用のKubernetesクラスター環境は個人学習の環境や開発環境、テスト環境より多くの要件があります。プロダクション環境は多くのユーザーによるセキュアなアクセスや安定した可用性、変化する需要に適用するためのリソースが必要になる場合があります。 プロダクション用のKubernetes環境をどこに配置するか(オンプレミスまたはクラウド)、どの程度の管理を自分で行うか、それとも他に任せるかを決定する際には、以下の問題がKubernetesクラスターに対する要件にどのように影響を与えるかを考慮してください。 * _可用性_: 単一のマシンで動作するKubernetes[学習環境](https://kubernetes.io/ja/docs/setup/#learning-environment) には単一障害点があります。高可用性のクラスターの作成するには下記の点を考慮する必要があります。 * ワーカーノードからのコントロールプレーンの分離 * 複数ノードへのコントロールプレーンのレプリケーション * クラスターの[APIサーバー](https://kubernetes.io/ja/docs/concepts/overview/components/#kube-apiserver "Kubernetes APIを提供するコントロールプレーンのコンポーネントです。") へのトラフィックの負荷分散 * 変化するワークロードに応じて、十分な数のワーカーノードが利用可能であること、または迅速に利用可能になること * _スケール_: プロダクション用のKubernetes環境が安定した要求を受けることが予測できる場合、必要なキャパシティをセットアップすることができるかもしれません。しかし、時間の経過と共に成長する需要やシーズンや特別なイベントのようなことで大幅な変化を予測する場合、コントロールプレーンやワーカーノードへの多くのリクエストにより増加する負荷を軽減するスケールの方法や未使用のリソースを削減するためのスケールダウンの方法を計画する必要があリます。 * _セキュリティやアクセス管理_: 自身のKubernetes学習クラスターでは全管理者権限を持っています。しかし、重要なワークロードを保持していたり、複数のユーザーが利用する共有クラスターでは、誰がどのクラスターのリソースに対してアクセスできるかをより制限されたアプローチを必要とします。ユーザーやワークロードが必要なリソースへアクセスできることを実現するロールベースアクセス制御([RBAC](https://kubernetes.io/ja/docs/reference/access-authn-authz/rbac/) )や他のセキュリティメカニズムを使用し、ワークロードやクラスターを保護することができます。[ポリシー](https://kubernetes.io/ja/docs/concepts/policy/) や[コンテナリソース](https://kubernetes.io/ja/docs/concepts/configuration/manage-resources-containers/) を管理することによってユーザーやワークロードがアクセスできるリソースの制限を設定できます。 自身のプロダクション環境のKubernetesを構築する前に、[ターンキークラウドソリューション](https://kubernetes.io/ja/docs/setup/production-environment/turnkey-solutions/) や プロバイダーや他の[Kubernetesパートナー](https://kubernetes.io/ja/partners/) へ仕事の一部や全てを委託することを考えてください。オプションには次のものが含まれます。 * _サーバーレス_: クラスターを全く管理せずに第三者の設備上でワークロードを実行します。CPU使用量やメモリ、ディスクリクエストなどの利用に応じて課金します。 * _マネージドコントロールプレーン_: クラスターのコントロールプレーンのスケールと可用性やパッチとアップグレードの実行をプロバイダーに管理してもらいます。 * _マネージドワーカーノード_: 需要に合わせてノードのプールを構成し、プロバイダーがワーカーノードが利用可能であることを保証し、需要に応じたアップグレードを実施できるようにします。 * _統合_: ストレージ、コンテナレジストリ、認証方法、開発ツールなどの他の必要なサービスとKubernetesを統合するプロバイダーも存在します。 プロダクション用のKubernetesクラスターを自身で構築する場合でもパートナーと連携する場合でもクラスターの_コントロールプレーン_、_ワーカーノード_、_ユーザーアクセス_、および_ワークロードリソース_に関連する要件を評価するために以下のセクションのレビューを行なってください。 プロダクション環境のクラスターのセットアップ ---------------------- プロダクション環境向けのKubernetesクラスターでは、コントロールプレーンが異なる方法で複数のコンピューターに分散されたサービスからクラスターを管理します。一方で、各ワーカーノードは単一のエンティティとして表され、KubernetesのPodを実行するように設定されています。 ### プロダクション環境のコントロールプレーン 最もシンプルなKubernetesクラスターはすべてのコントロールプレーンとワーカーノードサービスが同一のマシン上で稼働しています。[Kubernetesコンポーネント](https://kubernetes.io/ja/docs/concepts/overview/components/) の図に示すようにワーカーノードの追加によって環境をスケールさせることができます。クラスターが短時間の稼働や深刻な問題が起きたときに破棄してもよい場合は、同一マシン上での構成で要件を満たしているかもしれません。 永続性や高可用性のクラスターが必要であれば、コントロールプレーンの拡張方法を考えなければいけません。設計上、単一のマシンで動作するコントロールプレーンサービスは高可用性ではありません。クラスターを常に稼働させ、何か問題が発生した場合に修復できる保証が重要な場合は、以下のステップを考えてください。 * _デプロイツールの選択_: kubeadm、kopsやkubesprayなどのツールを使ってコントロールプレーンをデプロイできます。これらのデプロイメント方法を使用したプロダクション環境向けののデプロイのヒントを学ぶために[デプロイツールによるKubernetesのインストール](https://kubernetes.io/ja/docs/setup/production-environment/tools/) をご覧になってください。異なる[コンテナランタイム](https://kubernetes.io/ja/docs/setup/production-environment/container-runtimes/) をデプロイに使用することができます。 * _証明書の管理_: コントロールプレーンサービス間の安全な通信は証明書を使用して実装されています。証明書はデプロイ時に自動で生成したり、独自の認証局を使用し生成することができます。詳細は[PKI証明書と要件](https://kubernetes.io/ja/docs/setup/best-practices/certificates/) をご覧ください。 * _APIサーバー用のロードバランサーの構成_: 外部からのAPIリクエストを異なるノード上で稼働しているAPIサーバーサービスインスタンスに分散させるためにロードバランサーを設定します。詳細は [外部ロードバランサーの作成](https://kubernetes.io/ja/docs/tasks/access-application-cluster/create-external-load-balancer/) をご覧ください。 * _etcdサービスの分離とバックアップ_: etcdサービスは他のコントロールプレーンサービスと同じマシン上で動作させることも、追加のセキュリティと可用性のために別のマシン上で動作させることもできます。etcdはクラスターの構成データを格納しており、必要に応じてデータベースを修復できるようにするためにetcdデータベースのバックアップは定期的に行うべきです。etcdの構成と使用に関する詳細は[etcd FAQ](https://etcd.io/docs/v3.5/faq/) をご覧ください。また、[Kubernetes向けのetcdクラスターの運用](https://kubernetes.io/ja/docs/tasks/administer-cluster/configure-upgrade-etcd/) と[kubeadmを使用した高可用性etcdクラスターのセットアップ](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) もご覧ください。 * _複数のコントロールプレーンシステムの作成_: 高可用性のためにコントロールプレーンは単一のマシンに限定されるべきではありません。コントロールプレーンサービスはinitサービス（systemdなど）によって実行される場合、各サービスは少なくとも3台のマシンで実行されるべきです。しかし、Kubernetes内でPodとしてコントロールプレーンサービスを実行することで、リクエストしたサービスのレプリカ数が常に利用可能であることが保証されます。スケジューラーは耐障害性が備わっているべきですが、高可用性は必要ありません。一部のデプロイメントツールはKubernetesサービスのリーダー選出のために[Raft](https://raft.github.io/) コンセンサスアルゴリズムを設定しています。プライマリが失われた場合、別のサービスが自らを選出して引き継ぎます。 * _複数ゾーンへの配置_: クラスターを常に利用可能に保つことが重要である場合、複数のデータセンターにまたがって実行されるクラスターを作成することを検討してください。クラウド環境ではゾーンと呼ばれます。ゾーンのグループはリージョンと呼ばれます。同リージョンで複数のゾーンにクラスターを分散させることで、一つのゾーンが利用不可能になったとしても、クラスタが機能し続ける可能性を向上できます。詳細は、[複数ゾーンでの稼働](https://kubernetes.io/ja/docs/setup/best-practices/multiple-zones/) をご覧ください。 * _継続的な機能の管理_: クラスターを長期間稼働する計画がある場合、正常性とセキュリティを維持するために行うべきタスクがあります。例えば、kubeadmを使用してインストールした場合、[証明書管理](https://kubernetes.io/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) や[kubeadmによるクラスターのアップグレード](https://kubernetes.io/ja/docs/setup/production-environment/s/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) を支援するドキュメントがあります。より多くのKubernetes管理タスクのリストについては、[クラスターの管理](https://kubernetes.io/ja/docs/tasks/administer-cluster/) をご覧ください。 コントロールプレーンサービスを実行する際の利用可能なオプションについて学ぶためには、[kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) 、[kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) 、[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) のコンポーネントページをご覧ください。高可用性のコントロールプレーンの例については、[高可用性トポロジーのオプション](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/ha-topology/) 、[kubeadmを使用した高可用性クラスターの作成](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/high-availability/) 、[Kubernetes向けetcdクラスターの運用](https://kubernetes.io/ja/docs/tasks/administer-cluster/configure-upgrade-etcd/) をご覧ください。etcdクラスターのバックアップ計画の作成については、[etcdクラスターのバックアップ](https://kubernetes.io/ja/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) をご覧ください。 ### プロダクション環境のワーカーノード プロダクション向けのワークロードとそのワークロードが依存するサービス(CoreDNSなど)は耐障害性を必要とします。自身でコントロールプレーンを管理するか、クラウドプロバイダーに任せるかに関わらず、ワーカーノード(単にノードとも呼ばれます)の管理方法を考える必要があります。 * _ノードの構成_: ノードは物理マシンもしくは仮想マシンになります。ノードを自身で作成し管理したい場合、サポートされてるオペレーティングシステムをインストールし、適切な[ノードサービス](https://kubernetes.io/ja/docs/concepts/overview/components/#node-components) を追加し、実行します。 * ノードをセットアップする際に、ワークロードの需要に合わせた適切なメモリ、CPU、ディスク速度、ストレージ容量を確保することを考えること * 汎用コンピュータシステムで十分か、GPUプロセッサやWindowsノード、VMの分離を必要とするワークロードがあるかどうかを考えること * _ノードの検証_: ノードがKubernetesクラスターに参加するための要件を満たしていることを保証する方法についての情報は[有効なノードのセットアップ](https://kubernetes.io/ja/docs/setup/best-practices/node-conformance/) をご覧ください。 * _クラスターへのノードの追加_: 自身でクラスターを管理している場合、自身のマシンをセットアップし手動で追加するか、または自動でクラスターのAPIサーバーに登録させることによってノードを追加できます。これらのKubernetesへノードを追加するためのセットアップ方法については、[ノード](https://kubernetes.io/ja/docs/concepts/architecture/nodes/) セクションをご覧ください。 * _ノードのスケール_: クラスターのキャパシティの拡張プランを作成することは最終的に必要になります。稼働させなければいけないPod数やコンテナ数を基にどのくらいのノード数が必要なのかを決定をするための助けとなる[大規模クラスターの考慮事項](https://kubernetes.io/ja/docs/setup/best-practices/cluster-large/) をご覧ください。自身でノードを管理する場合、自身で物理機材を購入し設置することを意味します。 * _ノードのオートスケーリング_: ノードやノードが提供するキャパシティを自動的に管理するために利用できるツールについて学ぶために、[クラスターのオートスケーリング](https://kubernetes.io/ja/docs/concepts/cluster-administration/cluster-autoscaling) をご覧ください。 * _ノードのヘルスチェックのセットアップ_: 重要なワークロードのためにノード上で稼働しているノードとPodが正常であることを確認しなければいけません。[Node Problem Detector](https://kubernetes.io/ja/docs/tasks/debug/debug-cluster/monitor-node-health/) デーモンを使用し、ノードが正常であることを保証してください。 プロダクション環境のユーザー管理 ---------------- プロダクション環境では、自身または少人数の小さなグループがクラスターにアクセスするモデルから、数十人から数百人がアクセスする可能性のあるモデルへと移行するかもしれません。学習環境やプラットフォームのプロトタイプでは、すべての作業を行うための1つの管理アカウントを持っているかもしれません。プロダクション環境では、異なる名前空間へのアクセスレベルが異なる複数のアカウントを持つことになリます。 プロダクション環境向けのクラスターを運用することは、他のユーザーによるアクセスを選択的に許可する方法を決定することを意味します。特に、クラスターにアクセスをしようとするユーザーの身元を検証するための戦略を選択し(認証)、ユーザーが要求する操作に対して権限があるかどうかを決定する必要があります(認可)。: * _認証_: APIサーバーはクライアント証明書、bearerトークン、認証プロキシまたはHTTPベーシック認証を使用し、ユーザーを認証できます。使用したい認証の方法を選択できます。プラグインを使用することで、APIサーバーはLDAPやKerberosなどの組織の既存の認証方法を活用できます。Kubernetesユーザーを認証する様々な方法の説明は[認証](https://kubernetes.io/ja/docs/reference/access-authn-authz/authentication/) をご覧ください。 * _認可_: 通常のユーザーを認可する際には、おそらくRBACとABACの認可方法のどちらかを選択することになります。様々なユーザーアカウントの認可方式(およびサービスアカウントによるクラスターがアクセスするための認可方式)を評価するために、[認可の概要](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) をご覧ください。 * _ロールベースアクセスコントロール_: ([RBAC](https://kubernetes.io/ja/docs/reference/access-authn-authz/rbac/) ): 認証されたユーザーに特定の権限のセットを許可することによってクラスターへのアクセスを割り当てることができます。特定のNamespace(Role)やクラスター全体(ClusterRole)に権限を割り当てることができます。RoleBindingsやClusterRoleBindingsを使用することによって、権限を特定のユーザーに付与することができます。 * _属性ベースアクセスコントロール_ ([ABAC](https://kubernetes.io/ja/docs/reference/access-authn-authz/abac/) ): クラスターのリソース属性に基づいたポリシーを作成し、その属性に基づいてアクセスを許可または拒否することができます。ポリシーファイルの各行は、バージョニングプロパティ(apiVersionとkind)やsubject(ユーザーやグループ)に紐づくプロパティとリソースに紐づくプロパティとリソースに紐づかないプロパティ(/version or /apis)と読み取り専用プロパティを持つmapのspecプロパティを特定します。詳細は、[Examples](https://kubernetes.io/docs/reference/access-authn-authz/abac/#examples) をご覧ください。 プロダクション用のKubernetesクラスターの認証認可をセットアップするにあたって、いくつかの考慮事項があります。 * _認証モードの設定_: Kubernetes APIサーバー ([kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) )の起動時に、_\--authorization-mode_フラグを使用しサポートされた認証モードを設定しなければいけません。例えば、_/etc/kubernetes/manifests_配下の_kube-adminserver.yaml_ファイルで\*--authorization-mode\*フラグにNodeやRBACを設定することで、認証されたリクエストに対してノードやRBACの認証を許可することができます。 * _ユーザー証明書とロールバインディングの作成(RMAC)_: RBAC認証を使用している場合、ユーザーはクラスター証明機関により署名された証明書署名要求(CSR)を作成でき、各ユーザーにRolesとClusterRolesをバインドすることができます。詳細は[証明書署名要求](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/) をご覧ください。 * _属性を組み合わせたポリシーの作成(ABAC)_: ABAC認証を使用している場合、特定のリソース（例えばPod）、Namespace、またはAPIグループにアクセスするために、選択されたユーザーやグループに属性の組み合わせで形成されたポリシーを割り当てることができます。より多くの情報は[Examples](https://kubernetes.io/docs/reference/access-authn-authz/abac/#examples) をご覧ください。 * _アドミッションコントローラーの考慮事項_: APIサーバーを経由してくるリクエストのための追加の認証形式に[Webhookトークン認証](https://kubernetes.io/ja/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) があります。Webhookや他の特別な認証形式はAPIサーバーへアドミッションコントローラーを追加し有効化される必要があります。 ワークロードリソースの制限の設定 ---------------- プロダクションワークロードからの要求はKubernetesのコントロールプレーンの内外の両方で負荷が生じる原因になります。クラスターのワークロードの需要に合わせて設定するためには、次の項目を考慮してください。 * _Namespaceの制限の設定_: メモリやCPUなどの項目のクォートをNamespaceごとに設定します。詳細については、[メモリー、CPU、APIリソースの管理](https://kubernetes.io/ja/docs/tasks/administer-cluster/manage-resources/) をご覧ください。制限を継承するために[階層型Namespace](https://kubernetes.io/blog/2020/08/14/introducing-hierarchical-namespaces/) を設定することもできます。 * _DNS要求のための準備_: ワークロードの急激なスケールアップを予測するのであれば、DNSサービスもスケールアップする準備をする必要があります。詳細については、[クラスター内のDNSサービスのオートスケール](https://kubernetes.io/ja/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) をご覧ください。 * _追加のサービスアカウントの作成_: ユーザーアカウントはクラスターで何ができるかを決定し、サービスアカウントは特定のNamespace内でのPodへのアクセスを定義します。 デフォルトでは、Podは名前空間のデフォルトのサービスアカウントを引き受けます。新規のサービスアカウントの作成についての情報は[サービスアカウントの管理](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/) をご覧ください。例えば、以下のようなことが考えられます： * Podが特定のコンテナレジストリからイメージをプルするためのシークレットを追加する。例は[Podのためのサービスアカウントの構成](https://kubernetes.io/docs/tasks/configure-Pod-container/configure-service-account/) についてご覧ください。 * サービスアカウントへRBAC権限を割り当てる。詳細は[サービスアカウントの権限](https://kubernetes.io/ja/docs/reference/access-authn-authz/rbac/#service-account-permissions) をご覧ください。 次の項目 ---- * プロダクション環境のKubernetesを自身で構築するか、[ターンキークラウドソリューション](https://kubernetes.io/ja/docs/setup/production-environment/turnkey-solutions/) や[Kubernetesパートナー](https://kubernetes.io/ja/partners/) から取得するかを決定する * 自身で構築することを選んだ場合、[証明書](https://kubernetes.io/ja/docs/setup/best-practices/certificates/) の管理方法を計画し、[etcd](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) や[APIサーバー](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/ha-topology/) などの機能のための高可用性をセットアップする * [kubeadm](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/) 、[kops](https://kops.sigs.k8s.io/) 、[Kubespray](https://kubespray.io/) からデプロイメント方法を選択する * [認証](https://kubernetes.io/ja/docs/reference/access-authn-authz/authentication/) と [認可](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) の方法を決定し、ユーザー管理を構成する * [リソース制限](https://kubernetes.io/ja/docs/tasks/administer-cluster/manage-resources/) や[DNSオートスケーリング](https://kubernetes.io/ja/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) や[サービスアカウント](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/) のセットアップによってアプリケーションのワークロードのための準備をする フィードバック ------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最終更新 September 25, 2024 at 12:06 AM PST: [\[ja\] fix some typos in documentation (4f0adc47b3)](https://github.com/kubernetes/website/commit/4f0adc47b35eb834c1b2450091ed5ed0e669a22a) --- # Persiapan | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Getting started](https://kubernetes.io/docs/setup/) Persiapan ========= Bagian ini mencantumkan berbagai cara untuk menyiapkan dan menjalankan Kubernetes. Ketika kamu menginstal Kubernetes, pilih tipe instalasi berdasarkan: kemudahan perawatan, keamanan, sumber daya yang tersedia, dan keahlian yang dibutuhkan untuk mengoperasikan dan mengelola klaster. Kamu dapat menggelar klaster Kubernetes di mesin lokal, _cloud_, _datacenter_ di tempat, atau pilih klaster Kubernetes yang dikelola. Ada juga solusi khusus di berbagai penyedia _cloud_, atau lingkungan _baremetal_. Lingkungan Pembelajaran ----------------------- Jika kamu sedang belajar Kubernetes, gunakan alat yang didukung oleh komunitas Kubernetes, atau alat di ekosistem untuk menyiapkan klaster Kubernetes di mesin lokal. Lingkungan Produksi ------------------- Pada saat mengevaluasi sebuah solusi untuk lingkungan produksi, pertimbangkan aspek dari pengoperasian klaster Kubernetes atau abstraksi yang ingin kamu kelola atau membiarkan penyedia. [Kubernetes Partner](https://kubernetes.io/partners/#conformance) termasuk dari daftar dari penyedia [_Certified_ Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) . * * * ##### [Lingkungan Pembelajaran](https://kubernetes.io/id/docs/setup/learning-environment/) ##### [Lingkungan Produksi](https://kubernetes.io/id/docs/setup/production-environment/) ##### [Praktek-praktek Terbaik](https://kubernetes.io/id/docs/setup/best-practices/) Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified January 10, 2022 at 11:28 AM PST: [Update translate id/docs/setup/\_index.md (cd49be169e)](https://github.com/kubernetes/website/commit/cd49be169eb1889fed4a1bc6b1a2b901bae20a5a) --- # Secrets | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) Secrets ======= Feedback -------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Zuletzt geändert April 08, 2023 at 6:38 PM PST: [Add translation for "Secret and configuration management" (adf7b99e4b)](https://github.com/kubernetes/website/commit/adf7b99e4ba5bd1bd1e0685eba1c34be5eee833e) --- # Ingress | Kubernetes Ingress ======= 使用一种能感知协议配置的机制来解析 URI、主机名称、路径等 Web 概念， 让你的 HTTP（或 HTTPS）网络服务可被访问。 Ingress 概念允许你通过 Kubernetes API 定义的规则将流量映射到不同后端。 特性状态： `Kubernetes v1.19 [stable]` Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。 #### 说明： Kubernetes 项目推荐使用 [Gateway](https://gateway-api.sigs.k8s.io/) 而不是 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/) 。 Ingress API 已经被冻结。 这意味着： * Ingress API 是正式发布的，并且遵循正式发布 API 的[稳定性保证](https://kubernetes.io/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) 。 Kubernetes 项目没有计划从 Kubernetes 中移除 Ingress。 * Ingress API 不再进行开发，也不会对其进行进一步的更改或更新。 术语 -- 为了表达更加清晰，本指南定义以下术语： * 节点（Node）: Kubernetes 集群中的一台工作机器，是集群的一部分。 * 集群（Cluster）: 一组运行容器化应用程序的 Node，这些应用由 Kubernetes 管理。 在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。 * 边缘路由器（Edge Router）: 在集群中强制执行防火墙策略的路由器。 可以是由云提供商管理的网关，也可以是物理硬件。 * 集群网络（Cluster Network）: 一组逻辑的或物理的连接，基于 Kubernetes [网络模型](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/) 实现集群内的通信。 * 服务（Service）：Kubernetes [服务（Service）](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/ "将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。") ， 使用[标签](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/ "用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。") 选择算符（Selectors） 来选择一组 Pod。除非另作说明，否则假定 Service 具有只能在集群网络内路由的虚拟 IP。 Ingress 是什么？ ------------ [Ingress](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#ingress-v1-networking-k8s-io) 提供从集群外部到集群内[服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源所定义的规则来控制。 下面是 Ingress 的一个简单示例，可将所有流量都发送到同一 Service： [![ingress-diagram](https://kubernetes.io/zh-cn/docs/images/ingress.svg)](https://mermaid.live/edit#pako:eNqNkktLAzEQgP9KSC8Ku6XWBxKlJz0IHsQeuz1kN7M2uC-SrA9sb6X26MFLFZGKoCC0CIIn_Td1139halZq8eJlE2a--TI7yRn2YgaYYCc6EDRpod39DSdCyAs4RGqhMRndffRfs6dxc9Euox0NgZR2NhpmF73sqos2XVFD-ctt_vY2uTnPh8PJ4BGV7Ro3ZKOoaH5Li6Bt19r56zi7fM4fupP-oC1BHHEPGnWzGlimruno87qXvd__qjdpw2pXErOlxl7Mmn_j1VkcImb-i0q5BT5KAsoj5PMgICXGmCWViA-BlHzfL_b2MWeqRVaSE8uLg1iQUqVS2ZiTHK7LQrFcXfNg9V8WnZu3eEEqFYjCNCslJdd15zXVmcacODP9TMcqJmBN5zL9VKdt_uLM1ZoBzIVNF8WqM06ELRyCCCln-oWcTVkHqxaE4GCitwx8mgbK0Y-no9E0YVTBNuMqFpj4NJBgYZqquH4aeZgokcIPtMWpvtywoDpfU3_yww) 图. Ingress 通过配置，Ingress 可为 Service 提供外部可访问的 URL、对其流量作负载均衡、 终止 SSL/TLS，以及基于名称的虚拟托管等能力。 [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers) 负责完成 Ingress 的工作，具体实现上通常会使用某个负载均衡器， 不过也可以配置边缘路由器或其他前端来帮助处理流量。 Ingress 不会随意公开端口或协议。 将 HTTP 和 HTTPS 以外的服务开放到 Internet 时，通常使用 [Service.Type=NodePort](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#type-nodeport) 或 [Service.Type=LoadBalancer](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#loadbalancer) 类型的 Service。 环境准备 ---- 你必须拥有一个 [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。仅创建 Ingress 资源本身没有任何效果。 你可以从许多 [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers) 中进行选择。 理想情况下，所有 Ingress 控制器都应遵从参考规范。 但实际上，各个 Ingress 控制器操作略有不同。 #### 说明： 确保你查看了 Ingress 控制器的文档，以了解选择它的注意事项。 Ingress 资源 ---------- 一个最小的 Ingress 资源示例： [`service/networking/minimal-ingress.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/minimal-ingress.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/minimal-ingress.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: minimal-ingress spec: ingressClassName: nginx-example rules: - http: paths: - path: /testpath pathType: Prefix backend: service: name: test port: number: 80 Ingress 需要指定 `apiVersion`、`kind`、 `metadata`和 `spec` 字段。 Ingress 对象的命名必须是合法的 [DNS 子域名名称](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) 。 关于如何使用配置文件的一般性信息，请参见[部署应用](https://kubernetes.io/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/) 、 [配置容器](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 、 [管理资源](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/manage-deployment/) 。 Ingress 控制器经常使用[注解](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/annotations/) 来配置行为。 请查阅你选择的 Ingress 控制器的文档，以了解预期和/或支持的注解。 [Ingress 规约](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec) 提供了配置负载均衡器或者代理服务器所需要的所有信息。 最重要的是，其中包含对所有入站请求进行匹配的规则列表。 Ingress 资源仅支持用于转发 HTTP(S) 流量的规则。 如果 `ingressClassName` 被省略，那么你应该定义一个[默认的 Ingress 类](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#default-ingress-class) 。 有些 Ingress 控制器甚至可以在没有定义默认 IngressClass 的情况下工作。 即使你使用的 Ingress 控制器能够在没有任何 IngressClass 的情况下运行， Kubernetes 项目仍然建议你定义一个默认的 IngressClass。 ### Ingress 规则 每个 HTTP 规则都包含以下信息： * 可选的 `host`。在此示例中，未指定 `host`，因此该规则基于所指定 IP 地址来匹配所有入站 HTTP 流量。 如果提供了 `host`（例如 `foo.bar.com`），则 `rules` 适用于所指定的主机。 * 路径列表（例如 `/testpath`）。每个路径都有一个由 `service.name` 和 `service.port.name` 或 `service.port.number` 确定的关联后端。 主机和路径都必须与入站请求的内容相匹配，负载均衡器才会将流量引导到所引用的 Service， * `backend`（后端）是 [Service 文档](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 中所述的 Service 和端口名称的组合， 或者是通过 [CRD](https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ "通过定制化的代码给你的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。") 方式来实现的[自定义资源后端](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#resource-backend) 。 对于发往 Ingress 的 HTTP（和 HTTPS）请求，如果与规则中的主机和路径匹配， 则会被发送到所列出的后端。 通常会在 Ingress 控制器中配置 `defaultBackend`（默认后端）， 以便为无法与规约中任何路径匹配的所有请求提供服务。 ### 默认后端 没有设置规则的 Ingress 将所有流量发送到同一个默认后端，而在这种情况下 `.spec.defaultBackend` 则是负责处理请求的那个默认后端。 `defaultBackend` 通常是 [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers) 的配置选项， 而非在 Ingress 资源中设置。 如果未设置 `.spec.rules`，则必须设置 `.spec.defaultBackend`。 如果未设置 `defaultBackend`，那么如何处理与所有规则都不匹配的流量将交由 Ingress 控制器决定（请参考你的 Ingress 控制器的文档以了解它是如何处理这种情况的）。 如果 Ingress 对象中主机和路径都没有与 HTTP 请求匹配，则流量将被路由到默认后端。 ### 资源后端 `Resource` 后端是一个 ObjectRef 对象，指向同一名字空间中的另一个 Kubernetes 资源， 将其视为 Ingress 对象。 `Resource` 后端与 Service 后端是互斥的，在二者均被设置时会无法通过合法性检查。 `Resource` 后端的一种常见用法是将所有入站数据导向保存静态资产的对象存储后端。 [`service/networking/ingress-resource-backend.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/ingress-resource-backend.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/ingress-resource-backend.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-resource-backend spec: defaultBackend: resource: apiGroup: k8s.example.com kind: StorageBucket name: static-assets rules: - http: paths: - path: /icons pathType: ImplementationSpecific backend: resource: apiGroup: k8s.example.com kind: StorageBucket name: icon-assets 创建了如上的 Ingress 之后，你可以使用下面的命令查看它： kubectl describe ingress ingress-resource-backend Name: ingress-resource-backend Namespace: default Address: Default backend: APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets Rules: Host Path Backends ---- ---- -------- * /icons APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets Annotations: Events: ### 路径类型 Ingress 中的每个路径都需要有对应的路径类型（Path Type）。未明确设置 `pathType` 的路径无法通过合法性检查。当前支持的路径类型有三种： * `ImplementationSpecific`：对于这种路径类型，匹配方法取决于 IngressClass。 具体实现可以将其作为单独的 `pathType` 处理或者作与 `Prefix` 或 `Exact` 类型相同的处理。 * `Exact`：精确匹配 URL 路径，且区分大小写。 * `Prefix`：基于以 `/` 分隔的 URL 路径前缀匹配。匹配区分大小写， 并且对路径中各个元素逐个执行匹配操作。 路径元素指的是由 `/` 分隔符分隔的路径中的标签列表。 如果每个 _p_ 都是请求路径 _p_ 的元素前缀，则请求与路径 _p_ 匹配。 #### 说明： 如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会被视为匹配 （例如：`/foo/bar` 匹配 `/foo/bar/baz`, 但不匹配 `/foo/barbaz`）。 ### 示例 | 类型 | 路径 | 请求路径 | 匹配与否？ | | --- | --- | --- | --- | | Prefix | `/` | （所有路径） | 是 | | Exact | `/foo` | `/foo` | 是 | | Exact | `/foo` | `/bar` | 否 | | Exact | `/foo` | `/foo/` | 否 | | Exact | `/foo/` | `/foo` | 否 | | Prefix | `/foo` | `/foo`, `/foo/` | 是 | | Prefix | `/foo/` | `/foo`, `/foo/` | 是 | | Prefix | `/aaa/bb` | `/aaa/bbb` | 否 | | Prefix | `/aaa/bbb` | `/aaa/bbb` | 是 | | Prefix | `/aaa/bbb/` | `/aaa/bbb` | 是，忽略尾部斜线 | | Prefix | `/aaa/bbb` | `/aaa/bbb/` | 是，匹配尾部斜线 | | Prefix | `/aaa/bbb` | `/aaa/bbb/ccc` | 是，匹配子路径 | | Prefix | `/aaa/bbb` | `/aaa/bbbxyz` | 否，字符串前缀不匹配 | | Prefix | `/`, `/aaa` | `/aaa/ccc` | 是，匹配 `/aaa` 前缀 | | Prefix | `/`, `/aaa`, `/aaa/bbb` | `/aaa/bbb` | 是，匹配 `/aaa/bbb` 前缀 | | Prefix | `/`, `/aaa`, `/aaa/bbb` | `/ccc` | 是，匹配 `/` 前缀 | | Prefix | `/aaa` | `/ccc` | 否，使用默认后端 | | 混合 | `/foo` (Prefix), `/foo` (Exact) | `/foo` | 是，优选 Exact 类型 | #### 多重匹配 在某些情况下，Ingress 中会有多条路径与同一个请求匹配。这时匹配路径最长者优先。 如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型。 主机名通配符 ------ 主机名可以是精确匹配（例如 “`foo.bar.com`”）或者使用通配符来匹配 （例如 “`*.foo.com`”）。 精确匹配要求 HTTP `host` 头部字段与 `host` 字段值完全匹配。 通配符匹配则要求 HTTP `host` 头部字段与通配符规则中的后缀部分相同。 | 主机 | host 头部 | 匹配与否？ | | --- | --- | --- | | `*.foo.com` | `bar.foo.com` | 基于相同的后缀匹配 | | `*.foo.com` | `baz.bar.foo.com` | 不匹配，通配符仅覆盖了一个 DNS 标签 | | `*.foo.com` | `foo.com` | 不匹配，通配符仅覆盖了一个 DNS 标签 | [`service/networking/ingress-wildcard-host.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/ingress-wildcard-host.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/ingress-wildcard-host.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-wildcard-host spec: rules: - host: "foo.bar.com" http: paths: - pathType: Prefix path: "/bar" backend: service: name: service1 port: number: 80 - host: "*.foo.com" http: paths: - pathType: Prefix path: "/foo" backend: service: name: service2 port: number: 80 Ingress 类 --------- Ingress 可以由不同的控制器实现，通常使用不同的配置。 每个 Ingress 应当指定一个类，也就是一个对 IngressClass 资源的引用。 IngressClass 资源包含额外的配置，其中包括应当实现该类的控制器名称。 [`service/networking/external-lb.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/external-lb.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/external-lb.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: external-lb spec: controller: example.com/ingress-controller parameters: apiGroup: k8s.example.com kind: IngressParameters name: external-lb IngressClass 中的 `.spec.parameters` 字段可用于引用其他资源以提供与该 IngressClass 相关的配置。 参数（`parameters`）的具体类型取决于你在 IngressClass 的 `.spec.controller` 字段中指定的 Ingress 控制器。 ### IngressClass 的作用域 取决于你所使用的 Ingress 控制器，你可能可以使用集群作用域的参数或某个名字空间作用域的参数。 * [集群作用域](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#tabs-ingressclass-parameter-scope-0) * [命名空间作用域](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#tabs-ingressclass-parameter-scope-1) IngressClass 参数的默认作用域是集群范围。 如果你设置了 `.spec.parameters` 字段且未设置 `.spec.parameters.scope` 字段，或是将 `.spec.parameters.scope` 字段设为了 `Cluster`， 那么该 IngressClass 所引用的即是一个集群作用域的资源。 参数的 `kind`（和 `apiGroup` 一起）指向一个集群作用域的 API 类型 （可能是一个定制资源（Custom Resource）），而其 `name` 字段则进一步确定 该 API 类型的一个具体的、集群作用域的资源。 示例： --- apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: external-lb-1 spec: controller: example.com/ingress-controller parameters: # 此 IngressClass 的配置定义在一个名为 “external-config-1” 的 # ClusterIngressParameter（API 组为 k8s.example.net）资源中。 # 这项定义告诉 Kubernetes 去寻找一个集群作用域的参数资源。 scope: Cluster apiGroup: k8s.example.net kind: ClusterIngressParameter name: external-config-1 特性状态： `Kubernetes v1.23 [stable]` 如果你设置了 `.spec.parameters` 字段且将 `.spec.parameters.scope` 字段设为了 `Namespace`，那么该 IngressClass 将会引用一个名字空间作用域的资源。 `.spec.parameters.namespace` 必须和此资源所处的名字空间相同。 参数的 `kind`（和 `apiGroup` 一起）指向一个命名空间作用域的 API 类型 （例如：ConfigMap），而其 `name` 则进一步确定指定 API 类型的、 位于你指定的命名空间中的具体资源。 名字空间作用域的参数帮助集群操作者将对工作负载所需的配置数据（比如：负载均衡设置、 API 网关定义）的控制权力委派出去。如果你使用集群作用域的参数，那么你将面临以下情况之一： * 每次应用一项新的配置变更时，集群操作团队需要批准其他团队所作的修改。 * 集群操作团队必须定义具体的准入控制规则，比如 [RBAC](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/) 角色与角色绑定，以使得应用程序团队可以修改集群作用域的配置参数资源。 IngressClass API 本身是集群作用域的。 这里是一个引用名字空间作用域配置参数的 IngressClass 的示例： --- apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: external-lb-2 spec: controller: example.com/ingress-controller parameters: # 此 IngressClass 的配置定义在一个名为 “external-config” 的 # IngressParameter（API 组为 k8s.example.com）资源中， # 该资源位于 “external-configuration” 名字空间中。 scope: Namespace apiGroup: k8s.example.com kind: IngressParameter namespace: external-configuration name: external-config ### 已废弃的注解 在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前， Ingress 类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。 这个注解从未被正式定义过，但是得到了 Ingress 控制器的广泛支持。 Ingress 中新的 `ingressClassName` 字段用来替代该注解，但并非完全等价。 注解通常用于引用实现该 Ingress 的控制器的名称，而这个新的字段则是对一个包含额外 Ingress 配置的 IngressClass 资源的引用，其中包括了 Ingress 控制器的名称。 ### 默认 Ingress 类 你可以将一个特定的 IngressClass 标记为集群默认 Ingress 类。 将某个 IngressClass 资源的 `ingressclass.kubernetes.io/is-default-class` 注解设置为 `true` 将确保新的未指定 `ingressClassName` 字段的 Ingress 能够被赋予这一默认 IngressClass. #### 注意： 如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 `ingressClassName` 的 Ingress 对象。 解决这个问题需要确保集群中最多只能有一个 IngressClass 被标记为默认。 首先定义一个默认的 IngressClass。建议指定默认的 IngressClass： [`service/networking/default-ingressclass.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/default-ingressclass.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/default-ingressclass.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: labels: app.kubernetes.io/component: controller name: nginx-example annotations: ingressclass.kubernetes.io/is-default-class: "true" spec: controller: k8s.io/ingress-nginx Ingress 类型 ---------- ### 由单个 Service 来支持的 Ingress 现有的 Kubernetes 概念允许你暴露单个 Service（参见[替代方案](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#alternatives) ）。 你也可以使用 Ingress 并设置无规则的**默认后端**来完成这类操作。 [`service/networking/test-ingress.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/test-ingress.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/test-ingress.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: test-ingress spec: defaultBackend: service: name: test port: number: 80 如果使用 `kubectl apply -f` 创建此 Ingress，则应该能够查看刚刚添加的 Ingress 的状态： kubectl get ingress test-ingress NAME CLASS HOSTS ADDRESS PORTS AGE test-ingress external-lb * 203.0.113.123 80 59s 其中 `203.0.113.123` 是由 Ingress 控制器分配的 IP，用以服务于此 Ingress。 #### 说明： Ingress 控制器和负载平衡器的 IP 地址分配操作可能需要一两分钟。 在此之前，你通常会看到地址字段的取值为 ``。 ### 简单扇出 一个扇出（Fanout）配置根据请求的 HTTP URI 将来自同一 IP 地址的流量路由到多个 Service。 Ingress 允许你将负载均衡器的数量降至最低。例如，这样的设置： [![ingress-fanout-diagram](https://kubernetes.io/zh-cn/docs/images/ingressFanOut.svg)](https://mermaid.live/edit#pako:eNqNUk1v0zAY_iuWewEpyRKnjM5FPY0DEgfEjk0PTvxmtZbGke3woW03NDjuChNCRRyQkMYFidP4NyXlX5DMjroykLg4j_x8vM6j9xhnkgOm-FCxao4ePx0nJUJZIaA0d6ary48_33xvvnyd3fUD9Kg8VKC131wum_Oz5t0r9CBVE7T-9mF9dbV6_3q9XK7efkaBPxFWOXUOD0X3R8FeFEQkDqKYzK6HOJHvT052cilPNKhnIoNoemAB6i_okIThbU_KVO8hf3oIHYUj59F1an_u18VZ8-PTjRhLuyltZiV5NH0i-ewvBLlFEEvE_yKGGwJKbmtlWu9DjqqCiRLloijogHPuaaPkEdBBnucO-88FN3M6rF54mSykooMwDMdbIUcj7SJispvBvf9KabntlKyotQHlkjZWOkjTdDuGbGLsxE1S36jXl9YD4nWldsc1irtj2D39htdumy1l69q-zH3H2MMLUAsmeLuux50uwWYOC0gwbSGHnNWFSXBSnrbSuuLMwEMujFSY5qzQ4GFWG3nwsswwNaqGXrQvWLsgC6c6_Q0zxBrK) 图. Ingress 扇出 这将需要一个如下所示的 Ingress： [`service/networking/simple-fanout-example.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/simple-fanout-example.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/simple-fanout-example.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: simple-fanout-example spec: rules: - host: foo.bar.com http: paths: - path: /foo pathType: Prefix backend: service: name: service1 port: number: 4200 - path: /bar pathType: Prefix backend: service: name: service2 port: number: 8080 当你使用 `kubectl apply -f` 创建 Ingress 时： kubectl describe ingress simple-fanout-example Name: simple-fanout-example Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo service1:4200 (10.8.0.90:4200) /bar service2:8080 (10.8.0.91:8080) Annotations: nginx.ingress.kubernetes.io/rewrite-target: / Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 22s loadbalancer-controller default/test 此 Ingress 控制器构造一个特定于实现的负载均衡器来供 Ingress 使用， 前提是 Service （`service1`、`service2`）存在。 当它完成负载均衡器的创建时，你会在 Address 字段看到负载均衡器的地址。 #### 说明： 取决于你所使用的 [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers/) ， 你可能需要创建默认 HTTP 后端[服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 。 ### 基于名称的虚拟主机服务 基于名称的虚拟主机支持将针对多个主机名的 HTTP 流量路由到同一 IP 地址上。 [![ingress-namebase-diagram](https://kubernetes.io/zh-cn/docs/images/ingressNameBased.svg)](https://mermaid.live/edit#pako:eNqNkk9v0zAYxr-K5V6GlESNU6B4qKdxQOKA2LHpwYnfrNaSOLId_mjbDQ2OXAdMUxEHJKRxQWLaND4NXcq3IJkT2gKTuDiv_Dzv73UevXs4lhwwxTuKFVP06MlmmCMUpwJyszGen364ev2t-vxlcsv10MN8R4HWbnU6q94cVm9fovuRGqHF15PF5eX8-NViNpsffUKeOxLWOW47HOTfHXr3fM8ngecHZHI9pDW57mj_x9nF1ftzihIpvYgpL5bZvgb1VMTgj7dtgboLOuzfCGiaG8gKgPwJIL8Buozsb_98d1h9_7jCtHI7sB5QSO6PH0s--YdA_hKIFYKbhMFSgJzbwJnWW5CgImUiR4lIU9rjnDvaKLkLtJckSVu7zwQ3UzoonjuxTKWivX6_v7kG2R3qFhGQOzHc_i9Kra1T4rTUBlRLWrbSXhRF6xiyxNiJS1KXqNOF1hXEaUJtjusqaI5B8_SVXruHNpS1a_uy9lsr2MEZqIwJXq_yXuMMsZlCBiGmdckhYWVqQhzmB7W1LDgz8IALIxWmCUs1OJiVRm6_yGNMjSqhM20JVq9I1roOfgEKNyn5) 图. 基于名称实现虚拟托管的 Ingress 以下 Ingress 让后台负载均衡器基于 [Host 头部字段](https://tools.ietf.org/html/rfc7230#section-5.4) 来路由请求。 [`service/networking/name-virtual-host-ingress.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/name-virtual-host-ingress.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/name-virtual-host-ingress.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: name-virtual-host-ingress spec: rules: - host: foo.bar.com http: paths: - pathType: Prefix path: "/" backend: service: name: service1 port: number: 80 - host: bar.foo.com http: paths: - pathType: Prefix path: "/" backend: service: name: service2 port: number: 80 如果你所创建的 Ingress 资源没有在 `rules` 中定义主机，则规则可以匹配指向 Ingress 控制器 IP 地址的所有网络流量，而无需基于名称的虚拟主机。 例如，下面的 Ingress 对象会将请求 `first.bar.com` 的流量路由到 `service1`，将请求 `second.bar.com` 的流量路由到 `service2`，而将所有其他流量路由到 `service3`。 [`service/networking/name-virtual-host-ingress-no-third-host.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/name-virtual-host-ingress-no-third-host.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: name-virtual-host-ingress-no-third-host spec: rules: - host: first.bar.com http: paths: - pathType: Prefix path: "/" backend: service: name: service1 port: number: 80 - host: second.bar.com http: paths: - pathType: Prefix path: "/" backend: service: name: service2 port: number: 80 - http: paths: - pathType: Prefix path: "/" backend: service: name: service3 port: number: 80 ### TLS 你可以通过设定包含 TLS 私钥和证书的[Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/ "Secret 用于存储敏感信息，如密码、 OAuth 令牌和 SSH 密钥。") 来保护 Ingress。 Ingress 资源只支持一个 TLS 端口 443，并假定 TLS 连接终止于 Ingress 节点 （与 Service 及其 Pod 间的流量都以明文传输）。 如果 Ingress 中的 TLS 配置部分指定了不同主机，那么它们将通过 SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。 TLS Secret 的数据中必须包含键名为 `tls.crt` 的证书和键名为 `tls.key` 的私钥， 才能用于 TLS 目的。例如： apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: default data: tls.crt: base64 编码的证书 tls.key: base64 编码的私钥 type: kubernetes.io/tls 在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道。 你要确保所创建的 TLS Secret 创建自包含 `https-example.foo.com` 的公共名称 （Common Name，CN）的证书。这里的公共名称也被称为全限定域名（Fully Qualified Domain Name，FQDN）。 #### 说明： 注意，不能针对默认规则使用 TLS，因为这样做需要为所有可能的子域名签发证书。 因此，`tls` 字段中的 `hosts` 的取值需要与 `rules` 字段中的 `host` 完全匹配。 [`service/networking/tls-example-ingress.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/service/networking/tls-example-ingress.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 service/networking/tls-example-ingress.yaml 到剪贴板") apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: tls-example-ingress spec: tls: - hosts: - https-example.foo.com secretName: testsecret-tls rules: - host: https-example.foo.com http: paths: - path: / pathType: Prefix backend: service: name: service1 port: number: 80 #### 说明： 各种 Ingress 控制器在所支持的 TLS 特性上参差不齐。 你应参考所选的 Ingress 控制器的文档，以了解 TLS 在你的环境中是如何工作的。 ### 负载均衡 Ingress 控制器启动引导时使用一些适用于所有 Ingress 的负载均衡策略设置， 例如负载均衡算法、后端权重方案等。 更高级的负载均衡概念（例如持久会话、动态权重）尚未通过 Ingress 公开。 你可以通过用于 Service 的负载均衡器来获取这些功能。 值得注意的是，尽管健康检查不是通过 Ingress 直接暴露的，在 Kubernetes 中存在[就绪态探针](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) 这类等价的概念，供你实现相同的目的。 请查阅特定控制器的说明文档。 更新 Ingress ---------- 要更新现有的 Ingress 以添加新的 Host，可以通过编辑资源来更新它： kubectl describe ingress test Name: test Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo service1:80 (10.8.0.90:80) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 35s loadbalancer-controller default/test kubectl edit ingress test 这一命令将打开编辑器，允许你以 YAML 格式编辑现有配置。 修改它来增加新的主机： spec: rules: - host: foo.bar.com http: paths: - backend: service: name: service1 port: number: 80 path: /foo pathType: Prefix - host: bar.baz.com http: paths: - backend: service: name: service2 port: number: 80 path: /foo pathType: Prefix .. 保存更改后，kubectl 将更新 API 服务器上的资源，该资源将告诉 Ingress 控制器重新配置负载均衡器。 验证： kubectl describe ingress test Name: test Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo service1:80 (10.8.0.90:80) bar.baz.com /foo service2:80 (10.8.0.91:80) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 45s loadbalancer-controller default/test 你也可以针对修改后的 Ingress YAML 文件，通过 `kubectl replace -f` 命令获得同样结果。 跨可用区的失效 ------- 不同的云厂商使用不同的技术来实现跨故障域的流量分布。 请查看相关 [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers) 的文档以了解详细信息。 替代方案 ---- 不直接使用 Ingress 资源，也有多种方法暴露 Service： * 使用 [Service.Type=LoadBalancer](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#loadbalancer) * 使用 [Service.Type=NodePort](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#type-nodeport) 接下来 --- * 进一步了解 [Ingress](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-v1/) API * 进一步了解 [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers/) 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 November 27, 2025 at 9:48 AM PST: [\[zh-cn\]sync ingress (7ea767180f)](https://github.com/kubernetes/website/commit/7ea767180fc2a27e2cde6d07e1ee6e79606bb8a3) --- # Versi Dokumentasi yang Tersedia | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Available Documentation Versions](https://kubernetes.io/docs/home/supported-doc-versions/) Versi Dokumentasi yang Tersedia =============================== Situs web ini berisi dokumentasi untuk versi terkini Kubernetes dan empat versi sebelumnya. Versi terbaru ------------- * [v1.35](https://kubernetes.io/id/docs/home/supported-doc-versions/) (dokumentasi ini) Versi lama ---------- * [v1.34](https://v1-34.docs.kubernetes.io/id/docs/home/supported-doc-versions/) * [v1.33](https://v1-33.docs.kubernetes.io/id/docs/home/supported-doc-versions/) * [v1.32](https://v1-32.docs.kubernetes.io/id/docs/home/supported-doc-versions/) * [v1.31](https://v1-31.docs.kubernetes.io/id/docs/home/supported-doc-versions/) --- # 도커심 제거 및 CRI 호환 런타임 사용에 대한 기사 | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Articles on dockershim Removal and on Using CRI-compatible Runtimes](https://kubernetes.io/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) 도커심 제거 및 CRI 호환 런타임 사용에 대한 기사 ============================= 이 문서는 쿠버네티스의 _도커심_ 사용 중단(deprecation) 및 제거, 또는 해당 제거를 고려한 CRI 호환 컨테이너 런타임 사용에 관한 기사 및 기타 페이지 목록을 제공한다. 쿠버네티스 프로젝트 ---------- * 쿠버네티스 블로그: [도커심 제거 FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/) (originally published 2020/12/02) * 쿠버네티스 블로그: [업데이트: 도커심 제거 FAQ](https://kubernetes.io/blog/2022/02/17/dockershim-faq/) (updated published 2022/02/17) * 쿠버네티스 블로그: [도커심에서 움직이는 쿠버네티스: 약속과 다음 단계](https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/) (published 2022/01/07) * 쿠버네티스 블로그: [도커심 제거가 다가오고 있다. 준비됐는가?](https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/) (published 2021/11/12) * 쿠버네티스 문서: [도커심에서 마이그레이션하기](https://kubernetes.io/ko/docs/tasks/administer-cluster/migrating-from-dockershim/) * 쿠버네티스 문서: [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/) * 쿠버네티스 개선 제안 이슈: [KEP-2221: kubelet에서 도커심 제거하기](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2221-remove-dockershim/README.md) * 쿠버네티스 개선 제안 이슈: [kubelet에서 도커심 제거하기](https://github.com/kubernetes/enhancements/issues/2221) (_k/enhancements#2221_) GitHub 이슈를 통해 피드백을 제공할 수 있다. [**도커심 제거 피드백 및 이슈**](https://github.com/kubernetes/kubernetes/issues/106917) . (_k/kubernetes/#106917_) 외부 소스 ----- * 아마존 웹 서비스 EKS 문서: [아마존 EKS 도커심 지원 종료](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html) * CNCF 컨퍼런스 영상: [도커에서 containerd 런타임으로 마이그레이션하며 얻은 교훈](https://www.youtube.com/watch?v=uDOu6rK4yOk) (Ana Caylin, at KubeCon Europe 2019) * 도커닷컴 블로그: [개발자가 도커, 도커 엔진 및 쿠버네티스 v1.20에 관해 알아야 할 사항](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/) (published 2020/12/04) * "_구글 오픈소스_" 유튜브 채널: [구글과 함께 쿠버네티스 배우기 - 도커심에서 containerd로 마이그레이션하기](https://youtu.be/fl7_4hjT52g) * Azure의 Microsoft 앱 블로그: [도커심 지원 중단 및 AKS](https://techcommunity.microsoft.com/t5/apps-on-azure-blog/dockershim-deprecation-and-aks/ba-p/3055902) (published 2022/01/21) * Mirantis 블로그: [도커심의 미래는 cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/) (published 2021/04/21) * Mirantis: [Mirantis/cri-dockerd](https://github.com/Mirantis/cri-dockerd) Git 리포지터리 (깃허브) * Tripwire: [곧 다가올 도커심의 지원 중단이 당신의 쿠버네티스에 미칠 영향](https://www.tripwire.com/state-of-security/security-data-protection/cloud/how-dockershim-forthcoming-deprecation-affects-your-kubernetes/) (published 2021/07/01) 피드백 --- 이 페이지가 도움이 되었나요? 네 아니요 피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 원한다면 GitHub 리포지터리에 이슈를 열어서 [문제 리포트](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 또는 [개선 제안이 가능합니다.](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 최종 수정 March 14, 2023 at 10:29 AM PST: [\[ko\] Update outdated files in \`dev-1.26-ko.1\` (M8-M9,M127-M133) (20b88e92c0)](https://github.com/kubernetes/website/commit/20b88e92c0d4f1e010aec481027a99fd0935b577) --- # 存活、就绪和启动探针 | Kubernetes 存活、就绪和启动探针 ========== Kubernetes 提供了多种探针： * [存活探针](https://kubernetes.io/zh-cn/docs/concepts/configuration/liveness-readiness-startup-probes/#liveness-probe) * [就绪探针](https://kubernetes.io/zh-cn/docs/concepts/configuration/liveness-readiness-startup-probes/#readiness-probe) * [启动探针](https://kubernetes.io/zh-cn/docs/concepts/configuration/liveness-readiness-startup-probes/#startup-probe) 存活探针 ---- 存活探针决定何时重启容器。 例如，当应用在运行但无法取得进展时，存活探针可以捕获这类死锁。 如果一个容器的存活探针失败多次，kubelet 将重启该容器。 存活探针不会等待就绪探针成功。 如果你想在执行存活探针前等待，你可以定义 `initialDelaySeconds`，或者使用[启动探针](https://kubernetes.io/zh-cn/docs/concepts/configuration/liveness-readiness-startup-probes/#startup-probe) 。 就绪探针 ---- 就绪探针决定容器何时准备好接受流量。 这种探针在等待应用执行耗时的初始任务时非常有用； 例如：建立网络连接、加载文件和预热缓存。在容器的生命周期后期， 就绪探针也很有用，例如，从临时故障或过载中恢复时。 如果就绪探针返回的状态为失败，Kubernetes 会将该 Pod 从所有对应服务的端点中移除。 就绪探针在容器的整个生命期内持续运行。 启动探针 ---- 启动探针检查容器内的应用是否已启动。 启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被 kubelet 杀掉。 如果配置了这类探针，它会禁用存活检测和就绪检测，直到启动探针成功为止。 这类探针仅在启动时执行，不像存活探针和就绪探针那样周期性地运行。 * 更多细节参阅[配置存活、就绪和启动探针](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes) 。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 August 02, 2025 at 12:09 PM PST: [\[zh-cn\]sync liveness-readiness-startup-probes.md (9e15d650a4)](https://github.com/kubernetes/website/commit/9e15d650a4ff77871d03716f78c0ab93ec005ef9) --- # KubeletチェックポイントAPI | Kubernetes **このページに記載されている情報は古い可能性があります** このページの更新日は英語版よりも古いため、記載されている情報が古い可能性があります。最新の情報をご覧になりたい方は英語版のページをご覧ください: [Kubelet Checkpoint API](https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/) KubeletチェックポイントAPI ================== FEATURE STATE: `Kubernetes v1.25 [alpha]` コンテナのチェックポイントは実行中のコンテナのステートフルコピーを作成するための機能です。 コンテナのステートフルコピーがあると、デバックや類似の目的のために別のコンピューターに移動させることができます。 チェックポイントコンテナデータを復元可能なコンピューターに移動させる場合、その復元したコンテナは、チェックポイントが作成された正確に同じ地点で実行が再開されます。 保存したデータを検査することも可能です。 ただし、検査を行うための適したツールを保持している必要があります。 コンテナのチェックポイントを作成することで、セキュリティ影響が発生する場合があります。 通常、チェックポイントはチェックポイントされたコンテナ内のすべてのプロセスのすべてのメモリーページを含んでいます。 メモリー内で使用された全てがローカルディスク上で利用できるようになることを意味しています。 これはすべてのプライベートデータを含んでおり、もしかしたら暗号化に使用した鍵も含まれているかもしれません。 基礎となるCRI実装(そのノード上のコンテナランタイム)は、`root`ユーザーのみがアクセス可能なチェックポイントアーカイブを作成するべきです。 チェックポイントアーカイブが他のシステムに転送された場合、全てのメモリーページがチェックポイントアーカイブのオーナーによって読み取れるようになることを覚えておくことが重要です。 操作方法 ---- ### `post` 指定したコンテナのチェックポイント 指定したPodから指定したコンテナのチェックポイントを作成するようにkubeletに指示します。 kubeletチェックポイントインターフェースへのアクセスの制御方法についての詳細な情報は、[Kubelet authentication/authorization reference](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz) を参照してください。 kubeletは基礎となる[CRI](https://kubernetes.io/ja/docs/concepts/architecture/cri "kubeletとローカルコンテナランタイム間の通信のためのプロトコルです。") 実装にチェックポイントをリクエストします。 チェックポイントリクエストでは、kubeletが`checkpoint---.tar`のようなチェックポイントアーカイブの名前を指定します。 併せて、(`--root-dir`で定義される)rootディレクトリ配下の`checkpoints`ディレクトリに、チェックポイントアーカイブを保存することをリクエストします。 デフォルトは`/var/lib/kubelet/checkpoints`です。 チェックポイントアーカイブは _tar_ フォーマットであり、[`tar`](https://pubs.opengroup.org/onlinepubs/7908799/xcu/tar.html) の実装を使用して一覧表示できます。 アーカイブの内容は、基礎となるCRI実装(ノード上のコンテナランタイム)に依存します。 #### HTTPリクエスト POST /checkpoint/{namespace}/{pod}/{container} #### パラメーター * **namespace** (_パス内_): string, 必須項目 [Namespace](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/namespaces "同一の物理クラスター上で複数の仮想クラスターをサポートするために使われる抽象概念です。") * **pod** (_パス内_): string, 必須項目 [Pod](https://kubernetes.io/ja/docs/concepts/workloads/pods/ "一番小さく一番シンプルな Kubernetes のオブジェクト。Pod とはクラスターで動作しているいくつかのコンテナのまとまりです。") * **container** (_パス内_): string, 必須項目 [コンテナ](https://kubernetes.io/ja/docs/concepts/containers/ "ソフトウェアとそのすべての依存関係を含む、軽量でポータブルな実行可能イメージです。") * **timeout** (_クエリ内_): integer チェックポイントの作成が終了するまで待機する秒単位のタイムアウト。 ゼロまたはタイムアウトが指定されていない場合、デフォルトは[CRI](https://kubernetes.io/ja/docs/concepts/architecture/cri "kubeletとローカルコンテナランタイム間の通信のためのプロトコルです。") タイムアウトの値が使用されます。 チェックポイント作成時間はコンテナの使用メモリーに直接依存します。 コンテナの使用メモリーが多いほど、対応するチェックポイントを作成するために必要な時間が長くなります。 #### レスポンス 200: OK 401: Unauthorized 404: Not Found (`ContainerCheckpoint`フィーチャーゲートが無効の場合) 404: Not Found (指定した`namespace`や`pod`、`container`が見つからない場合) 500: Internal Server Error (CRI実装でチェックポイント中にエラーが発生した場合(詳細はエラーメッセージを参照)) 500: Internal Server Error (CRI実装がチェックポイントCRI APIを実装していない場合(詳細はエラーメッセージを参照)) フィードバック ------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最終更新 February 06, 2024 at 3:15 PM PST: [Term "interface" variations fix (f5564b66e9)](https://github.com/kubernetes/website/commit/f5564b66e98a9d458e9a24c17ea1aa44a0ea98f8) --- # Best practices | Kubernetes Best practices ============== * * * ##### [Überlegungen für große Cluster](https://kubernetes.io/de/docs/setup/best-practices/cluster-large/) ##### [PKI Zertifikate and Anforderungen](https://kubernetes.io/de/docs/setup/best-practices/zertifikate/) Feedback -------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Zuletzt geändert August 12, 2025 at 11:03 AM PST: [first shot localizing best-practices certificates (dd97a5ba27)](https://github.com/kubernetes/website/commit/dd97a5ba2773e57b9e405fcfcb24de6df0342086) --- # Service 所用的协议 | Kubernetes Service 所用的协议 ============= 如果你配置 [Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/ "将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。") ， 你可以从 Kubernetes 支持的任何网络协议中选择一个协议。 Kubernetes 支持以下协议用于 Service： * [`SCTP`](https://kubernetes.io/zh-cn/docs/reference/networking/service-protocols/#protocol-sctp) * [`TCP`](https://kubernetes.io/zh-cn/docs/reference/networking/service-protocols/#protocol-tcp) **（默认值）** * [`UDP`](https://kubernetes.io/zh-cn/docs/reference/networking/service-protocols/#protocol-udp) 当你定义 Service 时， 你还可以指定其使用的[应用协议](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#application-protocol) 。 本文详细说明了一些特殊场景，这些场景通常均使用 TCP 作为传输协议： * [HTTP](https://kubernetes.io/zh-cn/docs/reference/networking/service-protocols/#protocol-http-special) 和 [HTTPS](https://kubernetes.io/zh-cn/docs/reference/networking/service-protocols/#protocol-http-special) * [PROXY 协议](https://kubernetes.io/zh-cn/docs/reference/networking/service-protocols/#protocol-proxy-special) * [TLS](https://kubernetes.io/zh-cn/docs/reference/networking/service-protocols/#protocol-tls-special) 终止于负载均衡器处 支持的协议 ----- Service 端口的 `protocol` 有 3 个有效值： ### `SCTP` 特性状态： `Kubernetes v1.20 [stable]` 当使用支持 SCTP 流量的网络插件时，你可以为大多数 Service 使用 SCTP。 对于 `type: LoadBalancer` Service，对 SCTP 的支持情况取决于提供此项设施的云供应商（大部分不支持）。 运行 Windows 的节点不支持 SCTP。 #### 支持多宿主 SCTP 关联 对多宿主 SCTP 关联的支持要求 CNI 插件可以支持为 Pod 分配多个接口和 IP 地址。 针对多宿主 SCTP 关联的 NAT 需要在对应的内核模块具有特殊的逻辑。 ### `TCP` 你可以将 TCP 用于任何类别的 Service，这是默认的网络协议。 ### `UDP` 你可以将 UDP 用于大多数 Service。对于 `type: LoadBalancer` Service， UDP 的支持与否取决于提供此项设施的云供应商。 特殊场景 ---- ### HTTP 如果你的云供应商支持负载均衡，而且尤其是该云供应商的负载均衡器实现了 HTTP/HTTPS 反向代理， 可将流量转发到该 Service 的后端端点，那么你就可以使用 LoadBalancer 模式的 Service 以便在 Kubernetes 集群外部配置负载均衡器。 通常，你将 Service 协议设置为 `TCP`， 并添加一个[注解](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/annotations/ "注解是以键值对的形式给资源对象附加随机的无法标识的元数据。") （一般取决于你的云供应商）配置负载均衡器，以便在 HTTP 级别处理流量。 此配置也可能包括为你的工作负载提供 HTTPS（基于 TLS 的 HTTP）并反向代理纯 HTTP。 #### 说明： 你也可以使用 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/ "Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。") 来暴露 HTTP/HTTPS Service。 你可能还想指定连接的[应用协议](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#application-protocol) 是 `http` 还是 `https`。如果从负载均衡器到工作负载的会话是不带 TLS 的 HTTP，请使用 `http`； 如果从负载均衡器到工作负载的会话使用 TLS 加密，请使用 `https`。 ### PROXY 协议 如果你的云供应商支持此协议，你可以使用设置为 `type: LoadBalancer` 的 Service， 在 Kubernetes 本身的外部配置负载均衡器，以转发用 [PROXY 协议](https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt) 封装的连接。 负载均衡器然后发送一个初始的八位元组系列来描述传入的连接，这类似于以下示例（PROXY 协议 v1）： PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n 代理协议前导码之后的数据是来自客户端的原始数据。 当任何一侧关闭连接时，负载均衡器也会触发连接关闭并在可行的情况下发送所有残留数据。 通常，你会将 Service 协议定义为 `TCP`。 你还会设置一个特定于云供应商的注解，将负载均衡器配置为以 PROXY 协议封装所有传入的连接。 ### TLS 如果你的云供应商支持 TLS，你可以使用设置为 `type: LoadBalancer` 的 Service 作为设置外部反向代理的一种方式，其中从客户端到负载均衡器的连接是 TLS 加密的且该负载均衡器是 TLS 对等服务器。从负载均衡器到工作负载的连接可以是 TLS，或可能是纯文本。 你可以使用的确切选项取决于你的云供应商或自定义 Service 实现。 通常，你会将协议设置为 `TCP` 并设置一个注解（通常特定于你的云供应商）， 将负载均衡器配置为充当一个 TLS 服务器。你将使用特定于云供应商的机制来配置 TLS 身份 （作为服务器，也可能作为连接到工作负载的客户端）。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 March 20, 2023 at 4:43 PM PST: [\[zh-cn\] Reference files to sync task-6 (cd39843b37)](https://github.com/kubernetes/website/commit/cd39843b3726bc95b28130e88021683e4c84981a) --- # IPv4/IPv6 dual-stack | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [IPv4/IPv6 dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) IPv4/IPv6 dual-stack ==================== Kubernetes erlaubt Netzwerkkonfigurationen mit IPv4 oder IPv6 (Single Stack). Im Dual-Stack-Betrieb kann IPv4 im Verbund mit IPv6 verwendet werden. Feedback -------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Zuletzt geändert April 08, 2023 at 6:48 PM PST: [Add translation for "IPv4/IPv6 dual stack" (6d82d6c4fa)](https://github.com/kubernetes/website/commit/6d82d6c4fa90047f268d4d800b9d130bf4113f21) --- # Problèmes et alertes de sécurité de Kubernetes | Kubernetes **Les informations contenues dans ce document peuvent être obsolètes** Ce document a une date de mise à jour antérieure à celle de l'original, les informations qu'il contient peuvent donc être obsolètes. Si vous comprenez l'anglais, consultez la version anglaise pour obtenir les informations les plus récentes : [Kubernetes Issues and Security](https://kubernetes.io/docs/reference/issues-security/) Problèmes et alertes de sécurité de Kubernetes ============================================== Feedback -------- Cette page est elle utile ? Oui Non Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the [GitHub Repository](https://www.github.com/kubernetes/website/) if you want to [report a problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [suggest an improvement](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Dernière modification June 11, 2019 at 7:06 PM PST: [Add all the \_index files for the French translation (#14744) (d028d87b8e)](https://github.com/kubernetes/website/commit/d028d87b8e86829d16d7cb34c8d652cd8de1c28c) --- # Kontainer Environment | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Container Environment](https://kubernetes.io/docs/concepts/containers/container-environment/) Kontainer Environment ===================== Laman ini menjelaskan berbagai _resource_ yang tersedia di dalam Kontainer pada suatu _environment_. _Environment_ Kontainer ----------------------- _Environment_ Kontainer pada Kubernetes menyediakan beberapa _resource_ penting yang tersedia di dalam Kontainer: * Sebuah _Filesystem_, yang merupakan kombinasi antara [image](https://kubernetes.io/id/docs/concepts/containers/images/) dan satu atau banyak [_volumes_](https://kubernetes.io/id/docs/concepts/storage/volumes/) . * Informasi tentang Kontainer tersebut. * Informasi tentang objek-objek lain di dalam klaster. ### Informasi tentang Kontainer _Hostname_ sebuah Kontainer merupakan nama dari Pod dimana Kontainer dijalankan. Informasi ini tersedia melalui perintah `hostname` atau panggilan (_function call_) [`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) pada `libc`. Nama Pod dan _namespace_ tersedia sebagai variabel _environment_ melalui [API _downward_](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) . Variabel _environment_ yang ditulis pengguna dalam Pod _definition_ juga tersedia di dalam Kontainer, seperti halnya variabel _environment_ yang ditentukan secara statis di dalam _image_ Docker. ### Informasi tentang Klaster Daftar semua _Service_ yang dijalankan ketika suatu Kontainer dibuat, tersedia di dalam Kontainer tersebut sebagai variabel _environment_. Variabel-variabel _environment_ tersebut sesuai dengan sintaksis _links_ dari Docker. Untuk suatu _Service_ bernama _foo_ yang terkait dengan Kontainer bernama _bar_, variabel-variabel di bawah ini tersedia: FOO_SERVICE_HOST= FOO_SERVICE_PORT= Semua _Service_ memiliki alamat-alamat IP yang bisa didapatkan di dalam Kontainer melalui DNS, jika [_addon_ DNS](http://releases.k8s.io/main/cluster/addons/dns/) diaktifkan.  Selanjutnya ----------- * Pelajari lebih lanjut tentang [berbagai _hook_ pada _lifecycle_ Kontainer](https://kubernetes.io/id/docs/concepts/containers/container-lifecycle-hooks/) . * Dapatkan pengalaman praktis soal [memberikan _handler_ untuk _event_ dari _lifecycle_ Kontainer](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified July 10, 2020 at 10:24 PM PST: [Replace EN links to ID links (0c799ef757)](https://github.com/kubernetes/website/commit/0c799ef757368c8839a912df5d949fa2603042f5) --- # DNS untuk Service dan Pod | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) DNS untuk Service dan Pod ========================= Laman ini menyediakan ikhtisar dari dukungan DNS oleh Kubernetes. Pendahuluan ----------- Kubernetes DNS melakukan _scheduling_ DNS Pod dan Service yang ada pada klaster, serta melakukan konfigurasi kubelet untuk memberikan informasi bagi setiap Container untuk menggunakan DNS Service IP untuk melakukan resolusi DNS. ### Apa Sajakah yang Mendapatkan Nama DNS? Setiap Service yang didefinisikan di dalam klaster (termasuk server DNS itu sendiri) memiliki nama DNS. Secara default, sebuah _list_ pencarian DNS pada Pod klien akan mencantumkan _namespace_ Pod itu sendiri serta domain _default_ klaster. Hal ini dapat diilustrasikan dengan contoh berikut: Asumsikan sebuah Service dengan nama `foo` pada Kubernetes dengan _namespace_ `bar`. Sebuah Pod yang dijalankan di _namespace_ `bar` dapat melakukan resolusi terhadap Service ini dengan melakukan _query_ DNS untuk `foo`. Sebuah Pod yang dijalankan pada namespace `quux` dapat melakukan resolusi Service ini dengan melakukan _query_ DNS untuk `foo.bar`. Bagian di bawah ini akan menampilkan detail tipe rekaman serta _layout_ yang didukung. _Layout_ atau nama _query_ lain yang dapat digunakan dianggap sebagai detail implementasi yang bisa saja berubah tanpa adanya pemberitahuan sebelumnya. Untuk informasi spesifikasi terbaru kamu dapat membaca [Service Discovery pada Kubernetes berbasis DNS](https://github.com/kubernetes/dns/blob/master/docs/specification.md) . Service ------- ### A record Service "Normal" (bukan _headless_) akan diberikan sebuah A _record_ untuk sebuah nama dalam bentuk `my-svc.my-namespace.svc.cluster-domain.example`. Inilah yang kemudian digunakan untuk melakukan resolusi IP klaster dari Service tersebut. Service "Headless" (tanpa IP klaster) juga memiliki sebuah A _record_ DNS dengan format `my-svc.my-namespace.svc.cluster-domain.example`. Tidak seperti halnya Service normal, DNS ini akan melakukan resolusi pada serangkauan IP dari Pod yang dipilih oleh Service tadi. Klien diharapkan untuk mengkonsumsi serangkaian IP ini atau cara lain yang digunakan adalah pemilihan menggunakan penjadwalan Round-Robin dari set yang ada. ### SRV _record_ SRV _record_ dibuat untuk port bernama yang merupakan bagian dari Service normal maupun [Headless Services](https://kubernetes.io/id/docs/concepts/services-networking/service/#headless-services) . Untuk setiap port bernama, SRV _record_ akan memiliki format `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. Untuk sebuah Service normal, ini akan melakukan resolusi pada nomor port dan nama domain: `my-svc.my-namespace.svc.cluster-domain.example`. Untuk Service headless, ini akan melakukan resolusi pada serangkaian Pod yang merupakan _backend_ dari Service tersebut yang memiliki format: `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`. Pod --- ### Hostname Pod dan _Field_ Subdomain Saat ini ketika sebuah Pod dibuat, _hostname_\-nya adalah nilai dari `metadata.name`. Spek Pod memiliki _field_ opsional `hostname`, yang dapat digunakan untuk menspesifikasikan _hostname_ Pod. Ketika dispesifikasikan, maka nama ini akan didahulukan di atas nama Pod . Misalnya, sebuah Pod dengan `hostname` yang diberikan nilai "`my-host`", maka _hostname_ Pod tersebut akan menjadi "`my-host`". Spek Pod juga memiliki _field_ opsional `subdomain` yang dapat digunakan untuk menspesifikasikan subdomain Pod tersebut. Misalnya saja sebuah Pod dengan `hostname` yang diberi nilai "`foo`", dan `subdomain` yang diberi nilai "`bar`", pada _namespace_ "`my-namespace`", akan memiliki _fully qualified domain name_ (FQDN) "`foo.bar.my-namespace.svc.cluster-domain.example`". Contoh: apiVersion: v1 kind: Service metadata: name: default-subdomain spec: selector: name: busybox clusterIP: None ports: - name: foo # Actually, no port is needed. port: 1234 targetPort: 1234 --- apiVersion: v1 kind: Pod metadata: name: busybox1 labels: name: busybox spec: hostname: busybox-1 subdomain: default-subdomain containers: - image: busybox:1.28 command: - sleep - "3600" name: busybox --- apiVersion: v1 kind: Pod metadata: name: busybox2 labels: name: busybox spec: hostname: busybox-2 subdomain: default-subdomain containers: - image: busybox:1.28 command: - sleep - "3600" name: busybox Jika terdapat sebuah Service _headless_ memiliki nama yang sama dengan subdomain dari suatu Pod pada _namespace_ yang sama, server KubeDNS klaster akan mengembalikan A _record_ untuk FQDN Pod. Sebagai contoh, misalnya terdapat sebuah Pod dengan _hostname_ "`busybox-1`" dan subdomain "`default-subdomain`", serta sebuah Service _headless_ dengan nama "`default-subdomain`" berada pada suatu _namespace_ yang sama, maka Pod tersebut akan menerima FQDN dirinya sendiri sebagai "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS mengembalikan A _record_ pada nama tersebut dan mengarahkannya pada IP Pod. Baik Pod "`busybox1`" dan "`busybox2`" bisa saja memiliki A _record_ yang berbeda. Objek Endpoint dapat menspesifikasikan `hostname` untuk alamat _endpoint_ manapun beserta dengan alamat IP-nya. #### Catatan: Karena A _record_ tidak dibuat untuk sebuah Pod, maka `hostname` diperlukan agar sebuah Pod memiliki A _record_. Sebuah Pod yang tidak memiliki `hostname` tetapi memiliki `subdomain` hanya akan membuat sebuah A _record_ untuk Service _headless_ (`default-subdomain.my-namespace.svc.cluster-domain.example`), yang merujuk pada IP dari Pod tersebut. Pod juga harus dalam status _ready_ agar dapat memiliki A _record_ kecuali _field_ `publishNotReadyAddresses=True` diaktifkan pada Service. ### Kebijakan DNS Pod Kebijakan DNS dapat diaktifkan untuk setiap Pod. Kubernetes saat ini mendukung kebijakan DNS spesifik Pod (_pod-specific DNS policies_). Kebijakan ini dispesifikasikan pada _field_ `dnsPolicy` yang ada pada spek Pod. * "`Default`": Pod akan mewarisi konfigurasi resolusi yang berasal dari Node dimana Pod tersebut dijalankan. Silakan baca [diskusi terkait](https://kubernetes.io/id/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) untuk detailnya. * "`ClusterFirst`": _Query_ DNS apa pun yang tidak sesuai dengan sufiks domain klaster yang sudah dikonfigurasi misalnya "`www.kubernetes.io`", akan di-_forward_ ke _nameserver_ _upstream_ yang diwarisi dari Node. Administrator klaster bisa saja memiliki _stub-domain_ atau DNS _usptream_ lain yang sudah dikonfigurasi. Silakan lihat [diskusi terkait](https://kubernetes.io/id/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) untuk detail lebih lanjut mengenai bagaimana _query_ DNS melakukan hal tersebut. * "`ClusterFirstWithHostNet`": Untuk Pod yang dijalankan dengan menggunakan `hostNetwork`, kamu harus secara eksplisit mengaktifkan kebijakan DNS-nya menjadi "`ClusterFirstWithHostNet`". * "`None`": Hal ini mengisikan sebuah Pod untuk mengabaikan konfigurasi DNS dari _environment_ Kubernetes Semua pengaturan DNS disediakan menngunakan _field_ `dnsConfig` yang ada pada spek Pod. Silakan lihat [konfigurasi DNS Pod](https://kubernetes.io/id/docs/concepts/services-networking/dns-pod-service/#konfigurasi-dns-pod) di bawah. #### Catatan: "Default" bukan merupakan nilai _default_ kebijakan DNS. Jika `dnsPolicy` tidak secara eksplisit dispesifikasikan, maka “ClusterFirst” akan digunakan. Contoh di bawah ini menunjukkan sebuah Pod dengan kebijakan DNS yang diubah menjadi "`ClusterFirstWithHostNet`" karena _field_ `hostNetwork` diubah menjadi `true`. apiVersion: v1 kind: Pod metadata: name: busybox namespace: default spec: containers: - image: busybox:1.28 command: - sleep - "3600" imagePullPolicy: IfNotPresent name: busybox restartPolicy: Always hostNetwork: true dnsPolicy: ClusterFirstWithHostNet ### Konfigurasi DNS Pod Konfigurasi DNS Pod mengizinkan pengguna untuk memiliki lebih banyak kontrol terhadap pengaturan DNS pada Pod. _Field_ `dnsConfig` bersifat opsional dan dapat digunakan dengan pengaturan `dnsPolicy` apa pun. Meskipun begitu, ketika _field_ `dnsPolicy` pada sebuah Pod diubah menjadi "`None`", maka _field_ `dnsConfig` harus dispesifikasikan. Berikut merupakan properti yang dapat dispesifikasikan oleh pengguna pada _field_ `dnsConfig`: * `nameservers`: serangkaian alamat IP yang akan digunakan sebagai server DNS bagi Pod. Jumlah maksimum dari IP yang dapat didaftarkan pada _field_ ini adalah tiga buah IP. Ketika sebuah `dnsPolicy` pada Pod diubah menjadi "`None`", maka list ini setidaknya harus mengandung sebuah alamat IP, selain kasus tersebut properti ini bersifat opsional. Server yang didaftarkan akan digabungkan di dalam _nameserver_ dasar yang dihasilkan dari kebijakan DNS yang dispesifikasikan, apabila terdapat duplikat terhadap alamat yang didaftarkan maka alamat tersebut akan dihapus. * `searches`: merupakan serangkaian domain pencarian DNS yang digunakan untuk proses _lookup_ pada Pod. Properti ini bersifat opsional. Ketika dispesifikasikan, list yang disediakan akan digabungkan dengan nama domain pencarian dasar yang dihasilkan dari kebijakan DNS yang dipilih. Alamat yang duplikat akan dihapus. Nilai maksimum domain pencarian yang dapat didaftarkan adalah 6 domain. * `options`: merupakan sebuah list opsional yang berisikan objek dimana setiap objek bisa saja memiliki properti `name` (yang bersifat wajib). Isi dari properti ini akan digabungkan dengan opsi yang dihasilkan kebijakan DNS yang digunakan. Alamat yang duplikat akan dihapus. Di bawah ini merupakan contoh sebuah Pod dengan pengaturan DNS kustom: [`service/networking/custom-dns.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/id/examples/service/networking/custom-dns.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/custom-dns.yaml to clipboard") apiVersion: v1 kind: Pod metadata: namespace: default name: dns-example spec: containers: - name: test image: nginx dnsPolicy: "None" dnsConfig: nameservers: - 1.2.3.4 searches: - ns1.svc.cluster-domain.example - my.dns.search.suffix options: - name: ndots value: "2" - name: edns0 Ketika Pod diatas dibuat, maka Container `test` memiliki isi berkas `/etc/resolv.conf` sebagai berikut: nameserver 1.2.3.4 search ns1.svc.cluster-domain.example my.dns.search.suffix options ndots:2 edns0 Untuk pengaturan IPv6, _path_ pencarian dan name server harus dispesifikasikan sebagai berikut: kubectl exec -it dns-example -- cat /etc/resolv.conf Keluaran yang dihasilkan akan menyerupai: nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example options ndots:5 ### Keberadaan Fitur (_Feature Availability_) Keberadaan Pod DNS Config dan DNS Policy "`None`"" diilustrasikan pada tabel di bawah ini. | versi k8s | Dukungan Fitur | | --- | --- | | 1.14 | Stable | | 1.10 | Beta (aktif secara default) | | 1.9 | Alpha | Selanjutnya ----------- Untuk petunjuk lebih lanjut mengenai administrasi konfigurasi DNS, kamu dapat membaca [Cara Melakukan Konfigurasi Service DNS](https://kubernetes.io/id/docs/tasks/administer-cluster/dns-custom-nameservers/) Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified July 25, 2023 at 12:32 PM PST: [ID localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files (f2374598b5)](https://github.com/kubernetes/website/commit/f2374598b5c65871aa312193e383d734033d6b0b) --- # Überwachung, Protokollierung und Fehlerbehebung | Kubernetes Überwachung, Protokollierung und Fehlerbehebung =============================================== Feedback -------- War diese Seite hilfreich? Ja Nein Danke für die Rückmeldung. Wenn Sie eine spezifische, beantwortbare Frage zur Verwendung von Kubernetes haben, stellen Sie diese unter [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Öffnen Sie ein Problem im GitHub-Repo, wenn Sie möchten [Ein Problem melden](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) oder [Eine Verbesserung vorschlagen](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Zuletzt geändert June 22, 2021 at 6:12 PM PST: [\[de\] Remove exec permission on markdown files (bee4cb77c2)](https://github.com/kubernetes/website/commit/bee4cb77c2b6c12425794c84de503a8a59f3bf3b) --- # Visão Geral | Kubernetes **Este documento pode estar desatualizado** Este documento possui uma data de atualização mais antiga que o documento original. Portanto, este conteúdo pode estar desatualizado. Se você lê inglês, veja a versão em inglês para acessar a versão mais atualizada: [Overview](https://kubernetes.io/docs/concepts/overview/) Visão Geral =========== Kubernetes é um plataforma de código aberto, portável e extensiva para o gerenciamento de cargas de trabalho e serviços distribuídos em contêineres, que facilita tanto a configuração declarativa quanto a automação. Ele possui um ecossistema grande, e de rápido crescimento. Serviços, suporte, e ferramentas para Kubernetes estão amplamente disponíveis. Essa página é uma visão geral do Kubernetes. Kubernetes é um plataforma de código aberto, portável e extensiva para o gerenciamento de cargas de trabalho e serviços distribuídos em contêineres, que facilita tanto a configuração declarativa quanto a automação. Ele possui um ecossistema grande, e de rápido crescimento. Serviços, suporte, e ferramentas para Kubernetes estão amplamente disponíveis. O Google tornou Kubernetes um projeto de código-aberto em 2014. O Kubernetes combina [mais de 15 anos de experiência do Google](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/) executando cargas de trabalho produtivas em escala, com as melhores idéias e práticas da comunidade. O nome **Kubernetes** tem origem no Grego, significando _timoneiro_ ou _piloto_. **K8s** é a abreviação derivada pela troca das oito letras "ubernete" por "8", se tornado _K"8"s_. Voltando no tempo ----------------- Vamos dar uma olhada no porque o Kubernetes é tão útil, voltando no tempo. ![Evolução das implantações](https://kubernetes.io/images/docs/Container_Evolution.svg) **Era da implantação tradicional:** No início, as organizações executavam aplicações em servidores físicos. Não havia como definir limites de recursos para aplicações em um mesmo servidor físico, e isso causava problemas de alocação de recursos. Por exemplo, se várias aplicações fossem executadas em um mesmo servidor físico, poderia haver situações em que uma aplicação ocupasse a maior parte dos recursos e, como resultado, o desempenho das outras aplicações seria inferior. Uma solução para isso seria executar cada aplicação em um servidor físico diferente. Mas isso não escalava, pois os recursos eram subutilizados, e se tornava custoso para as organizações manter muitos servidores físicos. **Era da implantação virtualizada:** Como solução, a virtualização foi introduzida. Esse modelo permite que você execute várias máquinas virtuais (VMs) em uma única CPU de um servidor físico. A virtualização permite que as aplicações sejam isoladas entre as VMs, e ainda fornece um nível de segurança, pois as informações de uma aplicação não podem ser acessadas livremente por outras aplicações. A virtualização permite melhor utilização de recursos em um servidor físico, e permite melhor escalabilidade porque uma aplicação pode ser adicionada ou atualizada facilmente, reduz os custos de hardware e muito mais. Com a virtualização, você pode apresentar um conjunto de recursos físicos como um cluster de máquinas virtuais descartáveis. Cada VM é uma máquina completa que executa todos os componentes, incluindo seu próprio sistema operacional, além do hardware virtualizado. **Era da implantação em contêineres:** Contêineres são semelhantes às VMs, mas têm propriedades de isolamento flexibilizados para compartilhar o sistema operacional (SO) entre as aplicações. Portanto, os contêineres são considerados leves. Semelhante a uma VM, um contêiner tem seu próprio sistema de arquivos, compartilhamento de CPU, memória, espaço de processo e muito mais. Como eles estão separados da infraestrutura subjacente, eles são portáveis entre nuvens e distribuições de sistema operacional. Contêineres se tornaram populares porque eles fornecem benefícios extra, tais como: * Criação e implantação ágil de aplicações: aumento da facilidade e eficiência na criação de imagem de contêiner comparado ao uso de imagem de VM. * Desenvolvimento, integração e implantação contínuos: fornece capacidade de criação e de implantação de imagens de contêiner de forma confiável e frequente, com a funcionalidade de efetuar reversões rápidas e eficientes (devido à imutabilidade da imagem). * Separação de interesses entre Desenvolvimento e Operações: crie imagens de contêineres de aplicações no momento de construção/liberação em vez de no momento de implantação, desacoplando as aplicações da infraestrutura. * A capacidade de observação (Observabilidade) não apenas apresenta informações e métricas no nível do sistema operacional, mas também a integridade da aplicação e outros sinais. * Consistência ambiental entre desenvolvimento, teste e produção: funciona da mesma forma em um laptop e na nuvem. * Portabilidade de distribuição de nuvem e sistema operacional: executa no Ubuntu, RHEL, CoreOS, localmente, nas principais nuvens públicas e em qualquer outro lugar. * Gerenciamento centrado em aplicações: eleva o nível de abstração da execução em um sistema operacional em hardware virtualizado à execução de uma aplicação em um sistema operacional usando recursos lógicos. * Microserviços fracamente acoplados, distribuídos, elásticos e livres: as aplicações são divididas em partes menores e independentes e podem ser implantados e gerenciados dinamicamente - não uma pilha monolítica em execução em uma grande máquina de propósito único. * Isolamento de recursos: desempenho previsível de aplicações. * Utilização de recursos: alta eficiência e densidade. Por que você precisa do Kubernetes e o que ele pode fazer --------------------------------------------------------- Os contêineres são uma boa maneira de agrupar e executar suas aplicações. Em um ambiente de produção, você precisa gerenciar os contêineres que executam as aplicações e garantir que não haja tempo de inatividade. Por exemplo, se um contêiner cair, outro contêiner precisa ser iniciado. Não seria mais fácil se esse comportamento fosse controlado por um sistema? É assim que o Kubernetes vem ao resgate! O Kubernetes oferece uma estrutura para executar sistemas distribuídos de forma resiliente. Ele cuida do escalonamento e da recuperação à falha de sua aplicação, fornece padrões de implantação e muito mais. Por exemplo, o Kubernetes pode gerenciar facilmente uma implantação no método canário para seu sistema. O Kubernetes oferece a você: * **Descoberta de serviço e balanceamento de carga** O Kubernetes pode expor um contêiner usando o nome DNS ou seu próprio endereço IP. Se o tráfego para um contêiner for alto, o Kubernetes pode balancear a carga e distribuir o tráfego de rede para que a implantação seja estável. * **Orquestração de armazenamento** O Kubernetes permite que você monte automaticamente um sistema de armazenamento de sua escolha, como armazenamentos locais, provedores de nuvem pública e muito mais. * **Lançamentos e reversões automatizadas** Você pode descrever o estado desejado para seus contêineres implantados usando o Kubernetes, e ele pode alterar o estado real para o estado desejado em um ritmo controlado. Por exemplo, você pode automatizar o Kubernetes para criar novos contêineres para sua implantação, remover os contêineres existentes e adotar todos os seus recursos para o novo contêiner. * **Empacotamento binário automático** Você fornece ao Kubernetes um cluster de nós que pode ser usado para executar tarefas nos contêineres. Você informa ao Kubernetes de quanta CPU e memória (RAM) cada contêiner precisa. O Kubernetes pode encaixar contêineres em seus nós para fazer o melhor uso de seus recursos. * **Autocorreção** O Kubernetes reinicia os contêineres que falham, substitui os contêineres, elimina os contêineres que não respondem à verificação de integridade definida pelo usuário e não os anuncia aos clientes até que estejam prontos para servir. * **Gerenciamento de configuração e de segredos** O Kubernetes permite armazenar e gerenciar informações confidenciais, como senhas, tokens OAuth e chaves SSH. Você pode implantar e atualizar segredos e configuração de aplicações sem reconstruir suas imagens de contêiner e sem expor segredos em sua pilha de configuração. O que o Kubernetes não é ------------------------ O Kubernetes não é um sistema PaaS (plataforma como serviço) tradicional e completo. Como o Kubernetes opera no nível do contêiner, e não no nível do hardware, ele fornece alguns recursos geralmente aplicáveis comuns às ofertas de PaaS, como implantação, escalonamento, balanceamento de carga, e permite que os usuários integrem suas soluções de _logging_, monitoramento e alerta. No entanto, o Kubernetes não é monolítico, e essas soluções padrão são opcionais e conectáveis. O Kubernetes fornece os blocos de construção para a construção de plataformas de desenvolvimento, mas preserva a escolha e flexibilidade do usuário onde é importante. Kubernetes: * Não limita os tipos de aplicações suportadas. O Kubernetes visa oferecer suporte a uma variedade extremamente diversa de cargas de trabalho, incluindo cargas de trabalho sem estado, com estado e de processamento de dados. Se uma aplicação puder ser executada em um contêiner, ele deve ser executado perfeitamente no Kubernetes. * Não implanta código-fonte e não constrói sua aplicação. Os fluxos de trabalho de integração contínua, entrega e implantação (CI/CD) são determinados pelas culturas e preferências da organização, bem como pelos requisitos técnicos. * Não fornece serviços em nível de aplicação, tais como middleware (por exemplo, barramentos de mensagem), estruturas de processamento de dados (por exemplo, Spark), bancos de dados (por exemplo, MySQL), caches, nem sistemas de armazenamento em cluster (por exemplo, Ceph), como serviços integrados. Esses componentes podem ser executados no Kubernetes e/ou podem ser acessados por aplicações executadas no Kubernetes por meio de mecanismos portáteis, como o [Open Service Broker](https://openservicebrokerapi.org/) . * Não dita soluções de _logging_, monitoramento ou alerta. Ele fornece algumas integrações como prova de conceito e mecanismos para coletar e exportar métricas. * Não fornece nem exige um sistema/idioma de configuração (por exemplo, Jsonnet). Ele fornece uma API declarativa que pode ser direcionada por formas arbitrárias de especificações declarativas. * Não fornece nem adota sistemas abrangentes de configuração de máquinas, manutenção, gerenciamento ou autocorreção. * Adicionalmente, o Kubernetes não é um mero sistema de orquestração. Na verdade, ele elimina a necessidade de orquestração. A definição técnica de orquestração é a execução de um fluxo de trabalho definido: primeiro faça A, depois B e depois C. Em contraste, o Kubernetes compreende um conjunto de processos de controle independentes e combináveis que conduzem continuamente o estado atual em direção ao estado desejado fornecido. Não importa como você vai de A para C. O controle centralizado também não é necessário. Isso resulta em um sistema que é mais fácil de usar e mais poderoso, robusto, resiliente e extensível. Próximos passos --------------- * Dê uma olhada em [Componentes do Kubernetes](https://kubernetes.io/pt-br/docs/concepts/overview/components/) . * Pronto para [Iniciar](https://kubernetes.io/pt-br/docs/setup/) ? Comentários ----------- Esta página foi útil? Sim Não Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abra um bug no repositório do GitHub se você deseja [relatar um problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) ou [sugerir uma melhoria](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Última modificação July 08, 2023 at 7:01 PM PST: [\[pt-br\] Update docs/concepts/overview/\_index.md (#41070) (9493bb5ab1)](https://github.com/kubernetes/website/commit/9493bb5ab1c5e8a9da8b2f0f29dc6ce8634415ec) --- # 卷 | Kubernetes 卷 = Kubernetes **卷**为 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ "Pod 表示你的集群上一组正在运行的容器。") 中的容器提供了一种通过文件系统访问和共享数据的方式。存在不同类别的卷，你可以将其用于各种用途，例如： * 基于 [ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/ "ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。") 或 [Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/ "Secret 用于存储敏感信息，如密码、 OAuth 令牌和 SSH 密钥。") 填充配置文件 * 为 Pod 提供一些临时的涂销空间 * 在同一个 Pod 中的两个不同容器之间共享文件系统 * 在两个不同的 Pod 之间共享文件系统（即使这些 Pod 运行在不同的节点上） * 持久化存储数据，这样即使 Pod 重启或被替换，存储的数据仍然可用 * 基于容器所在 Pod 的详细信息，将配置信息传递给运行在容器中的应用 （例如告诉[边车容器](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/sidecar-containers/ "在 Pod 的整个生命期内保持运行的辅助容器。") ：Pod 运行在哪个命名空间） * 以只读权限访问另一个容器镜像中的数据 数据共享可以发生在容器内不同本地进程之间，或在不同容器之间，或在多个 Pod 之间。 为什么卷很重要 ------- * **数据持久性：** 容器中的文件在磁盘上是临时存放的，这给在容器中运行较重要的应用带来一些问题。 当容器崩溃或被停止时，容器的状态不会被保存，因此在容器生命期内创建或修改的所有文件都将丢失。 在崩溃之后，kubelet 会以干净的状态重启容器。 * **共享存储：** 当多个容器在一个 Pod 中运行并需要共享文件时，会出现另一个问题。 那就是在所有容器之间设置和访问共享文件系统可能会很有难度。 Kubernetes [卷（Volume）](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/ "包含可被 Pod 中容器访问的数据的目录。") 这一抽象概念能够解决这两个问题。 在你学习卷、持久卷（PersistentVolume）和持久卷申领（PersistentVolumeClaim）之前， 你应该先了解 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ "Pod 表示你的集群上一组正在运行的容器。") ， 确保你理解 Kubernetes 如何使用 Pod 来运行容器。 卷是如何工作的 ------- Kubernetes 支持很多类型的卷。 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ "Pod 表示你的集群上一组正在运行的容器。") 可以同时使用任意数目的卷类型。 [临时卷](https://kubernetes.io/zh-cn/docs/concepts/storage/ephemeral-volumes/) 类型将生命期关联到特定的 Pod， 但[持久卷](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/) 可以比任意独立 Pod 的生命期长。 当 Pod 不再存在时，Kubernetes 也会销毁临时卷；不过 Kubernetes 不会销毁持久卷。 对于给定 Pod 中任何类型的卷，在容器重启期间数据都不会丢失。 卷的核心是一个目录，其中可能存有数据，Pod 中的容器可以访问该目录中的数据。 所采用的特定的卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放的内容。 使用卷时, 在 `.spec.volumes` 字段中设置为 Pod 提供的卷，并在 `.spec.containers[*].volumeMounts` 字段中声明卷在容器中的挂载位置。 当 Pod 被启动时，容器中的进程看到的文件系统视图是由它们的[容器镜像](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-image "镜像（Image）是保存的容器实例，它打包了应用运行所需的一组软件。") 的初始内容以及挂载在容器中的卷（如果定义了的话）所组成的。 其中根文件系统同容器镜像的内容相吻合。 任何在该文件系统下的写入操作，如果被允许的话，都会影响接下来容器中进程访问文件系统时所看到的内容。 卷被挂载在镜像中的[指定路径](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#using-subpath) 下。 Pod 配置中的每个容器必须独立指定各个卷的挂载位置。 卷不能挂载到其他卷之上（不过存在一种[使用 subPath](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#using-subpath) 的相关机制）， 也不能与其他卷有硬链接。 卷类型 --- Kubernetes 支持下列类型的卷： ### awsElasticBlockStore（已弃用） 在 Kubernetes 1.35 中，所有针对树内 `awsElasticBlockStore` 类型的操作都会被重定向到 `ebs.csi.aws.com` [CSI](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi "容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。") 驱动。 AWSElasticBlockStore 树内存储驱动已在 Kubernetes v1.19 版本中废弃， 并在 v1.27 版本中被完全移除。 Kubernetes 项目建议你转为使用 [AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) 第三方存储驱动插件。 ### azureDisk（已弃用） 在 Kubernetes 1.35 中，所有针对树内 `azureDisk` 类型的操作都会被重定向到 `disk.csi.azure.com` [CSI](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi "容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。") 驱动。 AzureDisk 树内存储驱动已在 Kubernetes v1.19 版本中废弃，并在 v1.27 版本中被完全移除。 Kubernetes 项目建议你转为使用 [Azure Disk](https://github.com/kubernetes-sigs/azuredisk-csi-driver) 第三方存储驱动插件。 ### azureFile（已弃用） 在 Kubernetes 1.35 中，所有针对树内 `azureFile` 类型的操作都会被重定向到 `file.csi.azure.com` [CSI](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi "容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。") 驱动。 AzureFile 树内存储驱动在 Kubernetes v1.21 版本中被弃用，并在 v1.30 版本中被完全移除。 Kubernetes 项目建议你改为使用 [Azure File](https://github.com/kubernetes-sigs/azurefile-csi-driver) 第三方存储驱动。 ### cephfs（已移除） Kubernetes 1.35 不包括 `cephfs` 卷类型。 `cephfs` 树内存储驱动在 Kubernetes v1.28 版本中被弃用，并在 v1.31 版本中被完全移除。 ### cinder（已弃用） 在 Kubernetes 1.35 中，所有针对树内 `cinder` 类型的操作都会被重定向到 `cinder.csi.openstack.org` [CSI](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi "容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。") 驱动。 OpenStack Cinder 树内存储驱动已在 Kubernetes v1.11 版本中废弃， 并在 v1.26 版本中被完全移除。 Kubernetes 项目建议你转为使用 [OpenStack Cinder](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) 第三方存储驱动插件。 ### configMap [`configMap`](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 卷提供了向 Pod 注入配置数据的方法。 ConfigMap 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被 Pod 中运行的容器化应用使用。 引用 configMap 对象时，你可以在卷中通过它的名称来引用。 你可以自定义 ConfigMap 中特定条目所要使用的路径。 下面的配置显示了如何将名为 `log-config` 的 ConfigMap 挂载到名为 `configmap-pod` 的 Pod 中： apiVersion: v1 kind: Pod metadata: name: configmap-pod spec: containers: - name: test image: busybox:1.28 command: ['sh', '-c', 'echo "The app is running!" && tail -f /dev/null'] volumeMounts: - name: config-vol mountPath: /etc/config volumes: - name: config-vol configMap: name: log-config items: - key: log_level path: log_level.conf `log-config` ConfigMap 以卷的形式挂载，并且存储在 `log_level` 条目中的所有内容都被挂载到 Pod 的 `/etc/config/log_level.conf` 路径下。 请注意，这个路径来源于卷的 `mountPath` 和 `log_level` 键对应的 `path`。 #### 说明： * 你必须先[创建 ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/#create-a-configmap) ， 才能使用它。 * ConfigMap 总是以 `readOnly` 的模式挂载。 * 某容器以 [`subPath`](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#using-subpath) 卷挂载方式使用 ConfigMap 时， 若 ConfigMap 发生变化，此容器将无法接收更新。 * 文本数据挂载成文件时采用 UTF-8 字符编码。如果使用其他字符编码形式，可使用 `binaryData` 字段。 ### downwardAPI `downwardAPI` 卷用于为应用提供 [downward API](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/downward-api/ "将 Pod 和容器字段值暴露给容器中运行的代码的机制。") 数据。 在这类卷中，所公开的数据以纯文本格式的只读文件形式存在。 #### 说明： 容器以 [subPath](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#using-subpath) 卷挂载方式使用 downward API 时， 在字段值更改时将不能接收到它的更新。 更多详细信息请参考[通过文件将 Pod 信息呈现给容器](https://kubernetes.io/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 。 ### emptyDir 对于定义了 `emptyDir` 卷的 Pod，在 Pod 被指派到某节点时此卷会被创建。 就像其名称所表示的那样，`emptyDir` 卷最初是空的。尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同，但这些容器都可以读写 `emptyDir` 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时，`emptyDir` 卷中的数据也会被永久删除。 #### 说明： 容器崩溃并**不**会导致 Pod 被从节点上移除，因此容器崩溃期间 `emptyDir` 卷中的数据是安全的。 `emptyDir` 的一些用途： * 缓存空间，例如基于磁盘的归并排序。 * 为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。 * 在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。 `emptyDir.medium` 字段用来控制 `emptyDir` 卷的存储位置。 默认情况下，`emptyDir` 卷存储在该节点所使用的介质上； 此处的介质可以是磁盘、SSD 或网络存储，这取决于你的环境。 你可以将 `emptyDir.medium` 字段设置为 `"Memory"`， 以告诉 Kubernetes 为你挂载 tmpfs（基于 RAM 的文件系统）。 虽然 tmpfs 速度非常快，但是要注意它与磁盘不同， 并且你所写入的所有文件都会计入容器的内存消耗，受容器内存限制约束。 你可以通过为默认介质指定大小限制，来限制 `emptyDir` 卷的存储容量。 此存储是从[节点临时存储](https://kubernetes.io/zh-cn/docs/concepts/storage/ephemeral-storage/#setting-requests-and-limits-for-local-ephemeral-storage) 中分配的。 如果来自其他来源（如日志文件或镜像分层数据）的数据占满了存储，`emptyDir` 可能会在达到此限制之前发生存储容量不足的问题。 如果未指定大小，内存支持的卷将被设置为节点可分配内存的大小。 #### 注意： 使用内存作为介质的 `emptyDir` 卷时， 请查阅[此处](https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/#memory-backed-emptydir) ， 了解有关资源管理方面的注意事项。 #### emptyDir 配置示例 apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: sizeLimit: 500Mi #### emptyDir 内存配置示例 apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: sizeLimit: 500Mi medium: Memory ### fc（光纤通道） `fc` 卷类型允许将现有的光纤通道块存储卷挂载到 Pod 中。 可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN（World Wide Names）。 如果指定了多个 WWN，targetWWNs 期望这些 WWN 来自多路径连接。 #### 说明： 你必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷），这样 Kubernetes 主机才可以访问它们。 ### gcePersistentDisk（已弃用） 在 Kubernetes 1.35 中，所有针对树内 `gcePersistentDisk` 类型的操作都会被重定向到 `pd.csi.storage.gke.io` [CSI](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi "容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。") 驱动。 `gcePersistentDisk` 源代码树内卷存储驱动在 Kubernetes v1.17 版本中被弃用， 在 v1.28 版本中被完全移除。 Kubernetes 项目建议你转为使用 [Google Compute Engine Persistent Disk CSI](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) 第三方存储驱动插件。 ### gitRepo（已弃用） #### 警告： `gitRepo` 卷插件已经被弃用且默认禁用。 如果需要制备已挂载 Git 仓库的 Pod，你可以将 [EmptyDir](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#emptydir) 卷挂载到 [Init 容器](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/) 中， 使用 Git 命令完成仓库的克隆操作，然后将 [EmptyDir](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#emptydir) 卷挂载到 Pod 的容器中。 * * * 你可以使用 [ValidatingAdmissionPolicy](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/validating-admission-policy/) 这类[策略](https://kubernetes.io/zh-cn/docs/concepts/policy/) 来限制在你的集群中使用 `gitRepo` 卷。 你可以使用以下通用表达语言（CEL）表达式作为策略的一部分，以拒绝使用 `gitRepo` 卷： !has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo)) 如果你明确启用 `GitRepoVolumeDriver` [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) ， 你可以在集群中使用这个已废弃的存储插件。 `gitRepo` 卷是一个卷插件的例子。 该查卷挂载一个空目录，并将一个 Git 代码仓库克隆到这个目录中供 Pod 使用。 下面给出一个 `gitRepo` 卷的示例： apiVersion: v1 kind: Pod metadata: name: server spec: containers: - image: nginx name: nginx volumeMounts: - mountPath: /mypath name: git-volume volumes: - name: git-volume gitRepo: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ### glusterfs（已移除） Kubernetes 1.35 不包含 `glusterfs` 卷类型。 GlusterFS 树内存储驱动程序在 Kubernetes v1.25 版本中被弃用，然后在 v1.26 版本中被完全移除。 ### hostPath `hostPath` 卷能将主机节点文件系统上的文件或目录挂载到你的 Pod 中。 虽然这不是大多数 Pod 需要的，但是它为一些应用提供了强大的逃生舱。 #### 警告： 使用 `hostPath` 类型的卷存在许多安全风险。如果可以，你应该尽量避免使用 `hostPath` 卷。 例如，你可以改为定义并使用 [`local` PersistentVolume](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#local) 。 如果你通过准入时的验证来限制对节点上特定目录的访问，这种限制只有在你额外要求所有 `hostPath` 卷的挂载都是**只读**的情况下才有效。如果你允许不受信任的 Pod 以读写方式挂载任意主机路径， 则该 Pod 中的容器可能会破坏可读写主机挂载卷的安全性。 * * * 无论 `hostPath` 卷是以只读还是读写方式挂载，使用时都需要小心，这是因为： * 访问主机文件系统可能会暴露特权系统凭证（例如 kubelet 的凭证）或特权 API（例如容器运行时套接字）， 这些可以被用于容器逃逸或攻击集群的其他部分。 * 具有相同配置的 Pod（例如基于 PodTemplate 创建的 Pod）可能会由于节点上的文件不同而在不同节点上表现出不同的行为。 * `hostPath` 卷的用量不会被视为临时存储用量。 你需要自己监控磁盘使用情况，因为过多的 `hostPath` 磁盘使用量会导致节点上的磁盘压力。 `hostPath` 的一些用法有： * 运行一个需要访问节点级系统组件的容器 （例如一个将系统日志传输到集中位置的容器，使用只读挂载 `/var/log` 来访问这些日志） * 让存储在主机系统上的配置文件可以被[静态 Pod](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/static-pod/ "静态 Pod（Static Pod）是指由特定节点上的 kubelet 守护进程直接管理的 Pod。") 以只读方式访问；与普通 Pod 不同，静态 Pod 无法访问 ConfigMap。 #### `hostPath` 卷类型 除了必需的 `path` 属性外，你还可以选择为 `hostPath` 卷指定 `type`。 `type` 的可用值有： | 取值 | 行为 | | --- | --- | | `‌""` | 空字符串（默认）用于向后兼容，这意味着在安装 hostPath 卷之前不会执行任何检查。 | | `DirectoryOrCreate` | 如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 kubelet 相同的组和属主信息。 | | `Directory` | 在给定路径上必须存在的目录。 | | `FileOrCreate` | 如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 kubelet 相同的组和所有权。 | | `File` | 在给定路径上必须存在的文件。 | | `Socket` | 在给定路径上必须存在的 UNIX 套接字。 | | `CharDevice` | **（仅 Linux 节点）** 在给定路径上必须存在的字符设备。 | | `BlockDevice` | **（仅 Linux 节点）** 在给定路径上必须存在的块设备。 | #### 注意： `FileOrCreate` 模式**不会**创建文件的父目录。如果挂载文件的父目录不存在，Pod 将启动失败。 为了确保这种模式正常工作，你可以尝试分别挂载目录和文件，如 `hostPath` 的 [`FileOrCreate` 示例](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#hostpath-fileorcreate-example) 所示。 下层主机上创建的某些文件或目录只能由 root 用户访问。 此时，你需要在[特权容器](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/) 中以 root 身份运行进程，或者修改主机上的文件权限，以便能够从 `hostPath` 卷读取数据（或将数据写入到 `hostPath` 卷）。 #### hostPath 配置示例 * [Linux 节点](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#hostpath-examples-0) * [Windows 节点](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#hostpath-examples-1) --- # 此清单将主机上的 "/data/foo" 目录挂载为 hostpath-example-linux Pod 中运行的单个容器内的 "/foo" 目录 # # 容器中的挂载是只读的 apiVersion: v1 kind: Pod metadata: name: hostpath-example-linux spec: os: { name: linux } nodeSelector: kubernetes.io/os: linux containers: - name: example-container image: registry.k8s.io/test-webserver volumeMounts: - mountPath: /foo name: example-volume readOnly: true volumes: - name: example-volume # 挂载 "/data/foo"，但仅当该目录已经存在时 hostPath: path: /data/foo # 主机上的目录位置 type: Directory # 此字段可选 --- # 此清单将主机上的 "C:\Data\foo" 目录挂载为 hostpath-example-windows Pod 中运行的单个容器内的 "C:\foo" 目录 # # 容器中的挂载是只读的 apiVersion: v1 kind: Pod metadata: name: hostpath-example-windows spec: os: { name: windows } nodeSelector: kubernetes.io/os: windows containers: - name: example-container image: microsoft/windowsservercore:1709 volumeMounts: - name: example-volume mountPath: "C:\\foo" readOnly: true volumes: # 从主机挂载 "C:\Data\foo"，但仅当该目录已经存在时 - name: example-volume hostPath: path: "C:\\Data\\foo" # 主机上的目录位置 type: Directory # 此字段可选 #### hostPath FileOrCreate 配置示例 以下清单定义了一个 Pod，将 `/var/local/aaa` 挂载到 Pod 中的单个容器内。 如果节点上还没有路径 `/var/local/aaa`，kubelet 会创建这一目录，然后将其挂载到 Pod 中。 如果 `/var/local/aaa` 已经存在但不是一个目录，Pod 会失败。 此外，kubelet 还会尝试在该目录内创建一个名为 `/var/local/aaa/1.txt` 的文件（从主机的视角来看）； 如果在该路径上已经存在某个东西且不是常规文件，则 Pod 会失败。 以下是清单示例： apiVersion: v1 kind: Pod metadata: name: test-webserver spec: os: { name: linux } nodeSelector: kubernetes.io/os: linux containers: - name: test-webserver image: registry.k8s.io/test-webserver:latest volumeMounts: - mountPath: /var/local/aaa name: mydir - mountPath: /var/local/aaa/1.txt name: myfile volumes: - name: mydir hostPath: # 确保文件所在目录被创建成功。 path: /var/local/aaa type: DirectoryOrCreate - name: myfile hostPath: path: /var/local/aaa/1.txt type: FileOrCreate ### image 特性状态： `Kubernetes v1.35 [beta]`（默认启用） `image` 卷源代表一个在 kubelet 主机上可用的 OCI 对象（容器镜像或工件）。 使用 `image` 卷源的一个例子是： [`pods/image-volumes.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/pods/image-volumes.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 pods/image-volumes.yaml 到剪贴板") apiVersion: v1 kind: Pod metadata: name: image-volume spec: containers: - name: shell command: ["sleep", "infinity"] image: debian volumeMounts: - name: volume mountPath: /volume volumes: - name: volume image: reference: quay.io/crio/artifact:v2 pullPolicy: IfNotPresent 此卷在 Pod 启动时基于提供的 `pullPolicy` 值进行解析： `Always` kubelet 始终尝试拉取此引用。如果拉取失败，kubelet 会将 Pod 设置为 `Failed`。 `Never` kubelet 从不拉取此引用，仅使用本地镜像或工件。 如果本地没有任何镜像层存在，或者该镜像的清单未被缓存，则 Pod 会变为 `Failed`。 `IfNotPresent` 如果引用在磁盘上不存在，kubelet 会进行拉取。 如果引用不存在且拉取失败，则 Pod 会变为 `Failed`。 如果 Pod 被删除并重新创建，此卷会被重新解析，这意味着在 Pod 重新创建时将可以访问新的远程内容。 在 Pod 启动期间解析或拉取镜像失败将导致容器无法启动，并可能显著增加延迟。 如果失败，将使用正常的卷回退进行重试，并输出 Pod 失败的原因和相关消息。 此卷可以挂载的对象类型由主机上的容器运行时实现负责定义，至少必须包含容器镜像字段所支持的所有有效类型。 OCI 对象将以只读方式被挂载到单个目录（`spec.containers[*].volumeMounts[*].mountPath`）中。 此外： * 从 Kubernetes v1.33 开始，才支持容器的 [`subPath`](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#using-subpath) 或 [`subPathExpr`](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#using-subpath-expanded-environment) 挂载（`spec.containers[*].volumeMounts[*].subPath`、`spec.containers[*].volumeMounts[*].subPathExpr`）。 * `spec.securityContext.fsGroupChangePolicy` 字段对这种卷没有效果。 * [`AlwaysPullImages` 准入控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 也适用于此卷源， 就像适用于容器镜像一样。 `image` 类型可用的字段如下： `reference` 要使用的工件引用。例如，你可以指定 `registry.k8s.io/conformance:v1.35.0` 来加载 Kubernetes 合规性测试镜像中的文件。其行为与 `pod.spec.containers[*].image` 相同。 拉取 Secret 的组装方式与容器镜像所用的方式相同，即通过查找节点凭据、服务账户镜像拉取 Secret 和 Pod 规约镜像拉取 Secret。此字段是可选的，允许更高层次的配置管理在 Deployment 和 StatefulSet 这类工作负载控制器中默认使用或重载容器镜像。 参阅[容器镜像更多细节](https://kubernetes.io/zh-cn/docs/concepts/containers/images) 。 `pullPolicy` 拉取 OCI 对象的策略。可能的值为：`Always`、`Never` 或 `IfNotPresent`。 如果指定了 `:latest` 标记，则默认为 `Always`，否则默认为 `IfNotPresent`。 有关如何使用卷源的更多细节， 请参见 [**Pod 使用镜像卷**](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/image-volumes) 示例。 ### iscsi `iscsi` 卷能将 iSCSI（基于 IP 的 SCSI）卷挂载到你的 Pod 中。 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`iscsi` 卷的内容在删除 Pod 时会被保留，卷只是被卸载。 这意味着 `iscsi` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 #### 说明： 在使用 iSCSI 卷之前，你必须拥有自己的 iSCSI 服务器，并在上面创建卷。 iSCSI 的一个特点是它可以同时被多个用户以只读方式挂载。 这意味着你可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 上使用它。 不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载。不允许同时写入。 ### local `local` 卷所代表的是某个被挂载的本地存储设备，例如磁盘、分区或者目录。 `local` 卷只能用作静态创建的持久卷。不支持动态配置。 与 `hostPath` 卷相比，`local` 卷能够以持久和可移植的方式使用，而无需手动将 Pod 调度到节点。系统通过查看 PersistentVolume 的节点亲和性配置，就能了解卷的节点约束。 然而，`local` 卷仍然取决于底层节点的可用性，并不适合所有应用程序。 如果节点变得不健康，那么 `local` 卷也将变得不可被 Pod 访问。使用它的 Pod 将不能运行。 使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征而带来的潜在的数据丢失风险。 下面是一个使用 `local` 卷和 `nodeAffinity` 的持久卷示例： apiVersion: v1 kind: PersistentVolume metadata: name: example-pv spec: capacity: storage: 100Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: local-storage local: path: /mnt/disks/ssd1 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - example-node 使用 `local` 卷时，你需要设置 PersistentVolume 对象的 `nodeAffinity` 字段。 Kubernetes 调度器使用 PersistentVolume 的 `nodeAffinity` 信息来将使用 `local` 卷的 Pod 调度到正确的节点。 PersistentVolume 对象的 `volumeMode` 字段可被设置为 `"Block"` （而不是默认值 `"Filesystem"`），以将 `local` 卷作为原始块设备暴露出来。 使用 `local` 卷时，建议创建一个 StorageClass 并将其 `volumeBindingMode` 设置为 `WaitForFirstConsumer`。要了解更多详细信息，请参考 [local StorageClass 示例](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#local) 。 延迟卷绑定的操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时，会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。 你可以在 Kubernetes 之外单独运行静态驱动以改进对 `local` 卷的生命周期管理。 请注意，此驱动尚不支持动态配置。 有关如何运行外部 `local` 卷驱动，请参考 [`local` 卷驱动用户指南](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner) 。 #### 说明： 如果不使用外部静态驱动来管理卷的生命周期，用户需要手动清理和删除 `local` 类型的持久卷。 ### nfs `nfs` 卷能将 NFS（网络文件系统）挂载到你的 Pod 中。 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`nfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载。 这意味着 `nfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /my-nfs-data name: test-volume volumes: - name: test-volume nfs: server: my-nfs-server.example.com path: /my-nfs-volume readOnly: true #### 说明： 在使用 NFS 卷之前，你必须运行自己的 NFS 服务器并将目标 share 导出备用。 还需要注意，不能在 Pod 规约中指定 NFS 挂载可选项。 可以选择设置服务端的挂载可选项，或者使用 [`/etc/nfsmount.conf`](https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html) 。 此外，还可以通过允许设置挂载可选项的持久卷挂载 NFS 卷。 ### persistentVolumeClaim `persistentVolumeClaim` 卷用来将[持久卷](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/) （PersistentVolume）挂载到 Pod 中。 持久卷申领（PersistentVolumeClaim）是用户在不知道特定云环境细节的情况下“申领”持久存储（例如 iSCSI 卷）的一种方法。 更多详情请参考[持久卷](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/) 。 ### portworxVolume（已弃用） 特性状态： `Kubernetes v1.25 [deprecated]` `portworxVolume` 是一个可伸缩的块存储层，能够以超融合（hyperconverged）的方式与 Kubernetes 一起运行。 [Portworx](https://portworx.com/use-case/kubernetes-storage/) 支持对服务器上存储的指纹处理、基于存储能力进行分层以及跨多个服务器整合存储容量。 Portworx 可以以 in-guest 方式在虚拟机中运行，也可以在裸金属 Linux 节点上运行。 `portworxVolume` 类型的卷可以通过 Kubernetes 动态创建，也可以预先配备并在 Pod 内引用。 下面是一个引用预先配备的 Portworx 卷的示例 Pod： apiVersion: v1 kind: Pod metadata: name: test-portworx-volume-pod spec: containers: - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /mnt name: pxvol volumes: - name: pxvol # 此 Portworx 卷必须已经存在 portworxVolume: volumeID: "pxvol" fsType: "" #### 说明： 在 Pod 中使用 portworxVolume 之前，你要确保有一个名为 `pxvol` 的 PortworxVolume 存在。 #### Portworx CSI 迁移 特性状态： `Kubernetes v1.33 [stable]`（默认启用） 在 Kubernetes 1.35 中，默认情况下， 所有针对树内 Portworx 卷的操作都会被重定向到 `pxd.portworx.com` 容器存储接口（CSI）驱动。 [Portworx CSI 驱动程序](https://docs.portworx.com/portworx-enterprise/operations/operate-kubernetes/storage-operations/csi) 必须安装在集群上。 ### 投射（projected） 投射卷能将若干现有的卷来源映射到同一目录上。更多详情请参考[投射卷](https://kubernetes.io/zh-cn/docs/concepts/storage/projected-volumes/) 。 ### rbd（已移除） Kubernetes 1.35 不包括 `rbd` 卷类型。 [Rados 块设备](https://docs.ceph.com/en/latest/rbd/) （RBD） 树内存储驱动及其 CSI 迁移支持在 Kubernetes v1.28 版本中被弃用，并在 v1.31 版本中被完全移除。 ### secret `secret` 卷用来给 Pod 传递敏感信息，例如密码。你可以将 Secret 存储在 Kubernetes API 服务器上，然后以文件的形式挂载到 Pod 中，无需直接与 Kubernetes 耦合。 `secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性（持久化的）存储器。 #### 说明： * 使用前你必须在 Kubernetes API 中创建 Secret。 * Secret 总是以 `readOnly` 的模式挂载。 * 容器以 [`subPath`](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#using-subpath) 卷挂载方式使用 Secret 时，将无法接收 Secret 的更新。 更多详情请参考[配置 Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/) 。 ### vsphereVolume（已弃用） 在 Kubernetes 1.35 中，所有针对树内 `vsphereVolume` 类型的操作都被重定向到 `csi.vsphere.vmware.com` [CSI](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi "容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。") 驱动。 `vsphereVolume` 树内存储驱动在 Kubernetes v1.19 版本中被弃用，并在 v1.30 版本中被完全移除。 Kubernetes 项目建议你改为使用 [vSphere CSI](https://github.com/kubernetes-sigs/vsphere-csi-driver) 第三方存储驱动。 使用 subPath ---------- 有时，在单个 Pod 中共享卷以供多方使用是很有用的。 `volumeMounts[*].subPath` 属性可用于指定所引用的卷内的子路径，而不是其根路径。 下面例子展示了如何配置某包含 LAMP 堆栈（Linux Apache MySQL PHP）的 Pod 使用同一共享卷。 此示例中的 `subPath` 配置不建议在生产环境中使用。 PHP 应用的代码和相关数据映射到卷的 `html` 文件夹，MySQL 数据库存储在卷的 `mysql` 文件夹中： apiVersion: v1 kind: Pod metadata: name: my-lamp-site spec: containers: - name: mysql image: mysql env: - name: MYSQL_ROOT_PASSWORD value: "rootpasswd" volumeMounts: - mountPath: /var/lib/mysql name: site-data subPath: mysql - name: php image: php:7.0-apache volumeMounts: - mountPath: /var/www/html name: site-data subPath: html volumes: - name: site-data persistentVolumeClaim: claimName: my-lamp-site-data ### 使用带有扩展环境变量的 subPath 特性状态： `Kubernetes v1.17 [stable]` 使用 `subPathExpr` 字段可以基于 downward API 环境变量来构造 `subPath` 目录名。 `subPath` 和 `subPathExpr` 属性是互斥的。 在这个示例中，`Pod` 使用 `subPathExpr` 来 `hostPath` 卷 `/var/log/pods` 中创建目录 `pod1`。 `hostPath` 卷采用来自 `downwardAPI` 的 Pod 名称生成目录名。 宿主机目录 `/var/log/pods/pod1` 被挂载到容器的 `/logs` 中。 apiVersion: v1 kind: Pod metadata: name: pod1 spec: containers: - name: container1 env: - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name image: busybox:1.28 command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] volumeMounts: - name: workdir1 mountPath: /logs # 包裹变量名的是小括号，而不是大括号 subPathExpr: $(POD_NAME) restartPolicy: Never volumes: - name: workdir1 hostPath: path: /var/log/pods 资源 -- `emptyDir` 卷的存储介质（例如磁盘、SSD 等）是由保存 kubelet 数据的根目录（通常是 `/var/lib/kubelet`）的文件系统的介质确定。 Kubernetes 对 `emptyDir` 卷或者 `hostPath` 卷可以消耗的空间没有限制，容器之间或 Pod 之间也没有隔离。 要了解如何使用资源规约来请求空间， 可参考[如何管理资源](https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/) 。 树外（Out-of-Tree）卷插件 ------------------ Out-of-Tree 卷插件包括[容器存储接口（CSI）](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#csi "容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。") 和 FlexVolume（已弃用）。它们使存储供应商能够创建自定义存储插件，而无需将插件源码添加到 Kubernetes 代码仓库。 以前，所有卷插件（如上面列出的卷类型）都是“树内（In-Tree）”的。 “树内”插件是与 Kubernetes 的核心组件一同构建、链接、编译和交付的。 这意味着向 Kubernetes 添加新的存储系统（卷插件）需要将代码合并到 Kubernetes 核心代码库中。 CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署（安装）在 Kubernetes 集群上。 对于希望创建树外（Out-Of-Tree）卷插件的存储供应商， 请参考[卷插件常见问题](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) 。 ### CSI [容器存储接口](https://github.com/container-storage-interface/spec/blob/master/spec.md) （CSI） 为容器编排系统（如 Kubernetes）定义标准接口，以将任意存储系统暴露给它们的容器工作负载。 更多详情请阅读 [CSI 设计方案](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) 。 #### 说明： Kubernetes v1.13 废弃了对 CSI 规范版本 0.2 和 0.3 的支持，并将在以后的版本中删除。 #### 说明： CSI 驱动可能并非兼容所有的 Kubernetes 版本。 请查看特定 CSI 驱动的文档，以了解各个 Kubernetes 版本所支持的部署步骤以及兼容性列表。 一旦在 Kubernetes 集群上部署了 CSI 兼容卷驱动程序，用户就可以使用 `csi` 卷类型来挂接、挂载 CSI 驱动所提供的卷。 `csi` 卷可以在 Pod 中以三种方式使用： * 通过 [PersistentVolumeClaim](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#persistentvolumeclaim) 对象引用 * 使用[一般性的临时卷](https://kubernetes.io/zh-cn/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) * 使用 [CSI 临时卷](https://kubernetes.io/zh-cn/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) ， 前提是驱动支持这种用法 存储管理员可以使用以下字段来配置 CSI 持久卷： * `driver`：指定要使用的卷驱动名称的字符串值。 这个值必须与 CSI 驱动程序在 `GetPluginInfoResponse` 中返回的值相对应；该接口定义在 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo) 中。 Kubernetes 使用所给的值来标识要调用的 CSI 驱动程序；CSI 驱动程序也使用该值来辨识哪些 PV 对象属于该 CSI 驱动程序。 * `volumeHandle`：唯一标识卷的字符串值。 该值必须与 CSI 驱动在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应；接口定义在 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中。 在所有对 CSI 卷驱动程序的调用中，引用该 CSI 卷时都使用此值作为 `volume_id` 参数。 * `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置该卷为只读。默认值是 `false`。 该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动。 * `fsType`：如果 PV 的 `VolumeMode` 为 `Filesystem`，那么此字段指定挂载卷时应该使用的文件系统。 如果卷尚未格式化，并且支持格式化，此值将用于格式化卷。 此值可以通过 `ControllerPublishVolumeRequest`、`NodeStageVolumeRequest` 和 `NodePublishVolumeRequest` 的 `VolumeCapability` 字段传递给 CSI 驱动。 * `volumeAttributes`：一个字符串到字符串的映射表，用来设置卷的静态属性。 该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes` 字段的映射相对应； [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。 该映射通过 `ControllerPublishVolumeRequest`、`NodeStageVolumeRequest` 和 `NodePublishVolumeRequest` 中的 `volume_context` 字段传递给 CSI 驱动。 * `controllerPublishSecretRef`：对包含敏感信息的 Secret 对象的引用； 该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 `ControllerUnpublishVolume` 调用。 此字段是可选的；在不需要 Secret 时可以是空的。 如果 Secret 包含多个 Secret 条目，则所有的 Secret 条目都会被传递。 * `nodeExpandSecretRef`：对包含敏感信息的 Secret 对象的引用， 该信息会传递给 CSI 驱动以完成 CSI `NodeExpandVolume` 调用。 此字段是可选的，如果不需要 Secret，则可能是空的。 如果 Secret 包含多个 Secret 条目，则传递所有 Secret 条目。 当你为节点初始化的卷扩展配置 Secret 数据时，kubelet 会通过 `NodeExpandVolume()` 调用将该数据传递给 CSI 驱动。所有受支持的 Kubernetes 版本都提供 `nodeExpandSecretRef` 字段， 并且默认可用。Kubernetes v1.25 之前的版本不包括此支持。 为每个 kube-apiserver 和每个节点上的 kubelet 启用名为 `CSINodeExpandSecret` 的[特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates-removed/) 。 自 Kubernetes 1.27 版本起，此特性已默认启用，无需显式启用特性门控。 在节点初始化的存储大小调整操作期间，你还必须使用支持或需要 Secret 数据的 CSI 驱动。 * `nodePublishSecretRef`：对包含敏感信息的 Secret 对象的引用。 该信息传递给 CSI 驱动来完成 CSI `NodePublishVolume` 调用。 此字段是可选的，如果不需要 Secret，则可能是空的。 如果 Secret 对象包含多个 Secret 条目，则传递所有 Secret 条目。 * `nodeStageSecretRef`：对包含敏感信息的 Secret 对象的引用， 该信息会传递给 CSI 驱动以完成 CSI `NodeStageVolume` 调用。 此字段是可选的，如果不需要 Secret，则可能是空的。 如果 Secret 包含多个 Secret 条目，则传递所有 Secret 条目。 #### CSI 原始块卷支持 特性状态： `Kubernetes v1.18 [stable]` 具有外部 CSI 驱动程序的供应商能够在 Kubernetes 工作负载中实现原始块卷支持。 你可以和以前一样， 安装自己的[带有原始块卷支持的 PV/PVC](https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) ， 采用 CSI 对此过程没有影响。 #### CSI 临时卷 特性状态： `Kubernetes v1.25 [stable]` 你可以直接在 Pod 规约中配置 CSI 卷。采用这种方式配置的卷都是临时卷， 无法在 Pod 重新启动后继续存在。 进一步的信息可参阅[临时卷](https://kubernetes.io/zh-cn/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) 。 有关如何开发 CSI 驱动的更多信息，请参考 [kubernetes-csi 文档](https://kubernetes-csi.github.io/docs/) 。 #### Windows CSI 代理 特性状态： `Kubernetes v1.22 [stable]` CSI 节点插件需要执行多种特权操作，例如扫描磁盘设备和挂载文件系统等。 这些操作在每个宿主机操作系统上都是不同的。对于 Linux 工作节点而言，容器化的 CSI 节点插件通常部署为特权容器。对于 Windows 工作节点而言，容器化 CSI 节点插件的特权操作是通过 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy) 来支持的。csi-proxy 是一个由社区管理的、独立的可执行二进制文件， 需要被预安装到每个 Windows 节点上。 要了解更多的细节，可以参考你要部署的 CSI 插件的部署指南。 #### 从树内插件迁移到 CSI 驱动程序 特性状态： `Kubernetes v1.25 [stable]` `CSIMigration` 特性针对现有树内插件的操作会被定向到相应的 CSI 插件（应已安装和配置）。 因此，操作员在过渡到取代树内插件的 CSI 驱动时，无需对现有存储类、PV 或 PVC（指树内插件）进行任何配置更改。 #### 说明： 即使你针对这种卷完成了 CSI 迁移且你升级到不再内置对这种存储类别的支持的 Kubernetes 版本， 现有的由树内卷插件所创建的 PV 在未来无需进行任何配置更改就可以使用， 作为迁移的一部分，你或其他集群管理员**必须**安装和配置适用于该存储的 CSI 驱动。 Kubernetes 不会为你安装该软件。 * * * 在完成迁移之后，你也可以定义新的 PVC 和 PV，引用原来的、内置的集成存储。 只要你安装并配置了适当的 CSI 驱动，即使是全新的卷，PV 的创建仍然可以继续工作。 实际的存储管理现在通过 CSI 驱动来进行。 所支持的操作和特性包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、 挂载（Mount）/卸载（Unmount）和调整卷大小。 上面的[卷类型](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#volume-types) 节列出了支持 `CSIMigration` 并已实现相应 CSI 驱动程序的树内插件。 ### flexVolume（已弃用） 特性状态： `Kubernetes v1.23 [deprecated]` FlexVolume 是一个使用基于 exec 的模型来与驱动程序对接的树外插件接口。 用户必须在每个节点上的预定义卷插件路径中安装 FlexVolume 驱动程序可执行文件，在某些情况下，控制平面节点中也要安装。 Pod 通过 `flexvolume` 树内插件与 FlexVolume 驱动程序交互。 下面的 FlexVolume [插件](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) 以 PowerShell 脚本的形式部署在宿主机系统上，支持 Windows 节点： * [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) * [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) #### 说明： FlexVolume 已被弃用。推荐使用树外 CSI 驱动来将外部存储整合进 Kubernetes。 FlexVolume 驱动的维护者应开发一个 CSI 驱动并帮助用户从 FlexVolume 驱动迁移到 CSI。 FlexVolume 用户应迁移工作负载以使用对等的 CSI 驱动。 挂载卷的传播 ------ #### 注意： 挂载卷的传播是一项底层功能，不能在所有类型的卷中以一致的方式工作。 建议只在 `hostPath` 或基于内存的 `emptyDir` 卷中使用。 详情请参考[讨论](https://github.com/kubernetes/kubernetes/issues/95049) 。 挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器，甚至共享到同一节点上的其他 Pod。 卷的挂载传播特性由 `containers[*].volumeMounts` 中的 `mountPropagation` 字段控制， 它的值包括： * `None` - 此卷挂载将不会感知到主机后续在此卷或其任何子目录上执行的挂载变化。 类似的，容器所创建的卷挂载在主机上是不可见的。这是默认模式。 该模式等同于 [`mount(8)`](https://man7.org/linux/man-pages/man8/mount.8.html) 中描述的 `rprivate` 挂载传播选项。 然而，当 `rprivate` 传播选项不适用时，CRI 运行时可以转为选择 `rslave` 挂载传播选项 （即 `HostToContainer`）。当挂载源包含 Docker 守护进程的根目录（`/var/lib/docker`）时， cri-dockerd（Docker）已知可以选择 `rslave` 挂载传播选项。 * `HostToContainer` - 此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。 换句话说，如果主机在此挂载卷中挂载任何内容，容器将能看到它被挂载在那里。 类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容，挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。 该模式等同于 [`mount(8)`](https://man7.org/linux/man-pages/man8/mount.8.html) 中描述的 `rslave` 挂载传播选项。 * `Bidirectional` - 这种卷挂载和 `HostToContainer` 挂载表现相同。 另外，容器创建的卷挂载将被传播回至主机和使用同一卷的所有 Pod 的所有容器。 该模式的典型用例是带有 FlexVolume 或 CSI 驱动的 Pod，或者需要通过 `hostPath` 卷在主机上挂载某些东西的 Pod。 该模式等同于 [`mount(8)`](https://man7.org/linux/man-pages/man8/mount.8.html) 中描述的 `rshared` 挂载传播选项。 #### 警告： `Bidirectional` 形式的挂载传播可能比较危险。 它可以破坏主机操作系统，因此它只被允许在特权容器中使用。 强烈建议你熟悉 Linux 内核行为。 此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。 只读挂载 ---- 通过将 `.spec.containers[*].volumeMounts[*].readOnly` 字段设置为 `true` 可以使挂载只读。 这不会使卷本身只读，但该容器将无法写入此卷。 Pod 中的其他容器可以以读写方式挂载同一个卷。 在 Linux 上，只读挂载默认不会以递归方式只读。 假如有一个 Pod 将主机的 `/mnt` 挂载为 `hostPath` 卷。 如果在 `/mnt/` 上有另一个以读写方式挂载的文件系统（如 tmpfs、NFS 或 USB 存储）， 即使挂载本身被指定为只读，挂载到容器中的卷 `/mnt/` 也是可写的。 ### 递归只读挂载 特性状态： `Kubernetes v1.33 [stable]`（默认启用） 通过为 kubelet 和 kube-apiserver 设置 `RecursiveReadOnlyMounts` [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) ， 并为 Pod 设置 `.spec.containers[*].volumeMounts[*].recursiveReadOnly` 字段， 递归只读挂载可以被启用。 允许的值为： * `Disabled`（默认）：无效果。 * `Enabled`：使挂载递归只读。需要满足以下所有要求： * `readOnly` 设置为 `true` * `mountPropagation` 不设置，或设置为 `None` * 主机运行 Linux 内核 v5.12 或更高版本 * [CRI 级别](https://kubernetes.io/zh-cn/docs/concepts/architecture/cri) 的容器运行时支持递归只读挂载 * OCI 级别的容器运行时支持递归只读挂载 如果其中任何一个不满足，递归只读挂载将会失败。 * `IfPossible`：尝试应用 `Enabled`，如果内核或运行时类不支持该特性，则回退为 `Disabled`。 示例： [`storage/rro.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/storage/rro.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 storage/rro.yaml 到剪贴板") apiVersion: v1 kind: Pod metadata: name: rro spec: volumes: - name: mnt hostPath: # tmpfs 被挂载到 /mnt/tmpfs 上 path: /mnt containers: - name: busybox image: busybox args: ["sleep", "infinity"] volumeMounts: # /mnt-rro/tmpfs 不可写入 - name: mnt mountPath: /mnt-rro readOnly: true mountPropagation: None recursiveReadOnly: Enabled # /mnt-ro/tmpfs 可写入 - name: mnt mountPath: /mnt-ro readOnly: true # /mnt-rw/tmpfs 可写入 - name: mnt mountPath: /mnt-rw 当此属性被 kubelet 和 kube-apiserver 识别到时， `.status.containerStatuses[*].volumeMounts[*].recursiveReadOnly` 字段将被设置为 `Enabled` 或 `Disabled`。 #### 实现 **说明：** 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) ，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读[内容指南](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) 。 以下容器运行时已知支持递归只读挂载。 CRI 级别： * [containerd](https://containerd.io/) ，自 v2.0 起 * [CRI-O](https://cri-o.io/) ，自 v1.30 起 OCI 级别： * [runc](https://runc.io/) ，自 v1.1 起 * [crun](https://github.com/containers/crun) ，自 v1.8.6 起 接下来 --- 参考[使用持久卷部署 WordPress 和 MySQL](https://kubernetes.io/zh-cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 February 17, 2026 at 5:40 PM PST: [\[zh-cn\]sync volumes (7e814d17d3)](https://github.com/kubernetes/website/commit/7e814d17d33ab9719a05b6c91b393c9f7daedd49) 本页面中的条目引用了第三方产品或项目，这些产品（项目）提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品（项目）负责。请参阅[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) 了解更多细节。 在提交更改建议，向本页添加新的第三方链接之前，你应该先阅读[内容指南。](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) --- # Referencia | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Reference](https://kubernetes.io/docs/reference/) Referencia ========== Esta sección de la documentación de Kubernetes contiene información de referencia. Información de referencia sobre la API -------------------------------------- * [Descripción general de la API de Kubernetes](https://kubernetes.io/docs/reference/using-api/api-overview/) * Documentación de referencia de las últimas versiones de la API de Kubernetes: * [1.14](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/) * [1.13](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/) * [1.12](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.12/) * [1.11](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/) * [1.10](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/) Librerías de cliente para la API -------------------------------- Para llamar a la API de Kubernetes desde un lenguaje de programación, puedes usar [librerías de cliente](https://kubernetes.io/docs/reference/using-api/client-libraries/) . En estos momento, las librerías con soporte oficial son: * [Kubernetes Go client library](https://github.com/kubernetes/client-go/) * [Kubernetes Python client library](https://github.com/kubernetes-client/python) * [Kubernetes Java client library](https://github.com/kubernetes-client/java) * [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) Información de referencia sobre la CLI -------------------------------------- * [kubectl](https://kubernetes.io/docs/user-guide/kubectl-overview) - Utilidad CLI para ejecutar comandos y administrar clústeres de Kubernetes. * [JSONPath](https://kubernetes.io/docs/user-guide/jsonpath/) - Guía de sintaxis para el uso de [expresiones JSONPath](http://goessner.net/articles/JsonPath/) con kubectl. * [kubeadm](https://kubernetes.io/docs/admin/kubeadm/) - Utilidad CLI para aprovisionar fácilmente un clústeres Kubernetes seguro. * [kubefed](https://kubernetes.io/docs/admin/kubefed/) - Utilidad CLI para ayudarte a administrar tus clústeres federados. Información de referencia sobre la configuración ------------------------------------------------ * [kubelet](https://kubernetes.io/docs/admin/kubelet/) - El principal _agente_ que se ejecuta en cada nodo. El kubelet toma un conjunto de PodSpecs y asegura que los contenedores descritos estén funcionando y en buen estado. * [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver/) - API REST que valida y configura datos para objetos API como pods, servicios, controladores de replicación, ... * [kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager/) - Daemon que integra los bucles de control enviados con Kubernetes. * [kube-proxy](https://kubernetes.io/docs/admin/kube-proxy/) - Puede hacer fowarding simple o con round-robin de TCP/UDP a través de un conjunto de back-ends. * [kube-scheduler](https://kubernetes.io/docs/admin/kube-scheduler/) - Planificador que gestiona la disponibilidad, el rendimiento y la capacidad. * [federation-apiserver](https://kubernetes.io/docs/admin/federation-apiserver/) - Servidor API para clusters federados. * [federation-controller-manager](https://kubernetes.io/docs/admin/federation-controller-manager/) - Proceso que integra los bucles de control enviados con la federación Kubernetes. Documentos de diseño -------------------- Un archivo de los documentos de diseño para la funcionalidad de Kubernetes. Puedes empezar por [Arquitectura de Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) y [Vista general del diseño de Kubernetes](https://git.k8s.io/community/contributors/design-proposals) . * * * ##### [Glosario de términos](https://kubernetes.io/es/docs/reference/glossary/) ##### [kubectl CLI](https://kubernetes.io/es/docs/reference/kubectl/) ##### [Kubernetes API](https://kubernetes.io/es/docs/reference/kubernetes-api/) ##### [Utilizando la API de Kubernetes](https://kubernetes.io/es/docs/reference/using-api/) ##### [Accediendo a la API de Kubernetes](https://kubernetes.io/es/docs/reference/access-authn-authz/) ##### [Reportando problemas en Kubernetes](https://kubernetes.io/es/docs/reference/issues-security/) ##### [Herramientas de configuración](https://kubernetes.io/es/docs/reference/setup-tools/) ##### [Herramientas de línea de comandos](https://kubernetes.io/es/docs/reference/command-line-tools-reference/) ##### [Federation API](https://kubernetes.io/es/docs/reference/federation/) Comentarios ----------- ¿Esta página le ha sido de ayuda? Sí No Muchas gracias por el feedback. Si tienes alguna pregunta específica sobre como usar Kubernetes, puedes preguntar en [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Abre un issue en el repositorio de GitHub si quieres [reportar un problema](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) o [sugerir alguna mejora](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Última modificación July 17, 2022 at 8:13 PM PST: [\[es\] Fix links for k/design-proposals-archive (758650ae2f)](https://github.com/kubernetes/website/commit/758650ae2f367860d3e3501e4068aa2895dc044f) --- # Formación en línea | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/tutorials/online-training/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/tutorials/online-training/) . Formación en línea ================== --- # Kubernetes Vulnerability Announcements - CVE Feed Kubernetes Vulnerability Announcements - CVE Feedhttps://kubernetes.io/docs/reference/issues-security/official-cve-feed/Auto-refreshing official CVE feed for Kubernetes repositoryHugo -- gohugo.ioen-USThe Kubernetes AuthorsFri, 20 Mar 2026 12:45:52 +0000CVE-2026-4342https://github.com/kubernetes/kubernetes/issues/137893Thu, 19 Mar 2026 14:32:54 +0000https://www.cve.org/cverecord?id=CVE-2026-4342ingress-nginx comment-based nginx configuration injectionCVE-2026-3864https://github.com/kubernetes/kubernetes/issues/137797Tue, 17 Mar 2026 05:54:49 +0000https://www.cve.org/cverecord?id=CVE-2026-3864CSI Driver for NFS path traversal via subDir may delete unintended directories on the NFS serverCVE-2025-15566https://github.com/kubernetes/kubernetes/issues/136789Fri, 06 Feb 2026 02:54:24 +0000https://www.cve.org/cverecord?id=CVE-2025-15566ingress-nginx auth-proxy-set-headers nginx configuration injectionCVE-2026-24514https://github.com/kubernetes/kubernetes/issues/136680Mon, 02 Feb 2026 03:06:14 +0000https://www.cve.org/cverecord?id=CVE-2026-24514ingress-nginx Admission Controller denial of serviceCVE-2026-24513https://github.com/kubernetes/kubernetes/issues/136679Mon, 02 Feb 2026 03:06:04 +0000https://www.cve.org/cverecord?id=CVE-2026-24513ingress-nginx auth-url protection bypassCVE-2026-24512https://github.com/kubernetes/kubernetes/issues/136678Mon, 02 Feb 2026 03:05:54 +0000https://www.cve.org/cverecord?id=CVE-2026-24512ingress-nginx rules.http.paths.path nginx configuration injectionCVE-2026-1580https://github.com/kubernetes/kubernetes/issues/136677Mon, 02 Feb 2026 03:05:43 +0000https://www.cve.org/cverecord?id=CVE-2026-1580ingress-nginx auth-method nginx configuration injectionCVE-2025-14269https://github.com/kubernetes/kubernetes/issues/135798Wed, 17 Dec 2025 19:23:10 +0000https://www.cve.org/cverecord?id=CVE-2025-14269Credential caching in Headlamp with Helm enabledCVE-2025-13281https://github.com/kubernetes/kubernetes/issues/135525Sun, 30 Nov 2025 23:08:37 +0000https://www.cve.org/cverecord?id=CVE-2025-13281Portworx Half-Blind SSRF in kube-controller-managerCVE-2025-9708https://github.com/kubernetes/kubernetes/issues/134063Mon, 15 Sep 2025 04:59:12 +0000https://www.cve.org/cverecord?id=CVE-2025-9708Kubernetes C# Client: improper certificate validation in custom CA mode may lead to man-in-the-middle attacksCVE-2025-7445https://github.com/kubernetes/kubernetes/issues/133897Thu, 04 Sep 2025 21:40:42 +0000https://www.cve.org/cverecord?id=CVE-2025-7445secrets-store-sync-controller discloses service account tokens in logsCVE-2025-5187https://github.com/kubernetes/kubernetes/issues/133471Mon, 11 Aug 2025 16:29:36 +0000https://www.cve.org/cverecord?id=CVE-2025-5187Nodes can delete themselves by adding an OwnerReferenceCVE-2025-7342https://github.com/kubernetes/kubernetes/issues/133115Mon, 21 Jul 2025 23:22:19 +0000https://www.cve.org/cverecord?id=CVE-2025-7342VM images built with Kubernetes Image Builder Nutanix or OVA providers use default credentials for Windows images if user did not overrideCVE-2025-4563https://github.com/kubernetes/kubernetes/issues/132151Fri, 06 Jun 2025 15:48:26 +0000https://www.cve.org/cverecord?id=CVE-2025-4563Nodes can bypass dynamic resource allocation authorization checksCVE-2025-1974https://github.com/kubernetes/kubernetes/issues/131009Sun, 23 Mar 2025 17:38:57 +0000https://www.cve.org/cverecord?id=CVE-2025-1974ingress-nginx admission controller RCE escalationCVE-2025-1098https://github.com/kubernetes/kubernetes/issues/131008Sun, 23 Mar 2025 17:38:53 +0000https://www.cve.org/cverecord?id=CVE-2025-1098ingress-nginx controller configuration injection via unsanitized mirror annotationsCVE-2025-1097https://github.com/kubernetes/kubernetes/issues/131007Sun, 23 Mar 2025 17:38:49 +0000https://www.cve.org/cverecord?id=CVE-2025-1097ingress-nginx controller configuration injection via unsanitized auth-tls-match-cn annotationCVE-2025-24514https://github.com/kubernetes/kubernetes/issues/131006Sun, 23 Mar 2025 17:38:44 +0000https://www.cve.org/cverecord?id=CVE-2025-24514ingress-nginx controller configuration injection via unsanitized auth-url annotationCVE-2025-24513https://github.com/kubernetes/kubernetes/issues/131005Sun, 23 Mar 2025 17:38:28 +0000https://www.cve.org/cverecord?id=CVE-2025-24513ingress-nginx controller auth secret file path traversal vulnerabilityCVE-2025-1767https://github.com/kubernetes/kubernetes/issues/130786Thu, 13 Mar 2025 16:08:20 +0000https://www.cve.org/cverecord?id=CVE-2025-1767GitRepo Volume Inadvertent Local Repository AccessCVE-2025-0426https://github.com/kubernetes/kubernetes/issues/130016Thu, 06 Feb 2025 20:03:44 +0000https://www.cve.org/cverecord?id=CVE-2025-0426Node Denial of Service via kubelet Checkpoint APICVE-2024-9042https://github.com/kubernetes/kubernetes/issues/129654Wed, 15 Jan 2025 22:28:29 +0000https://www.cve.org/cverecord?id=CVE-2024-9042Command Injection affecting Windows nodes via nodes/\*/logs/query APICVE-2024-10220https://github.com/kubernetes/kubernetes/issues/128885Wed, 20 Nov 2024 15:30:44 +0000https://www.cve.org/cverecord?id=CVE-2024-10220Arbitrary command execution through gitRepo volumeCVE-2024-9594https://github.com/kubernetes/kubernetes/issues/128007Fri, 11 Oct 2024 18:04:50 +0000https://www.cve.org/cverecord?id=CVE-2024-9594VM images built with Image Builder with some providers use default credentials during buildsCVE-2024-9486https://github.com/kubernetes/kubernetes/issues/128006Fri, 11 Oct 2024 18:04:31 +0000https://www.cve.org/cverecord?id=CVE-2024-9486VM images built with Image Builder and Proxmox provider use default credentialsCVE-2024-7646https://github.com/kubernetes/kubernetes/issues/126744Fri, 16 Aug 2024 16:10:31 +0000https://www.cve.org/cverecord?id=CVE-2024-7646Ingress-nginx Annotation Validation BypassCVE-2024-7598https://github.com/kubernetes/kubernetes/issues/126587Wed, 07 Aug 2024 21:30:11 +0000https://www.cve.org/cverecord?id=CVE-2024-7598Network restriction bypass via race condition during namespace terminationCVE-2024-5321https://github.com/kubernetes/kubernetes/issues/126161Wed, 17 Jul 2024 13:06:48 +0000https://www.cve.org/cverecord?id=CVE-2024-5321Incorrect permissions on Windows containers logsCVE-2024-3744https://github.com/kubernetes/kubernetes/issues/124759Wed, 08 May 2024 16:02:57 +0000https://www.cve.org/cverecord?id=CVE-2024-3744azure-file-csi-driver discloses service account tokens in logsCVE-2024-3177https://github.com/kubernetes/kubernetes/issues/124336Tue, 16 Apr 2024 14:04:09 +0000https://www.cve.org/cverecord?id=CVE-2024-3177Bypassing mountable secrets policy imposed by the ServiceAccount admission pluginCVE-2023-5528https://github.com/kubernetes/kubernetes/issues/121879Tue, 14 Nov 2023 15:54:16 +0000https://www.cve.org/cverecord?id=CVE-2023-5528Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodesCVE-2023-5044https://github.com/kubernetes/kubernetes/issues/126817Wed, 25 Oct 2023 15:48:28 +0000https://www.cve.org/cverecord?id=CVE-2023-5044Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotationCVE-2023-5043https://github.com/kubernetes/kubernetes/issues/126816Wed, 25 Oct 2023 15:48:20 +0000https://www.cve.org/cverecord?id=CVE-2023-5043Ingress nginx annotation injection causes arbitrary command executionCVE-2022-4886https://github.com/kubernetes/kubernetes/issues/126815Wed, 25 Oct 2023 15:48:08 +0000https://www.cve.org/cverecord?id=CVE-2022-4886ingress-nginx path sanitization can be bypassedCVE-2023-3955https://github.com/kubernetes/kubernetes/issues/119595Wed, 26 Jul 2023 15:30:50 +0000https://www.cve.org/cverecord?id=CVE-2023-3955Insufficient input sanitization on Windows nodes leads to privilege escalationCVE-2023-3893https://github.com/kubernetes/kubernetes/issues/119594Wed, 26 Jul 2023 15:30:26 +0000https://www.cve.org/cverecord?id=CVE-2023-3893Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalationCVE-2023-3676https://github.com/kubernetes/kubernetes/issues/119339Fri, 14 Jul 2023 18:27:48 +0000https://www.cve.org/cverecord?id=CVE-2023-3676Insufficient input sanitization on Windows nodes leads to privilege escalationCVE-2023-2431https://github.com/kubernetes/kubernetes/issues/118690Thu, 15 Jun 2023 14:42:32 +0000https://www.cve.org/cverecord?id=CVE-2023-2431Bypass of seccomp profile enforcementCVE-2023-2728https://github.com/kubernetes/kubernetes/issues/118640Tue, 13 Jun 2023 14:42:06 +0000https://www.cve.org/cverecord?id=CVE-2023-2728Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission pluginCVE-2023-2727https://github.com/kubernetes/kubernetes/issues/118640Tue, 13 Jun 2023 14:42:06 +0000https://www.cve.org/cverecord?id=CVE-2023-2727Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission pluginCVE-2023-2878https://github.com/kubernetes/kubernetes/issues/118419Fri, 02 Jun 2023 19:03:54 +0000https://www.cve.org/cverecord?id=CVE-2023-2878secrets-store-csi-driver discloses service account tokens in logsCVE-2022-3294https://github.com/kubernetes/kubernetes/issues/113757Tue, 08 Nov 2022 21:33:26 +0000https://www.cve.org/cverecord?id=CVE-2022-3294Node address isn't always verified when proxyingCVE-2022-3162https://github.com/kubernetes/kubernetes/issues/113756Tue, 08 Nov 2022 21:33:07 +0000https://www.cve.org/cverecord?id=CVE-2022-3162Unauthorized read of Custom ResourcesCVE-2022-3172https://github.com/kubernetes/kubernetes/issues/112513Fri, 16 Sep 2022 13:14:50 +0000https://www.cve.org/cverecord?id=CVE-2022-3172Aggregated API server can cause clients to be redirected (SSRF)CVE-2021-25749https://github.com/kubernetes/kubernetes/issues/112192Thu, 01 Sep 2022 21:02:01 +0000https://www.cve.org/cverecord?id=CVE-2021-25749\`runAsNonRoot\` logic bypass for Windows containersCVE-2021-25748https://github.com/kubernetes/kubernetes/issues/126814Fri, 10 Jun 2022 16:01:41 +0000https://www.cve.org/cverecord?id=CVE-2021-25748Ingress-nginx \`path\` sanitization can be bypassed with newline characterCVE-2021-25746https://github.com/kubernetes/kubernetes/issues/126813Fri, 22 Apr 2022 16:18:27 +0000https://www.cve.org/cverecord?id=CVE-2021-25746Ingress-nginx directive injection via annotationsCVE-2021-25745https://github.com/kubernetes/kubernetes/issues/126812Fri, 22 Apr 2022 16:18:21 +0000https://www.cve.org/cverecord?id=CVE-2021-25745Ingress-nginx \`path\` can be pointed to service account token fileCVE-2021-25742https://github.com/kubernetes/kubernetes/issues/126811Thu, 21 Oct 2021 16:08:21 +0000https://www.cve.org/cverecord?id=CVE-2021-25742Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespacesCVE-2021-25741https://github.com/kubernetes/kubernetes/issues/104980Mon, 13 Sep 2021 20:58:56 +0000https://www.cve.org/cverecord?id=CVE-2021-25741Symlink Exchange Can Allow Host Filesystem AccessCVE-2020-8561https://github.com/kubernetes/kubernetes/issues/104720Wed, 01 Sep 2021 20:18:50 +0000https://www.cve.org/cverecord?id=CVE-2020-8561Webhook redirect in kube-apiserverCVE-2021-25740https://github.com/kubernetes/kubernetes/issues/103675Wed, 14 Jul 2021 03:30:07 +0000https://www.cve.org/cverecord?id=CVE-2021-25740Endpoint & EndpointSlice permissions allow cross-Namespace forwardingCVE-2021-25737https://github.com/kubernetes/kubernetes/issues/102106Tue, 18 May 2021 19:14:27 +0000https://www.cve.org/cverecord?id=CVE-2021-25737Holes in EndpointSlice Validation Enable Host Network HijackCVE-2020-8562https://github.com/kubernetes/kubernetes/issues/101493Mon, 26 Apr 2021 19:18:04 +0000https://www.cve.org/cverecord?id=CVE-2020-8562Bypass of Kubernetes API Server proxy TOCTOUCVE-2021-3121https://github.com/kubernetes/kubernetes/issues/101435Fri, 23 Apr 2021 18:07:32 +0000https://www.cve.org/cverecord?id=CVE-2021-3121Processes may panic upon receipt of malicious protobuf messagesCVE-2021-25735https://github.com/kubernetes/kubernetes/issues/100096Wed, 10 Mar 2021 18:18:01 +0000https://www.cve.org/cverecord?id=CVE-2021-25735Validating Admission Webhook does not observe some previous fieldsCVE-2020-8554https://github.com/kubernetes/kubernetes/issues/97076Fri, 04 Dec 2020 20:02:15 +0000https://www.cve.org/cverecord?id=CVE-2020-8554Man in the middle using LoadBalancer or ExternalIPsCVE-2020-8566https://github.com/kubernetes/kubernetes/issues/95624Thu, 15 Oct 2020 22:07:53 +0000https://www.cve.org/cverecord?id=CVE-2020-8566Ceph RBD adminSecrets exposed in logs when loglevel >= 4CVE-2020-8565https://github.com/kubernetes/kubernetes/issues/95623Thu, 15 Oct 2020 22:05:32 +0000https://www.cve.org/cverecord?id=CVE-2020-8565Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9CVE-2020-8564https://github.com/kubernetes/kubernetes/issues/95622Thu, 15 Oct 2020 22:03:19 +0000https://www.cve.org/cverecord?id=CVE-2020-8564Docker config secrets leaked when file is malformed and log level >= 4CVE-2020-8563https://github.com/kubernetes/kubernetes/issues/95621Thu, 15 Oct 2020 22:00:44 +0000https://www.cve.org/cverecord?id=CVE-2020-8563Secret leaks in kube-controller-manager when using vSphere providerCVE-2020-8557https://github.com/kubernetes/kubernetes/issues/93032Mon, 13 Jul 2020 18:39:08 +0000https://www.cve.org/cverecord?id=CVE-2020-8557Node disk DOS by writing to container /etc/hostsCVE-2020-8559https://github.com/kubernetes/kubernetes/issues/92914Wed, 08 Jul 2020 17:03:16 +0000https://www.cve.org/cverecord?id=CVE-2020-8559Privilege escalation from compromised node to clusterCVE-2020-8558https://github.com/kubernetes/kubernetes/issues/92315Fri, 19 Jun 2020 18:38:58 +0000https://www.cve.org/cverecord?id=CVE-2020-8558Node setting allows for neighboring hosts to bypass localhost boundaryCVE-2020-8555https://github.com/kubernetes/kubernetes/issues/91542Thu, 28 May 2020 16:13:34 +0000https://www.cve.org/cverecord?id=CVE-2020-8555Half-Blind SSRF in kube-controller-managerCVE-2020-10749https://github.com/kubernetes/kubernetes/issues/91507Wed, 27 May 2020 19:32:29 +0000https://www.cve.org/cverecord?id=CVE-2020-10749IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisementsCVE-2019-11254https://github.com/kubernetes/kubernetes/issues/89535Thu, 26 Mar 2020 18:55:26 +0000https://www.cve.org/cverecord?id=CVE-2019-11254kube-apiserver Denial of Service vulnerability from malicious YAML payloadsCVE-2020-8552https://github.com/kubernetes/kubernetes/issues/89378Mon, 23 Mar 2020 18:35:34 +0000https://www.cve.org/cverecord?id=CVE-2020-8552apiserver DoS (oom)CVE-2020-8551https://github.com/kubernetes/kubernetes/issues/89377Mon, 23 Mar 2020 18:34:40 +0000https://www.cve.org/cverecord?id=CVE-2020-8551Kubelet DoS via APICVE-2020-8553https://github.com/kubernetes/kubernetes/issues/126818Wed, 19 Feb 2020 19:00:32 +0000https://www.cve.org/cverecord?id=CVE-2020-8553ingress-nginx auth-type basic annotation vulnerabilityCVE-2019-11251https://github.com/kubernetes/kubernetes/issues/87773Mon, 03 Feb 2020 15:12:22 +0000https://www.cve.org/cverecord?id=CVE-2019-11251kubectl cp symlink vulnerabilityCVE-2018-1002102https://github.com/kubernetes/kubernetes/issues/85867Tue, 03 Dec 2019 22:58:37 +0000https://www.cve.org/cverecord?id=CVE-2018-1002102Unvalidated redirectCVE-2019-11255https://github.com/kubernetes/kubernetes/issues/85233Wed, 13 Nov 2019 20:57:31 +0000https://www.cve.org/cverecord?id=CVE-2019-11255CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutationCVE-2019-11253https://github.com/kubernetes/kubernetes/issues/83253Fri, 27 Sep 2019 16:53:31 +0000https://www.cve.org/cverecord?id=CVE-2019-11253Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attackCVE-2019-11250https://github.com/kubernetes/kubernetes/issues/81114Thu, 08 Aug 2019 02:03:04 +0000https://www.cve.org/cverecord?id=CVE-2019-11250Bearer tokens are revealed in logs (audit finding TOB-K8S-001)CVE-2019-11248https://github.com/kubernetes/kubernetes/issues/81023Tue, 06 Aug 2019 14:34:33 +0000https://www.cve.org/cverecord?id=CVE-2019-11248/debug/pprof exposed on kubelet's healthz portCVE-2019-11249https://github.com/kubernetes/kubernetes/issues/80984Mon, 05 Aug 2019 12:44:23 +0000https://www.cve.org/cverecord?id=CVE-2019-11249Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversalCVE-2019-11247https://github.com/kubernetes/kubernetes/issues/80983Mon, 05 Aug 2019 12:44:08 +0000https://www.cve.org/cverecord?id=CVE-2019-11247API server allows access to custom resources via wrong scopeCVE-2019-11245https://github.com/kubernetes/kubernetes/issues/78308Fri, 24 May 2019 16:14:49 +0000https://www.cve.org/cverecord?id=CVE-2019-11245container uid changes to root after first restart or if image is already pulled to the nodeCVE-2019-11243https://github.com/kubernetes/kubernetes/issues/76797Thu, 18 Apr 2019 21:31:53 +0000https://www.cve.org/cverecord?id=CVE-2019-11243rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig()CVE-2019-11244https://github.com/kubernetes/kubernetes/issues/76676Tue, 16 Apr 2019 20:14:25 +0000https://www.cve.org/cverecord?id=CVE-2019-11244\`kubectl --http-cache=<world-accessible dir>\` creates world-writeable cached schema filesCVE-2019-1002100https://github.com/kubernetes/kubernetes/issues/74534Mon, 25 Feb 2019 19:39:09 +0000https://www.cve.org/cverecord?id=CVE-2019-1002100json-patch requests can exhaust apiserver resourcesCVE-2018-1002105https://github.com/kubernetes/kubernetes/issues/71411Mon, 26 Nov 2018 11:07:36 +0000https://www.cve.org/cverecord?id=CVE-2018-1002105proxy request handling in kube-apiserver can leave vulnerable TCP connectionsCVE-2018-1002101https://github.com/kubernetes/kubernetes/issues/65750Tue, 03 Jul 2018 08:06:15 +0000https://www.cve.org/cverecord?id=CVE-2018-1002101smb mount security issueCVE-2018-1002100https://github.com/kubernetes/kubernetes/issues/61297Fri, 16 Mar 2018 19:24:46 +0000https://www.cve.org/cverecord?id=CVE-2018-1002100Kubectl copy doesn't check for paths outside of it's destination directory.CVE-2017-1002102https://github.com/kubernetes/kubernetes/issues/60814Mon, 05 Mar 2018 20:55:20 +0000https://www.cve.org/cverecord?id=CVE-2017-1002102atomic writer volume handling allows arbitrary file deletion in host filesystemCVE-2017-1002101https://github.com/kubernetes/kubernetes/issues/60813Mon, 05 Mar 2018 20:53:58 +0000https://www.cve.org/cverecord?id=CVE-2017-1002101subpath volume mount handling allows arbitrary file access in host filesystemCVE-2017-1002100https://github.com/kubernetes/kubernetes/issues/47611Thu, 15 Jun 2017 18:59:13 +0000https://www.cve.org/cverecord?id=CVE-2017-1002100Azure PV should be Private scope not Container scopeCVE-2017-1000056https://github.com/kubernetes/kubernetes/issues/43459Tue, 21 Mar 2017 15:22:29 +0000https://www.cve.org/cverecord?id=CVE-2017-1000056PodSecurityPolicy admission plugin authorizes incorrectly --- # 外部 API | Kubernetes 这是本节的多页打印视图。 [点击此处打印](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#) . [返回本页常规视图](https://kubernetes.io/zh-cn/docs/reference/external-api/) . 外部 API ====== * 1: [Kubernetes 外部指标 (v1beta1)](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#pg-a241970449621c942f37d58d1e3cc348) * 2: [Kubernetes 指标 (v1beta1)](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#pg-9979560e9d76a835617d8d8e775f58fb) * 3: [Kubernetes 自定义指标 (v1beta2)](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#pg-f1c8b4f958fda36c18b6c443756e3292) 1 - Kubernetes 外部指标 (v1beta1) ============================= v1beta1 包是 v1beta1 版本的外部指标 API。 资源类型 ---- * [ExternalMetricValue](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#external-metrics-k8s-io-v1beta1-ExternalMetricValue) * [ExternalMetricValueList](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#external-metrics-k8s-io-v1beta1-ExternalMetricValueList) `ExternalMetricValue` --------------------- **出现在：** * [ExternalMetricValueList](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#external-metrics-k8s-io-v1beta1-ExternalMetricValueList) ExternalMetricValue 是外部指标的一个度量值。 单个度量值由指标名称和一组字符串标签标识。 对于一个指标，可以有多个具有不同标签集的值。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `external.metrics.k8s.io/v1beta1` | | `kind`
string | `ExternalMetricValue` | | `metricName` **\[必需\]**
`string` | 指标的名称。 | | `metricLabels` **\[必需\]**
`map[string]string` | 用于标识指标的单个时间序列的标签集。 | | `timestamp` **\[必需\]**
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#time-v1-meta) | 标明这些度量值生成的时间。 | | `window` **\[必需\]**
`int64` | 当返回根据累积度量计算的速率度量值时，此字段标明计算这些度量值的时间窗口 （\[Timestamp-Window, Timestamp\]）（或对于非计算的瞬时度量值为零）。 | | `value` **\[必需\]**
[`k8s.io/apimachinery/pkg/api/resource.Quantity`](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity) | 度量值。 | `ExternalMetricValueList` ------------------------- ExternalMetricValueList 是某个给定指标的某些标签集的数值列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `external.metrics.k8s.io/v1beta1` | | `kind`
string | `ExternalMetricValueList` | | `metadata` **\[必需\]**
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#listmeta-v1-meta) | 无描述。 | | `items` **\[必需\]**
[`[]ExternalMetricValue`](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#external-metrics-k8s-io-v1beta1-ExternalMetricValue) | 与给定标签集匹配的度量值。 | 2 - Kubernetes 指标 (v1beta1) =========================== v1beta1 包是 v1beta1 版本的指标 API。 资源类型 ---- * [NodeMetrics](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-NodeMetrics) * [NodeMetricsList](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-NodeMetricsList) * [PodMetrics](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-PodMetrics) * [PodMetricsList](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-PodMetricsList) `NodeMetrics` ------------- **出现在：** * [NodeMetricsList](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-NodeMetricsList) NodeMetrics 设置节点的资源用量指标。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `metrics.k8s.io/v1beta1` | | `kind`
string | `NodeMetrics` | | `metadata`
[`meta/v1.ObjectMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#objectmeta-v1-meta) | 标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

参阅 Kubernetes API 文档了解 `metadata` 字段。 | | `timestamp` **\[必需\]**
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#time-v1-meta) | 以下字段定义从时间间隔 \[Timestamp-Window，Timestamp\] 中收集指标的时间间隔。 | | `window` **\[必需\]**
[`meta/v1.Duration`](https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration) | 无描述。 | | `usage` **\[必需\]**
[`core/v1.ResourceList`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcelist-v1-core) | 内存用量是内存工作集。 | `NodeMetricsList` ----------------- NodeMetricsList 是 NodeMetrics 的列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `metrics.k8s.io/v1beta1` | | `kind`
string | `NodeMetricsList` | | `metadata` **\[必需\]**
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#listmeta-v1-meta) | 标准的列表元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | `items` **\[必需\]**
[`[]NodeMetrics`](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-NodeMetrics) | 节点指标的列表。 | `PodMetrics` ------------ **出现在：** * [PodMetricsList](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-PodMetricsList) PodMetrics 设置 Pod 的资源用量指标。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `metrics.k8s.io/v1beta1` | | `kind`
string | `PodMetrics` | | `metadata`
[`meta/v1.ObjectMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#objectmeta-v1-meta) | 标准的对象元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

参阅 Kubernetes API 文档了解 `metadata` 字段。 | | `timestamp` **\[必需\]**
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#time-v1-meta) | 以下字段定义了从时间间隔 \[Timestamp-Window，Timestamp\] 中收集指标的时间间隔。 | | `window` **\[必需\]**
[`meta/v1.Duration`](https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration) | 无描述。 | | `containers` **\[必需\]**
[`[]ContainerMetrics`](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-ContainerMetrics) | 在相同时间窗口内收集所有容器的指标。 | `PodMetricsList` ---------------- PodMetricsList 是 PodMetrics 的列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `metrics.k8s.io/v1beta1` | | `kind`
string | `PodMetricsList` | | `metadata` **\[必需\]**
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#listmeta-v1-meta) | 标准的列表元数据。更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | `items` **\[必需\]**
[`[]PodMetrics`](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-PodMetrics) | Pod 指标的列表。 | `ContainerMetrics` ------------------ **出现在：** * [PodMetrics](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#metrics-k8s-io-v1beta1-PodMetrics) ContainerMetrics 设置容器的资源用量指标。 | 字段 | 描述 | | --- | --- | | `name` **\[必需\]**
`string` | 与 pod.spec.containers 中某个对应的容器名称。 | | `usage` **\[必需\]**
[`core/v1.ResourceList`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#resourcelist-v1-core) | 内存用量是内容工作集。 | 3 - Kubernetes 自定义指标 (v1beta2) ============================== v1beta2 包是 v1beta2 版本的 custom\_metrics API。 资源类型 ---- * [MetricListOptions](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#custom-metrics-k8s-io-v1beta2-MetricListOptions) * [MetricValue](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#custom-metrics-k8s-io-v1beta2-MetricValue) * [MetricValueList](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#custom-metrics-k8s-io-v1beta2-MetricValueList) `MetricListOptions` ------------------- MetricListOptions 用于按其标签选择算符来选择指标。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `custom.metrics.k8s.io/v1beta2` | | `kind`
string | `MetricListOptions` | | `labelSelector`
`string` | 这个选择算符通过标签来限制所返回对象的列表。 默认为任意值。 | | `metricLabelSelector`
`string` | 这个选择算符通过标签来限制所返回指标的列表。 | `MetricValue` ------------- **出现在：** * [MetricValueList](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#custom-metrics-k8s-io-v1beta2-MetricValueList) MetricValue 是某些对象的指标值。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `custom.metrics.k8s.io/v1beta2` | | `kind`
string | `MetricValue` | | `describedObject` **\[必需\]**
[`core/v1.ObjectReference`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#objectreference-v1-core) | 指向描述对象的引用。 | | `metric` **\[必需\]**
[`MetricIdentifier`](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#custom-metrics-k8s-io-v1beta2-MetricIdentifier) | 无描述。 | | `timestamp` **\[必需\]**
[`meta/v1.Time`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#time-v1-meta) | 标明度量值生成的时间。 | | `windowSeconds` **\[必需\]**
`int64` | 当返回根据累积度量计算的速率度量值时，此字段标明计算这些度量值的时间窗口 （\[Timestamp-Window, Timestamp\]）（或对于非计算的瞬时度量值为零）。 | | `value` **\[必需\]**
[`k8s.io/apimachinery/pkg/api/resource.Quantity`](https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#Quantity) | 度量值。 | `MetricValueList` ----------------- MetricValueList 是某个给定指标的某些对象集的数值列表。 | 字段 | 描述 | | --- | --- | | `apiVersion`
string | `custom.metrics.k8s.io/v1beta2` | | `kind`
string | `MetricValueList` | | `metadata` **\[必需\]**
[`meta/v1.ListMeta`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#listmeta-v1-meta) | 无描述。 | | `items` **\[必需\]**
[`[]MetricValue`](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#custom-metrics-k8s-io-v1beta2-MetricValue) | 所描述对象的度量值。 | `MetricIdentifier` ------------------ **出现在：** * [MetricValue](https://kubernetes.io/zh-cn/docs/reference/external-api/_print/#custom-metrics-k8s-io-v1beta2-MetricValue) MetricIdentifier 按名称和可选的选择算符来标识指标。 | 字段 | 描述 | | --- | --- | | `name` **\[必需\]**
`string` | name 是给定指标的名称。 | | `selector`
[`meta/v1.LabelSelector`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#labelselector-v1-meta) | selector 表示可用于选择此指标的标签选择算符，通常就是传递给查询用于获取此指标的选择算符。 当留空时，仅使用指标的 Name 来采集指标。 | --- # Gateway API | Kubernetes Gateway API =========== Gateway API merupakan bagian dari API yang menyediakan penyediaan infrastruktur dinamis dan pengaturan trafik lanjutan. Gateway API menyediakan layanan jaringan dengan menggunakan mekanisme konfigurasi yang mudah di-_extend_, berorientasi _role_, dan mengerti konsep protokol. [Gateway API](https://gateway-api.sigs.k8s.io/) adalah sebuah [add-on](https://kubernetes.io/id/docs/concepts/cluster-administration/addons/ "Resources that extend the functionality of Kubernetes.") yang berisi [jenis-jenis](https://gateway-api.sigs.k8s.io/references/spec/) API yang menyediakan penyediaan infrastruktur dinamis dan pengaturan trafik tingkat lanjut. Prinsip Desain -------------- Prinsip-prinsip berikut membentuk desain dan arsitektur Gateway API: * **Berorientasi _role_:** Gateway API dimodelkan sesuai dengan _role_ organisasi yang bertanggung jawab untuk mengelola jaringan layanan Kubernetes: * **Penyedia Infrastruktur:** Mengelola infrastruktur yang memungkinkan beberapa klaster terisolasi untuk melayani beberapa _tenant_, misalnya penyedia layanan _cloud_. * **Operator klaster:** Mengelola klaster dan biasanya memperhatikan kebijakan, akses jaringan, izin aplikasi, dll. * **Pengembang Aplikasi:** Mengelola aplikasi yang berjalan di dalam klaster dan biasanya memperhatikan konfigurasi tingkat aplikasi dan komposisi [Service](https://kubernetes.io/id/docs/concepts/services-networking/service/) . * **Portabel:** Spesifikasi Gateway API didefinisikan sebagai [Custom Resource](https://kubernetes.io/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/) dan didukung oleh banyak [implementasi](https://gateway-api.sigs.k8s.io/implementations/) . * **Ekspresif:** Jenis-jenis Gateway API mendukung fungsi untuk kasus penggunaan routing trafik pada umumnya, seperti pencocokan berbasis header, pembobotan trafik, dan lainnya yang sebelumnya hanya mungkin dilakukan di [Ingress](https://kubernetes.io/id/docs/concepts/services-networking/ingress/) dengan menggunakan anotasi kustom. * **Dapat diperluas:** Gateway memungkinkan sumber daya kustom untuk dihubungkan pada berbagai lapisan API. Ini memungkinkan penyesuaian yang lebih detail pada tempat yang tepat dalam struktur API. Model Sumber Daya (_Resource_) ------------------------------ Gateway API memiliki tiga jenis API stabil: * **GatewayClass:** Mendefinisikan satu set gateway dengan konfigurasi umum dan dikelola oleh pengendali yang mengimplementasikan kelas tersebut. * **Gateway:** Mendefinisikan instans infrastruktur penanganan trafik, seperti penyeimbang beban (_load balancer_) _cloud_. * **HTTPRoute:** Mendefinisikan aturan khusus HTTP untuk memetakan trafik dari pendengar (_listener_) Gateway ke representasi titik akhir (_endpoint_) jaringan backend. Titik akhir ini sering diwakili sebagai sebuah [Service](https://kubernetes.io/id/docs/concepts/services-networking/service/ "Sebuah Cara untuk mengekspos aplikasi yang berjalan pada sebuah kumpulan Pod sebagai layanan jaringan.") . Gateway API diatur ke dalam berbagai jenis API yang memiliki hubungan saling ketergantungan untuk mendukung sifat berorientasi _role_ dari organisasi. Objek Gateway dikaitkan dengan tepat satu GatewayClass; GatewayClass menggambarkan pengendali gateway yang bertanggung jawab untuk mengelola Gateway dari kelas ini. Satu atau lebih jenis rute seperti HTTPRoute, kemudian dikaitkan dengan Gateway. Sebuah Gateway dapat memfilter rute yang mungkin akan dilampirkan pada `listeners`\-nya, membentuk model kepercayaan dua arah dengan rute. Gambar berikut mengilustrasikan hubungan dari tiga jenis Gateway API yang stabil: ![Gambar yang mengilustrasikan hubungan dari tiga jenis Gateway API yang stabil](https://kubernetes.io/docs/images/gateway-kind-relationships.svg) ### Gateway Gateway menggambarkan sebuah instans infrastruktur penanganan trafik. Ini mendefinisikan titik akhir jaringan yang dapat digunakan untuk memproses trafik, seperti penyaringan (_filter_), penyeimbangan (_balancing_), pemisahan (_splitting_), dll. untuk backend seperti sebuah Service. Sebagai contoh, Gateway dapat mewakili penyeimbang beban (_load balancer_) _cloud_ atau server proksi dalam klaster yang dikonfigurasikan untuk menerima trafik HTTP. Contoh minimal dari Gateway _resource_: apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: example-gateway spec: gatewayClassName: example-class listeners: - name: http protocol: HTTP port: 80 Dalam contoh ini, sebuah instans dari infrastruktur penanganan trafik diprogram untuk mendengarkan trafik HTTP pada port 80. Karena _field_ `addresses` tidak ditentukan, sebuah alamat atau nama host ditugaskan ke Gateway oleh pengendali implementasi. Alamat ini digunakan sebagai titik akhir jaringan untuk memproses trafik titik akhir jaringan backend yang didefinisikan dalam rute. Lihat [Gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Gateway) referensi untuk definisi lengkap dari API ini. ### HTTPRoute Jenis HTTPRoute menentukan perilaku _routing_ dari permintaan HTTP dari _listener_ Gateway ke titik akhir jaringan backend. Untuk backend Service, implementasi dapat mewakili titik akhir jaringan backend sebagai IP Service atau Endpoints pendukung dari Service tersebut. HTTPRoute mewakili konfigurasi yang diterapkan pada implementasi Gateway yang mendasarinya. Sebagai contoh, mendefinisikan HTTPRoute baru dapat mengakibatkan pengaturan rute trafik tambahan pada penyeimbang beban _cloud_ atau server proksi dalam klaster. Contoh minimal dari HTTPRoute: apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: example-httproute spec: parentRefs: - name: example-gateway hostnames: - "www.example.com" rules: - matches: - path: type: PathPrefix value: /login backendRefs: - name: example-svc port: 8080 Dalam contoh ini, trafik HTTP dari Gateway `example-gateway` dengan header Host: yang disetel ke `www.example.com` dan jalur permintaan yang ditentukan sebagai `/login` akan diarahkan ke Service `example-svc` pada port `8080`. Lihat referensi [HTTPRoute](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.HTTPRoute) untuk definisi lengkap dari API ini. Aliran Permintaan (_Request Flow_) ---------------------------------- Berikut adalah contoh sederhana dari trafik HTTP yang diarahkan ke sebuah Service menggunakan Gateway dan HTTPRoute: ![Diagram yang memberikan contoh trafik HTTP yang diarahkan ke sebuah Service menggunakan Gateway dan HTTPRoute](https://kubernetes.io/docs/images/gateway-request-flow.svg) Dalam contoh ini, aliran permintaan untuk Gateway yang diimplementasikan sebagai _reverse proxy_ adalah: 1. Klien mulai mempersiapkan permintaan HTTP untuk URL `http://www.example.com` 2. Resolver DNS klien melakukan query untuk nama tujuan dan mengetahui pemetaan ke satu atau lebih alamat IP yang terkait dengan Gateway. 3. Klien mengirimkan permintaan ke alamat IP Gateway; _reverse proxy_ menerima permintaan HTTP dan menggunakan header Host: untuk mencocokkan konfigurasi yang berasal dari Gateway dan HTTPRoute yang terlampir. 4. Secara opsional, _reverse proxy_ dapat melakukan pencocokan header permintaan dan/atau jalur berdasarkan aturan pencocokan dari HTTPRoute. 5. Secara opsional, _reverse proxy_ dapat memodifikasi permintaan; sebagai contoh, untuk menambah atau menghapus header, berdasarkan aturan filter dari HTTPRoute. 6. Terakhir, _reverse proxy_ meneruskan permintaan ke satu atau lebih backend. Kesesuaian (_Conformance_) -------------------------- Gateway API mencakup beragam fitur dan diimplementasikan secara luas. Kombinasi ini memerlukan definisi dan pengujian kesesuaian yang jelas untuk memastikan bahwa API memberikan pengalaman yang konsisten di mana pun digunakan. Lihat dokumentasi [conformance](https://gateway-api.sigs.k8s.io/concepts/conformance/) untuk memahami rincian seperti saluran rilis (_release channel_), tingkat dukungan, dan menjalankan tes kesesuaian (_conformance test_). Migrasi dari Ingress -------------------- Gateway API adalah penerus API [Ingress](https://kubernetes.io/id/docs/concepts/services-networking/ingress/) tapi tidak termasuk dalam jenis Ingress. Akibatnya, konversi satu kali dari sumber daya Ingress yang ada ke sumber daya Gateway API diperlukan. Referensi panduan [migrasi ingress](https://gateway-api.sigs.k8s.io/guides/getting-started/migrating-from-ingress) untuk rincian tentang migrasi sumber daya Ingress ke sumber daya Gateway API. Selanjutnya ----------- Alih-alih sumber daya Gateway API yang diimplementasikan secara natif oleh Kubernetes, spesifikasinya didefinisikan sebagai [Custom Resource Definition](https://kubernetes.io/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/) yang didukung oleh berbagai [implementasi](https://gateway-api.sigs.k8s.io/implementations/) . [Instal](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api) CRD Gateway API atau ikuti petunjuk instalasi dari implementasi yang kamu pilih. Setelah menginstal sebuah implementasi, gunakan panduan [Memulai](https://gateway-api.sigs.k8s.io/guides/) untuk membantu kamu segera memulai bekerja dengan Gateway API. #### Catatan: Pastikan untuk meninjau dokumentasi dari implementasi yang kamu pilih untuk memahami hal-hal yang perlu diperhatikan. Referensi [spesifikasi API](https://gateway-api.sigs.k8s.io/reference/spec/) untuk rincian tambahan dari semua jenis Gateway API. Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified December 27, 2025 at 12:16 AM PST: [\[id\] Fix broken link in 'Gateway API' page (f68a941551)](https://github.com/kubernetes/website/commit/f68a9415510026b95713dd9a379355fa97c7abc4) --- # 服务、负载均衡和联网 | Kubernetes 服务、负载均衡和联网 ========== Kubernetes 网络背后的概念和资源。 Kubernetes 网络模型 --------------- Kubernetes 网络模型由几个部分构成： * 集群中的每个 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/) 都会获得自己的、独一无二的集群范围 IP 地址。 * Pod 有自己的私有网络命名空间，Pod 内的所有容器共享这个命名空间。 运行在同一个 Pod 中的不同容器的进程彼此之间可以通过 `localhost` 进行通信。 * **Pod 网络**（也称为集群网络）处理 Pod 之间的通信。它确保（除非故意进行网络分段）： * 所有 Pod 可以与所有其他 Pod 进行通信， 无论它们是在同一个[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 还是在不同的节点上。 Pod 可以直接相互通信，而无需使用代理或地址转换（NAT）。 在 Windows 上，这条规则不适用于主机网络 Pod。 * 节点上的代理（例如系统守护进程或 kubelet）可以与该节点上的所有 Pod 进行通信。 * [Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) API 允许你为由一个或多个后端 Pod 实现的服务提供一个稳定（长效）的 IP 地址或主机名， 其中组成服务的各个 Pod 可以随时变化。 * Kubernetes 会自动管理 [EndpointSlice](https://kubernetes.io/zh-cn/docs/concepts/services-networking/endpoint-slices/) 对象，以提供有关当前用来提供 Service 的 Pod 的信息。 * 服务代理实现通过使用操作系统或云平台 API 来拦截或重写数据包， 监视 Service 和 EndpointSlice 对象集，并在数据平面编程将服务流量路由到其后端。 * [Gateway](https://kubernetes.io/zh-cn/docs/concepts/services-networking/gateway/) API （或其前身 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/) 使得集群外部的客户端能够访问 Service。 * 当使用受支持的 [云提供商（Cloud Provider）](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-cloud-provider "一个提供云计算平台的组织。") 时，通过 Service API 的 [`type: LoadBalancer`](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#loadbalancer) 可以使用一种更简单但可配置性较低的集群 Ingress 机制。 * [NetworkPolicy](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies) 是一个内置的 Kubernetes API，允许你控制 Pod 之间的流量或 Pod 与外部世界之间的流量。 在早期的容器系统中，不同主机上的容器之间没有自动连通， 因此通常需要显式创建容器之间的链路，或将容器端口映射到主机端口，以便其他主机上的容器能够访问。 在 Kubernetes 中并不需要如此操作；在 Kubernetes 的网络模型中， 从端口分配、命名、服务发现、负载均衡、应用配置和迁移的角度来看，Pod 可以被视作虚拟机或物理主机。 这个模型只有少部分是由 Kubernetes 自身实现的。 对于其他部分，Kubernetes 定义 API，但相应的功能由外部组件提供，其中一些是可选的： * Pod 网络命名空间的设置由实现[容器运行时接口（CRI）](https://kubernetes.io/zh-cn/docs/concepts/containers/cri/) 的系统层面软件处理。 * Pod 网络本身由 [Pod 网络实现](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/addons/#networking-and-network-policy) 管理。 在 Linux 上，大多数容器运行时使用[容器网络接口 (CNI)](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ "容器网络接口 (Container network interface；CNI) 插件是遵循 appc/CNI 协议的一类网络插件。") 与 Pod 网络实现进行交互，因此这些实现通常被称为 **CNI 插件**。 * Kubernetes 提供了一个默认的服务代理实现，称为 [kube-proxy](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/ "kube-proxy 是集群中每个节点上运行的网络代理。") ， 但某些 Pod 网络实现使用其自己的服务代理，以便与实现的其余组件集成得更紧密。 * NetworkPolicy 通常也由 Pod 网络实现提供支持。 （某些更简单的 Pod 网络实现不支持 NetworkPolicy，或者管理员可能会选择在不支持 NetworkPolicy 的情况下配置 Pod 网络。在这些情况下，API 仍然存在，但将没有效果。） * [Gateway API 的实现](https://gateway-api.sigs.k8s.io/implementations/) 有很多， 其中一些特定于某些云环境，还有一些更专注于“裸金属”环境，而其他一些则更加通用。 接下来 --- [使用 Service 连接到应用](https://kubernetes.io/zh-cn/docs/tutorials/services/connect-applications-service/) 教程通过一个实际的示例让你了解 Service 和 Kubernetes 如何联网。 [集群网络](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/) 解释了如何为集群设置网络， 还概述了所涉及的技术。 * * * ##### [服务（Service）](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 将在集群中运行的应用通过同一个面向外界的端点公开出去，即使工作负载分散于多个后端也完全可行。 ##### [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/) 使用一种能感知协议配置的机制来解析 URI、主机名称、路径等 Web 概念， 让你的 HTTP（或 HTTPS）网络服务可被访问。 Ingress 概念允许你通过 Kubernetes API 定义的规则将流量映射到不同后端。 ##### [Ingress 控制器](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers/) 为了让 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/) 在集群中工作， 你必须运行一个 Ingress 控制器。你需要选择至少一个 Ingress 控制器并确保其已被部署到你的集群中。 本页列出了你可以部署的常见 Ingress 控制器。 ##### [Gateway API](https://kubernetes.io/zh-cn/docs/concepts/services-networking/gateway/) Gateway API 是一组 API 类别，可提供动态基础设施制备和高级流量路由。 ##### [EndpointSlice](https://kubernetes.io/zh-cn/docs/concepts/services-networking/endpoint-slices/) EndpointSlice API 是 Kubernetes 用于扩缩 Service 以处理大量后端的机制，还允许集群高效更新其健康后端的列表。 ##### [网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量， NetworkPolicy 可以让你为集群内以及 Pod 与外界之间的网络流量指定规则。 你的集群必须使用支持 NetworkPolicy 实施的网络插件。 ##### [Service 与 Pod 的 DNS](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dns-pod-service/) 你的工作负载可以使用 DNS 发现集群内的 Service，本页说明具体工作原理。 ##### [IPv4/IPv6 双协议栈](https://kubernetes.io/zh-cn/docs/concepts/services-networking/dual-stack/) Kubernetes 允许你配置单协议栈 IPv4 网络、单协议栈 IPv6 网络或同时激活这两种网络的双协议栈网络。本页说明具体配置方法。 ##### [拓扑感知路由](https://kubernetes.io/zh-cn/docs/concepts/services-networking/topology-aware-routing/) **拓扑感知路由**提供了一种机制帮助保持网络流量处于流量发起的区域内。 在集群中 Pod 之间优先使用相同区域的流量有助于提高可靠性、性能（网络延迟和吞吐量）或降低成本。 ##### [Windows 网络](https://kubernetes.io/zh-cn/docs/concepts/services-networking/windows-networking/) ##### [Service ClusterIP 分配](https://kubernetes.io/zh-cn/docs/concepts/services-networking/cluster-ip-allocation/) ##### [服务内部流量策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service-traffic-policy/) 如果集群中的两个 Pod 想要通信，并且两个 Pod 实际上都在同一节点运行， **服务内部流量策略** 可以将网络流量限制在该节点内。 通过集群网络避免流量往返有助于提高可靠性、增强性能（网络延迟和吞吐量）或降低成本。 反馈 -- 此页是否对你有帮助？ 是 否 感谢反馈。如果你有一个关于如何使用 Kubernetes 的具体问题需要答案，可以访问 [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . 如果需要，请在 [GitHub 仓库](https://www.github.com/kubernetes/website/) 上登记新的问题 [报告问题](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) 或者 [提出改进建议](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最后修改 November 16, 2025 at 8:46 PM PST: [\[zh-cn\]sync services-networking/\_index.md (be0487ab2e)](https://github.com/kubernetes/website/commit/be0487ab2e0e6f8176a0be08c79a3905d3080007) --- # Dienste, Lastverteilung und Netzwerkfunktionen | Kubernetes Das ist eine für den Ausdruck optimierte Ansicht des gesamten Kapitels inkl. Unterseiten. [Druckvorgang starten](https://kubernetes.io/de/docs/concepts/services-networking/_print/#) . [Zur Standardansicht zurückkehren](https://kubernetes.io/de/docs/concepts/services-networking/) . Dienste, Lastverteilung und Netzwerkfunktionen ============================================== Konzepte und Resourcen bezüglich Netzwerktechnik in Kubernetes * 1: [Services](https://kubernetes.io/de/docs/concepts/services-networking/_print/#pg-5701136fd2ce258047b6ddc389112352) * 2: [IPv4/IPv6 dual-stack](https://kubernetes.io/de/docs/concepts/services-networking/_print/#pg-21f8d19c60c33914baab66224c3d46a7) 1 - Services ============ Veröffentliche deine Applikation über einen einzelnen, nach außen sichtbaren Endpunkt, auch wenn die Workload über mehrere Backends verteilt ist. 2 - IPv4/IPv6 dual-stack ======================== Kubernetes erlaubt Netzwerkkonfigurationen mit IPv4 oder IPv6 (Single Stack). Im Dual-Stack-Betrieb kann IPv4 im Verbund mit IPv6 verwendet werden. --- # 调试集群 | Kubernetes 这是本节的多页打印视图。 [点击此处打印](https://kubernetes.io/zh-cn/docs/reference/debug-cluster/_print/#) . [返回本页常规视图](https://kubernetes.io/zh-cn/docs/reference/debug-cluster/) . 调试集群 ==== * 1: [流控](https://kubernetes.io/zh-cn/docs/reference/debug-cluster/_print/#pg-9cfe3b0b8b8f3f9e554a1e2ee560a46b) 1 - 流控 ====== API 优先级和公平性控制着 Kubernetes API 服务器在负载过高的情况下的行为。你可以在 [API 优先级和公平性](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/flow-control/) 文档中找到更多信息。 问题诊断 ---- 对于启用了 APF 的 API 服务器，每个 HTTP 响应都有两个额外的 HTTP 头： `X-Kubernetes-PF-FlowSchema-UID` 和 `X-Kubernetes-PF-PriorityLevel-UID`， 给出与请求匹配的 FlowSchema 和已分配的优先级级别。 如果请求用户没有查看这些对象的权限，则这些 HTTP 头中将不包含 API 对象的名称， 因此在调试时，你可以使用类似如下的命令： kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}" kubectl get prioritylevelconfigurations -o custom-columns="uid:{metadata.uid},name:{metadata.name}" 来获取 UID 与 FlowSchema 的名称和 PriorityLevelConfiguration 的名称之间的对应关系。 ### 调试端点 启用 APF 特性后，`kube-apiserver` 会在其 HTTP/HTTPS 端口额外提供以下路径： 你需要确保自己具有访问这些端点的权限。如果你使用管理员身份，则无需进行任何操作。 必要时可以通过设置 `nonResourceURLs` 来访问 `/debug/api_priority_and_fairness/` 参照 [RBAC](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/) 文档授予权限。 * `/debug/api_priority_and_fairness/dump_priority_levels` —— 所有优先级及其当前状态的列表。你可以这样获取： kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels 输出格式为 CSV，类似于： PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests, DispatchedRequests, RejectedRequests, TimedoutRequests, CancelledRequests catch-all, 0, true, false, 0, 0, 1, 0, 0, 0 exempt, 0, true, false, 0, 0, 0, 0, 0, 0 global-default, 0, true, false, 0, 0, 46, 0, 0, 0 leader-election, 0, true, false, 0, 0, 4, 0, 0, 0 node-high, 0, true, false, 0, 0, 34, 0, 0, 0 system, 0, true, false, 0, 0, 48, 0, 0, 0 workload-high, 0, true, false, 0, 0, 500, 0, 0, 0 workload-low, 0, true, false, 0, 0, 0, 0, 0, 0 所选列名的解释： * `IsQuiescing` 表示当队列已被腾空时此优先级级别是否将被移除。 * `/debug/api_priority_and_fairness/dump_queues` —— 所有队列及其当前状态的列表。 你可以这样获取： kubectl get --raw /debug/api_priority_and_fairness/dump_queues 输出格式为 CSV，类似于： PriorityLevelName, Index, PendingRequests, ExecutingRequests, SeatsInUse, NextDispatchR, InitialSeatsSum, MaxSeatsSum, TotalWorkSum workload-low, 14, 27, 0, 0, 77.64342019ss, 270, 270, 0.81000000ss workload-low, 74, 26, 0, 0, 76.95387841ss, 260, 260, 0.78000000ss ... leader-election, 0, 0, 0, 0, 5088.87053833ss, 0, 0, 0.00000000ss leader-election, 1, 0, 0, 0, 0.00000000ss, 0, 0, 0.00000000ss ... workload-high, 0, 0, 0, 0, 0.00000000ss, 0, 0, 0.00000000ss workload-high, 1, 0, 0, 0, 1119.44936475ss, 0, 0, 0.00000000ss 所选列名的解释： * `NextDispatchR`：下一个请求将被调度时的 R 进度计读数，单位为 seat-second。 * `InitialSeatsSum`：与在某个给定队列中所有请求关联的 InitialSeats 的总和。 * `MaxSeatsSum`：与某个给定队列中所有请求关联的 MaxSeats 的总和。 * `TotalWorkSum`：在某个给定队列中所有等待中请求的总工作量，单位为 seat-second。 注意：`seat-second`（缩写为 `ss`）是 APF 领域中的工作量单位。 * `/debug/api_priority_and_fairness/dump_requests` - 所有请求的列表， 包括队列中正在等待的请求和正在执行的请求。你可以运行以下类似命令获取此列表： kubectl get --raw /debug/api_priority_and_fairness/dump_requests 输出格式为 CSV，类似于： PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, InitialSeats, FinalSeats, AdditionalLatency, StartTime exempt, exempt, -1, -1, , 2023-07-15T04:51:25.596404345Z, 1, 0, 0s, 2023-07-15T04:51:25.596404345Z workload-low, service-accounts, 14, 0, system:serviceaccount:default:loadtest, 2023-07-18T00:12:51.386556253Z, 10, 0, 0s, 0001-01-01T00:00:00Z workload-low, service-accounts, 14, 1, system:serviceaccount:default:loadtest, 2023-07-18T00:12:51.487092539Z, 10, 0, 0s, 0001-01-01T00:00:00Z 你可以使用以下命令获得更详细的清单： kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1' 输出格式为 CSV，类似于： PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, InitialSeats, FinalSeats, AdditionalLatency, StartTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource exempt, exempt, -1, -1, , 2023-07-15T04:51:25.596404345Z, 1, 0, 0s, 2023-07-15T04:51:25.596404345Z, system:serviceaccount:system:admin, list, /api/v1/namespaces/kube-stress/configmaps, kube-stress, , v1, configmaps, workload-low, service-accounts, 14, 0, system:serviceaccount:default:loadtest, 2023-07-18T00:13:08.986534842Z, 10, 0, 0s, 0001-01-01T00:00:00Z, system:serviceaccount:default:loadtest, list, /api/v1/namespaces/kube-stress/configmaps, kube-stress, , v1, configmaps, workload-low, service-accounts, 14, 1, system:serviceaccount:default:loadtest, 2023-07-18T00:13:09.086476021Z, 10, 0, 0s, 0001-01-01T00:00:00Z, system:serviceaccount:default:loadtest, list, /api/v1/namespaces/kube-stress/configmaps, kube-stress, , v1, configmaps, 所选列名的解释： * `QueueIndex`：队列的索引。对于没有队列的优先级级别，该值将为 -1。 * `RequestIndexInQueue`：某个给定请求在队列中的索引。对于正在执行的请求，该值将为 -1。 * `InitialSeats`：在请求的初始（正常）执行阶段占用的席位数。 * `FinalSeats`：在请求执行的最终阶段占用的席位数，包括与之关联的 WATCH 通知。 * `AdditionalLatency`：在请求执行的最终阶段所耗用的额外时间。 FinalSeats 将在此时间段内被占用。这并不意味着用户会感知到任何延迟。 * `StartTime`：请求开始执行的时间。对于排队的请求，该值将为 0001-01-01T00:00:00Z。 ### 调试日志生成行为 在 `-v=3` 或更详细的情况下，API 服务器会为在 API 服务日志中为每个请求输出一行 httplog， 其中包括以下属性： * `apf_fs`：请求被分类到的 FlowSchema 的名称。 * `apf_pl`：该 FlowSchema 的优先级名称。 * `apf_iseats`：为请求执行的初始（正常）阶段确定的席位数量。 * `apf_fseats`：为请求的最后执行阶段（考虑关联的 `watch` 通知）确定的席位数量。 * `apf_additionalLatency`：请求执行最后阶段的持续时间。 在更高级别的精细度下，将有日志行揭示 APF 如何处理请求的详细信息，主要用于调试目的。 ### 响应头 APF 将以下两个头添加到每个 HTTP 响应消息中。 这些信息不会出现在审计日志中，但可以从客户端查看。 对于使用 `klog` 的客户端，使用 `-v=8` 或更高的详细级别可以查看这些头。 * `X-Kubernetes-PF-FlowSchema-UID` 保存相应请求被分类到的 FlowSchema 对象的 UID。 * `X-Kubernetes-PF-PriorityLevel-UID` 保存与该 FlowSchema 关联的 PriorityLevelConfiguration 对象的 UID。 接下来 --- 有关 API 优先级和公平性的设计细节的背景信息， 请参阅[增强提案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness) 。 --- # Notes | Kubernetes Notes ===== Kubernetes release notes. Release notes can be found by reading the [Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) that matches your Kubernetes version. View the changelog for 1.35 on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md) . Alternately, release notes can be searched and filtered online at: [relnotes.k8s.io](https://relnotes.k8s.io/) . View filtered release notes for 1.35 on [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.35.0) . Feedback -------- Was this page helpful? Yes No Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the [GitHub Repository](https://www.github.com/kubernetes/website/) if you want to [report a problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [suggest an improvement](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified August 07, 2023 at 10:05 AM PST: [Clean up /releases (7ed368d0be)](https://github.com/kubernetes/website/commit/7ed368d0be2f5b31bb38655e19f7899db167f3d1) --- # Kubernetes 问题和安全 | Kubernetes 这是本节的多页打印视图。 [点击此处打印](https://kubernetes.io/zh-cn/docs/reference/issues-security/_print/#) . [返回本页常规视图](https://kubernetes.io/zh-cn/docs/reference/issues-security/) . Kubernetes 问题和安全 ================ * 1: [Kubernetes 问题追踪](https://kubernetes.io/zh-cn/docs/reference/issues-security/_print/#pg-980c0542a3b195a20cfd4358792e2a38) * 2: [Kubernetes 安全和信息披露](https://kubernetes.io/zh-cn/docs/reference/issues-security/_print/#pg-1f7dc06f1cc1ea2cdde4480e54d5fb34) * 3: [官方 CVE 订阅源](https://kubernetes.io/zh-cn/docs/reference/issues-security/_print/#pg-f8584cd3b29b891198316c53d71b787c) 1 - Kubernetes 问题追踪 =================== 要报告安全问题，请遵循 [Kubernetes 安全问题公开流程](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/#report-a-vulnerability) 。 使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) 跟踪 Kubernetes 编码工作和公开问题。 * [安全响应委员会（Security Response Committee，SRC）](https://github.com/kubernetes/committee-security-response) 已公布的[已知 CVE 官方列表](https://kubernetes.io/zh-cn/docs/reference/issues-security/official-cve-feed/) * [CVE 相关问题](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) 与安全性相关的公告将发送到 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 邮件列表。 2 - Kubernetes 安全和信息披露 ====================== 本页面介绍 Kubernetes 安全和信息披露相关的内容。 安全公告 ---- 加入 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 组，以获取关于安全性和主要 API 公告的电子邮件。 报告一个漏洞 ------ 我们非常感谢向 Kubernetes 开源社区报告漏洞的安全研究人员和用户。 所有的报告都由社区志愿者进行彻底调查。 如需报告，请将你的漏洞提交给 [Kubernetes 漏洞赏金计划](https://hackerone.com/kubernetes) 。 这样做可以使得社区能够在标准化的响应时间内对漏洞进行分类和处理。 你还可以通过电子邮件向私有 [security@kubernetes.io](mailto:security@kubernetes.io) 列表发送电子邮件，邮件中应该包含 [所有 Kubernetes 错误报告](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml) 所需的详细信息。 你可以使用[安全响应委员会成员](https://git.k8s.io/security/README.md#product-security-committee-psc) 的 GPG 密钥加密你的发往邮件列表的邮件。揭示问题时不需要使用 GPG 来加密。 ### 我应该在什么时候报告漏洞？ * 你认为在 Kubernetes 中发现了一个潜在的安全漏洞 * 你不确定漏洞如何影响 Kubernetes * 你认为你在 Kubernetes 依赖的另一个项目中发现了一个漏洞 * 对于具有漏洞报告和披露流程的项目，请直接在该项目处报告 ### 我什么时候不应该报告漏洞？ * 你需要调整 Kubernetes 组件安全性的帮助 * 你需要应用与安全相关更新的帮助 * 你的问题与安全无关 安全漏洞响应 ------ 每个报告在 3 个工作日内由安全响应委员会成员确认和分析， 这将启动[安全发布过程](https://git.k8s.io/security/security-release-process.md#disclosures) 。 与安全响应委员会共享的任何漏洞信息都保留在 Kubernetes 项目中，除非有必要修复该问题，否则不会传播到其他项目。 随着安全问题从分类、识别修复、发布计划等方面的进展，我们将不断更新报告。 公开披露时间 ------ 公开披露日期由 Kubernetes 安全响应委员会和 bug 提交者协商。 我们倾向于在能够为用户提供缓解措施之后尽快完全披露该 bug。 当 bug 或其修复还没有被完全理解，解决方案没有经过良好的测试，或者为了处理供应商协调问题时，延迟披露是合理的。 信息披露的时间范围从即时（尤其是已经公开的）到几周不等。 对于具有直接缓解措施的漏洞，我们希望报告日期到披露日期的间隔是 7 天。 在设置披露日期方面，Kubernetes 安全响应委员会拥有最终决定权。 3 - 官方 CVE 订阅源 ============== 特性状态： `Kubernetes v1.27 [beta]` 这是由 Kubernetes 安全响应委员会（Security Response Committee, SRC）公布的经社区维护的官方 CVE 列表。 更多细节请参阅 [Kubernetes 安全和信息披露](https://kubernetes.io/zh-cn/docs/reference/issues-security/security/) 。 Kubernetes 项目以 [JSON Feed](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) 和 [RSS feed](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/feed.xml) 格式就已发布的安全问题提供了可通过程序访问的提要。 你可以通过执行以下命令来查阅这些安全问题： * [JSON feed](https://kubernetes.io/zh-cn/docs/reference/issues-security/_print/#cve-feeds-0) * [RSS feed](https://kubernetes.io/zh-cn/docs/reference/issues-security/_print/#cve-feeds-1) [链接到 JSON 格式](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json [链接到 RSS 格式](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/feed.xml) curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml | | | | | --- | --- | --- |Kubernetes CVE 列表 （最后更新：2026-03-20 12:45:52 UTC） | CVE ID | 问题描述 | CVE GitHub Issue URL | | --- | --- | --- | | [CVE-2026-4342](https://github.com/kubernetes/kubernetes/issues/137893) | ingress-nginx comment-based nginx configuration injection | [#137893](https://github.com/kubernetes/kubernetes/issues/137893) | | [CVE-2026-3864](https://github.com/kubernetes/kubernetes/issues/137797) | CSI Driver for NFS path traversal via subDir may delete unintended directories on the NFS server | [#137797](https://github.com/kubernetes/kubernetes/issues/137797) | | [CVE-2025-15566](https://github.com/kubernetes/kubernetes/issues/136789) | ingress-nginx auth-proxy-set-headers nginx configuration injection | [#136789](https://github.com/kubernetes/kubernetes/issues/136789) | | [CVE-2026-24514](https://github.com/kubernetes/kubernetes/issues/136680) | ingress-nginx Admission Controller denial of service | [#136680](https://github.com/kubernetes/kubernetes/issues/136680) | | [CVE-2026-24513](https://github.com/kubernetes/kubernetes/issues/136679) | ingress-nginx auth-url protection bypass | [#136679](https://github.com/kubernetes/kubernetes/issues/136679) | | [CVE-2026-24512](https://github.com/kubernetes/kubernetes/issues/136678) | ingress-nginx rules.http.paths.path nginx configuration injection | [#136678](https://github.com/kubernetes/kubernetes/issues/136678) | | [CVE-2026-1580](https://github.com/kubernetes/kubernetes/issues/136677) | ingress-nginx auth-method nginx configuration injection | [#136677](https://github.com/kubernetes/kubernetes/issues/136677) | | [CVE-2025-14269](https://github.com/kubernetes/kubernetes/issues/135798) | Credential caching in Headlamp with Helm enabled | [#135798](https://github.com/kubernetes/kubernetes/issues/135798) | | [CVE-2025-13281](https://github.com/kubernetes/kubernetes/issues/135525) | Portworx Half-Blind SSRF in kube-controller-manager | [#135525](https://github.com/kubernetes/kubernetes/issues/135525) | | [CVE-2025-9708](https://github.com/kubernetes/kubernetes/issues/134063) | Kubernetes C# Client: improper certificate validation in custom CA mode may lead to man-in-the-middle attacks | [#134063](https://github.com/kubernetes/kubernetes/issues/134063) | | [CVE-2025-7445](https://github.com/kubernetes/kubernetes/issues/133897) | secrets-store-sync-controller discloses service account tokens in logs | [#133897](https://github.com/kubernetes/kubernetes/issues/133897) | | [CVE-2025-5187](https://github.com/kubernetes/kubernetes/issues/133471) | Nodes can delete themselves by adding an OwnerReference | [#133471](https://github.com/kubernetes/kubernetes/issues/133471) | | [CVE-2025-7342](https://github.com/kubernetes/kubernetes/issues/133115) | VM images built with Kubernetes Image Builder Nutanix or OVA providers use default credentials for Windows images if user did not override | [#133115](https://github.com/kubernetes/kubernetes/issues/133115) | | [CVE-2025-4563](https://github.com/kubernetes/kubernetes/issues/132151) | Nodes can bypass dynamic resource allocation authorization checks | [#132151](https://github.com/kubernetes/kubernetes/issues/132151) | | [CVE-2025-1974](https://github.com/kubernetes/kubernetes/issues/131009) | ingress-nginx admission controller RCE escalation | [#131009](https://github.com/kubernetes/kubernetes/issues/131009) | | [CVE-2025-1098](https://github.com/kubernetes/kubernetes/issues/131008) | ingress-nginx controller configuration injection via unsanitized mirror annotations | [#131008](https://github.com/kubernetes/kubernetes/issues/131008) | | [CVE-2025-1097](https://github.com/kubernetes/kubernetes/issues/131007) | ingress-nginx controller configuration injection via unsanitized auth-tls-match-cn annotation | [#131007](https://github.com/kubernetes/kubernetes/issues/131007) | | [CVE-2025-24514](https://github.com/kubernetes/kubernetes/issues/131006) | ingress-nginx controller configuration injection via unsanitized auth-url annotation | [#131006](https://github.com/kubernetes/kubernetes/issues/131006) | | [CVE-2025-24513](https://github.com/kubernetes/kubernetes/issues/131005) | ingress-nginx controller auth secret file path traversal vulnerability | [#131005](https://github.com/kubernetes/kubernetes/issues/131005) | | [CVE-2025-1767](https://github.com/kubernetes/kubernetes/issues/130786) | GitRepo Volume Inadvertent Local Repository Access | [#130786](https://github.com/kubernetes/kubernetes/issues/130786) | | [CVE-2025-0426](https://github.com/kubernetes/kubernetes/issues/130016) | Node Denial of Service via kubelet Checkpoint API | [#130016](https://github.com/kubernetes/kubernetes/issues/130016) | | [CVE-2024-9042](https://github.com/kubernetes/kubernetes/issues/129654) | Command Injection affecting Windows nodes via nodes/\*/logs/query API | [#129654](https://github.com/kubernetes/kubernetes/issues/129654) | | [CVE-2024-10220](https://github.com/kubernetes/kubernetes/issues/128885) | Arbitrary command execution through gitRepo volume | [#128885](https://github.com/kubernetes/kubernetes/issues/128885) | | [CVE-2024-9594](https://github.com/kubernetes/kubernetes/issues/128007) | VM images built with Image Builder with some providers use default credentials during builds | [#128007](https://github.com/kubernetes/kubernetes/issues/128007) | | [CVE-2024-9486](https://github.com/kubernetes/kubernetes/issues/128006) | VM images built with Image Builder and Proxmox provider use default credentials | [#128006](https://github.com/kubernetes/kubernetes/issues/128006) | | [CVE-2024-7646](https://github.com/kubernetes/kubernetes/issues/126744) | Ingress-nginx Annotation Validation Bypass | [#126744](https://github.com/kubernetes/kubernetes/issues/126744) | | [CVE-2024-7598](https://github.com/kubernetes/kubernetes/issues/126587) | Network restriction bypass via race condition during namespace termination | [#126587](https://github.com/kubernetes/kubernetes/issues/126587) | | [CVE-2024-5321](https://github.com/kubernetes/kubernetes/issues/126161) | Incorrect permissions on Windows containers logs | [#126161](https://github.com/kubernetes/kubernetes/issues/126161) | | [CVE-2024-3744](https://github.com/kubernetes/kubernetes/issues/124759) | azure-file-csi-driver discloses service account tokens in logs | [#124759](https://github.com/kubernetes/kubernetes/issues/124759) | | [CVE-2024-3177](https://github.com/kubernetes/kubernetes/issues/124336) | Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#124336](https://github.com/kubernetes/kubernetes/issues/124336) | | [CVE-2023-5528](https://github.com/kubernetes/kubernetes/issues/121879) | Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes | [#121879](https://github.com/kubernetes/kubernetes/issues/121879) | | [CVE-2023-5044](https://github.com/kubernetes/kubernetes/issues/126817) | Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation | [#126817](https://github.com/kubernetes/kubernetes/issues/126817) | | [CVE-2023-5043](https://github.com/kubernetes/kubernetes/issues/126816) | Ingress nginx annotation injection causes arbitrary command execution | [#126816](https://github.com/kubernetes/kubernetes/issues/126816) | | [CVE-2022-4886](https://github.com/kubernetes/kubernetes/issues/126815) | ingress-nginx path sanitization can be bypassed | [#126815](https://github.com/kubernetes/kubernetes/issues/126815) | | [CVE-2023-3955](https://github.com/kubernetes/kubernetes/issues/119595) | Insufficient input sanitization on Windows nodes leads to privilege escalation | [#119595](https://github.com/kubernetes/kubernetes/issues/119595) | | [CVE-2023-3893](https://github.com/kubernetes/kubernetes/issues/119594) | Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation | [#119594](https://github.com/kubernetes/kubernetes/issues/119594) | | [CVE-2023-3676](https://github.com/kubernetes/kubernetes/issues/119339) | Insufficient input sanitization on Windows nodes leads to privilege escalation | [#119339](https://github.com/kubernetes/kubernetes/issues/119339) | | [CVE-2023-2431](https://github.com/kubernetes/kubernetes/issues/118690) | Bypass of seccomp profile enforcement | [#118690](https://github.com/kubernetes/kubernetes/issues/118690) | | [CVE-2023-2728](https://github.com/kubernetes/kubernetes/issues/118640) | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#118640](https://github.com/kubernetes/kubernetes/issues/118640) | | [CVE-2023-2727](https://github.com/kubernetes/kubernetes/issues/118640) | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#118640](https://github.com/kubernetes/kubernetes/issues/118640) | | [CVE-2023-2878](https://github.com/kubernetes/kubernetes/issues/118419) | secrets-store-csi-driver discloses service account tokens in logs | [#118419](https://github.com/kubernetes/kubernetes/issues/118419) | | [CVE-2022-3294](https://github.com/kubernetes/kubernetes/issues/113757) | Node address isn't always verified when proxying | [#113757](https://github.com/kubernetes/kubernetes/issues/113757) | | [CVE-2022-3162](https://github.com/kubernetes/kubernetes/issues/113756) | Unauthorized read of Custom Resources | [#113756](https://github.com/kubernetes/kubernetes/issues/113756) | | [CVE-2022-3172](https://github.com/kubernetes/kubernetes/issues/112513) | Aggregated API server can cause clients to be redirected (SSRF) | [#112513](https://github.com/kubernetes/kubernetes/issues/112513) | | [CVE-2021-25749](https://github.com/kubernetes/kubernetes/issues/112192) | \`runAsNonRoot\` logic bypass for Windows containers | [#112192](https://github.com/kubernetes/kubernetes/issues/112192) | | [CVE-2021-25748](https://github.com/kubernetes/kubernetes/issues/126814) | Ingress-nginx \`path\` sanitization can be bypassed with newline character | [#126814](https://github.com/kubernetes/kubernetes/issues/126814) | | [CVE-2021-25746](https://github.com/kubernetes/kubernetes/issues/126813) | Ingress-nginx directive injection via annotations | [#126813](https://github.com/kubernetes/kubernetes/issues/126813) | | [CVE-2021-25745](https://github.com/kubernetes/kubernetes/issues/126812) | Ingress-nginx \`path\` can be pointed to service account token file | [#126812](https://github.com/kubernetes/kubernetes/issues/126812) | | [CVE-2021-25742](https://github.com/kubernetes/kubernetes/issues/126811) | Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces | [#126811](https://github.com/kubernetes/kubernetes/issues/126811) | | [CVE-2021-25741](https://github.com/kubernetes/kubernetes/issues/104980) | Symlink Exchange Can Allow Host Filesystem Access | [#104980](https://github.com/kubernetes/kubernetes/issues/104980) | | [CVE-2020-8561](https://github.com/kubernetes/kubernetes/issues/104720) | Webhook redirect in kube-apiserver | [#104720](https://github.com/kubernetes/kubernetes/issues/104720) | | [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675) | Endpoint & EndpointSlice permissions allow cross-Namespace forwarding | [#103675](https://github.com/kubernetes/kubernetes/issues/103675) | | [CVE-2021-25737](https://github.com/kubernetes/kubernetes/issues/102106) | Holes in EndpointSlice Validation Enable Host Network Hijack | [#102106](https://github.com/kubernetes/kubernetes/issues/102106) | | [CVE-2020-8562](https://github.com/kubernetes/kubernetes/issues/101493) | Bypass of Kubernetes API Server proxy TOCTOU | [#101493](https://github.com/kubernetes/kubernetes/issues/101493) | | [CVE-2021-3121](https://github.com/kubernetes/kubernetes/issues/101435) | Processes may panic upon receipt of malicious protobuf messages | [#101435](https://github.com/kubernetes/kubernetes/issues/101435) | | [CVE-2021-25735](https://github.com/kubernetes/kubernetes/issues/100096) | Validating Admission Webhook does not observe some previous fields | [#100096](https://github.com/kubernetes/kubernetes/issues/100096) | | [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076) | Man in the middle using LoadBalancer or ExternalIPs | [#97076](https://github.com/kubernetes/kubernetes/issues/97076) | | [CVE-2020-8566](https://github.com/kubernetes/kubernetes/issues/95624) | Ceph RBD adminSecrets exposed in logs when loglevel >= 4 | [#95624](https://github.com/kubernetes/kubernetes/issues/95624) | | [CVE-2020-8565](https://github.com/kubernetes/kubernetes/issues/95623) | Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9 | [#95623](https://github.com/kubernetes/kubernetes/issues/95623) | | [CVE-2020-8564](https://github.com/kubernetes/kubernetes/issues/95622) | Docker config secrets leaked when file is malformed and log level >= 4 | [#95622](https://github.com/kubernetes/kubernetes/issues/95622) | | [CVE-2020-8563](https://github.com/kubernetes/kubernetes/issues/95621) | Secret leaks in kube-controller-manager when using vSphere provider | [#95621](https://github.com/kubernetes/kubernetes/issues/95621) | | [CVE-2020-8557](https://github.com/kubernetes/kubernetes/issues/93032) | Node disk DOS by writing to container /etc/hosts | [#93032](https://github.com/kubernetes/kubernetes/issues/93032) | | [CVE-2020-8559](https://github.com/kubernetes/kubernetes/issues/92914) | Privilege escalation from compromised node to cluster | [#92914](https://github.com/kubernetes/kubernetes/issues/92914) | | [CVE-2020-8558](https://github.com/kubernetes/kubernetes/issues/92315) | Node setting allows for neighboring hosts to bypass localhost boundary | [#92315](https://github.com/kubernetes/kubernetes/issues/92315) | | [CVE-2020-8555](https://github.com/kubernetes/kubernetes/issues/91542) | Half-Blind SSRF in kube-controller-manager | [#91542](https://github.com/kubernetes/kubernetes/issues/91542) | | [CVE-2020-10749](https://github.com/kubernetes/kubernetes/issues/91507) | IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements | [#91507](https://github.com/kubernetes/kubernetes/issues/91507) | | [CVE-2019-11254](https://github.com/kubernetes/kubernetes/issues/89535) | kube-apiserver Denial of Service vulnerability from malicious YAML payloads | [#89535](https://github.com/kubernetes/kubernetes/issues/89535) | | [CVE-2020-8552](https://github.com/kubernetes/kubernetes/issues/89378) | apiserver DoS (oom) | [#89378](https://github.com/kubernetes/kubernetes/issues/89378) | | [CVE-2020-8551](https://github.com/kubernetes/kubernetes/issues/89377) | Kubelet DoS via API | [#89377](https://github.com/kubernetes/kubernetes/issues/89377) | | [CVE-2020-8553](https://github.com/kubernetes/kubernetes/issues/126818) | ingress-nginx auth-type basic annotation vulnerability | [#126818](https://github.com/kubernetes/kubernetes/issues/126818) | | [CVE-2019-11251](https://github.com/kubernetes/kubernetes/issues/87773) | kubectl cp symlink vulnerability | [#87773](https://github.com/kubernetes/kubernetes/issues/87773) | | [CVE-2018-1002102](https://github.com/kubernetes/kubernetes/issues/85867) | Unvalidated redirect | [#85867](https://github.com/kubernetes/kubernetes/issues/85867) | | [CVE-2019-11255](https://github.com/kubernetes/kubernetes/issues/85233) | CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation | [#85233](https://github.com/kubernetes/kubernetes/issues/85233) | | [CVE-2019-11253](https://github.com/kubernetes/kubernetes/issues/83253) | Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack | [#83253](https://github.com/kubernetes/kubernetes/issues/83253) | | [CVE-2019-11250](https://github.com/kubernetes/kubernetes/issues/81114) | Bearer tokens are revealed in logs (audit finding TOB-K8S-001) | [#81114](https://github.com/kubernetes/kubernetes/issues/81114) | | [CVE-2019-11248](https://github.com/kubernetes/kubernetes/issues/81023) | /debug/pprof exposed on kubelet's healthz port | [#81023](https://github.com/kubernetes/kubernetes/issues/81023) | | [CVE-2019-11249](https://github.com/kubernetes/kubernetes/issues/80984) | Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal | [#80984](https://github.com/kubernetes/kubernetes/issues/80984) | | [CVE-2019-11247](https://github.com/kubernetes/kubernetes/issues/80983) | API server allows access to custom resources via wrong scope | [#80983](https://github.com/kubernetes/kubernetes/issues/80983) | | [CVE-2019-11245](https://github.com/kubernetes/kubernetes/issues/78308) | container uid changes to root after first restart or if image is already pulled to the node | [#78308](https://github.com/kubernetes/kubernetes/issues/78308) | | [CVE-2019-11243](https://github.com/kubernetes/kubernetes/issues/76797) | rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig() | [#76797](https://github.com/kubernetes/kubernetes/issues/76797) | | [CVE-2019-11244](https://github.com/kubernetes/kubernetes/issues/76676) | \`kubectl --http-cache=\` creates world-writeable cached schema files | [#76676](https://github.com/kubernetes/kubernetes/issues/76676) | | [CVE-2019-1002100](https://github.com/kubernetes/kubernetes/issues/74534) | json-patch requests can exhaust apiserver resources | [#74534](https://github.com/kubernetes/kubernetes/issues/74534) | | [CVE-2018-1002105](https://github.com/kubernetes/kubernetes/issues/71411) | proxy request handling in kube-apiserver can leave vulnerable TCP connections | [#71411](https://github.com/kubernetes/kubernetes/issues/71411) | | [CVE-2018-1002101](https://github.com/kubernetes/kubernetes/issues/65750) | smb mount security issue | [#65750](https://github.com/kubernetes/kubernetes/issues/65750) | | [CVE-2018-1002100](https://github.com/kubernetes/kubernetes/issues/61297) | Kubectl copy doesn't check for paths outside of it's destination directory. | [#61297](https://github.com/kubernetes/kubernetes/issues/61297) | | [CVE-2017-1002102](https://github.com/kubernetes/kubernetes/issues/60814) | atomic writer volume handling allows arbitrary file deletion in host filesystem | [#60814](https://github.com/kubernetes/kubernetes/issues/60814) | | [CVE-2017-1002101](https://github.com/kubernetes/kubernetes/issues/60813) | subpath volume mount handling allows arbitrary file access in host filesystem | [#60813](https://github.com/kubernetes/kubernetes/issues/60813) | | [CVE-2017-1002100](https://github.com/kubernetes/kubernetes/issues/47611) | Azure PV should be Private scope not Container scope | [#47611](https://github.com/kubernetes/kubernetes/issues/47611) | | [CVE-2017-1000056](https://github.com/kubernetes/kubernetes/issues/43459) | PodSecurityPolicy admission plugin authorizes incorrectly | [#43459](https://github.com/kubernetes/kubernetes/issues/43459) | 此订阅源会自动刷新，但从宣布 CVE 到可在此订阅源中找到对应的 CVE 会有一个明显却很小的延迟（几分钟到几小时）。 此订阅源的真实来源是一组 GitHub Issue，通过受控和受限的标签 `official-cve-feed` 进行过滤。 原始数据存放在 Google Cloud Bucket 中，只有社区少数受信任的成员可以写入。 --- # Berkontribusi ke Dokumentasi Kubernetes | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/id/docs/contribute/_print/#) . [Return to the regular view of this page](https://kubernetes.io/id/docs/contribute/) . Berkontribusi ke Dokumentasi Kubernetes ======================================= * 1: [Menyarankan peningkatan kualitas konten](https://kubernetes.io/id/docs/contribute/_print/#pg-e5340359b8afe1fe409af06178af8886) * 2: [Berpartisipasi dalam SIG Docs](https://kubernetes.io/id/docs/contribute/_print/#pg-8b9b22280711800788333c1a4d129735) * 3: [Dokumentasi Khusus Untuk Translasi Bahasa Indonesia](https://kubernetes.io/id/docs/contribute/_print/#pg-9d388974115458abb65431d0a8610843) Jika kamu ingin membantu dengan berkontribusi ke dokumentasi atau situs web Kubernetes, kami dengan senang hati menerima bantuan kamu! Siapapun bisa berkontribusi, baik kamu yang masih baru atau sudah lama di proyek ini, maupun jika kamu adalah seorang developer, seorang pengguna, atau bahkan seorang yang tidak tahan melihat saltik (_typo_)! Untuk informasi mengenai isi dan gaya (penulisan) dokumentasi Kubernetes, lihat [ikhtisar gaya penulisan dokumentasi](https://kubernetes.io/docs/contribute/style/) . Jenis-jenis kontributor dokumentasi ----------------------------------- * Seorang _member_ dari organisasi Kubernetes yang telah [menandatangani CLA](https://kubernetes.io/docs/contribute/start#sign-the-cla) dan berkontribusi waktu dan usahanya untuk proyek ini. Lihat [Keanggotaan komunitas](https://github.com/kubernetes/community/blob/master/community-membership.md) untuk kriteria spesifik untuk keanggotaan. * Seorang SIG Docs _reviewer_ adalah seorang anggota organisasi Kubernetes yang telah menunjukkan ketertarikannya untuk memeriksa _pull request_ dokumentasi dan telah ditambahkan ke dalam grup GitHub yang sesuai dan berkas-berkas `OWNERS` di dalam repositori GitHub, oleh seorang SIG Docs Approver. * Seorang SIG Docs _approver_ adalah seorang anggota yang memiliki predikat yang baik dan telah menunjukkan komitmen berkelanjutan terhadap proyek ini. Seorang _approver_ dapat melakukan _merge_ terhadap _pull request_ dan mempublikasi konten atas nama organisasi Kubernetes. Para _approver_ juga dapat mewakili SIG Docs dalam komunitas Kubernetes yang lebih besar. Beberapa tugas seorang SIG Docs _approver_, seperti mengkoordinasi sebuah perilisan, membutuhkan komitmen waktu yang signifikan. Cara-cara untuk berkontribusi ke dokumentasi -------------------------------------------- Daftar ini dibagi menjadi hal-hal yang dapat dilakukan oleh siapapun, hal-hal yang dapat dilakukan oleh anggota-anggota organisasi Kubernetes, dan hal-hal yang memerlukan tingkat akses yang lebih tinggi serta pengetahuan terhadap proses-proses SIG Docs. Berkontribusi secara konsisten dari waktu ke waktu dapat membantumu mengerti beberapa peralatan dan keputusan organisasi yang telah dibuat. Daftar ini bukanlah daftar lengkap mengenai cara-cara kamu dapat berkontribusi terhadap dokumentasi Kubernetes, tetapi daftar ini dapat membantumu memulainya. * [Siapapun](https://kubernetes.io/docs/contribute/start/) * Membuka _issue_ untuk ditindaklanjuti * [Member](https://kubernetes.io/docs/contribute/start/) * Memutakhirkan dokumentasi yang sudah ada * Menyampaikan ide-ide untuk pembaruan di [Slack](http://slack.k8s.io/) atau \[milis SIG docs\][SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) * Meningkatkan aksesibilitas dokumentasi * Memberikan umpan balik yang tidak memikat terhadap PR-PR * Menulis blog atau studi kasus * [Reviewer](https://kubernetes.io/docs/contribute/intermediate/) * Mendokumentasikan fitur-fitur baru * Menyortir dan mengkategorisasi masalah-masalah * Memeriksa PR-PR * Membuat diagram-diagram, aset grafis, dan _screencast_ atau video yang dapat di-_embed_ * Lokalisasi/penerjemahan * Berkontribusi pada repositori-repositori lain sebagai seorang wakil dokumentasi * Menyunting _user-facing strings_ di dalam kode * Memutakhirkan komentar-komentar pada kode, Godoc * [Approver](https://kubernetes.io/docs/contribute/advanced/) * Mempublikasi konten kontributor dengan menyetujui dan melakukan _merge_ terhadap PR-PR * Berpartisipasi di dalam sebuah tim rilis Kubernetes sebagai seorang wakil dokumentasi * Mengusulkan pemutakhiran terhadap petunjuk gaya penulisan * Mengusulkan pemutakhiran terhadap _test-test_ dokumentasi * Mengusulkan pemutakhiran terhadap situs web Kubernetes atau peralatan lainnya Cara-cara tambahan untuk berkontribusi -------------------------------------- * Untuk berkontribusi ke komunitas Kubernetes melalui forum-forum daring seperti Twitter atau Stack Overflow, atau mengetahui tentang pertemuan komunitas (_meetup_) lokal dan acara-acara Kubernetes, kunjungi [situs komunitas Kubernetes](https://kubernetes.io/id/community/) . * Untuk mulai berkontribusi ke pengembangan fitur, baca [_cheatseet_ kontributor](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) . * Untuk kontribusi khusus ke halaman Bahasa Indonesia, baca [Dokumentasi Khusus Untuk Translasi Bahasa Indonesia](https://kubernetes.io/id/docs/contribute/localization_id/) 1 - Menyarankan peningkatan kualitas konten =========================================== Jika kamu menemukan masalah pada dokumentasi Kubernetes, atau mempunyai ide untuk konten baru, maka silakan untuk membuat isu pada Github. Kamu hanya membutuhkan sebuah [akun Github](https://github.com/join) dan sebuah _web browser_. Pada kebanyakan kasus, pekerjaan dalam dokumentasi Kubernetes diawali dengan sebuah isu pada Github. Kontributor Kubernetes akan mengkaji, mengkategorisasi dan menandai isu sesuai kebutuhan. Selanjutnya, kamu atau anggota lain dari komunitas Kubernetes dapat membuat _pull request_ dengan perubahan yang akan menyelesaikan masalahnya. Membuka sebuah issue -------------------- Jika kamu mau menyarankan peningkatan kualitas pada konten yang sudah ada, atau menemukan kesalahan, maka silakan membuka sebuah isu. 1. Turun ke bagian bawah dari suatu halaman dan klik pada tombol **Buat Isu**. Ini akan mengantarmu pada halaman Github isu dengan beberapa tajuk yang telah diisi. 2. Deskripsikan isu atau saran untuk peningkatan kualitas. Sediakan detail sebanyak mungkin yang kamu bisa. 3. Klik **Submit new issue** Setelah dikirim, cek isu yang kamu buat secara berkala atau hidupkan notifikasi Github. Pengulas (_reviewer_) atau anggota komunitas lainnya mungkin akan menanyakan pertanyaan sebelum mereka mengambil suatu tindakan terhadap isumu. Menyarankan konten baru ----------------------- Jika kamu memiliki ide untuk konten baru, tapi kamu tidak yakin dimana mengutarakannya, kamu tetap dapat membuat sebuah isu. Antara lain: * Pilih halaman pada bagian yang menurutmu konten tersebut berhubungan dan klik **Buat Isu**. * Pergi ke [Github](https://github.com/kubernetes/website/issues/new/) dan langsung membuat isu. Bagaimana cara membuat isu yang bagus ------------------------------------- Perhatikan hal berikut ketika membuat sebuah isu: * Memberikan deskripsi isu yang jelas. Deskripsikan apa yang memang kurang, tertinggal, salah atau konten mana yang memerlukan peningkatan kualitas. * Jelaskan dampak spesifik dari isu terhadap pengguna. * Batasi cakupan dari sebuah isu menjadi ukuran pekerjaan yang masuk akal. Untuk masalah dengan cakupan yang besar, pecah isu itu menjadi beberapa isu lebih kecil. Misal, "Membenahi dokumentasi keamanan" masih sangat luas cakupannya, tapi "Penambahan detail pada topik 'Pembatasan akses jaringan'" adalah lebih spesifik untuk dikerjakan. * Mencari isu yang sudah ada untuk melihat apakah ada sesuatu yang berhubungan atau mirip dengan isu yang baru. * Jika isu yang baru berhubungan dengan isu lain atau _pull request_, tambahkan rujukan dengan menuliskan URL lengkap atau dengan nomor isu atau _pull request_ yang diawali dengan karakter `#`. Contohnya, `Diajukan oleh #987654`. * Mengikuti [Kode Etik Komunitas](https://kubernetes.io/id/community/code-of-conduct/) . Menghargai kontributor lain. Misalnya, "Dokumentasi ini sangat jelek" adalah contoh yang tidak membantu dan juga bukan masukan yang sopan. 2 - Berpartisipasi dalam SIG Docs ================================= SIG Docs merupakan salah satu [kelompok peminatan khusus (_special interest groups_)](https://github.com/kubernetes/community/blob/master/sig-list.md) dalam proyek Kubernetes, yang berfokus pada penulisan, pembaruan, dan pemeliharaan dokumentasi untuk Kubernetes secara keseluruhan. Lihatlah [SIG Docs dari repositori github komunitas](https://github.com/kubernetes/community/tree/master/sig-docs) untuk informasi lebih lanjut tentang SIG. SIG Docs menerima konten dan ulasan dari semua kontributor. Siapa pun dapat membuka _pull request_ (PR), dan siapa pun boleh mengajukan isu tentang konten atau komen pada _pull request_ yang sedang berjalan. Kamu juga bisa menjadi [anggota (_member_)](https://kubernetes.io/id/docs/contribute/participating/roles-and-responsibilities/#anggota) , [pengulas (_reviewer_](https://kubernetes.io/id/docs/contribute/participating/roles-and-responsibilities/#pengulas) , atau [pemberi persetujuan (_approver_)](https://kubernetes.io/id/docs/contribute/participating/roles-and-responsibilities/#approvers) . Peran tersebut membutuhkan akses dan mensyaratkan tanggung jawab tertentu untuk menyetujui dan melakukan perubahan. Lihatlah [keanggotaan-komunitas (_community-membership_)](https://github.com/kubernetes/community/blob/master/community-membership.md) untuk informasi lebih lanjut tentang cara kerja keanggotaan dalam komunitas Kubernetes. Selebihnya dari dokumen ini akan menguraikan beberapa cara unik dari fungsi peranan tersebut dalam SIG Docs, yang bertanggung jawab untuk memelihara salah satu aspek yang paling berhadapan dengan publik dalam Kubernetes - situs web dan dokumentasi dari Kubernetes. Ketua umum (_chairperson_) SIG Docs ----------------------------------- Setiap SIG, termasuk SIG Docs, memilih satu atau lebih anggota SIG untuk bertindak sebagai ketua umum. Mereka merupakan kontak utama antara SIG Docs dan bagian lain dari organisasi Kubernetes. Mereka membutuhkan pengetahuan yang luas tentang struktur proyek Kubernetes secara keseluruhan dan bagaimana SIG Docs bekerja di dalamnya. Lihatlah [Kepemimpinan (_leadership_)](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) untuk daftar ketua umum yang sekarang. Tim dan automasi dalam SIG Docs ------------------------------- Automasi dalam SIG Docs bergantung pada dua mekanisme berbeda: Tim GitHub dan berkas OWNERS. ### Tim GitHub Terdapat dua kategori tim dalam SIG Docs [tim (_teams_)](https://github.com/orgs/kubernetes/teams?query=sig-docs) dalam GitHub: * `@sig-docs-{language}-owners` merupakan pemberi persetujuan (_approver_) dan pemimpin (_lead_) * `@sig-docs-{language}-reviews` merupakan pengulas (_reviewer_) Setiap tim dapat direferensikan dengan `@name` mereka dalam komen GitHub untuk berkomunikasi dengan setiap orang di dalam grup. Terkadang tim Prow dan GitHub tumpang tindih (_overlap_) tanpa kecocokan sama persis. Untuk penugasan masalah, _pull request_, dan untuk mendukung persetujuan PR, otomatisasi menggunakan informasi dari berkas `OWNERS`. ### Berkas OWNERS dan bagian yang utama (_front-matter_) Proyek Kubernetes menggunakan perangkat otomatisasi yang disebut prow untuk melakukan automatisasi yang terkait dengan isu dan _pull request_ dalam GitHub. [Repositori situs web Kubernetes](https://github.com/kubernetes/website) menggunakan dua buah [prow _plugin_](https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins) ): * blunderbuss * approve Kedua _plugin_ menggunakan berkas [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) dan [OWNERS\_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) dalam level teratas dari repositori GitHub `kubernetes/website` untuk mengontrol bagaimana prow bekerja di dalam repositori. Berkas OWNERS berisi daftar orang-orang yang menjadi pengulas dan pemberi persetujuan di dalam SIG Docs. Berkas OWNERS juga bisa terdapat di dalam subdirektori, dan dapat menimpa peranan karena dapat bertindak sebagai pengulas atau pemberi persetujuan berkas untuk subdirektori itu dan apa saja yang ada di dalamnya. Untuk informasi lebih lanjut tentang berkas OWNERS pada umumnya, lihatlah [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) . Selanjutnya, berkas _markdown_ individu dapat menyimpan daftar pengulas dan pemberi persetujuan pada bagian yang utama, baik dengan menyimpan daftar nama pengguna individu GitHub atau grup GitHub. Kombinasi dari berkas OWNERS dan bagian yang utama dalam berkas _markdown_ menentukan saran kepada pemilik PR yang didapat dari sistem otomatis tentang siapa yang akan meminta ulasan teknis dan ulasan editorial untuk PR mereka. Cara menggabungkan pekerjaan ---------------------------- Ketika _pull request_ digabungkan ke cabang (_branch_) yang digunakan untuk mempublikasikan konten, konten itu dipublikasikan di [https://kubernetes.io](https://kubernetes.io/) . Untuk memastikan bahwa kualitas konten yang kita terbitkan bermutu tinggi, kita membatasi penggabungan _pull request_ bagi para pemberi persetujuan SIG Docs. Beginilah cara kerjanya. * Ketika _pull request_ memiliki label `lgtm` dan `approve`, tidak memiliki label `hold`, dan telah lulus semua tes, _pull request_ akan digabungkan secara otomatis. * Anggota organisasi Kubernetes dan pemberi persetujuan SIG Docs dapat menambahkan komen untuk mencegah penggabungan otomatis dari _pull request_ yang diberikan (dengan menambahkan komen `/hold` atau menahan komen `/lgtm`). * Setiap anggota Kubernetes dapat menambahkan label `lgtm` dengan menambahkan komen `lgtm` * Hanya pemberi persetujuan SIG Docs yang bisa menggabungkan _pull request_ dengan menambahkan komen `/approve`. Beberapa pemberi persetujuan juga dapat melakukan tugas tambahan seperti [PR _Wrangler_](https://kubernetes.io/id/docs/contribute/advanced#menjadi-pr-wrangler-untuk-seminggu) atau [Ketua Umum SIG Docs](https://kubernetes.io/id/docs/contribute/_print/#ketua-umum-sig-docs) . Selanjutnya ----------- Untuk informasi lebih lanjut tentang cara berkontribusi pada dokumentasi Kubernetes, lihatlah: * [Berkontribusi konten baru](https://kubernetes.io/id/docs/contribute/overview/) * [Mengulas konten](https://kubernetes.io/id/docs/contribute/review/reviewing-prs) * [Panduan gaya dokumentasi](https://kubernetes.io/id/docs/contribute/style/) 3 - Dokumentasi Khusus Untuk Translasi Bahasa Indonesia ======================================================= Panduan khusus untuk bergabung ke komunitas SIG DOC Indonesia dan melakukan kontribusi untuk menerjemahkan dokumentasi Kubernetes ke dalam Bahasa Indonesia. Manajemen _Milestone_ Tim ------------------------- Secara umum siklus translasi dokumentasi ke Bahasa Indonesia akan dilakukan 3 kali dalam setahun (sekitar setiap 4 bulan). Untuk menentukan dan mengevaluasi pencapaian atau _milestone_ dalam kurun waktu tersebut [jadwal rapat daring reguler tim Bahasa Indonesia](https://zoom.us/j/6072809193) dilakukan secara konsisten setiap dua minggu sekali. Dalam [agenda rapat ini](https://docs.google.com/document/d/1Qrj-WUAMA11V6KmcfxJsXcPeWwMbFsyBGV4RGbrSRXY) juga dilakukan pemilihan PR _Wrangler_ untuk dua minggu ke depan. Tugas PR _Wrangler_ tim Bahasa Indonesia serupa dengan PR _Wrangler_ dari proyek _upstream_. Target pencapaian atau _milestone_ tim akan dirilis sebagai [_issue tracking_ seperti ini](https://github.com/kubernetes/website/issues/22296) pada Kubernetes GitHub Website setiap 4 bulan. Dan bersama dengan informasi PR _Wrangler_ yang dipilih setiap dua minggu, keduanya akan diumumkan di Slack _channel_ [#kubernetes-docs-id](https://kubernetes.slack.com/archives/CJ1LUCUHM) dari Komunitas Kubernetes. Cara Memulai Translasi ---------------------- Untuk menerjemahkan satu halaman Bahasa Inggris ke Bahasa Indonesia, lakukan langkah-langkah berikut ini: * Periksa halaman _issue_ di GitHub dan pastikan tidak ada orang lain yang sudah mengklaim halaman kamu dalam daftar periksa atau komentar-komentar sebelumnya. * Klaim halaman kamu pada _issue_ di GitHub dengan memberikan komentar di bawah dengan nama halaman yang ingin kamu terjemahkan dan ambillah hanya satu halaman dalam satu waktu. * _Fork_ [repo ini](https://github.com/kubernetes/website) , buat terjemahan kamu, dan kirimkan PR (_pull request_) dengan label `language/id`. * Setelah dikirim, pengulas akan memberikan komentar dalam beberapa hari, dan tolong untuk menjawab semua komentar. Direkomendasikan juga untuk melakukan [_squash_](https://github.com/wprig/wprig/wiki/How-to-squash-commits) _commit_ kamu dengan pesan _commit_ yang baik. Informasi Acuan Untuk Translasi ------------------------------- Tidak ada panduan gaya khusus untuk menulis translasi ke bahasa Indonesia. Namun, secara umum kita dapat mengikuti panduan gaya bahasa Inggris dengan beberapa tambahan untuk kata-kata impor yang dicetak miring. Harap berkomitmen dengan terjemahan kamu dan pada saat kamu mendapatkan komentar dari pengulas, silakan atasi sebaik-baiknya. Kami berharap halaman yang diklaim akan diterjemahkan dalam waktu kurang lebih dua minggu. Jika ternyata kamu tidak dapat berkomitmen lagi, beri tahu para pengulas agar mereka dapat meberikan halaman tersebut ke orang lain. Beberapa acuan tambahan dalam melakukan translasi silakan lihat informasi berikut ini: ### Daftar Glosarium Translasi dari tim SIG DOC Indonesia Untuk kata-kata selengkapnya silakan baca glosariumnya di [sini](https://kubernetes.io/id/docs/contribute/_print/#glosarium-indonesia) . ### KBBI Konsultasikan dengan situs KBBI (Kamus Besar Bahasa Indonesia) di [sini](https://kbbi.web.id/) atau situs dari Kemendikbud di [sini](https://kbbi.kemdikbud.go.id/) . ### RSNI Glosarium dari Ivan Lanin [RSNI Glosarium](https://github.com/jk8s/sig-docs-id-localization-how-tos/blob/master/resources/RSNI-glossarium.pdf) dapat digunakan untuk memahami bagaimana menerjemahkan berbagai istilah teknis dan khusus Kubernetes. Panduan Penulisan _Source Code_ ------------------------------- ### Mengikuti kode asli dari dokumentasi bahasa Inggris Untuk kenyamanan pemeliharaan, ikuti lebar teks asli dalam kode bahasa Inggris. Dengan kata lain, jika teks asli ditulis dalam baris yang panjang tanpa putus satu baris, maka teks tersebut ditulis panjang dalam satu baris meskipun dalam bahasa Indonesia. Jagalah agar tetap serupa. ### Hapus nama pengulas di kode asli bahasa Inggris Terkadang pengulas ditentukan di bagian atas kode di teks asli Bahasa Inggris. Secara umum, pengulas-pengulas halaman aslinya akan kesulitan untuk meninjau halaman dalam bahasa Indonesia, jadi hapus kode yang terkait dengan informasi pengulas dari metadata kode tersebut. Panduan Penulisan Kata-kata Translasi ------------------------------------- ### Panduan umum * Gunakan "kamu" daripada "Anda" sebagai subyek agar lebih bersahabat dengan para pembaca dokumentasi. * Tulislah miring untuk kata-kata bahasa Inggris yang diimpor jika kamu tidak dapat menemukan kata-kata tersebut dalam bahasa Indonesia. * ✅ Benar: _controller_. * ❌ Salah: controller, `controller`. * Selalu rujuk setiap istilah teknis saat pertama kali disebutkan dalam dokumen ke glosarium. * Gunakan kalimat aktif bila memungkinkan. * ✅ Benar: "Pod menjalankan satu atau lebih kontainer." * ❌ Salah: "Sebuah Pod menjalankan satu atau lebih kontainer." (terlalu kaku) * Jangan menerjemahkan perintah CLI atau keluaran perintah CLI (misalnya, `kubectl get pods` harus tetap dalam bahasa Inggris). * Ikuti terjemahan di [Glosarium Indonesia](https://kubernetes.io/id/docs/contribute/_print/#glosarium-indonesia) . ### Panduan untuk kata-kata API Objek Kubernetes Gunakan gaya "CamelCase" untuk menulis objek API Kubernetes, lihat daftar lengkapnya [di sini](https://kubernetes.io/docs/reference/kubernetes-api/) . Sebagai contoh: * PersistentVolume * ✅ Benar: PersistentVolume. * ❌ Salah: volume persisten, `PersistentVolume`, persistentVolume. * Pod * ✅ Benar: Pod. * ❌ Salah: pod, `pod`, "pod". 💡 _Tips_: Biasanya API objek sudah ditulis dalam huruf kapital pada halaman asli bahasa Inggris. ### Panduan untuk kata-kata yang sama dengan API Objek Kubernetes Ada beberapa kata-kata yang serupa dengan nama API objek dari Kubernetes dan dapat mengacu ke arti yang lebih umum (tidak selalu dalam konteks Kubernetes). Sebagai contoh: _service_, _container_, _node_ , dan lain sebagainya. Kata-kata sebaiknya diterjemahkan ke Bahasa Indonesia sebagai contoh _service_ menjadi layanan, _container_ menjadi kontainer. 💡 _Tips_: Biasanya kata-kata yang mengacu ke arti yang lebih umum sudah _tidak_ ditulis dalam huruf kapital pada halaman asli bahasa Inggris. ### Panduan untuk "Feature Gate" Kubernetes Istilah [_feature gate_](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) Kubernetes tidak perlu diterjemahkan ke dalam bahasa Indonesia dan tetap dipertahankan dalam bentuk aslinya. Contoh dari _feature gate_ adalah sebagai berikut: * AllowUnsafeMalformedObjectDeletion * AnonymousAuthConfigurableEndpoints * APIResponseCompression * ... ### Glosarium Indonesia | **Inggris** | **Indonesia** | **Catatan** | **Sumber** | | --- | --- | --- | --- | | Add-ons | ... | ... | ... | | Admission Controller | ... | ... | ... | | Affinity | Afinitas | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/afinitas](https://kbbi.kemdikbud.go.id/entri/afinitas) | | Aggregation Layer | Lapisan Agregasi | Dilokalkan | ... | | Annotation | Anotasi | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/anotasi](https://kbbi.kemdikbud.go.id/entri/anotasi) | | API Group | Grup API | Dilokalkan | ... | | API Resource | Sumber Daya API | Dilokalkan | ... | | API Server | Server API | Dilokalkan | ... | | API-initiated eviction | ... | ... | ... | | App Container | Kontainer Aplikasi | Dilokalkan | ... | | Application Architect | Aplikasi Arsitek | Dilokalkan | ... | | Applications | Aplikasi | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/aplikasi](https://kbbi.kemdikbud.go.id/entri/aplikasi) | | Approver | Pemberi Persetujuan | Dilokalkan | ... | | cAdvisor | cAdvisor | Tetap | ... | | Certificate | Sertifikat | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/sertifikat](https://kbbi.kemdikbud.go.id/entri/sertifikat) | | cgroup (control group) | cgroup (control group) | Tetap | ... | | CIDR | CIDR | Tetap | ... | | CLA (Contributor License Agreement) | CLA (Contributor License Agreement) | Tetap | ... | | Cluster | Klaster | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/klaster](https://kbbi.kemdikbud.go.id/entri/klaster) | | ConfigMap | ConfigMap | Tetap | ... | | Container | Kontainer | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/kontainer](https://kbbi.kemdikbud.go.id/entri/kontainer) | | Container Environment Variables | ... | ... | ... | | Container Lifecycle Hooks | ... | ... | ... | | Container Network Interface (CNI) | ... | ... | ... | | Container Runtime | ... | ... | ... | | Container Runtime Interface (CRI) | ... | ... | ... | | Container Storage Interface (CSI) | ... | ... | ... | | containerd | containerd | Tetap | ... | | Contributor | Kontributor | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/kontributor](https://kbbi.kemdikbud.go.id/entri/kontributor) | | Control Plane | ... | ... | ... | | Controller | Pengontrol | Dilokalkan | ... | | CRI-O | ... | ... | ... | | CronJob | CronJob | Tetap | ... | | CustomResourceDefinition | ... | ... | ... | | DaemonSet | DaemonSet | Tetap | ... | | Data Plane | ... | ... | ... | | Deployment | Deployment | Tetap | ... | | Developer | ... | ... | ... | | Device Plugin | ... | ... | ... | | Disruption | Disrupsi | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/disrupsi](https://kbbi.kemdikbud.go.id/entri/disrupsi) | | Docker | Docker | Tetap | ... | | Dockershim | Dockershim | Tetap | ... | | Downstream | ... | ... | ... | | Downward API | ... | ... | ... | | Drain | ... | ... | ... | | Duration | Durasi | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/durasi](https://kbbi.kemdikbud.go.id/entri/durasi) | | Dynamic Volume Provisioning | ... | ... | ... | | Endpoints | ... | ... | ... | | EdnpointSlice | ... | ... | ... | | Ephemeral Container | Kontainer Sementara | Dilokalkan | ... | | etcd | etcd | Tetap | ... | | Event | ... | ... | ... | | Eviction | Pengusiran | Dilokalkan | ... | | Extensions | Ekstensi | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/ekstensi](https://kbbi.kemdikbud.go.id/entri/ekstensi) | | Feature gate | ... | ... | ... | | Finalizer | ... | ... | ... | | FlexVolume | FlexVolume | Tetap | ... | | Garbage Collection | ... | ... | ... | | Gateway API | ... | ... | ... | | Group Version Resource | ... | ... | ... | | Helm Chart | ... | ... | ... | | Horizontal Pod Autoscaler | ... | ... | ... | | HostAliases | HostAliases | Tetap | ... | | Image | Image | Tetap | ... | | Immutable Infrastucture | ... | ... | ... | | Ingress | Ingress | Tetap | ... | | Init Container | Kontainer Inisiasi | Dilokalkan | ... | | Istio | Istio | Tetap | ... | | Job | Job | Tetap | ... | | JSON Web Token (JWT) | JSON Web Token (JWT) | Tetap | ... | | kOps (Kubernetes Operations) | kOps (Operasi Kubernetes) | Dilokalkan | ... | | kube-controller-manager | kube-controller-manager | Tetap | ... | | kube-proxy | kube-proxy | Tetap | ... | | kube-scheduler | kube-scheduler | Tetap | ... | | Kubeadm | Kubeadm | Tetap | ... | | Kubectl | Kubectl | Tetap | ... | | Kubelet | Kubelet | Tetap | ... | | Kubernetes API | API Kubernetes | Dilokalkan | ... | | Label | Label | Tetap, Label juga adalah Label dalam Bahasa | [https://kbbi.kemdikbud.go.id/entri/label](https://kbbi.kemdikbud.go.id/entri/label) | | LimitRange | LimitRange | Tetap | ... | | Logging | ... | ... | ... | | Managed Service | ... | ... | ... | | Manifest | Manifes | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/manifes](https://kbbi.kemdikbud.go.id/entri/manifes) | | Master | Master | Tetap, Master juga adalah Master dalam Bahasa | [https://kbbi.kemdikbud.go.id/entri/master](https://kbbi.kemdikbud.go.id/entri/master) | | Member | Anggota | Dilokalkan | ... | | Minikube | Minikube | Tetap | ... | | Mirror Pod | ... | ... | ... | | Mixed Version Proxy (MVP) | ... | ... | ... | | Name | Name | Tetap | ... | | Namespace | Namespace | Tetap | ... | | Network Policy | ... | ... | ... | | Node | Node | Tetap | ... | | Node-pressure eviction | ... | ... | ... | | Object | Objek | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/objek](https://kbbi.kemdikbud.go.id/entri/objek) | | Operator pattern | ... | ... | ... | | Persistent Volume | Persistent Volume | Tetap | ... | | Persistent Volume Claim | Persistent Volume Claim | Tetap | ... | | Platform Developer | ... | ... | ... | | Pod | Pod | Tetap (widely understood) | ... | | Pod Disruption | Disrupsi Pod | Dilokalkan | ... | | Pod Disruption Budget | ... | ... | ... | | Pod Lifecycle | ... | ... | ... | | Pod Priority | Prioritas Pod | Dilokalkan | ... | | Pod Security Admission | ... | ... | ... | | Pod Security Policy | ... | ... | ... | | PodTemplate | PodTemplate | Tetap | ... | | Preemption | ... | ... | ... | | PriorityClass | PriorityClass | Tetap | ... | | Probe | ... | ... | ... | | Proxy | ... | ... | ... | | QoS Class | Kelas QoS | Dilokalkan | ... | | Quantity | Kuantitas | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/kuantitas](https://kbbi.kemdikbud.go.id/entri/kuantitas) | | RBAC (Role-Based Access Control) | RBAC (Role-Based Access Control) | Tetap | ... | | Replica | ... | ... | ... | | ReplicaSet | ReplicaSet | Tetap | ... | | ReplicationController | ReplicationController | Tetap | ... | | Resource (infrastructure) | ... | ... | ... | | Resource Quotas | ... | ... | ... | | Reviewer | Pengulas | Dilokalkan | [https://kbbi.kemdikbud.go.id/entri/pengulas](https://kbbi.kemdikbud.go.id/entri/pengulas) | | Secret | Secret | Tetap | ... | | Security Context | ... | ... | ... | | Selector | ... | ... | ... | | Service | Servis | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/servis](https://kbbi.kemdikbud.go.id/entri/servis) | | Service Catalog | ... | ... | ... | | ServiceAccount | ServiceAccount | Tetap | ... | | Shuffle-sharding | Shuffle-sharding | Tetap | ... | | Sidecar Container | Kontainer Sidecar | Dilokalkan | ... | | SIG (special interest group) | SIG (special interest group) | Tetap | ... | | Spec | Spec | Tetap | ... | | StatefulSet | StatefulSet | Tetap | ... | | Static Pod | Pod Statis | Dilokalkan | ... | | Storage Class | ... | ... | ... | | sysctl | sysctl | Tetap | ... | | Taint | ... | ... | ... | | Toleration | Toleransi | Ejaan yang disesuaikan | [https://kbbi.kemdikbud.go.id/entri/toleransi](https://kbbi.kemdikbud.go.id/entri/toleransi) | | UID | UID | Tetap | ... | | Upstream | ... | ... | ... | | user namespace | ... | ... | ... | | Volume | Volume | Tetap | ... | | Volume Plugin | Volume Plugin | Tetap | ... | | Watch | Watch | Tetap | ... | | WG (working group) | ... | ... | ... | | Workload | ... | ... | ... | --- # টাস্ক | Kubernetes এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। [মুদ্রণ করতে এখানে ক্লিক করুন](https://kubernetes.io/bn/docs/tasks/_print/#) . [এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন](https://kubernetes.io/bn/docs/tasks/) . টাস্ক ===== * 1: [টুল ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#pg-57bf66f59d9a642b82eebeabbc66470b) * 1.1: [macOS এ kubectl ইনস্টল এবং সেট আপ করুন](https://kubernetes.io/bn/docs/tasks/_print/#pg-961fc70b732cb8df4fd11a3463b6545c) * 1.2: [উইন্ডোজে kubectl ইনস্টল এবং সেট আপ করুন](https://kubernetes.io/bn/docs/tasks/_print/#pg-2cc93d3011d707aeb6564bab02048f7a) * 1.3: [লিনাক্সে kubectl ইনস্টল এবং সেট আপ করুন](https://kubernetes.io/bn/docs/tasks/_print/#pg-37b6179f23c8ad977cb9daa6d2da748a) কুবারনেটিস ডকুমেন্টেশনের এই বিভাগে এমন পৃষ্ঠা রয়েছে যা দেখায় কিভাবে পৃথক টাস্ক করতে হয়। সাধারণত পদক্ষেপের একটি সংক্ষিপ্ত ক্রম দিয়ে একটি টাস্ক পেজ দেখায় কিভাবে একটি একক জিনিস করতে হয়। আপনি যদি একটি টাস্ক পৃষ্ঠা লিখতে চান, দেখুন কীভাবে [একটি ডকুমেন্টেশন পুল রিকোয়েস্ট তৈরি করা](https://kubernetes.io/docs/contribute/new-content/open-a-pr/) যায়। 1 - টুল ইনস্টল করুন =================== আপনার কম্পিউটারে কুবারনেটিস টুল সেট আপ করুন। kubectl ------- কুবারনেটিস কমান্ড-লাইন টুল, [kubectl](https://kubernetes.io/docs/reference/kubectl/kubectl/) আপনাকে কুবারনেটিস ক্লাস্টারগুলির বিরুদ্ধে কমান্ড চালাতে অনুমতি দেয় । আপনি অ্যাপ্লিকেশন স্থাপন করতে, ক্লাস্টার সংস্থান পরিদর্শন ও পরিচালনা করতে এবং লগ দেখতে kubectl ব্যবহার করতে পারেন। আরও তথ্যের জন্য kubectl অপারেশনগুলির একটি সম্পূর্ণ তালিকা সহ দেখুন [`kubectl` রেফারেন্স ডকুমেন্টেশন](https://kubernetes.io/docs/reference/kubectl/) । kubectl বিভিন্ন লিনাক্স প্ল্যাটফর্ম, macOS এবং Windows এ ইনস্টলযোগ্য। নীচে আপনার পছন্দের অপারেটিং সিস্টেম খুঁজুন। * [লিনাক্সে kubectl ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/tools/install-kubectl-linux) * [macOS-এ kubectl ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/tools/install-kubectl-macos) * [উইন্ডোজে kubectl ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/tools/install-kubectl-windows) kind ---- [`kind`](https://kind.sigs.k8s.io/) আপনাকে কুবারনেটিস চালাতে দেয় আপনার স্থানীয় কম্পিউটারে। আপনি [ডকার](https://www.docker.com/) অথবা [পডম্যান](https://podman.io/) ইনস্টল এবং কনফিগার করুন। এই ধরনের [কুইক শুরু](https://kind.sigs.k8s.io/docs/user/quick-start/) পৃষ্ঠা আপনাকে কী করতে হবে তা দেখায়। [বিভিন্ন ধরনের কুইক স্টার্ট গাইড দেখুন](https://kind.sigs.k8s.io/docs/user/quick-start/) minikube -------- `kind` এর মতো, [`minikube`](https://minikube.sigs.k8s.io/) একটি টুল যা আপনাকে স্থানীয়ভাবে কুবারনেটিস চালাতে দেয় । `minikube` আপনার ব্যক্তিগত কম্পিউটারের (উইন্ডোজ, ম্যাকোস এবং লিনাক্স পিসি সহ) উপর একটি একক-নোড কুবারনেটিস ক্লাস্টার চালায় যাতে আপনি চেষ্টা করে দেখতে পারেন কুবারনেটিস, বা দৈনন্দিন উন্নয়ন কাজের জন্য। আপনি অফিসিয়াল নির্দেশিকা [শুরু করুন!](https://minikube.sigs.k8s.io/docs/start/) অনুসরণ করতে পারেন যদি আপনার ফোকাস হয় টুল ইনস্টল করার উপর। [minikube শুরু করুন! গাইডটি দেখুন](https://minikube.sigs.k8s.io/docs/start/) একবার আপনার `minikube` কাজ করলে, আপনি এটি [একটি নমুনা অ্যাপ্লিকেশন চালাতে](https://kubernetes.io/bn/docs/tutorials/hello-minikube/) ব্যবহার করতে পারেন । kubeadm ------- আপনি কুবারনেটিস ক্লাস্টার তৈরি এবং পরিচালনা করতে [kubeadm](https://kubernetes.io/bn/docs/reference/setup-tools/kubeadm/ "A tool for quickly installing Kubernetes and setting up a secure cluster.") টুল ব্যবহার করতে পারেন। এটি একটি ন্যূনতম কার্যকর, নিরাপদ ক্লাস্টার আপ এবং ব্যবহারকারী বান্ধব উপায়ে চালানোর জন্য প্রয়োজনীয় ক্রিয়া সম্পাদন করে। [kubeadm ইনস্টল করা](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) আপনাকে দেখায় কিভাবে kubeadm ইনস্টল করতে হয়। একবার ইনস্টল হয়ে গেলে আপনি এটিকে [একটি ক্লাস্টার তৈরি করতে](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) ব্যবহার করতে পারেন। [kubeadm ইনস্টল গাইড দেখুন](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 1.1 - macOS এ kubectl ইনস্টল এবং সেট আপ করুন ============================================ শুরু করার আগে ------------- আপনাকে অবশ্যই একটি kubectl সংস্করণ ব্যবহার করতে হবে যা আপনার ক্লাস্টারের একটি ছোট সংস্করণের পার্থক্যের মধ্যে রয়েছে। উদাহরণস্বরূপ, একটি v1.35 ক্লায়েন্ট v1.34, v1.35, এবং v1.36 নিয়ন্ত্রণ প্লেন এর সাথে যোগাযোগ করতে পারে। kubectl এর সর্বশেষ সামঞ্জস্যপূর্ণ সংস্করণ ব্যবহার করা অপ্রত্যাশিত সমস্যাগুলি এড়াতে সাহায্য করে৷ macOS এ kubectl ইনস্টল করুন --------------------------- macOS এ kubectl ইনস্টল করার জন্য নিম্নলিখিত পদ্ধতি রয়েছেঃ * [macOS এ kubectl ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-kubectl-on-macos) * [macOS-এ কার্ল দিয়ে kubectl বাইনারি ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-kubectl-binary-with-curl-on-macos) * [MacOS এ Homebrew দিয়ে ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-with-homebrew-on-macos) * [MacOS এ Macports দিয়ে ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-with-macports-on-macos) * [kubectl কনফিগারেশন যাচাই করুন](https://kubernetes.io/bn/docs/tasks/_print/#verify-kubectl-configuration) * [বাড়তি kubectl কনফিগারেশন এবং প্লাগইন](https://kubernetes.io/bn/docs/tasks/_print/#optional-kubectl-configurations-and-plugins) * [শেল অটোকমপ্লিট সক্ষম করুন](https://kubernetes.io/bn/docs/tasks/_print/#enable-shell-autocompletion) * [`kubectl convert` প্লাগইন ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-kubectl-convert-plugin) ### macOS-এ কার্ল সহ kubectl বাইনারি ইনস্টল করুন ১. সর্বশেষ রিলিজ ডাউনলোড করুন: * [Intel](https://kubernetes.io/bn/docs/tasks/_print/#download-binary-macos-0) * [Apple Silicon](https://kubernetes.io/bn/docs/tasks/_print/#download-binary-macos-1) curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl" #### বিঃদ্রঃ: একটি নির্দিষ্ট সংস্করণ ডাউনলোড করতে, নির্দিষ্ট সংস্করণের সাথে কমান্ডের `$(curl -L -s https://dl.k8s.io/release/stable.txt)` অংশটি প্রতিস্থাপন করুন। উদাহরণস্বরূপ, Intel macOS-এ সংস্করণ 1.35.0 ডাউনলোড করতে, টাইপ করুন: curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/amd64/kubectl" এবং অ্যাপল সিলিকনে macOS এর জন্য, টাইপ করুন: curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/arm64/kubectl" ২. বাইনারি যাচাই করুন (ঐচ্ছিক) kubectl checksum ফাইল ডাউনলোড করুন: * [Intel](https://kubernetes.io/bn/docs/tasks/_print/#download-checksum-macos-0) * [Apple Silicon](https://kubernetes.io/bn/docs/tasks/_print/#download-checksum-macos-1) curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256" চেকসাম ফাইলের বিপরীতে kubectl বাইনারি যাচাই করুন: echo "$(cat kubectl.sha256) kubectl" | shasum -a 256 --check বৈধ হলে, আউটপুট হল: kubectl: OK চেক ব্যর্থ হলে, `shasum` অশূন্য স্থিতি সহ প্রস্থান করে এবং অনুরূপ আউটপুট প্রিন্ট করে: kubectl: FAILED shasum: WARNING: 1 computed checksum did NOT match #### বিঃদ্রঃ: বাইনারি এবং চেকসামের একই সংস্করণ ডাউনলোড করুন। ৩. kubectl বাইনারি এক্সিকিউটেবল করুন। chmod +x ./kubectl ৪. আপনার সিস্টেম `PATH`\-এ একটি ফাইল অবস্থানে kubectl বাইনারি সরান। sudo mv ./kubectl /usr/local/bin/kubectl sudo chown root: /usr/local/bin/kubectl #### বিঃদ্রঃ: নিশ্চিত করুন যে `/usr/local/bin` আপনার PATH এনভায়রনমেন্ট ভেরিয়েবলে আছে। ৫. আপনার ইনস্টল করা সংস্করণ আপ-টু-ডেট কিনা তা নিশ্চিত করতে পরীক্ষা করুন: kubectl version --client #### বিঃদ্রঃ: উপরের কমান্ডটি একটি সতর্কতা তৈরি করবে: WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. আপনি এই সতর্কতা উপেক্ষা করতে পারেন. আপনি শুধুমাত্র `kubectl` এর যে সংস্করণটি ইনস্টল করেছেন তা পরীক্ষা করছেন। অথবা সংস্করণের বিস্তারিত দেখার জন্য এটি ব্যবহার করুন: kubectl version --client --output=yaml ৬. প্লাগইন ইনস্টল করার পরে, ইনস্টলেশন ফাইলগুলি পরিষ্কার করুন: rm kubectl kubectl.sha256 ### MacOS এ Homebrew দিয়ে ইনস্টল করুন আপনি যদি macOS-এ থাকেন এবং [Homebrew](https://brew.sh/) প্যাকেজ ম্যানেজার ব্যবহার করেন, তাহলে আপনি Homebrew-এর সাথে kubectl ইনস্টল করতে পারেন। ১. ইনস্টলেশন কমান্ড চালান: brew install kubectl অথবা, brew install kubernetes-cli ২. আপনার ইনস্টল করা সংস্করণ আপ-টু-ডেট কিনা তা নিশ্চিত করতে পরীক্ষা করুন: kubectl version --client ### MacOS এ Macports দিয়ে ইনস্টল করুন আপনি যদি macOS এ থাকেন এবং [Macports](https://macports.org/) প্যাকেজ ম্যানেজার ব্যবহার করেন, তাহলে আপনি ম্যাকপোর্টের সাথে kubectl ইনস্টল করতে পারেন। ১. ইনস্টলেশন কমান্ড চালান: sudo port selfupdate sudo port install kubectl ২. আপনার ইনস্টল করা সংস্করণ আপ-টু-ডেট কিনা তা নিশ্চিত করতে পরীক্ষা করুন: kubectl version --client kubectl কনফিগারেশন যাচাই করুন ----------------------------- kubectl-এর জন্য একটি কুবারনেটিস ক্লাস্টার খুঁজে পেতে এবং অ্যাক্সেস পেতে, যার জন্য প্রয়োজন [kubeconfig ফাইল](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) , যা স্বয়ংক্রিয়ভাবে তৈরি হয় যখন আপনি একটি ক্লাস্টার তৈরি করেন [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) ব্যবহার করে অথবা সফলভাবে একটি Minikube ক্লাস্টার স্থাপন করুন। ডিফল্টরূপে, kubectl কনফিগারেশন `~/.kube/config` এ অবস্থিত। ক্লাস্টার অবস্থা পেয়ে kubectl সঠিকভাবে কনফিগার করা হয়েছে তা পরীক্ষা করুন: kubectl cluster-info আপনি যদি একটি URL দেখতে পান, তাহলে আপনার ক্লাস্টার অ্যাক্সেস করার জন্য kubectl সঠিকভাবে কনফিগার করা হয়েছে। আপনি যদি নিম্নলিখিতগুলোর মতো একটি বার্তা দেখতে পান, তাহলে বুঝবেন যে kubectl সঠিকভাবে কনফিগার করা হয়নি অথবা একটি Kubernetes ক্লাস্টারের সাথে সংযোগ করতে সক্ষম নয়। সার্ভারের সাথে সংযোগ প্রত্যাখ্যান করা হয়েছিল - আপনি কি সঠিক হোস্ট বা পোর্ট উল্লেখ করেছেন? উদাহরণস্বরূপ, আপনি যদি আপনার ল্যাপটপে (স্থানীয়ভাবে) একটি কুবারনেটিস ক্লাস্টার চালাতে চান, তাহলে আপনাকে প্রথমে মিনিকুবের মতো একটি টুল ইনস্টল করতে হবে এবং তারপরে উপরে বর্ণিত কমান্ডগুলি পুনরায় চালাতে হবে। যদি kubectl ক্লাস্টার-তথ্য url প্রতিক্রিয়া প্রদান করে কিন্তু আপনি আপনার ক্লাস্টার অ্যাক্সেস করতে না পারেন, এটি সঠিকভাবে কনফিগার করা হয়েছে কিনা তা পরীক্ষা করতে, ব্যবহার করুন: kubectl cluster-info dump ### 'No Auth Provider Found' ত্রুটি বার্তার সমস্যা সমাধান কুবারনেটিস 1.26-এ, kubectl নিম্নলিখিত ক্লাউড প্রদানকারীদের পরিচালিত কুবারনেটিস অফারগুলোর জন্য অন্তর্নির্মিত অথেনটিকেশন সরিয়ে দিয়েছে। এই প্রদানকারীরা ক্লাউডের-নির্দিষ্ট অথেনটিকেশন প্রদানের জন্য kubectl প্লাগইন প্রকাশ করেছে। নির্দেশাবলীর জন্য, নিম্নলিখিত প্রদানকারী ডকুমেন্টেশন পড়ুন: * Azure AKS: [kubelogin plugin](https://azure.github.io/kubelogin/) * Google Kubernetes Engine: [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin) (একই ত্রুটির বার্তা দেখার অন্যান্য কারণও থাকতে পারে, এই পরিবর্তনের সাথে সম্পর্কিত নয়।) ঐচ্ছিক kubectl কনফিগারেশন এবং প্লাগইন ------------------------------------- ### শেল অটোকমপ্লিট সক্ষম করুন kubectl Bash, Zsh, Fish এবং PowerShell-এর জন্য অটোকমপ্লিট সমর্থন প্রদান করে যা আপনাকে অনেক টাইপিং বাঁচাতে পারে। নীচে Bash, Fish, এবং Zsh-এর জন্য স্বয়ংসম্পূর্ণতা সেট আপ করার পদ্ধতিগুলি রয়েছে৷ * [Bash](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-autocompletion-0) * [Fish](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-autocompletion-1) * [Zsh](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-autocompletion-2) ### ভূমিকা Bash-এর জন্য kubectl কমপ্লিশন স্ক্রিপ্ট `kubectl completion bash` দিয়ে তৈরি করা যেতে পারে। আপনার শেলে এই স্ক্রিপ্টটি সোর্স করা kubectl সম্পূর্ণতা সক্ষম করে। কিন্তু, kubectl কমপ্লিসন স্ক্রিপ্ট নির্ভর করে [**bash-completion**](https://github.com/scop/bash-completion) যা আপনাকে আগে ইনস্টল করতে হবে। #### সতর্কতা: bash-completion এর দুটি সংস্করণ আছে, v1 এবং v2। V1 Bash 3.2 এর জন্য (যা macOS-এ ডিফল্ট), এবং v2 হল Bash 4.1+ এর জন্য। kubectl পূর্ণতা স্ক্রিপ্ট \*\* কাজ করে না\*\* সঠিকভাবে bash-completion v1 এবং Bash 3.2 এর সাথে। এর জন্য **ব্যাশ-সম্পূর্ণ v2** এবং **ব্যাশ 4.1+** প্রয়োজন। সুতরাং, macOS-এ kubectl সমাপ্তি সঠিকভাবে ব্যবহার করতে সক্ষম হতে, আপনাকে Bash 4.1+ ([_instructions_](https://apple.stackexchange.com/a/292760) ) ইনস্টল এবং ব্যবহার করতে হবে। নিম্নলিখিত নির্দেশাবলী অনুমান করে যে আপনি Bash 4.1+ ব্যবহার করেন (অর্থাৎ, 4.1 বা তার পরবর্তী যেকোনো Bash সংস্করণ)। ### Bash আপগ্রেড করুন এখানে নির্দেশাবলী অনুমান করে আপনি ব্যাশ 4.1+ ব্যবহার করছেন। আপনি রান করে আপনার ব্যাশের সংস্করণটি পরীক্ষা করতে পারেন: echo $BASH_VERSION যদি এটি খুব পুরানো হয়, আপনি Homebrew ব্যবহার করে এটি ইনস্টল/আপগ্রেড করতে পারেন: brew install bash আপনার শেল পুনরায় লোড করুন এবং যাচাই করুন যে পছন্দসই সংস্করণটি ব্যবহার করা হচ্ছে: echo $BASH_VERSION $SHELL Homebrew সাধারণত `/usr/local/bin/bash` এ ইনস্টল হয়। ### ব্যাশ-কমপ্লিসন ইনস্টল করুন #### বিঃদ্রঃ: উল্লিখিত হিসাবে, এই নির্দেশাবলী অনুমান করে আপনি Bash 4.1+ ব্যবহার করেন, যার মানে আপনি bash-completion v2 ইনস্টল করবেন (Bash 3.2 এবং bash-completion v1 এর বিপরীতে, এই ক্ষেত্রে kubectl সমাপ্তি কাজ করবে না)। আপনি পরীক্ষা করতে পারেন যদি আপনার bash-completion v2 ইতিমধ্যেই `type _init_completion` দিয়ে ইনস্টল করা আছে। যদি না হয়, আপনি homebrew দিয়ে এটি ইনস্টল করতে পারেন: brew install bash-completion@2 এই কমান্ডের আউটপুটে যেমন বলা হয়েছে, আপনার `~/.bash_profile` ফাইলে নিম্নলিখিত যোগ করুন: brew_etc="$(brew --prefix)/etc" && [[ -r "${brew_etc}/profile.d/bash_completion.sh" ]] && . "${brew_etc}/profile.d/bash_completion.sh" আপনার শেল পুনরায় লোড করুন এবং যাচাই করুন যে bash-completion v2 সঠিকভাবে `type _init_completion` দিয়ে ইনস্টল করা আছে। ### kubectl অটোকমপ্লিসন চালু করুন আপনাকে এখন নিশ্চিত করতে হবে যে আপনার সমস্ত শেল সেশনে kubectl কমপ্লিসনের স্ক্রিপ্টটি পাওয়া যায়। এটি অর্জন করার একাধিক উপায় রয়েছে: * আপনার `~/.bash_profile` ফাইলে কমপ্লিসনের স্ক্রিপ্ট উৎস করুন: echo 'source <(kubectl completion bash)' >>~/.bash_profile * `/usr/local/etc/bash_completion.d` ডিরেক্টরিতে কমপ্লিসনের স্ক্রিপ্ট যোগ করুন: kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl * আপনার যদি kubectl এর জন্য একটি উপনাম থাকে তবে আপনি সেই উপনামের সাথে কাজ করার জন্য শেল কমপ্লিসন বাড়াতে পারেন: echo 'alias k=kubectl' >>~/.bash_profile echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile * আপনি যদি হোমব্রু দিয়ে kubectl ইনস্টল করেন (যেমন [এখানে ব্যাখ্যা করা হয়েছে](https://kubernetes.io/bn/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos) ), তাহলে kubectl কমপ্লিসনের স্ক্রিপ্ট ইতিমধ্যেই `/-এ থাকা উচিত usr/local/etc/bash_completion.d/kubectl`। সেক্ষেত্রে আপনার কিছু করার দরকার নেই। #### বিঃদ্রঃ: bash-completion v2-এর Homebrew ইনস্টলেশনটি `BASH_COMPLETION_COMPAT_DIR` ডিরেক্টরির সমস্ত ফাইলকে উৎস করে, তাই পরবর্তী দুটি পদ্ধতি কাজ করে। যে কোনো ক্ষেত্রে, আপনার শেল পুনরায় লোড করার পরে, kubectl সমাপ্তি কাজ করা উচিত। #### বিঃদ্রঃ: kubectl 1.23 বা তার পরের সংস্করণ প্রয়োজন fish এর স্বয়ংক্রিয় সমাপ্তি করার জন্য । fish এর জন্য kubectl সমাপ্তি স্ক্রিপ্ট `kubectl completion fish` কমান্ড দিয়ে তৈরি করা যেতে পারে। আপনার শেলের মধ্যে সমাপ্তি স্ক্রিপ্ট সোর্স করা kubectl স্বয়ংক্রিয় সমাপ্তি চালু করে। আপনার সমস্ত শেল সেশনে এটি করতে, আপনার `~/.config/fish/config.fish` ফাইলে নিম্নলিখিত লাইন যুক্ত করুন: kubectl completion fish | source আপনার শেল পুনরায় লোড করার পরে, kubectl স্বয়ংক্রিয় সমাপ্তি কাজ করা উচিত। Zsh-এর জন্য kubectl কমপ্লিশন স্ক্রিপ্ট `kubectl completion zsh` কমান্ড দিয়ে তৈরি করা যেতে পারে। আপনার শেলে সমাপ্তি স্ক্রিপ্ট সোর্স করা kubectl স্বয়ংসম্পূর্ণতা সক্ষম করে। 12 আপনার সমস্ত শেল সেশনে এটি করতে, আপনার `~/.zshrc` ফাইলে নিম্নলিখিত যোগ করুন: source <(kubectl completion zsh) আপনার যদি kubectl-এর একটি উপনাম থাকে, kubectl স্বয়ংসম্পূর্ণতা স্বয়ংক্রিয়ভাবে এটির সাথে কাজ করবে। আপনার শেল পুনরায় লোড করার পরে, kubectl স্বয়ংসম্পূর্ণতা কাজ করা উচিত। যদি আপনি একটি ত্রুটি পান যেমন `2: command not found: compdef`, তাহলে আপনার `~/.zshrc` ফাইলের শুরুতে নিম্নলিখিত যোগ করুন: autoload -Uz compinit compinit ### `kubectl convert` প্লাগইন ইনস্টল করুন কুবারনেটিস কমান্ড-লাইন টুল `kubectl` এর জন্য একটি প্লাগইন, যা আপনাকে বিভিন্ন আপিআই সংস্করণ এর মধ্যে রূপান্তর করতে দেয়। এটি নতুন কুবারনেটিস রিলিজের সাথে একটি অ-বঞ্চিত আপিআই সংস্করণে স্থানান্তর করতে বিশেষভাবে সহায়ক হতে পারে। আরও তথ্যের জন্য, [অপ্রচলিত apis-এ মাইগ্রেট করুন](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) ১. কমান্ড সহ সর্বশেষ রিলিজ ডাউনলোড করুন: * [Intel](https://kubernetes.io/bn/docs/tasks/_print/#download-convert-binary-macos-0) * [Apple Silicon](https://kubernetes.io/bn/docs/tasks/_print/#download-convert-binary-macos-1) curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert" curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert" ২. বাইনারি যাচাই করুন (ঐচ্ছিক) kubectl-convert checksum ফাইলটি ডাউনলোড করুন: * [Intel](https://kubernetes.io/bn/docs/tasks/_print/#download-convert-checksum-macos-0) * [Apple Silicon](https://kubernetes.io/bn/docs/tasks/_print/#download-convert-checksum-macos-1) curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256" curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256" চেকসাম ফাইলের বিপরীতে kubectl-রূপান্তর বাইনারি যাচাই করুন: echo "$(cat kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check বৈধ হলে, আউটপুট হল: kubectl-convert: OK চেক ব্যর্থ হলে, `shasum` অশূন্য স্থিতি সহ প্রস্থান করে এবং অনুরূপ আউটপুট প্রিন্ট করে: kubectl-convert: FAILED shasum: WARNING: 1 computed checksum did NOT match #### বিঃদ্রঃ: বাইনারি এবং চেকসামের একই সংস্করণ ডাউনলোড করুন। ৩. kubectl-রূপান্তর বাইনারি এক্সিকিউটেবল করুন chmod +x ./kubectl-convert ৪. আপনার সিস্টেম `PATH`\-এ একটি ফাইল অবস্থানে kubectl-রূপান্তর বাইনারি সরান। sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert sudo chown root: /usr/local/bin/kubectl-convert #### বিঃদ্রঃ: নিশ্চিত করুন যে `/usr/local/bin` আপনার PATH এনভায়রনমেন্ট ভেরিয়েবলে আছে। ৫. প্লাগইন সফলভাবে ইনস্টল করা হয়েছে যাচাই করুন kubectl convert --help আপনি যদি একটি ত্রুটি দেখতে না পান, এর মানে হল প্লাগইনটি সফলভাবে ইনস্টল করা হয়েছে। ৬. প্লাগইন ইনস্টল করার পরে, ইনস্টলেশন ফাইলগুলি পরিষ্কার করুন: rm kubectl-convert kubectl-convert.sha256 এর পরের কি ---------- * [ইনস্টল করুন Minikube](https://minikube.sigs.k8s.io/docs/start/) * ক্লাস্টার তৈরি সম্পর্কে আরও জানতে দেখুন [গাইড শুরু করা](https://kubernetes.io/bn/docs/setup/) ফাইলটি । * [আপনার অ্যাপ্লিকেশানটি কীভাবে লঞ্চ করবেন এবং প্রকাশ করবেন তা জানুন ।](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/) * আপনার যদি এমন একটি ক্লাস্টারে অ্যাক্সেসের প্রয়োজন হয় যা আপনি তৈরি করেননি, দেখুন [ক্লাস্টার অ্যাক্সেস নথি ভাগ করেন](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) . * [kubectl রেফারেন্স ডক্স](https://kubernetes.io/docs/reference/kubectl/kubectl/) পড়ুন । 1.2 - উইন্ডোজে kubectl ইনস্টল এবং সেট আপ করুন ============================================= শুরু করার আগে ------------- আপনাকে অবশ্যই একটি kubectl সংস্করণ ব্যবহার করতে হবে যা আপনার ক্লাস্টারের একটি ছোট সংস্করণের পার্থক্যের মধ্যে রয়েছে। উদাহরণ স্বরূপ, একটি v1.35 ক্লায়েন্ট v1.34, v1.35, and v1.36 কন্ট্রল প্লেনের সাথে যোগাযোগ করতে পারবে। kubectl এর সর্বশেষ সামঞ্জস্যপূর্ণ সংস্করণ ব্যবহার করা অপ্রত্যাশিত সমস্যাগুলি এড়াতে সাহায্য করে৷ উইন্ডোজে kubectl ইনস্টল করুন ---------------------------- উইন্ডোজে kubectl ইনস্টল করার জন্য নিম্নলিখিত পদ্ধতিগুলো অনুসরণ করতে পারেন: * [উইন্ডোজে কার্ল ব্যাবহার kubectl বাইনারি ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-kubectl-binary-with-curl-on-windows) * [Chocolatey, Scoop, বা winget ব্যবহার করে Windows এ ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-nonstandard-package-tools) ### উইন্ডোজে কার্ল ব্যাবহার kubectl বাইনারি ইনস্টল করুন 1. সর্বশেষ 1.35 প্যাচ রিলিজ ডাউনলোড করুন: [kubectl 1.35.0](https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl.exe) । অথবা যদি আপনার `curl` ইনস্টল থাকে, এই কমান্ডটি ব্যবহার করুন: curl.exe -LO "https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl.exe" #### বিঃদ্রঃ: সর্বশেষ স্থিতিশীল সংস্করণ খুঁজে বের করতে (উদাহরণস্বরূপ, স্ক্রিপ্টিংয়ের জন্য), [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt) দেখতে পারেন। 2. বাইনারি যাচাই করুন (অপশনাল) `kubectl` চেকসাম ফাইলটি ডাউনলোড করুন: curl.exe -LO "https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl.exe.sha256" চেকসাম ফাইলের বিপরীতে `kubectl` বাইনারি যাচাই করুন: * ডাউনলোড করা চেকসাম ফাইলের সাথে ম্যানুয়ালি `CertUtil` এর আউটপুট তুলনা করতে কমান্ড প্রম্পট ব্যবহার করে: CertUtil -hashfile kubectl.exe SHA256 type kubectl.exe.sha256 * একটি `True` বা `False` ফলাফল পেতে `-eq` অপারেটর ব্যবহার করে যাচাইকরণ স্বয়ংক্রিয় করতে PowerShell ব্যবহার করে: $(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256) 3. আপনার `PATH` এনভায়রনমেন্ট ভেরিয়েবলে `kubectl` বাইনারি ফোল্ডারটি অ্যাপেন্ড বা প্রিপেন্ড করুন। 4. `kubectl`\-এর সংস্করণ ডাউনলোড করা একই রকম তা নিশ্চিত করতে পরীক্ষা করুন kubectl version --client #### বিঃদ্রঃ: উপরের কমান্ডটি একটি সতর্ক বার্তা তৈরি করবে: WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. আপনি এই সতর্কতা উপেক্ষা করতে পারেন. আপনি শুধুমাত্র `kubectl` এর যে সংস্করণটি ইনস্টল করেছেন তা পরীক্ষা করছেন। অথবা সংস্করণের বিস্তারিত দেখার জন্য এটি ব্যবহার করুন: kubectl version --client --output=yaml 5. প্লাগইন ইনস্টল করার পরে, ইনস্টলেশন ফাইলগুলি পরিষ্কার করুন: del kubectl.exe kubectl.exe.sha256 #### বিঃদ্রঃ: [উইন্ডোজের জন্য ডকার ডেস্কটপ](https://docs.docker.com/docker-for-windows/#kubernetes) `PATH`\-এ `kubectl` এর নিজস্ব সংস্করণ যোগ করে। আপনি যদি আগে ডকার ডেস্কটপ ইনস্টল করে থাকেন, তাহলে আপনাকে ডকার ডেস্কটপ ইনস্টলার দ্বারা যোগ করা একটির আগে আপনার `PATH` এন্ট্রি স্থাপন করতে হবে অথবা ডকার ডেস্কটপের `kubectl` সরিয়ে ফেলতে হবে। ### Chocolatey, Scoop, বা winget ব্যবহার করে Windows এ ইনস্টল করুন 1. উইন্ডোজে kubectl ইনস্টল করতে আপনি উভয় [Chocolatey](https://chocolatey.org/) প্যাকেজ ম্যানেজার, [Scoop](https://scoop.sh/) কমান্ড-লাইন ইনস্টলার, অথবা [winget](https://learn.microsoft.com/en-us/windows/package-manager/winget/) প্যাকেজ ম্যানেজার ব্যবহার করতে পারেন। * [choco](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-win-install-0) * [scoop](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-win-install-1) * [winget](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-win-install-2) choco install kubernetes-cli scoop install kubectl winget install -e --id Kubernetes.kubectl 2. আপনার ইনস্টল করা সংস্করণ আপ-টু-ডেট কিনা তা নিশ্চিত করতে পরীক্ষা করুন: kubectl version --client 3. আপনার হোম ডিরেক্টরিতে নেভিগেট করুন: # If you're using cmd.exe, run: cd %USERPROFILE% cd ~ 4. `.kube` ডিরেক্টরি তৈরি করুন: mkdir .kube 5. আপনার তৈরি করা `.kube` ডিরেক্টরিতে ঢুকে পড়ুন: cd .kube 6. একটি দূরবর্তী Kubernetes ক্লাস্টার ব্যবহার করতে kubectl কনফিগার করুরু New-Item config -type file #### বিঃদ্রঃ: আপনার পছন্দের টেক্সট এডিটর, যেমন নোটপ্যাড দিয়ে কনফিগার ফাইলটি সম্পাদনা করুন। kubectl কনফিগারেশন যাচাই করুন ----------------------------- kubectl-এর জন্য একটি কুবারনেটিস ক্লাস্টার খুঁজে পেতে এবং অ্যাক্সেস পেতে, যার জন্য প্রয়োজন [kubeconfig ফাইল](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) , যা স্বয়ংক্রিয়ভাবে তৈরি হয় যখন আপনি একটি ক্লাস্টার তৈরি করেন [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) ব্যবহার করে অথবা সফলভাবে একটি Minikube ক্লাস্টার স্থাপন করুন। ডিফল্টরূপে, kubectl কনফিগারেশন `~/.kube/config` এ অবস্থিত। ক্লাস্টার অবস্থা পেয়ে kubectl সঠিকভাবে কনফিগার করা হয়েছে তা পরীক্ষা করুন: kubectl cluster-info আপনি যদি একটি URL দেখতে পান, তাহলে আপনার ক্লাস্টার অ্যাক্সেস করার জন্য kubectl সঠিকভাবে কনফিগার করা হয়েছে। আপনি যদি নিম্নলিখিতগুলোর মতো একটি বার্তা দেখতে পান, তাহলে বুঝবেন যে kubectl সঠিকভাবে কনফিগার করা হয়নি অথবা একটি Kubernetes ক্লাস্টারের সাথে সংযোগ করতে সক্ষম নয়। সার্ভারের সাথে সংযোগ প্রত্যাখ্যান করা হয়েছিল - আপনি কি সঠিক হোস্ট বা পোর্ট উল্লেখ করেছেন? উদাহরণস্বরূপ, আপনি যদি আপনার ল্যাপটপে (স্থানীয়ভাবে) একটি কুবারনেটিস ক্লাস্টার চালাতে চান, তাহলে আপনাকে প্রথমে মিনিকুবের মতো একটি টুল ইনস্টল করতে হবে এবং তারপরে উপরে বর্ণিত কমান্ডগুলি পুনরায় চালাতে হবে। যদি kubectl ক্লাস্টার-তথ্য url প্রতিক্রিয়া প্রদান করে কিন্তু আপনি আপনার ক্লাস্টার অ্যাক্সেস করতে না পারেন, এটি সঠিকভাবে কনফিগার করা হয়েছে কিনা তা পরীক্ষা করতে, ব্যবহার করুন: kubectl cluster-info dump ### 'No Auth Provider Found' ত্রুটি বার্তার সমস্যা সমাধান কুবারনেটিস 1.26-এ, kubectl নিম্নলিখিত ক্লাউড প্রদানকারীদের পরিচালিত কুবারনেটিস অফারগুলোর জন্য অন্তর্নির্মিত অথেনটিকেশন সরিয়ে দিয়েছে। এই প্রদানকারীরা ক্লাউডের-নির্দিষ্ট অথেনটিকেশন প্রদানের জন্য kubectl প্লাগইন প্রকাশ করেছে। নির্দেশাবলীর জন্য, নিম্নলিখিত প্রদানকারী ডকুমেন্টেশন পড়ুন: * Azure AKS: [kubelogin plugin](https://azure.github.io/kubelogin/) * Google Kubernetes Engine: [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin) (একই ত্রুটির বার্তা দেখার অন্যান্য কারণও থাকতে পারে, এই পরিবর্তনের সাথে সম্পর্কিত নয়।) অপশনাল kubectl কনফিগারেশন এবং প্লাগইন ------------------------------------- ### শেল ওটোকমপ্লিট চালু করুন kubectl Bash, Zsh, Fish এবং PowerShell-এর জন্য ওটোকম্পিট সমর্থন প্রদান করে, যা আপনাকে অনেক টাইপিং করা থেকে রক্ষা করতে পারে। পাওয়ারশেলের জন্য ওটোকম্পিট সেট আপ করার পদ্ধতিগুলি নীচে দেওয়া হল। PowerShell-এর জন্য kubectl সমাপ্তি স্ক্রিপ্ট `kubectl completion powershell` কমান্ড দিয়ে তৈরি করা যেতে পারে। আপনার সমস্ত শেল সেশনে এটি করতে, আপনার `$PROFILE` ফাইলে নিম্নলিখিত লাইন যোগ করুন: kubectl completion powershell | Out-String | Invoke-Expression এই কমান্ডটি প্রতিটি PowerShell স্টার্ট আপে স্বয়ংক্রিয় সমাপ্তি স্ক্রিপ্ট পুনরায় তৈরি করবে। আপনি চাইলে জেনারেট করা স্ক্রিপ্টটি সরাসরি আপনার `$PROFILE` ফাইলে যোগ করতে পারেন। আপনার `$PROFILE` ফাইলে জেনারেট করা স্ক্রিপ্ট যোগ করতে, আপনার পাওয়ারশেল প্রম্পটে নিম্নলিখিত লাইনটি চালান: kubectl completion powershell >> $PROFILE আপনার শেল পুনরায় লোড করার পরে, kubectl স্বয়ংক্রিয় সমাপ্তি কাজ করা উচিত। ### `kubectl convert` প্লাগইন ইনস্টল করুন কুবারনেটিস কমান্ড-লাইন টুল `kubectl` এর জন্য একটি প্লাগইন, যা আপনাকে বিভিন্ন আপিআই সংস্করণ এর মধ্যে রূপান্তর করতে দেয়। এটি নতুন কুবারনেটিস রিলিজের সাথে একটি অ-বঞ্চিত আপিআই সংস্করণে স্থানান্তর করতে বিশেষভাবে সহায়ক হতে পারে। আরও তথ্যের জন্য, [অপ্রচলিত apis-এ মাইগ্রেট করুন](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) 1. কমান্ড সহ সর্বশেষ রিলিজ ডাউনলোড করুন: curl.exe -LO "https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl-convert.exe" 2. বাইনারি যাচাই করুন (অপশনাল)। `kubectl-convert` চেকসাম ফাইলটি ডাউনলোড কর্সনা curl.exe -LO "https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl-convert.exe.sha256" চেকসাম ফাইলের বিপরীতে `kubectl-convert` বাইনারি যাচাই করুন: * ডাউনলোড করা চেকসাম ফাইলের সাথে ম্যানুয়ালি `CertUtil` এর আউটপুট তুলনা করতে কমান্ড প্রম্পট ব্যবহার করে: CertUtil -hashfile kubectl-convert.exe SHA256 type kubectl-convert.exe.sha256 * একটি `True` বা `False` ফলাফল পেতে `-eq` অপারেটর ব্যবহার করে যাচাইকরণ স্বয়ংক্রিয় করতে PowerShell ব্যবহার করে: $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) 3. আপনার `PATH` এনভায়রনমেন্ট ভেরিয়েবলের সাথে `kubectl-convert` বাইনারি ফোল্ডারটি অ্যাপেন্ড বা প্রিপেন্ড করুন। 4. প্লাগইন সফলভাবে ইনস্টল করা হয়েছে যাচাই করুন। kubectl convert --help আপনি যদি একটি ত্রুটি দেখতে না পান, এর মানে হল প্লাগইনটি সফলভাবে ইনস্টল করা হয়েছে। 5. প্লাগইন ইনস্টল করার পরে, ইনস্টলেশন ফাইলগুলি পরিষ্কার করুন: del kubectl-convert.exe kubectl-convert.exe.sha256 এর পরের কি ---------- * [ইনস্টল করুন Minikube](https://minikube.sigs.k8s.io/docs/start/) * ক্লাস্টার তৈরি সম্পর্কে আরও জানতে দেখুন [গাইড শুরু করা](https://kubernetes.io/bn/docs/setup/) ফাইলটি । * [আপনার অ্যাপ্লিকেশানটি কীভাবে লঞ্চ করবেন এবং প্রকাশ করবেন তা জানুন ।](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/) * আপনার যদি এমন একটি ক্লাস্টারে অ্যাক্সেসের প্রয়োজন হয় যা আপনি তৈরি করেননি, দেখুন [ক্লাস্টার অ্যাক্সেস নথি ভাগ করেন](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) . * [kubectl রেফারেন্স ডক্স](https://kubernetes.io/docs/reference/kubectl/kubectl/) পড়ুন । 1.3 - লিনাক্সে kubectl ইনস্টল এবং সেট আপ করুন ============================================= শুরু করার আগে ------------- আপনাকে অবশ্যই একটি kubectl সংস্করণ ব্যবহার করতে হবে যা আপনার ক্লাস্টারের একটি ছোট সংস্করণের পার্থক্যের মধ্যে রয়েছে। উদাহরণস্বরূপ, একটি v1.35 ক্লায়েন্ট v1.34, v1.35, এবং v1.36 এর কন্ট্রোল প্লেনের সাথে যোগাযোগ করতে পারে। kubectl এর সর্বশেষ সামঞ্জস্যপূর্ণ সংস্করণ ব্যবহার করা অপ্রত্যাশিত সমস্যাগুলি এড়াতে সাহায্য করে৷ লিনাক্সে kubectl ইনস্টল করুন ---------------------------- লিনাক্সে kubectl ইনস্টল করার জন্য নিম্নলিখিত পদ্ধতি বিদ্যমানঃ * [লিনাক্সে কার্ল দিয়ে kubectl বাইনারি ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-kubectl-binary-with-curl-on-linux) * [নেটিভ প্যাকেজ ম্যানেজমেন্ট দিয়ে ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-using-native-package-management) * [অন্যান্য প্যাকেজ ব্যবস্থাপনা ব্যবহার করে ইনস্টল করুন](https://kubernetes.io/bn/docs/tasks/_print/#install-using-other-package-management) ### লিনাক্সে কার্ল সহ kubectl বাইনারি ইনস্টল করুন ১. কমান্ড সহ সর্বশেষ রিলিজ ডাউনলোড করুন: curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" #### বিঃদ্রঃ: একটি নির্দিষ্ট সংস্করণ ডাউনলোড করতে, নির্দিষ্ট সংস্করণের সাথে কমান্ডের `$(curl -L -s https://dl.k8s.io/release/stable.txt)` অংশটি প্রতিস্থাপন করুন। উদাহরণস্বরূপ, লিনাক্সে সংস্করণ 1.35.0 ডাউনলোড করতে, টাইপ করুন: curl -LO https://dl.k8s.io/release/v1.35.0/bin/linux/amd64/kubectl ২. বাইনারি যাচাই করুন (ঐচ্ছিক) kubectl চেকসাম ফাইল ডাউনলোড করুন: curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256" চেকসাম ফাইলের বিপরীতে kubectl বাইনারি যাচাই করুন: echo "$(cat kubectl.sha256) kubectl" | sha256sum --check বৈধ হলে, আউটপুট হবে: kubectl: OK চেক ব্যর্থ হলে, `sha256` অশূন্য স্থিতি সহ প্রস্থান করে এবং অনুরূপ আউটপুট প্রিন্ট করে: kubectl: FAILED sha256sum: WARNING: 1 computed checksum did NOT match #### বিঃদ্রঃ: বাইনারি এবং চেকসামের একই সংস্করণ ডাউনলোড করুন। ৩. kubectl ইনস্টল করুন sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl #### বিঃদ্রঃ: যদি আপনার টার্গেট সিস্টেমে রুট অ্যাক্সেস না থাকে, তাহলেও আপনি `~/.local/bin` ডিরেক্টরিতে kubectl ইনস্টল করতে পারেন: chmod +x kubectl mkdir -p ~/.local/bin mv ./kubectl ~/.local/bin/kubectl # and then append (or prepend) ~/.local/bin to $PATH ৪. আপনার ইনস্টল করা সংস্করণ আপ-টু-ডেট কিনা তা নিশ্চিত করতে পরীক্ষা করুন: kubectl version --client #### বিঃদ্রঃ: উপরের কমান্ডটি একটি সতর্কতা তৈরি করবে: WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. আপনি এই সতর্কতা উপেক্ষা করতে পারেন। আপনি শুধুমাত্র `kubectl` এর সংস্করণটি পরীক্ষা করছেন যা আপনি ইনস্টল করেছেন। অথবা সংস্করণের বিস্তারিত দেখার জন্য এটি ব্যবহার করুনঃ kubectl version --client --output=yaml ### নেটিভ প্যাকেজ ম্যানেজমেন্ট ব্যবহার করে ইনস্টল করুন * [Debian-based distributions](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-install-0) * [Red Hat-based distributions](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-install-1) ১. `apt` প্যাকেজ ইনডেক্স আপডেট করুন এবং Kubernetes `apt` রিপোযিটোরী ব্যবহার করার জন্য প্রয়োজনীয় প্যাকেজ ইনস্টল করুন: sudo apt-get update sudo apt-get install -y ca-certificates curl আপনি যদি ডেবিয়ান ৯ (স্ট্রেচ) বা তার আগে ব্যবহার করেন তবে আপনাকে `apt-transport-https` ইনস্টল করতে হবে: sudo apt-get install -y apt-transport-https ২. গুগল ক্লাউড পাবলিক সাইনিং কী ডাউনলোড করুন: sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg ৩. কুবারনেটিস `apt` রিপোযিটোরী যোগ করুন: echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list ৪. নতুন রিপোযিটোরীর সাথে `apt` প্যাকেজ ইনডেক্স আপডেট করুন এবং kubectl ইনস্টল করুন: sudo apt-get update sudo apt-get install -y kubectl #### বিঃদ্রঃ: ডেবিয়ান ১২ এবং উবুন্টু ২২.০৪ এর চেয়ে পুরানো রিলিজে, `/etc/apt/keyrings` ডিফল্টরূপে বিদ্যমান নেই। আপনার প্রয়োজন হলে আপনি এই ডিরেক্টরিটি তৈরি করতে পারেন, এটি ওয়ার্ল্ড-রিডেবল কিন্তু শুধুমাত্র অ্যাডমিনদের দ্বারা লেখার যোগ্য। cat < প্রত্যাখ্যান করা হয়েছিল - আপনি কি সঠিক হোস্ট বা পোর্ট উল্লেখ করেছেন? উদাহরণস্বরূপ, আপনি যদি আপনার ল্যাপটপে (স্থানীয়ভাবে) একটি কুবারনেটিস ক্লাস্টার চালাতে চান, তাহলে আপনাকে প্রথমে মিনিকুবের মতো একটি টুল ইনস্টল করতে হবে এবং তারপরে উপরে বর্ণিত কমান্ডগুলি পুনরায় চালাতে হবে। যদি kubectl ক্লাস্টার-তথ্য url প্রতিক্রিয়া প্রদান করে কিন্তু আপনি আপনার ক্লাস্টার অ্যাক্সেস করতে না পারেন, এটি সঠিকভাবে কনফিগার করা হয়েছে কিনা তা পরীক্ষা করতে, ব্যবহার করুন: kubectl cluster-info dump ### 'No Auth Provider Found' ত্রুটি বার্তার সমস্যা সমাধান কুবারনেটিস 1.26-এ, kubectl নিম্নলিখিত ক্লাউড প্রদানকারীদের পরিচালিত কুবারনেটিস অফারগুলোর জন্য অন্তর্নির্মিত অথেনটিকেশন সরিয়ে দিয়েছে। এই প্রদানকারীরা ক্লাউডের-নির্দিষ্ট অথেনটিকেশন প্রদানের জন্য kubectl প্লাগইন প্রকাশ করেছে। নির্দেশাবলীর জন্য, নিম্নলিখিত প্রদানকারী ডকুমেন্টেশন পড়ুন: * Azure AKS: [kubelogin plugin](https://azure.github.io/kubelogin/) * Google Kubernetes Engine: [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin) (একই ত্রুটির বার্তা দেখার অন্যান্য কারণও থাকতে পারে, এই পরিবর্তনের সাথে সম্পর্কিত নয়।) ঐচ্ছিক kubectl কনফিগারেশন এবং প্লাগই ------------------------------------ ### শেল অটোকম্পিসন চালু করুন kubectl Bash, Zsh, Fish এবং PowerShell-এর জন্য অটোকম্পিসন সমর্থন প্রদান করে, যা আপনাকে অনেক টাইপিং বাঁচাতে পারে। নীচে Bash, Fish, এবং Zsh-এর জন্য স্বয়ংসম্পূর্ণতা সেট আপ করার পদ্ধতিগুলি রয়েছে৷ * [Bash](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-autocompletion-0) * [Fish](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-autocompletion-1) * [Zsh](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-autocompletion-2) ### ভূমিকা ব্যাশ-এর জন্য kubectl কমপ্লিশন স্ক্রিপ্ট `kubectl completion bash` কমান্ড দিয়ে তৈরি করা যেতে পারে। আপনার শেলে সমাপ্তি স্ক্রিপ্ট সোর্স করা kubectl অটোকমপ্লিসন সক্ষম করে। যাইহোক, কমপ্লিসন স্ক্রিপ্ট [**ব্যাশ-কমপ্লিসন**](https://github.com/scop/bash-completion) এর উপর নির্ভর করে, তার মানে হচ্ছে আপনাকে প্রথমে এই সফ্টওয়্যারটি ইনস্টল করতে হবে (আপনার ব্যাশ-কমপ্লিসন ইতিমধ্যেই ইনস্টল করা আছে কিনা তা `type _init_completion` চালিয়ে পরীক্ষা করতে পারেন)। ### ব্যাশ-কমপ্লিসন ইনস্টল করুন ব্যাশ-কমপ্লিসন অনেক প্যাকেজ ম্যানেজার দ্বারা প্রদান করা হয় ([এখানে](https://github.com/scop/bash-completion#installation) দেখুন)। আপনি এটিকে `apt-get install bash-completion` অথবা `yum install bash-completion`, ইত্যাদি দিয়ে ইনস্টল করতে পারেন। উপরের কমান্ডগুলি `/usr/share/bash-completion/bash_completion` তৈরি করে, যা ব্যাশ-কমপ্লিসন এর প্রধান স্ক্রিপ্ট। আপনার প্যাকেজ ম্যানেজারের উপর নির্ভর করে, আপনাকে ম্যানুয়ালি এই ফাইলটি আপনার `~/.bashrc` ফাইলে সোর্স করতে হবে। জানতে চাইলে, আপনার শেল পুনরায় লোড করুন এবং `type_init_completion` চালান। কমান্ডটি সফল হলে, আপনি ইতিমধ্যেই সেট করেছেন, অন্যথায় আপনার `~/.bashrc` ফাইলে নিম্নলিখিত যোগ করুন: source /usr/share/bash-completion/bash_completion আপনার শেল পুনরায় লোড করুন এবং `type _init_completion` লিখে ব্যাশ-কমপ্লিসন সঠিকভাবে ইনস্টল করা হয়েছে কিনা তা যাচাই করুন। ### kubectl অটোকমপ্লিসন চালু করুন #### ব্যাশ আপনাকে এখন নিশ্চিত করতে হবে যে kubectl সমাপ্তি স্ক্রিপ্টটি আপনার সমস্ত শেল সেশনে পাওয়া যায়। আপনি এটি করতে পারেন যা দুটি উপায় আছেঃ * [User](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-bash-autocompletion-0) * [System](https://kubernetes.io/bn/docs/tasks/_print/#kubectl-bash-autocompletion-1) echo 'source <(kubectl completion bash)' >>~/.bashrc kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null আপনার যদি kubectl এর জন্য একটি অ্যালিঅ্যাস থাকে তবে আপনি সেই অ্যালিঅ্যাসের সাথে কাজ করার জন্য শেল কমপ্লিসন বাড়াতে পারেনঃ echo 'alias k=kubectl' >>~/.bashrc echo 'complete -o default -F __start_kubectl k' >>~/.bashrc #### বিঃদ্রঃ: ব্যাশ-কমপ্লিসনের সূত্র `/etc/bash_completion.d`\-এ সমস্ত কমপ্লিসন স্ক্রিপ্ট। উভয় পন্থা সমতুল্য। আপনার শেল পুনরায় লোড করার পরে, kubectl অটোকমপ্লিসন কাজ করা উচিত। শেলের বর্তমান সেশনে ব্যাশ অটোকমপ্লিসন সক্ষম করতে, ~/.bashrc ফাইলটি উৎস করুনঃ source ~/.bashrc #### বিঃদ্রঃ: kubectl 1.23 বা তার পরের সংস্করণ প্রয়োজন fish এর স্বয়ংক্রিয় সমাপ্তি করার জন্য । fish এর জন্য kubectl সমাপ্তি স্ক্রিপ্ট `kubectl completion fish` কমান্ড দিয়ে তৈরি করা যেতে পারে। আপনার শেলের মধ্যে সমাপ্তি স্ক্রিপ্ট সোর্স করা kubectl স্বয়ংক্রিয় সমাপ্তি চালু করে। আপনার সমস্ত শেল সেশনে এটি করতে, আপনার `~/.config/fish/config.fish` ফাইলে নিম্নলিখিত লাইন যুক্ত করুন: kubectl completion fish | source আপনার শেল পুনরায় লোড করার পরে, kubectl স্বয়ংক্রিয় সমাপ্তি কাজ করা উচিত। Zsh-এর জন্য kubectl কমপ্লিশন স্ক্রিপ্ট `kubectl completion zsh` কমান্ড দিয়ে তৈরি করা যেতে পারে। আপনার শেলে সমাপ্তি স্ক্রিপ্ট সোর্স করা kubectl স্বয়ংসম্পূর্ণতা সক্ষম করে। 12 আপনার সমস্ত শেল সেশনে এটি করতে, আপনার `~/.zshrc` ফাইলে নিম্নলিখিত যোগ করুন: source <(kubectl completion zsh) আপনার যদি kubectl-এর একটি উপনাম থাকে, kubectl স্বয়ংসম্পূর্ণতা স্বয়ংক্রিয়ভাবে এটির সাথে কাজ করবে। আপনার শেল পুনরায় লোড করার পরে, kubectl স্বয়ংসম্পূর্ণতা কাজ করা উচিত। যদি আপনি একটি ত্রুটি পান যেমন `2: command not found: compdef`, তাহলে আপনার `~/.zshrc` ফাইলের শুরুতে নিম্নলিখিত যোগ করুন: autoload -Uz compinit compinit ### `kubectl convert` প্লাগইন ইনস্টল করুন কুবারনেটিস কমান্ড-লাইন টুল `kubectl` এর জন্য একটি প্লাগইন, যা আপনাকে বিভিন্ন আপিআই সংস্করণ এর মধ্যে রূপান্তর করতে দেয়। এটি নতুন কুবারনেটিস রিলিজের সাথে একটি অ-বঞ্চিত আপিআই সংস্করণে স্থানান্তর করতে বিশেষভাবে সহায়ক হতে পারে। আরও তথ্যের জন্য, [অপ্রচলিত apis-এ মাইগ্রেট করুন](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) ১. কমান্ড সহ সর্বশেষ রিলিজ ডাউনলোড করুন: curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert" ২. বাইনারি যাচাই করুন (ঐচ্ছিক) kubectl-convert চেকসাম ফাইলটি ডাউনলোড করুন: curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256" চেকসাম ফাইলের বিপরীতে kubectl-রূপান্তর বাইনারি যাচাই করুন: echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check বৈধ হলে, আউটপুট হল: kubectl-convert: OK চেক ব্যর্থ হলে, `sha256` অশূন্য স্থিতি সহ প্রস্থান করে এবং অনুরূপ আউটপুট প্রিন্ট করে: kubectl-convert: FAILED sha256sum: WARNING: 1 computed checksum did NOT match #### বিঃদ্রঃ: বাইনারি এবং চেকসামের একই সংস্করণ ডাউনলোড করুন। ৩. kubectl-convert ইনস্টল করুন sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert ৪. প্লাগইন সফলভাবে ইনস্টল করা হয়েছে যাচাই করুন kubectl convert --help আপনি যদি একটি ত্রুটি দেখতে না পান, এর মানে হল প্লাগইনটি সফলভাবে ইনস্টল করা হয়েছে। ৫. প্লাগইন ইনস্টল করার পরে, ইনস্টলেশন ফাইলগুলি পরিষ্কার করুন: rm kubectl-convert kubectl-convert.sha256 এর পরের কি ---------- * [ইনস্টল করুন Minikube](https://minikube.sigs.k8s.io/docs/start/) * ক্লাস্টার তৈরি সম্পর্কে আরও জানতে দেখুন [গাইড শুরু করা](https://kubernetes.io/bn/docs/setup/) ফাইলটি । * [আপনার অ্যাপ্লিকেশানটি কীভাবে লঞ্চ করবেন এবং প্রকাশ করবেন তা জানুন ।](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/) * আপনার যদি এমন একটি ক্লাস্টারে অ্যাক্সেসের প্রয়োজন হয় যা আপনি তৈরি করেননি, দেখুন [ক্লাস্টার অ্যাক্সেস নথি ভাগ করেন](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) . * [kubectl রেফারেন্স ডক্স](https://kubernetes.io/docs/reference/kubectl/kubectl/) পড়ুন । --- # Image | Kubernetes **Information in this document may be out of date** This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: [Images](https://kubernetes.io/docs/concepts/containers/images/) Image ===== Kamu membuat Docker _image_ dan mengunduhnya ke sebuah registri sebelum digunakan di dalam Kubernetes Pod. Properti `image` dari sebuah Container mendukung sintaksis yang sama seperti perintah `docker`, termasuk registri privat dan _tag_. Memperbarui Image ----------------- Kebijakan _pull default_ adalah `IfNotPresent` yang membuat Kubelet tidak lagi mengunduh (_pull_) sebuah image jika sudah ada terlebih dahulu. Jika kamu ingin agar selalu diunduh, kamu bisa melakukan salah satu dari berikut: * mengatur `imagePullPolicy` dari Container menjadi `Always`. * buang `imagePullPolicy` dan gunakan `:latest` _tag_ untuk _image_ yang digunakan. * buang `imagePullPolicy` dan juga _tag_ untuk _image_. * aktifkan [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) _admission controller_. Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](https://kubernetes.io/id/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut. Membuat Image Multi-arsitektur dengan Manifest ---------------------------------------------- Docker CLI saat ini mendukung perintah `docker manifest` dengan anak perintah `create`, `annotate`, dan `push`. Perintah-perintah ini dapat digunakan untuk membuat (_build_) dan mengunggah (_push_) manifes. Kamu dapat menggunakan perintah `docker manifest inspect` untuk membaca manifes. Lihat dokumentasi docker di sini: [https://docs.docker.com/edge/engine/reference/commandline/manifest/](https://docs.docker.com/edge/engine/reference/commandline/manifest/) Lihat contoh-contoh bagaimana kami menggunakan ini untuk proses _build harness_: [https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=](https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=) Perintah-perintah ini bergantung pada Docker CLI, dan diimplementasi hanya di sisi CLI. Kamu harus mengubah `$HOME/.docker/config.json` dan mengatur _key_ `experimental` untuk mengaktifkan atau cukup dengan mengatur `DOCKER_CLI_EXPERIMENTAL` variabel _environment_ menjadi `enabled` ketika memanggil perintah-perintah CLI. #### Catatan: Gunakan Docker _18.06 ke atas_, versi-versi di bawahnya memiliki _bug_ ataupun tidak mendukung perintah eksperimental. Contohnya [https://github.com/docker/cli/issues/1135](https://github.com/docker/cli/issues/1135) yang menyebabkan masalah di bawah containerd. Kalau kamu terkena masalah ketika mengunggah manifes-manifes yang rusak, cukup bersihkan manifes-manifes yang lama di `$HOME/.docker/manifests` untuk memulai dari awal. Untuk Kubernetes, kami biasanya menggunakan _image-image_ dengan sufiks `-$(ARCH)`. Untuk kompatibilitas (_backward compatibility_), lakukan _generate image-image_ yang lama dengan sufiks. Idenya adalah men-_generate_, misalnya `pause` image yang memiliki manifes untuk semua arsitektur dan misalnya `pause-amd64` yang punya kompatibilitas terhadap konfigurasi-konfigurasi lama atau berkas-berkas YAML yang bisa saja punya _image-image_ bersufiks yang di-_hardcode_. Menggunakan Registri Privat (_Private Registry_) ------------------------------------------------ Biasanya kita memerlukan _key_ untuk membaca _image-image_ yang tersedia pada suatu registri privat. Kredensial ini dapat disediakan melalui beberapa cara: * Menggunakan Google Container Registry * per-klaster * konfigurasi secara otomatis pada Google Compute Engine atau Google Kubernetes Engine * semua Pod dapat membaca registri privat yang ada di dalam proyek * Menggunakan Amazon Elastic Container Registry (ECR) * menggunakan IAM _role_ dan _policy_ untuk mengontrol akses ke repositori ECR * secara otomatis _refresh_ kredensial login ECR * Menggunakan Oracle Cloud Infrastructure Registry (OCIR) * menggunakan IAM _role_ dan _policy_ untuk mengontrol akses ke repositori OCIR * Menggunakan Azure Container Registry (ACR) * Menggunakan IBM Cloud Container Registry * menggunakan IAM _role_ dan _policy_ untuk memberikan akses ke IBM Cloud Container Registry * Konfigurasi Node untuk otentikasi registri privat * semua Pod dapat membaca registri privat manapun * memerlukan konfigurasi Node oleh admin klaster * Pra-unduh _image_ * semua Pod dapat menggunakan _image_ apapun yang di-_cached_ di dalam sebuah Node * memerlukan akses root ke dalam semua Node untuk pengaturannya * Mengatur ImagePullSecrets dalam sebuah Pod * hanya Pod-Pod yang menyediakan _key_ sendiri yang dapat mengakses registri privat Masing-masing opsi dijelaskan lebih lanjut di bawah ini. ### Menggunakan Google Container Registry Kubernetes memiliki dukungan _native_ untuk [Google Container Registry (GCR)](https://cloud.google.com/tools/container-registry/) , ketika dijalankan pada Google Compute Engine (GCE). Jika kamu menjalankan klaster pada GCE atau Google Kubernetes Engine, cukup gunakan nama panjang _image_ (misalnya gcr.io/my\_project/image:tag). Semua Pod di dalam klaster akan memiliki akses baca _image_ di registri ini. Kubelet akan melakukan otentikasi GCR menggunakan _service account_ yang dimiliki _instance_ Google. _Service acccount_ pada _instance_ akan memiliki sebuah `https://www.googleapis.com/auth/devstorage.read_only`, sehingga dapat mengunduh dari GCR di proyek yang sama, tapi tidak untuk unggah. ### Menggunakan Amazon Elastic Container Registry Kubernetes memiliki dukungan _native_ untuk [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) , ketika Node adalah AWS EC2 _instance_. Cukup gunakan nama panjang _image_ (misalnya `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) di dalam definisi Pod. Semua pengguna klaster yang dapat membuat Pod akan bisa menjalankan Pod yang dapat menggunakan _image-image_ di dalam registri ECR. Kubelet akan mengambil dan secara periodik memperbarui kredensial ECR, yang memerlukan _permission_ sebagai berikut: * `ecr:GetAuthorizationToken` * `ecr:BatchCheckLayerAvailability` * `ecr:GetDownloadUrlForLayer` * `ecr:GetRepositoryPolicy` * `ecr:DescribeRepositories` * `ecr:ListImages` * `ecr:BatchGetImage` Persyaratan: * Kamu harus menggunakan versi kubelet `v1.2.0` atau lebih (misal jalankan `/usr/bin/kubelet --version=true`). * Jika Node yang kamu miliki ada di region A dan registri kamu ada di region yang berbeda misalnya B, kamu perlu versi `v1.3.0` atau lebih. * ECR harus tersedia di region kamu. Cara _troubleshoot_: * Verifikasi semua persyaratan di atas. * Dapatkan kredensial $REGION (misalnya `us-west-2`) pada _workstation_ kamu. Lakukan SSH ke dalam _host_ dan jalankan Docker secara manual menggunakan kredensial tersebut. Apakah berhasil? * Tambahkan verbositas level _log_ kubelet paling tidak 3 dan periksa _log_ kubelet (misal `journalctl -u kubelet`) di baris-baris yang seperti ini: * `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` * `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr..amazonaws.com` ### Menggunakan Azure Container Registry (ACR) Ketika menggunakan [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) kamu dapat melakukan otentikasi menggunakan pengguna admin maupun sebuah _service principal_. Untuk keduanya, otentikasi dilakukan melalui proses otentikasi Docker standar. Instruksi-instruksi ini menggunakan perangkat [azure-cli](https://github.com/azure/azure-cli) . Kamu pertama perlu membuat sebuah registri dan men-_generate_ kredensial, dokumentasi yang lengkap tentang hal ini dapat dilihat pada [dokumentasi Azure container registry](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli) . Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk login: * `DOCKER_USER` : _service principal_, atau pengguna admin * `DOCKER_PASSWORD`: kata sandi dari _service principal_, atau kata sandi dari pengguna admin * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io` * `DOCKER_EMAIL`: `${some-email-address}` Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat [mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](https://kubernetes.io/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) . ### Menggunakan IBM Cloud Container Registry IBM Cloud Container Registry menyediakan sebuah registri _image_ privat yang _multi-tenant_, dapat kamu gunakan untuk menyimpan dan membagikan _image-image_ secara aman. Secara _default_, _image-image_ di dalam registri privat kamu akan dipindai (_scan_) oleh Vulnerability Advisor terintegrasi untuk deteksi isu keamanan dan kerentanan (_vulnerability_) yang berpotensi. Para pengguna di dalam akun IBM Cloud kamu dapat mengakses _image_, atau kamu dapat menggunakan IAM _role_ dan _policy_ untuk memberikan akses ke _namespace_ di IBM Cloud Container Registry. Untuk instalasi _plugin_ CLI di IBM Cloud Containerr Registry dan membuat sebuah _namespace_ untuk _image-image_ kamu, lihat [Mulai dengan IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=registry-getting-started) . Jika kamu menggunakan akun dan wilayah (_region_) yang sama, kamu dapat melakukan _deploy image-image_ yang disimpan di dalam IBM Cloud Container Registry ke dalam _namespace default_ dari klaster IBM Cloud Kubernetes Service yang kamu miliki tanpa konfigurasi tambahan, lihat [Membuat kontainer dari _image_](https://cloud.ibm.com/docs/containers?topic=containers-images) . Untuk opsi konfigurasi lainnya, lihat [Bagaimana cara mengotorasi klaster untuk mengunduh _image_ dari sebuah registri](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth) . ### Konfigurasi Node untuk Otentikasi ke sebuah Registri Privat #### Catatan: Jika kamu jalan di Google Kubernetes Engine, akan ada `.dockercfg` pada setiap Node dengan kredensial untuk Google Container Registry. Kamu tidak bisa menggunakan cara ini. #### Catatan: Jika kamu jalan di AWS EC2 dan menggunakan EC2 Container Registry (ECR), kubelet pada setiap Node akan dapat mengatur dan memperbarui kredensial login ECR. Kamu tidak bisa menggunakan cara ini. #### Catatan: Cara ini cocok jika kamu dapat mengontrol konfigurasi Node. Cara ini tidak akan bekerja dengan baik pada GCE, dan penyedia layanan cloud lainnya yang tidak melakukan penggantian Node secara otomatis. #### Catatan: Kubernetes pada saat ini hanya mendukung bagian `auths` dan `HttpHeaders` dari konfigurasi docker. Hal ini berarti bantuan kredensial (`credHelpers` atau `credsStore`) tidak didukung. Docker menyimpan _key_ untuk registri privat pada `$HOME/.dockercfg` atau berkas `$HOME/.docker/config.json`. Jika kamu menempatkan berkas yang sama pada daftar jalur pencarian (_search path_) berikut, kubelet menggunakannya sebagai penyedia kredensial saat mengunduh _image_. * `{--root-dir:-/var/lib/kubelet}/config.json` * `{cwd of kubelet}/config.json` * `${HOME}/.docker/config.json` * `/.docker/config.json` * `{--root-dir:-/var/lib/kubelet}/.dockercfg` * `{cwd of kubelet}/.dockercfg` * `${HOME}/.dockercfg` * `/.dockercfg` #### Catatan: Kamu mungkin harus mengatur `HOME=/root` secara eksplisit pada berkas _environment_ kamu untuk kubelet. Berikut langkah-langkah yang direkomendasikan untuk mengkonfigurasi Node kamu supaya bisa menggunakan registri privat. Pada contoh ini, coba jalankan pada _desktop/laptop_ kamu: 1. Jalankan `docker login [server]` untuk setiap set kredensial yang ingin kamu gunakan. Ini akan memperbarui `$HOME/.docker/config.json`. 2. Lihat `$HOME/.docker/config.json` menggunakan _editor_ untuk memastikan sudah berisi kredensial yang ingin kamu gunakan. 3. Dapatkan daftar Node, contohnya: * jika kamu ingin mendapatkan nama: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` * jika kamu ingin mendapatkan IP: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` 4. Salin `.docker/config.json` yang ada di lokal kamu pada salah satu jalur pencarian di atas. * contohnya: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done` Verifikasi dengana membuat sebuah Pod yanag menggunakan _image_ privat, contohnya: kubectl apply -f - < --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas, kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret. [Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](https://kubernetes.io/id/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini. Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat, perintah `kubectl create secret docker-registry` akan membuat sebuah Secret yang akan hanya bekerja menggunakan satu registri privat. #### Catatan: Pod-Pod hanya dapat mengacu pada imagePullSecrets di dalam _namespace_, sehingga proses ini perlu untuk diselesaikan satu kali setiap _namespace_. #### Mengacu pada imagePullSecrets di dalam sebuah Pod Sekarang, kamu dapat membuat Pod yang mengacu pada Secret dengan menambahkan bagian `imagePullSecrets` untuk sebuah definisi Pod. cat < pod.yaml apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey EOF cat <> ./kustomization.yaml resources: - pod.yaml EOF Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri privat. Hanya saja, mengatur _field_ ini dapat diotomasi dengan mengatur imagePullSecrets di dalam sumber daya [serviceAccount](https://kubernetes.io/docs/user-guide/service-accounts) . Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](https://kubernetes.io/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail. Kamu dapat menggunakan cara ini bersama `.docker/config.json` pada setiap Node. Kredensial-kredensial akan dapat di-_merged_. Cara ini akan dapat bekerja pada Google Kubernetes Engine. ### Kasus-Kasus Penggunaan (_Use Case_) Ada beberapa solusi untuk konfigurasi registri privat. Berikut beberapa kasus penggunaan dan solusi yang disarankan. 1. Klaster yang hanya menjalankan _image non-proprietary_ (misalnya open-source). Tidak perlu unutuk menyembunyikan _image_. * Gunakan _image_ publik pada Docker hub. * Tidak ada konfigurasi yang diperlukan. * Pada GCE/Google Kubernetes Engine, sebuah _mirror_ lokal digunakan secara otomatis untuk meningkatkan kecepatan dan ketersediaan. 2. Klaster yang menjalankan _image proprietary_ yang seharusnya disembunyikan dari luar perusahaan, tetapi bisa terlihat oleh pengguna klaster. * Gunakan sebuah privat [registri Docker](https://docs.docker.com/registry/) yang _hosted_. * Bisa saja di-_host_ pada [Docker Hub](https://hub.docker.com/signup) , atau lainnya. * Konfigurasi `.docker/config.json` secara manual pada setiap Node seperti dijelaskan di atas. * Atau, jalankan sebuah registri privat internal di belakang _firewall_ kamu dengan akses baca terbuka. * Tidak ada konfigurasi Kubernetes yang diperlukan. * Atau, ketika pada GCE/Google Kubernetes Engine, menggunakan Google Container Registry yang ada di proyek. * Hal ini bisa bekerja baik dengan _autoscaling_ klaster dibandingkan konfigurasi Node manual. * Atau, pada sebuah klaster dimana mengubah konfigurasi Node tidak nyaman, gunakan `imagePullSecrets`. 3. Klaster dengan _image proprietary_, beberapa memerlukan akses kontrol yang lebih ketat. * Pastikan [AlwaysPullImages _admission controller_](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktif. Sebaliknya, semua Pod berpotensi memiliki akses ke semua _image_. * Pindahkan data sensitif pada sumber daya "Secret", daripada mengemasnya menjadi sebuah _image_. 4. Sebuah klaster _multi-tenant_ dimana setiap _tenant_ memerlukan registri privatnya masing-masing. * Pastikan [AlwaysPullImages _admission controller_](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktif. Sebaliknya, semua Pod dari semua tenant berpotensi memiliki akses pada semua _image_. * Jalankan sebuah registri privat dimana otorisasi diperlukan. * Men-_generate_ kredensial registri uuntuk setiap _tenant_, masukkan ke dalam _secret_ uuntuk setiap _namespace tenant_. * _Tenant_ menambahkan _secret_ pada imagePullSecrets uuntuk setiap _namespace_. Jika kamu memiliki akses pada beberapa registri, kamu dapat membuat satu _secret_ untuk setiap registri. Kubelet akan melakukan _merge_ `imagePullSecrets` manapun menjadi sebuah virtual `.docker/config.json`. Masukan ------- Apakah halaman ini membantu? Ya Tidak Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Buat isu di repositori GitHub jika kamu ingin [laporkan problem](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) atau [beri saran perbaikan](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . Last modified July 10, 2020 at 10:24 PM PST: [Replace EN links to ID links (0c799ef757)](https://github.com/kubernetes/website/commit/0c799ef757368c8839a912df5d949fa2603042f5) --- # Aplicaciones Stateless | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/tutorials/stateless-application/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/tutorials/stateless-application/) . Aplicaciones Stateless ====================== --- # কুবারনেটিসে অবদান | Kubernetes এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। [মুদ্রণ করতে এখানে ক্লিক করুন](https://kubernetes.io/bn/docs/contribute/_print/#) . [এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন](https://kubernetes.io/bn/docs/contribute/) . কুবারনেটিসে অবদান ================= কুবারনেটিসে অবদান রাখার অনেক উপায় আছে। আপনি নতুন ফিচারগুলোর জন্য ডিজাইনে কাজ করতে পারেন, আপনি আমাদের কাছে ইতিমধ্যে থাকা কোডটি ডকুমেন্ট করতে পারেন, আপনি আমাদের [ব্লগের](https://kubernetes.io/bn/blog) জন্য লিখতে পারেন। আরও আছে: আপনি সেই নতুন ফিচারগুলোর বাস্তবায়ন করতে পারেন বা বাগগুলি ঠিক করতে পারেন৷ আপনি লোকেদের আমাদের অবদানকারী কমিউনিটিতে যোগ দিতে সাহায্য করতে পারেন, বা বিদ্যমান অবদানকারীদের সাপোর্ট করতে পারেন৷ এই সমস্ত ভিন্ন উপায়ে প্রকল্পে পার্থক্য আনতে, আমরা - কুবারনেটিস - একটি ডেডিকেটেড ওয়েবসাইট তৈরি করেছি: [https://k8s.dev/](https://k8s.dev/) । কুবারনেটিসে অবদান রাখার বিষয়ে আরও জানতে আপনি সেখানে যেতে পারেন। আপনি যদি বিশেষভাবে _এই_ ডকুমেন্টেশনে অবদান রাখার বিষয়ে জানতে চান, পড়ুন [কুবারনেটিস ডকুমেন্টেশনে অবদান রাখুন](https://kubernetes.io/docs/contribute/docs/) । এছাড়াও আপনি পড়তে পারেন [CNCF](https://cncf.io/ "Cloud Native Computing Foundation") [পৃষ্ঠা](https://contribute.cncf.io/contributors/projects/#kubernetes) কুবারনেটিস অবদান সম্পর্কে। --- # Container | Kubernetes Das ist eine für den Ausdruck optimierte Ansicht des gesamten Kapitels inkl. Unterseiten. [Druckvorgang starten](https://kubernetes.io/de/docs/concepts/containers/_print/#) . [Zur Standardansicht zurückkehren](https://kubernetes.io/de/docs/concepts/containers/) . Container ========= Methoden, um Anwendungen und ihre Abhängigkeiten zusammenzufassen. * 1: [Images](https://kubernetes.io/de/docs/concepts/containers/_print/#pg-16042b4652ad19e565c7263824029a43) 1 - Images ========== Sie erstellen Ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann. Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags. Aktualisieren von Images ------------------------ Die Standardregel für das Herunterladen von Images ist `IfNotPresent`, dies führt dazu, dass das Image wird nur heruntergeladen wenn es noch nicht lokal verfügbar ist. Wenn sie stattdessen möchten, dass ein Image immer forciert heruntergeladen wird, können sie folgendes tun: * Die `imagePullPolicy` des Containers auf `Always` setzen. * Die `imagePullPolicy` auslassen und `:latest` als Image Tag nutzen. * Die `imagePullPolicy` und den Tag des Images auslassen. * Den [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) Admission Controller aktivieren. Beachten Sie, dass Sie die Nutzung des `:latest` Tags vermeiden sollten. Für weitere Informationen siehe: [Best Practices for Configuration](https://kubernetes.io/docs/concepts/configuration/overview/#container-images) . Multi-Architektur Images mit Manifesten bauen --------------------------------------------- Das Docker Kommandozeilenwerkzeug unterstützt jetzt das Kommando `docker manifest` mit den Subkommandos `create`, `annotate` and `push`. Diese Kommandos können dazu genutzt werden Manifeste zu bauen und diese hochzuladen. Weitere Informationen finden sie in der Docker Dokumentation: [https://docs.docker.com/edge/engine/reference/commandline/manifest/](https://docs.docker.com/edge/engine/reference/commandline/manifest/) Hier einige Beispiele wie wir dies in unserem Build - Prozess nutzen: [https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=](https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=) Diese Kommandos basieren rein auf dem Docker Kommandozeileninterface und werden auch damit ausgeführt. Sie sollten entweder die Datei `$HOME/.docker/config.json` bearbeiten und den `experimental` Schlüssel auf `enabled` setzen, oder einfach die Umgebungsvariable `DOCKER_CLI_EXPERIMENTAL` auf `enabled` setzen, wenn Sie das Docker Kommandozeileninterface aufrufen. #### Hinweis: Nutzen die bitte Docker _18.06 oder neuer_, ältere Versionen haben entweder Bugs oder unterstützen die experimentelle Kommandozeilenoption nicht. Beispiel: [https://github.com/docker/cli/issues/1135](https://github.com/docker/cli/issues/1135) verursacht Probleme unter containerd. Wenn mit alten Manifesten Probleme auftreten, können sie die alten Manifeste in `$HOME/.docker/manifests` entfernen, um von vorne zu beginnen. Für Kubernetes selbst nutzen wir typischerweise Images mit dem Suffix `-$(ARCH)`. Um die Abwärtskompatibilität zu erhalten, bitten wir Sie, die älteren Images mit diesen Suffixen zu generieren. Die Idee dahinter ist z.B., das `pause` image zu generieren, welches das Manifest für alle Architekturen hat, `pause-amd64` wäre dann abwärtskompatibel zu älteren Konfigurationen, oder YAML - Dateien, die ein Image mit Suffixen hart kodiert enthalten. Nutzung einer privaten Registry ------------------------------- Private Registries könnten Schlüssel erfordern um Images von ihnen herunterzuladen. Authentifizierungsdaten können auf verschiedene Weisen hinterlegt werden: * Bei der Google Container Registry * Je Cluster * Automatisch in der Google Compute Engine oder Google Kubernetes Engine * Allen Pods erlauben von der privaten Registry des Projektes lesen zu können * Bei der Amazon Elastic Container Registry (ECR) * IAM Rollen und Richtlinien nutzen um den Zugriff auf ECR Repositories zu kontrollieren * Automatisch ECR Authentifizierungsdaten aktualisieren * Bei der Oracle Cloud Infrastructure Registry (OCIR) * IAM Rollen und Richtlinien nutzen um den Zugriff auf OCIR Repositories zu kontrollieren * Bei der Azure Container Registry (ACR) * Bei der IBM Cloud Container Registry * Nodes konfigurieren sich bei einer privaten Registry authentifizieren zu können - Allen Pods erlauben von jeder konfigurierten privaten Registry lesen zu können - Setzt die Konfiguration der Nodes durch einen Cluster - Aministrator voraus * Im Voraus heruntergeladene Images * Alle Pods können jedes gecachte Image auf einem Node nutzen * Setzt root - Zugriff auf allen Nodes zum Einrichten voraus * Spezifizieren eines ImagePullSecrets auf einem Pod * Nur Pods, die eigene Secrets tragen, haben Zugriff auf eine private Registry Jede Option wird im Folgenden im Detail beschrieben ### Bei Nutzung der Google Container Registry Kubernetes hat eine native Unterstützung für die [Google Container Registry (GCR)](https://cloud.google.com/tools/container-registry/) wenn es auf der Google Compute Engine (GCE) läuft. Wenn Sie ihren Cluster auf GCE oder der Google Kubernetes Engine betreiben, genügt es, einfach den vollen Image Namen zu nutzen (z.B. gcr.io/my\_project/image:tag ). Alle Pods in einem Cluster haben dann Lesezugriff auf Images in dieser Registry. Das Kubelet authentifiziert sich bei GCR mit Nutzung des Google service Kontos der jeweiligen Instanz. Das Google Servicekonto der Instanz hat einen `https://www.googleapis.com/auth/devstorage.read_only`, so kann es vom GCR des Projektes herunter, aber nicht hochladen. ### Bei Nutzung der Amazon Elastic Container Registry Kubernetes bietet native Unterstützung für die [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) , wenn Knoten AWS EC2 Instanzen sind. Es muss einfach nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden. Alle Benutzer eines Clusters, die Pods erstellen dürfen, können dann jedes der Images in der ECR Registry zum Ausführen von Pods nutzen. Das Kubelet wird periodisch ECR Zugriffsdaten herunterladen und auffrischen, es benötigt hierfür die folgenden Berechtigungen: * `ecr:GetAuthorizationToken` * `ecr:BatchCheckLayerAvailability` * `ecr:GetDownloadUrlForLayer` * `ecr:GetRepositoryPolicy` * `ecr:DescribeRepositories` * `ecr:ListImages` * `ecr:BatchGetImage` Voraussetzungen: * Sie müssen Kubelet in der Version `v1.2.0` nutzen. (Führen sie z.B. (e.g. run `/usr/bin/kubelet --version=true` aus um die Version zu prüfen) * Sie benötigen Version `v1.3.0` oder neuer wenn ihre Knoten in einer A - Region sind und sich ihre Registry in einer anderen B - Region befindet. * ECR muss in ihrer Region angeboten werden Fehlerbehebung: * Die oben genannten Voraussetzungen müssen erfüllt sein * Laden sie die $REGION (z.B. `us-west-2`) Zugriffsdaten auf ihren Arbeitsrechner. Verbinden sie sich per SSH auf den Host und nutzen die Docker mit diesen Daten. Funktioniert es? * Prüfen sie ob das Kubelet it dem Parameter `--cloud-provider=aws` läuft. * Prüfen sie die Logs des Kubelets (z.B. mit `journalctl -u kubelet`) auf Zeilen wie: * `plugins.go:56] Registering credential provider: aws-ecr-key` * `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider` ### Bei Nutzung der Azure Container Registry (ACR) Bei Nutzung der [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) können sie sich entweder als ein administrativer Nutzer, oder als ein Service Principal authentifizieren. In jedem Fall wird die Authentifizierung über die Standard - Docker Authentifizierung ausgeführt. Diese Anleitung bezieht sich auf das [azure-cli](https://github.com/azure/azure-cli) Kommandozeilenwerkzeug. Sie müssen zunächst eine Registry und Authentifizierungsdaten erstellen, eine komplette Dokumentation dazu finden sie hier: [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli) . Sobald sie ihre Container Registry erstellt haben, nutzen sie die folgenden Authentifizierungsdaten: * `DOCKER_USER` : Service Principal oder Administratorbenutzername * `DOCKER_PASSWORD`: Service Principal Password oder Administratorpasswort * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io` * `DOCKER_EMAIL`: `${some-email-address}` Wenn sie diese Variablen befüllt haben, können sie: [Kubernetes konfigurieren und damit einen Pod deployen](https://kubernetes.io/de/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) . ### Bei Nutzung der IBM Cloud Container Registry Die IBM Cloud Container Registry bietet eine mandantenfähige Private Image Registry, die Sie nutzen können, um ihre Docker Images sicher zu speichern und zu teilen. Standardmäßig werden Images in ihrer Private Registry vom integrierten Schwachstellenscaner durchsucht, um Sicherheitsprobleme und potentielle Schwachstellen zu finden. Benutzer können ihren IBM Cloud Account nutzen, um Zugang zu ihren Images zu erhalten, oder um einen Token zu generieren, der Zugriff auf die Registry Namespaces erlaubt. Um das IBM Cloud Container Registry Kommandozeilenwerkzeug zu installieren und einen Namespace für ihre Images zu erstellen, folgen sie dieser Dokumentation [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started) . Sie können die IBM Cloud Container Registry nutzen, um Container aus [IBM Cloud public images](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) und ihren eigenen Images in den `default` Namespace ihres IBM Cloud Kubernetes Service Clusters zu deployen. Um einen Container in einen anderen Namespace, oder um ein Image aus einer anderen IBM Cloud Container Registry Region oder einem IBM Cloud account zu deployen, erstellen sie ein Kubernetes `imagePullSecret`. Weitere Informationen finden sie unter: [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images) . ### Knoten für die Nutzung einer Private Registry konfigurieren #### Hinweis: Wenn sie Google Kubernetes Engine verwenden, gibt es schon eine `.dockercfg` auf jedem Knoten, die Zugriffsdaten für ihre Google Container Registry beinhaltet. Dann kann die folgende Vorgehensweise nicht angewendet werden. #### Hinweis: Wenn sie AWS EC2 verwenden und die EC2 Container Registry (ECR) nutzen, wird das Kubelet auf jedem Knoten die ECR Zugriffsdaten verwalten und aktualisieren. Dann kann die folgende Vorgehensweise nicht angewendet werden. #### Hinweis: Diese Vorgehensweise ist anwendbar, wenn sie ihre Knoten-Konfiguration ändern können; Sie wird nicht zuverlässig auf GCE oder einem anderen Cloud - Provider funktionieren, der automatisch Knoten ersetzt. #### Hinweis: Kubernetes unterstützt zurzeit nur die `auths` und `HttpHeaders` Abschnitte der Dockerkonfiguration. Das bedeutet, dass die Hilfswerkzeuge (`credHelpers` ooderr `credsStore`) nicht unterstützt werden. Docker speichert Schlüssel für eigene Registries entweder unter `$HOME/.dockercfg` oder `$HOME/.docker/config.json`. Wenn sie die gleiche Datei in einen der unten aufgeführten Suchpfade speichern, wird Kubelet sie als Hilfswerkzeug für Zugriffsdaten beim Beziehen von Images nutzen. * `{--root-dir:-/var/lib/kubelet}/config.json` * `{cwd of kubelet}/config.json` * `${HOME}/.docker/config.json` * `/.docker/config.json` * `{--root-dir:-/var/lib/kubelet}/.dockercfg` * `{cwd of kubelet}/.dockercfg` * `${HOME}/.dockercfg` * `/.dockercfg` #### Hinweis: Eventuell müssen sie `HOME=/root` in ihrer Umgebungsvariablendatei setzen. Dies sind die empfohlenen Schritte, um ihre Knoten für eine Nutzung einer eigenen Registry zu konfigurieren. In diesem Beispiel führen sie folgende Schritte auf ihrem Desktop/Laptop aus: 1. Führen sie `docker login [server]` für jeden Satz ihrer Zugriffsdaten aus. Dies aktualisiert `$HOME/.docker/config.json`. 2. Prüfen Sie `$HOME/.docker/config.json` in einem Editor darauf, ob dort nur Zugriffsdaten enthalten sind, die Sie nutzen möchten. 3. Erhalten sie eine Liste ihrer Knoten: * Wenn sie die Namen benötigen: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` * Wenn sie die IP - Adressen benötigen: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` 4. Kopieren sie ihre lokale `.docker/config.json` in einen der oben genannten Suchpfade. * Zum Beispiel: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done` Prüfen durch das Erstellen eines Pods, der ein eigenes Image nutzt, z.B.: kubectl apply -f - < --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL Wenn Sie bereits eine Datei mit Docker-Zugriffsdaten haben, können Sie die Zugriffsdaten als ein Kubernetes Secret importieren: [Create a Secret based on existing Docker credentials](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) beschreibt die Erstellung. Dies ist insbesondere dann sinnvoll, wenn sie mehrere eigene Container Registries nutzen, da `kubectl create secret docker-registry` ein Secret erstellt, das nur mit einer einzelnen eigenen Registry funktioniert. #### Hinweis: Pods können nur eigene Image Pull Secret in ihrem eigenen Namespace referenzieren, somit muss dieser Prozess jedes mal einzeln für jeden Namespace angewendet werden. #### Referenzierung eines imagePullSecrets bei einem Pod Nun können Sie Pods erstellen, die dieses Secret referenzieren, indem Sie einen Abschnitt `imagePullSecrets` zu ihrer Pod - Definition hinzufügen. cat < pod.yaml apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey EOF cat <> ./kustomization.yaml resources: - pod.yaml EOF Dies muss für jeden Pod getan werden, der eine eigene Registry nutzt. Die Erstellung dieser Sektion kann jedoch automatisiert werden, indem man imagePullSecrets einer [serviceAccount](https://kubernetes.io/docs/user-guide/service-accounts) Ressource hinzufügt. [Add ImagePullSecrets to a Service Account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) bietet detaillierte Anweisungen hierzu. Sie können dies in Verbindung mit einer auf jedem Knoten genutzten `.docker/config.json` benutzen, die Zugriffsdaten werden dann zusammengeführt. Dieser Vorgehensweise wird in der Google Kubernetes Engine funktionieren. ### Anwendungsfälle Es gibt eine Anzahl an Lösungen um eigene Registries zu konfigurieren, hier sind einige Anwendungsfälle und empfohlene Lösungen. 1. Cluster die nur nicht-proprietäre Images (z.B. open-source) ausführen. Images müssen nicht versteckt werden. * Nutzung von öffentlichen Images auf Docker Hub. * Keine Konfiguration notwendig. * Auf GCE/Google Kubernetes Engine, wird automatisch ein lokaler Spiegel für eine verbesserte Geschwindigkeit und Verfügbarkeit genutzt. 2. Cluster die einige proprietäre Images ausführen die für Außenstehende nicht sichtbar sein dürfen, aber für alle Cluster - Benutzer sichtbar sein sollen. * Nutzung einer gehosteten privaten Registry [Docker registry](https://docs.docker.com/registry/) . * Kann auf [Docker Hub](https://hub.docker.com/signup) , oder woanders gehostet werden. * Manuelle Konfiguration der .docker/config.json auf jedem Knoten, wie oben beschrieben. * Der Betrieb einer internen privaten Registry hinter ihrer Firewall mit offenen Leseberechtigungen. * Keine Kubernetes - Konfiguration notwendig * Wenn GCE/Google Kubernetes Engine genutzt wird, nutzen sie die Google Container Registry des Projektes. * Funktioniert besser mit Cluster - Autoskalierung als mit manueller Knotenkonfiguration. * Auf einem Cluster bei dem die Knotenkonfiguration ungünstig ist können `imagePullSecrets` genutzt werden. 3. Cluster mit proprieritären Images, mit einigen Images die eine erweiterte Zugriffskontrolle erfordern. * Stellen sie sicher das [AlwaysPullImages admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktiv ist, anderenfalls können alle Pods potenziell Zugriff auf alle Images haben. * Verschieben sie sensitive Daten in eine "Secret" Ressource statt sie im Image abzulegen. 4. Ein mandantenfähiger Cluster in dem jeder Mandant eine eigene private Registry benötigt. * Stellen sie dicher das [AlwaysPullImages admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktiv ist, anderenfalls können alle Pods potenziell Zugriff auf alle Images haben. * Nutzen sie eine private Registry die eine Authorisierung erfordert. * Generieren die Registry - Zugriffsdaten für jeden Mandanten, abgelegt in einem Secret das in jedem Mandanten - Namespace vorhanden ist. * Der Mandant fügt dieses Sercret zu den imagePullSecrets in jedem seiner Namespace hinzu. Falls die Zugriff auf mehrere Registries benötigen, können sie ein Secret für jede Registry erstellen, Kubelet wird jedwede `imagePullSecrets` in einer einzelnen `.docker/config.json` zusammenfassen. --- # Огляд | Kubernetes Це багатосторінковий друкований вигляд цього розділу. [Натисність щоб друкувати](https://kubernetes.io/uk/docs/concepts/overview/_print/#) . [Повернутися до звичайного перегляду сторінки](https://kubernetes.io/uk/docs/concepts/overview/) . Огляд ===== * 1: [Що таке Kubernetes?](https://kubernetes.io/uk/docs/concepts/overview/_print/#pg-45bdca6129cf540121623e903c18ba46) 1 - Що таке Kubernetes? ======================= Ця сторінка являє собою узагальнений огляд Kubernetes. Kubernetes - це платформа з відкритим вихідним кодом для управління контейнеризованими робочими навантаженнями та супутніми службами. Її основні характеристики - кросплатформенність, розширюваність, успішне використання декларативної конфігурації та автоматизації. Вона має гігантську, швидкопрогресуючу екосистему. Назва Kubernetes походить з грецької та означає керманич або пілот. Google відкрив доступ до вихідного коду проекту Kubernetes у 2014 році. Kubernetes побудовано [на базі п'ятнадцятирічного досвіду, що Google отримав, оперуючи масштабними робочими навантаженнями](https://research.google/pubs/pub43438) у купі з найкращими у своєму класі ідеями та практиками, які може запропонувати спільнота. Озираючись на першопричини -------------------------- Повернімось назад у часі та дізнаємось, завдяки чому Kubernetes став таким корисним. ![Еволюція розгортання](https://kubernetes.io/images/docs/Container_Evolution.svg) **Ера традиційного розгортання:** На початку організації запускали застосунки на фізичних серверах. Оскільки в такий спосіб не було можливості задати обмеження використання ресурсів, це спричиняло проблеми виділення та розподілення ресурсів на фізичних серверах. Наприклад: якщо багато застосунків було запущено на фізичному сервері, могли траплятись випадки, коли один застосунок забирав собі найбільше ресурсів, внаслідок чого інші програми просто не справлялись з обов'язками. Рішенням може бути запуск кожного застосунку на окремому фізичному сервері. Але такий підхід погано масштабується, оскільки ресурси не повністю використовуються; на додачу, це дорого, оскільки організаціям потрібно опікуватись багатьма фізичними серверами. **Ера віртуалізованого розгортання:** Як рішення - була представлена віртуалізація. Вона дозволяє запускати численні віртуальні машини (Virtual Machines або VMs) на одному фізичному ЦПУ сервера. Віртуалізація дозволила застосункам бути ізольованими у межах віртуальних машин та забезпечувала безпеку, оскільки інформація застосунку на одній VM не була доступна застосунку на іншій VM. Віртуалізація забезпечує краще використання ресурсів на фізичному сервері та кращу масштабованість, оскільки дозволяє легко додавати та оновлювати застосунки, зменшує витрати на фізичне обладнання тощо. З віртуалізацією ви можете представити ресурси у вигляді одноразових віртуальних машин. Кожна VM є повноцінною машиною з усіма компонентами, включно з власною операційною системою, що запущені поверх віртуалізованого апаратного забезпечення. **Ера розгортання контейнерів:** Контейнери схожі на VM, але мають спрощений варіант ізоляції і використовують спільну операційну систему для усіх застосунків. Саме тому контейнери вважаються "легкими", в порівнянні з віртуалками. Подібно до VM, контейнер має власну файлову систему, ЦПУ, пам'ять, простір процесів тощо. Оскільки контейнери вивільнені від підпорядкованої інфраструктури, їх можна легко переміщати між хмарними провайдерами чи дистрибутивами операційних систем. Контейнери стали популярними, бо надавали додаткові переваги, такі як: * Створення та розгортання застосунків за методологією Agile: спрощене та більш ефективне створення образів контейнерів у порівнянні до використання образів віртуальних машин. * Безперервна розробка, інтеграція та розгортання: забезпечення надійних та безперервних збирань образів контейнерів, їх швидке розгортання та легкі відкатування (за рахунок незмінності образів). * Розподіл відповідальності команд розробки та експлуатації: створення образів контейнерів застосунків під час збирання/релізу на противагу часу розгортання, і як наслідок, вивільнення застосунків із інфраструктури. * Спостереження не лише за інформацією та метриками на рівні операційної системи, але й за станом застосунку та іншими сигналами. * Однорідність середовища для розробки, тестування та робочого навантаження: запускається так само як на робочому комп'ютері, так і у хмарного провайдера. * ОС та хмарна кросплатформність: запускається на Ubuntu, RHEL, CoreOS, у власному дата-центрі, у Google Kubernetes Engine і взагалі будь-де. * Керування орієнтоване на застосунки: підвищення рівня абстракції від запуску операційної системи у віртуальному апаратному забезпеченні до запуску застосунку в операційній системі, використовуючи логічні ресурси. * Нещільно зв'язані, розподілені, еластичні, вивільнені мікросервіси: застосунки розбиваються на менші, незалежні частини для динамічного розгортання та управління, на відміну від монолітної архітектури, що працює на одній великій виділеній машині. * Ізоляція ресурсів: передбачувана продуктивність застосунку. * Використання ресурсів: висока ефективність та щільність. Чому вам потрібен Kubernetes і що він може робити ------------------------------------------------- Контейнери - це прекрасний спосіб упакувати та запустити ваші застосунки. У прод оточенні вам потрібно керувати контейнерами, в яких працюють застосунки, і стежити, щоб не було простою. Наприклад, якщо один контейнер припиняє роботу, інший має бути запущений йому на заміну. Чи не легше було б, якби цим керувала сама система? Ось де Kubernetes приходить на допомогу! Kubernetes надає вам каркас для еластичного запуску розподілених систем. Він опікується масштабуванням та аварійним відновленням вашого застосунку, пропонує шаблони розгортань тощо. Наприклад, Kubernetes дозволяє легко створювати розгортання за стратегією canary у вашій системі. Kubernetes надає вам: * **Виявлення сервісів та балансування навантаження** Kubernetes може надавати доступ до контейнера, використовуючи DNS-ім'я або його власну IP-адресу. Якщо контейнер зазнає завеликого мережевого навантаження, Kubernetes здатний збалансувати та розподілити його таким чином, щоб якість обслуговування залишалась стабільною. * **Оркестрація сховища інформації** Kubernetes дозволяє вам автоматично монтувати системи збереження інформації на ваш вибір: локальні сховища, рішення від хмарних провайдерів тощо. * **Автоматичне розгортання та відкатування** За допомогою Kubernetes ви можете описати бажаний стан контейнерів, що розгортаються, і він регульовано простежить за виконанням цього стану. Наприклад, ви можете автоматизувати в Kubernetes процеси створення нових контейнерів для розгортання, видалення існуючих контейнерів і передачу їхніх ресурсів на новостворені контейнери. * **Автоматичне розміщення задач** Ви надаєте Kubernetes кластер для запуску контейнерізованих задач і вказуєте, скільки ресурсів ЦПУ та пам'яті (RAM) необхідно для роботи кожного контейнера. Kubernetes розподіляє контейнери по вузлах кластера для максимально ефективного використання ресурсів. * **Самозцілення** Kubernetes перезапускає контейнери, що відмовили; заміняє контейнери; зупиняє роботу контейнерів, що не відповідають на задану користувачем перевірку стану, і не повідомляє про них клієнтам, допоки ці контейнери не будуть у стані робочої готовності. * **Управління секретами та конфігурацією** Kubernetes дозволяє вам зберігати та керувати чутливою інформацією, такою як паролі, OAuth токени та SSH ключі. Ви можете розгортати та оновлювати секрети та конфігурацію без перезбирання образів ваших контейнерів, не розкриваючи секрети в конфігурацію стека. Чим не є Kubernetes ------------------- Kubernetes не є комплексною системою PaaS (Платформа як послуга) у традиційному розумінні. Оскільки Kubernetes оперує швидше на рівні контейнерів, аніж на рівні апаратного забезпечення, деяка загальнозастосована функціональність і справді є спільною з PaaS, як-от розгортання, масштабування, розподіл навантаження, логування і моніторинг. Водночас Kubernetes не є монолітним, а вищезазначені особливості підключаються і є опціональними. Kubernetes надає будівельні блоки для створення платформ для розробників, але залишає за користувачем право вибору у важливих питаннях. Kubernetes: * Не обмежує типи застосунків, що підтримуються. Kubernetes намагається підтримувати найрізноманітніші типи навантажень, включно із застосунками зі станом (stateful) та без стану (stateless), навантаження по обробці даних тощо. Якщо ваш застосунок можна контейнеризувати, він чудово запуститься під Kubernetes. * Не розгортає застосунки з вихідного коду та не збирає ваші застосунки. Процеси безперервної інтеграції, доставки та розгортання (CI/CD) визначаються на рівні організації, та в залежності від технічних вимог. * Не надає сервіси на рівні застосунків як вбудовані: програмне забезпечення проміжного рівня (наприклад, шина передачі повідомлень), фреймворки обробки даних (наприклад, Spark), бази даних (наприклад, MySQL), кеш, некластерні системи збереження інформації (наприклад, Ceph). Ці компоненти можуть бути запущені у Kubernetes та/або бути доступними для застосунків за допомогою спеціальних механізмів, наприклад [Open Service Broker](https://openservicebrokerapi.org/) . * Не нав'язує використання інструментів для логування, моніторингу та сповіщень, натомість надає певні інтеграційні рішення як прототипи, та механізми зі збирання та експорту метрик. * Не надає та не змушує використовувати якусь конфігураційну мову/систему (як наприклад `Jsonnet`), натомість надає можливість використовувати API, що може бути використаний довільними формами декларативних специфікацій. * Не надає і не запроваджує жодних систем машинної конфігурації, підтримки, управління або самозцілення. * На додачу, Kubernetes - не просто система оркестрації. Власне кажучи, вона усуває потребу оркестрації як такої. Технічне визначення оркестрації - це запуск визначених процесів: спочатку A, за ним B, потім C. На противагу, Kubernetes складається з певної множини незалежних, складних процесів контролерів, що безперервно опрацьовують стан у напрямку, що заданий бажаною конфігурацією. Неважливо, як ви дістанетесь з пункту A до пункту C. Централізоване управління також не є вимогою. Все це виливається в систему, яку легко використовувати, яка є потужною, надійною, стійкою та здатною до легкого розширення. Що далі ------- * Перегляньте [компоненти Kubernetes](https://kubernetes.io/docs/concepts/overview/components/) * Готові [розпочати роботу](https://kubernetes.io/uk/docs/setup/) ? --- # Configurar pods y contenedores | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/tasks/configure-pod-container/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/tasks/configure-pod-container/) . Configurar pods y contenedores ============================== * 1: [Configura un Pod para Usar un Volume como Almacenamiento](https://kubernetes.io/es/docs/tasks/configure-pod-container/_print/#pg-484833fb880d1e179cc2965d15f84da5) 1 - Configura un Pod para Usar un Volume como Almacenamiento ============================================================ En esta página se muestra cómo configurar un Pod para usar un Volume (volumen) como almacenamiento. El sistema de ficheros de un Contenedor existe mientras el Contenedor exista. Por tanto, cuando un Contenedor es destruido o reiniciado, los cambios realizados en el sistema de ficheros se pierden. Para un almacenamiento más consistente que sea independiente del ciclo de vida del Contenedor, puedes usar un [Volume](https://kubernetes.io/es/docs/concepts/storage/volumes/) . Esta característica es especialmente importante para aplicaciones que deben mantener un estado, como motores de almacenamiento clave-valor (por ejemplo Redis) y bases de datos. Antes de empezar ---------------- Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos `kubectl` debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando [Minikube](https://kubernetes.io/docs/setup/minikube) , o puedes utilizar una de las siguientes herramientas en línea: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) * [Play with Kubernetes](https://labs.play-with-k8s.com/) Para comprobar la versión, introduzca `kubectl version`. Configura un Volume para un Pod ------------------------------- En este ejercicio crearás un Pod que ejecuta un único Contenedor. Este Pod tiene un Volume de tipo [emptyDir](https://kubernetes.io/es/docs/concepts/storage/volumes/#emptydir) (directorio vacío) que existe durante todo el ciclo de vida del Pod, incluso cuando el Contenedor es destruido y reiniciado. Aquí está el fichero de configuración del Pod: [`pods/storage/redis.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/es/examples/pods/storage/redis.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy pods/storage/redis.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: redis volumeMounts: - name: redis-storage mountPath: /data/redis volumes: - name: redis-storage emptyDir: {} 1. Crea el Pod: kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml 2. Verifica que el Contenedor del Pod se está ejecutando y después observa los cambios en el Pod kubectl get pod redis --watch La salida debería ser similar a: NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s 3. En otro terminal, abre una sesión interactiva dentro del Contenedor que se está ejecutando: kubectl exec -it redis -- /bin/bash 4. En el terminal, ve a `/data/redis` y crea un fichero: root@redis:/data# cd /data/redis/ root@redis:/data/redis# echo Hello > test-file 5. En el terminal, lista los procesos en ejecución: root@redis:/data/redis# apt-get update root@redis:/data/redis# apt-get install procps root@redis:/data/redis# ps aux La salida debería ser similar a: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux 6. En el terminal, mata el proceso de Redis: root@redis:/data/redis# kill donde `` es el ID de proceso (PID) de Redis. 7. En el terminal original, observa los cambios en el Pod de Redis. Eventualmente verás algo como lo siguiente: NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s redis 0/1 Completed 0 6m redis 1/1 Running 1 6m En este punto, el Contenedor ha sido destruido y reiniciado. Esto es debido a que el Pod de Redis tiene una [restartPolicy](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) (política de reinicio) de `Always` (siempre). 1. Abre un terminal en el Contenedor reiniciado: kubectl exec -it redis -- /bin/bash 2. En el terminal, ve a `/data/redis` y verifica que `test-file` todavía existe: root@redis:/data/redis# cd /data/redis/ root@redis:/data/redis# ls test-file 3. Elimina el Pod que has creado para este ejercicio: kubectl delete pod redis Siguientes pasos ---------------- * Revisa [Volume](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#volume-v1-core) . * Revisa [Pod](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#pod-v1-core) . * Además del almacenamiento local proporcionado por `emptyDir`, Kubernetes soporta diferentes tipos de soluciones de almacenamiento por red, incluyendo los discos gestionados de los diferentes proveedores cloud, como por ejemplo los _Persistent Disks_ en Google Cloud Platform o el _Elastic Block Storage_ de Amazon Web Services. Este tipo de soluciones para volúmenes son las preferidas para el almacenamiento de datos críticos. Kubernetes se encarga de todos los detalles, tal como montar y desmontar los dispositivos en los nodos del clúster. Revisa [Volumes](https://kubernetes.io/es/docs/concepts/storage/volumes/) para obtener más información. --- # Проблемы и безопасность Kubernetes | Kubernetes Это многостраничный печатный вид этого раздела. [Нажмите что бы печатать](https://kubernetes.io/ru/docs/reference/issues-security/_print/#) . [Вернуться к обычному просмотру страницы](https://kubernetes.io/ru/docs/reference/issues-security/) . Проблемы и безопасность Kubernetes ================================== * 1: [Трекер задач (Issues) Kubernetes](https://kubernetes.io/ru/docs/reference/issues-security/_print/#pg-980c0542a3b195a20cfd4358792e2a38) * 2: [Общие сведения о безопасности Kubernetes и раскрытии информации](https://kubernetes.io/ru/docs/reference/issues-security/_print/#pg-1f7dc06f1cc1ea2cdde4480e54d5fb34) * 3: [Официальный CVE-фид](https://kubernetes.io/ru/docs/reference/issues-security/_print/#pg-f8584cd3b29b891198316c53d71b787c) 1 - Трекер задач (Issues) Kubernetes ==================================== Чтобы сообщить о проблеме в области безопасности, воспользуйтесь процедурой [раскрытия информации о безопасности Kubernetes](https://kubernetes.io/ru/docs/reference/issues-security/security/#report-a-vulnerability) . Механизм [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) позволяет работать с кодом Kubernetes и отслеживать активные задачи. * Официальный [список известных CVE](https://kubernetes.io/ru/docs/reference/issues-security/official-cve-feed/) (уязвимостей в области безопасности), которые были обнародованы [Комитетом по реагированию на угрозы в области безопасности Kubernetes](https://github.com/kubernetes/committee-security-response) . * [Issues на GitHub, связанные с CVE](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) Связанные с безопасностью анонсы публикуются в рассылке [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) . 2 - Общие сведения о безопасности Kubernetes и раскрытии информации =================================================================== На этой странице приводятся общие сведения о безопасности Kubernetes и раскрытии информации, имеющей к ней отношение. Анонсы в области безопасности ----------------------------- Информация о проблемах в области безопасности и ключевых изменениях API доступна в рассылке [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) . Сообщить об уязвимости ---------------------- Мы искренне признательны исследователям в области безопасности и пользователям, которые передают информацию об уязвимостях в Open Source-сообщество Kubernetes. Все отчеты тщательно изучаются группой добровольцев сообщества. Чтобы создать отчет, отправьте свою уязвимость в [Bug Bounty-программу Kubernetes](https://hackerone.com/kubernetes) . Это позволит отследить и обработать уязвимость в стандартные сроки. Также можно оправить [стандартное письмо об ошибках Kubernetes](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml) с описанием проблемы с безопасностью и ее подробностями в закрытый список [security@kubernetes.io](mailto:security@kubernetes.io) . Письмо можно зашифровать, используя GPG-ключи [членов Комитета по безопасности](https://git.k8s.io/security/README.md#product-security-committee-psc) . Шифрование с использованием GPG НЕ является обязательным. ### Когда следует сообщать об уязвимости * Вы думаете, что обнаружили уязвимость в безопасности Kubernetes. * Вы не уверены, как именно уязвимость повлияет на Kubernetes. * Вы думаете, что обнаружили уязвимость в другом проекте, от которого зависит работа Kubernetes. * Если у проекта имеется собственный регламент регистрации и раскрытия информации об уязвимостях, пожалуйста, следуйте ему и пишите сразу в проект. ### Когда НЕ следует сообщать об уязвимости * Вам нужна помощь в настройке компонентов Kubernetes для обеспечения безопасности. * Вам нужна помощь в применении обновлений, связанных с безопасностью. * Проблема не связана с безопасностью. Реагирование на уязвимости в области безопасности ------------------------------------------------- Каждый отчет об уязвимости подтверждается и анализируется членами Комитета по реагированию на угрозы безопасности в течение 3 рабочих дней. После этого [запускается соответствующая процедура](https://git.k8s.io/security/security-release-process.md#disclosures) . Любая информация об уязвимостях, переданная Комитету по реагированию на угрозы безопасности, остается внутри проекта Kubernetes и не передается в другие проекты, если только этого не требуется для устранения проблемы. Автору отчета будет сообщено о результатах триажа и дальнейших шагах по подготовке исправления и планированию релиза. Сроки раскрытия информации -------------------------- Дата публичного раскрытия согласовывается Комитетом по реагированию на угрозы безопасности Kubernetes и автором отчета об уязвимости. Мы предпочитаем полностью раскрывать информацию об обнаруженной проблеме сразу после того, как станет понятно, какие шаги необходимо предпринять для устранения ее последствий. Разумно отложить раскрытие информации, если проблема или порядок дальнейших шагов не до конца понятны, решение плохо протестировано или необходима координация действий вендоров. Срок раскрытия информации варьируется от незамедлительного (особенно если она уже широко известна) до нескольких недель. Для "простых" уязвимостей с момента подачи отчета до даты раскрытия обычно проходит около 7 дней. Комитет по реагированию на угрозы безопасности сохраняет последнее слово при определении даты раскрытия информации. 3 - Официальный CVE-фид ======================= СТАТУС ФИЧИ: `Kubernetes v1.27 [beta]` Поддерживаемый сообществом список официальных CVE, анонсированных Комитетом по реагированию на проблемы безопасности Kubernetes. Подробности см. на странице [Общие сведения о безопасности Kubernetes и раскрытии информации](https://kubernetes.io/ru/docs/reference/issues-security/security/) . Проект Kubernetes публикует фиды с анонсами проблем в области безопасности в формате [JSON](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) и [RSS](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/feed.xml) , доступные для автоматического считывания. Доступ к ним можно получить, выполнив следующие команды: * [JSON-фид](https://kubernetes.io/ru/docs/reference/issues-security/_print/#cve-%d1%84%d0%b8%d0%b4%d1%8b-0) * [RSS-фид](https://kubernetes.io/ru/docs/reference/issues-security/_print/#cve-%d1%84%d0%b8%d0%b4%d1%8b-1) [Ссылка на JSON-формат](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json [Ссылка на RSS-формат](https://kubernetes.io/docs/reference/issues-security/official-cve-feed/feed.xml) curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml | | | | | --- | --- | --- |Официальный список Kubernetes CVE (последнее обновление: 20 мар. 2026 12:45:52 UTC) | CVE ID | Описание проблемы | CVE GitHub Issue URL | | --- | --- | --- | | [CVE-2026-4342](https://github.com/kubernetes/kubernetes/issues/137893) | ingress-nginx comment-based nginx configuration injection | [#137893](https://github.com/kubernetes/kubernetes/issues/137893) | | [CVE-2026-3864](https://github.com/kubernetes/kubernetes/issues/137797) | CSI Driver for NFS path traversal via subDir may delete unintended directories on the NFS server | [#137797](https://github.com/kubernetes/kubernetes/issues/137797) | | [CVE-2025-15566](https://github.com/kubernetes/kubernetes/issues/136789) | ingress-nginx auth-proxy-set-headers nginx configuration injection | [#136789](https://github.com/kubernetes/kubernetes/issues/136789) | | [CVE-2026-24514](https://github.com/kubernetes/kubernetes/issues/136680) | ingress-nginx Admission Controller denial of service | [#136680](https://github.com/kubernetes/kubernetes/issues/136680) | | [CVE-2026-24513](https://github.com/kubernetes/kubernetes/issues/136679) | ingress-nginx auth-url protection bypass | [#136679](https://github.com/kubernetes/kubernetes/issues/136679) | | [CVE-2026-24512](https://github.com/kubernetes/kubernetes/issues/136678) | ingress-nginx rules.http.paths.path nginx configuration injection | [#136678](https://github.com/kubernetes/kubernetes/issues/136678) | | [CVE-2026-1580](https://github.com/kubernetes/kubernetes/issues/136677) | ingress-nginx auth-method nginx configuration injection | [#136677](https://github.com/kubernetes/kubernetes/issues/136677) | | [CVE-2025-14269](https://github.com/kubernetes/kubernetes/issues/135798) | Credential caching in Headlamp with Helm enabled | [#135798](https://github.com/kubernetes/kubernetes/issues/135798) | | [CVE-2025-13281](https://github.com/kubernetes/kubernetes/issues/135525) | Portworx Half-Blind SSRF in kube-controller-manager | [#135525](https://github.com/kubernetes/kubernetes/issues/135525) | | [CVE-2025-9708](https://github.com/kubernetes/kubernetes/issues/134063) | Kubernetes C# Client: improper certificate validation in custom CA mode may lead to man-in-the-middle attacks | [#134063](https://github.com/kubernetes/kubernetes/issues/134063) | | [CVE-2025-7445](https://github.com/kubernetes/kubernetes/issues/133897) | secrets-store-sync-controller discloses service account tokens in logs | [#133897](https://github.com/kubernetes/kubernetes/issues/133897) | | [CVE-2025-5187](https://github.com/kubernetes/kubernetes/issues/133471) | Nodes can delete themselves by adding an OwnerReference | [#133471](https://github.com/kubernetes/kubernetes/issues/133471) | | [CVE-2025-7342](https://github.com/kubernetes/kubernetes/issues/133115) | VM images built with Kubernetes Image Builder Nutanix or OVA providers use default credentials for Windows images if user did not override | [#133115](https://github.com/kubernetes/kubernetes/issues/133115) | | [CVE-2025-4563](https://github.com/kubernetes/kubernetes/issues/132151) | Nodes can bypass dynamic resource allocation authorization checks | [#132151](https://github.com/kubernetes/kubernetes/issues/132151) | | [CVE-2025-1974](https://github.com/kubernetes/kubernetes/issues/131009) | ingress-nginx admission controller RCE escalation | [#131009](https://github.com/kubernetes/kubernetes/issues/131009) | | [CVE-2025-1098](https://github.com/kubernetes/kubernetes/issues/131008) | ingress-nginx controller configuration injection via unsanitized mirror annotations | [#131008](https://github.com/kubernetes/kubernetes/issues/131008) | | [CVE-2025-1097](https://github.com/kubernetes/kubernetes/issues/131007) | ingress-nginx controller configuration injection via unsanitized auth-tls-match-cn annotation | [#131007](https://github.com/kubernetes/kubernetes/issues/131007) | | [CVE-2025-24514](https://github.com/kubernetes/kubernetes/issues/131006) | ingress-nginx controller configuration injection via unsanitized auth-url annotation | [#131006](https://github.com/kubernetes/kubernetes/issues/131006) | | [CVE-2025-24513](https://github.com/kubernetes/kubernetes/issues/131005) | ingress-nginx controller auth secret file path traversal vulnerability | [#131005](https://github.com/kubernetes/kubernetes/issues/131005) | | [CVE-2025-1767](https://github.com/kubernetes/kubernetes/issues/130786) | GitRepo Volume Inadvertent Local Repository Access | [#130786](https://github.com/kubernetes/kubernetes/issues/130786) | | [CVE-2025-0426](https://github.com/kubernetes/kubernetes/issues/130016) | Node Denial of Service via kubelet Checkpoint API | [#130016](https://github.com/kubernetes/kubernetes/issues/130016) | | [CVE-2024-9042](https://github.com/kubernetes/kubernetes/issues/129654) | Command Injection affecting Windows nodes via nodes/\*/logs/query API | [#129654](https://github.com/kubernetes/kubernetes/issues/129654) | | [CVE-2024-10220](https://github.com/kubernetes/kubernetes/issues/128885) | Arbitrary command execution through gitRepo volume | [#128885](https://github.com/kubernetes/kubernetes/issues/128885) | | [CVE-2024-9594](https://github.com/kubernetes/kubernetes/issues/128007) | VM images built with Image Builder with some providers use default credentials during builds | [#128007](https://github.com/kubernetes/kubernetes/issues/128007) | | [CVE-2024-9486](https://github.com/kubernetes/kubernetes/issues/128006) | VM images built with Image Builder and Proxmox provider use default credentials | [#128006](https://github.com/kubernetes/kubernetes/issues/128006) | | [CVE-2024-7646](https://github.com/kubernetes/kubernetes/issues/126744) | Ingress-nginx Annotation Validation Bypass | [#126744](https://github.com/kubernetes/kubernetes/issues/126744) | | [CVE-2024-7598](https://github.com/kubernetes/kubernetes/issues/126587) | Network restriction bypass via race condition during namespace termination | [#126587](https://github.com/kubernetes/kubernetes/issues/126587) | | [CVE-2024-5321](https://github.com/kubernetes/kubernetes/issues/126161) | Incorrect permissions on Windows containers logs | [#126161](https://github.com/kubernetes/kubernetes/issues/126161) | | [CVE-2024-3744](https://github.com/kubernetes/kubernetes/issues/124759) | azure-file-csi-driver discloses service account tokens in logs | [#124759](https://github.com/kubernetes/kubernetes/issues/124759) | | [CVE-2024-3177](https://github.com/kubernetes/kubernetes/issues/124336) | Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#124336](https://github.com/kubernetes/kubernetes/issues/124336) | | [CVE-2023-5528](https://github.com/kubernetes/kubernetes/issues/121879) | Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes | [#121879](https://github.com/kubernetes/kubernetes/issues/121879) | | [CVE-2023-5044](https://github.com/kubernetes/kubernetes/issues/126817) | Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation | [#126817](https://github.com/kubernetes/kubernetes/issues/126817) | | [CVE-2023-5043](https://github.com/kubernetes/kubernetes/issues/126816) | Ingress nginx annotation injection causes arbitrary command execution | [#126816](https://github.com/kubernetes/kubernetes/issues/126816) | | [CVE-2022-4886](https://github.com/kubernetes/kubernetes/issues/126815) | ingress-nginx path sanitization can be bypassed | [#126815](https://github.com/kubernetes/kubernetes/issues/126815) | | [CVE-2023-3955](https://github.com/kubernetes/kubernetes/issues/119595) | Insufficient input sanitization on Windows nodes leads to privilege escalation | [#119595](https://github.com/kubernetes/kubernetes/issues/119595) | | [CVE-2023-3893](https://github.com/kubernetes/kubernetes/issues/119594) | Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation | [#119594](https://github.com/kubernetes/kubernetes/issues/119594) | | [CVE-2023-3676](https://github.com/kubernetes/kubernetes/issues/119339) | Insufficient input sanitization on Windows nodes leads to privilege escalation | [#119339](https://github.com/kubernetes/kubernetes/issues/119339) | | [CVE-2023-2431](https://github.com/kubernetes/kubernetes/issues/118690) | Bypass of seccomp profile enforcement | [#118690](https://github.com/kubernetes/kubernetes/issues/118690) | | [CVE-2023-2728](https://github.com/kubernetes/kubernetes/issues/118640) | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#118640](https://github.com/kubernetes/kubernetes/issues/118640) | | [CVE-2023-2727](https://github.com/kubernetes/kubernetes/issues/118640) | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | [#118640](https://github.com/kubernetes/kubernetes/issues/118640) | | [CVE-2023-2878](https://github.com/kubernetes/kubernetes/issues/118419) | secrets-store-csi-driver discloses service account tokens in logs | [#118419](https://github.com/kubernetes/kubernetes/issues/118419) | | [CVE-2022-3294](https://github.com/kubernetes/kubernetes/issues/113757) | Node address isn't always verified when proxying | [#113757](https://github.com/kubernetes/kubernetes/issues/113757) | | [CVE-2022-3162](https://github.com/kubernetes/kubernetes/issues/113756) | Unauthorized read of Custom Resources | [#113756](https://github.com/kubernetes/kubernetes/issues/113756) | | [CVE-2022-3172](https://github.com/kubernetes/kubernetes/issues/112513) | Aggregated API server can cause clients to be redirected (SSRF) | [#112513](https://github.com/kubernetes/kubernetes/issues/112513) | | [CVE-2021-25749](https://github.com/kubernetes/kubernetes/issues/112192) | \`runAsNonRoot\` logic bypass for Windows containers | [#112192](https://github.com/kubernetes/kubernetes/issues/112192) | | [CVE-2021-25748](https://github.com/kubernetes/kubernetes/issues/126814) | Ingress-nginx \`path\` sanitization can be bypassed with newline character | [#126814](https://github.com/kubernetes/kubernetes/issues/126814) | | [CVE-2021-25746](https://github.com/kubernetes/kubernetes/issues/126813) | Ingress-nginx directive injection via annotations | [#126813](https://github.com/kubernetes/kubernetes/issues/126813) | | [CVE-2021-25745](https://github.com/kubernetes/kubernetes/issues/126812) | Ingress-nginx \`path\` can be pointed to service account token file | [#126812](https://github.com/kubernetes/kubernetes/issues/126812) | | [CVE-2021-25742](https://github.com/kubernetes/kubernetes/issues/126811) | Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces | [#126811](https://github.com/kubernetes/kubernetes/issues/126811) | | [CVE-2021-25741](https://github.com/kubernetes/kubernetes/issues/104980) | Symlink Exchange Can Allow Host Filesystem Access | [#104980](https://github.com/kubernetes/kubernetes/issues/104980) | | [CVE-2020-8561](https://github.com/kubernetes/kubernetes/issues/104720) | Webhook redirect in kube-apiserver | [#104720](https://github.com/kubernetes/kubernetes/issues/104720) | | [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675) | Endpoint & EndpointSlice permissions allow cross-Namespace forwarding | [#103675](https://github.com/kubernetes/kubernetes/issues/103675) | | [CVE-2021-25737](https://github.com/kubernetes/kubernetes/issues/102106) | Holes in EndpointSlice Validation Enable Host Network Hijack | [#102106](https://github.com/kubernetes/kubernetes/issues/102106) | | [CVE-2020-8562](https://github.com/kubernetes/kubernetes/issues/101493) | Bypass of Kubernetes API Server proxy TOCTOU | [#101493](https://github.com/kubernetes/kubernetes/issues/101493) | | [CVE-2021-3121](https://github.com/kubernetes/kubernetes/issues/101435) | Processes may panic upon receipt of malicious protobuf messages | [#101435](https://github.com/kubernetes/kubernetes/issues/101435) | | [CVE-2021-25735](https://github.com/kubernetes/kubernetes/issues/100096) | Validating Admission Webhook does not observe some previous fields | [#100096](https://github.com/kubernetes/kubernetes/issues/100096) | | [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076) | Man in the middle using LoadBalancer or ExternalIPs | [#97076](https://github.com/kubernetes/kubernetes/issues/97076) | | [CVE-2020-8566](https://github.com/kubernetes/kubernetes/issues/95624) | Ceph RBD adminSecrets exposed in logs when loglevel >= 4 | [#95624](https://github.com/kubernetes/kubernetes/issues/95624) | | [CVE-2020-8565](https://github.com/kubernetes/kubernetes/issues/95623) | Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9 | [#95623](https://github.com/kubernetes/kubernetes/issues/95623) | | [CVE-2020-8564](https://github.com/kubernetes/kubernetes/issues/95622) | Docker config secrets leaked when file is malformed and log level >= 4 | [#95622](https://github.com/kubernetes/kubernetes/issues/95622) | | [CVE-2020-8563](https://github.com/kubernetes/kubernetes/issues/95621) | Secret leaks in kube-controller-manager when using vSphere provider | [#95621](https://github.com/kubernetes/kubernetes/issues/95621) | | [CVE-2020-8557](https://github.com/kubernetes/kubernetes/issues/93032) | Node disk DOS by writing to container /etc/hosts | [#93032](https://github.com/kubernetes/kubernetes/issues/93032) | | [CVE-2020-8559](https://github.com/kubernetes/kubernetes/issues/92914) | Privilege escalation from compromised node to cluster | [#92914](https://github.com/kubernetes/kubernetes/issues/92914) | | [CVE-2020-8558](https://github.com/kubernetes/kubernetes/issues/92315) | Node setting allows for neighboring hosts to bypass localhost boundary | [#92315](https://github.com/kubernetes/kubernetes/issues/92315) | | [CVE-2020-8555](https://github.com/kubernetes/kubernetes/issues/91542) | Half-Blind SSRF in kube-controller-manager | [#91542](https://github.com/kubernetes/kubernetes/issues/91542) | | [CVE-2020-10749](https://github.com/kubernetes/kubernetes/issues/91507) | IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements | [#91507](https://github.com/kubernetes/kubernetes/issues/91507) | | [CVE-2019-11254](https://github.com/kubernetes/kubernetes/issues/89535) | kube-apiserver Denial of Service vulnerability from malicious YAML payloads | [#89535](https://github.com/kubernetes/kubernetes/issues/89535) | | [CVE-2020-8552](https://github.com/kubernetes/kubernetes/issues/89378) | apiserver DoS (oom) | [#89378](https://github.com/kubernetes/kubernetes/issues/89378) | | [CVE-2020-8551](https://github.com/kubernetes/kubernetes/issues/89377) | Kubelet DoS via API | [#89377](https://github.com/kubernetes/kubernetes/issues/89377) | | [CVE-2020-8553](https://github.com/kubernetes/kubernetes/issues/126818) | ingress-nginx auth-type basic annotation vulnerability | [#126818](https://github.com/kubernetes/kubernetes/issues/126818) | | [CVE-2019-11251](https://github.com/kubernetes/kubernetes/issues/87773) | kubectl cp symlink vulnerability | [#87773](https://github.com/kubernetes/kubernetes/issues/87773) | | [CVE-2018-1002102](https://github.com/kubernetes/kubernetes/issues/85867) | Unvalidated redirect | [#85867](https://github.com/kubernetes/kubernetes/issues/85867) | | [CVE-2019-11255](https://github.com/kubernetes/kubernetes/issues/85233) | CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation | [#85233](https://github.com/kubernetes/kubernetes/issues/85233) | | [CVE-2019-11253](https://github.com/kubernetes/kubernetes/issues/83253) | Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack | [#83253](https://github.com/kubernetes/kubernetes/issues/83253) | | [CVE-2019-11250](https://github.com/kubernetes/kubernetes/issues/81114) | Bearer tokens are revealed in logs (audit finding TOB-K8S-001) | [#81114](https://github.com/kubernetes/kubernetes/issues/81114) | | [CVE-2019-11248](https://github.com/kubernetes/kubernetes/issues/81023) | /debug/pprof exposed on kubelet's healthz port | [#81023](https://github.com/kubernetes/kubernetes/issues/81023) | | [CVE-2019-11249](https://github.com/kubernetes/kubernetes/issues/80984) | Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal | [#80984](https://github.com/kubernetes/kubernetes/issues/80984) | | [CVE-2019-11247](https://github.com/kubernetes/kubernetes/issues/80983) | API server allows access to custom resources via wrong scope | [#80983](https://github.com/kubernetes/kubernetes/issues/80983) | | [CVE-2019-11245](https://github.com/kubernetes/kubernetes/issues/78308) | container uid changes to root after first restart or if image is already pulled to the node | [#78308](https://github.com/kubernetes/kubernetes/issues/78308) | | [CVE-2019-11243](https://github.com/kubernetes/kubernetes/issues/76797) | rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig() | [#76797](https://github.com/kubernetes/kubernetes/issues/76797) | | [CVE-2019-11244](https://github.com/kubernetes/kubernetes/issues/76676) | \`kubectl --http-cache=\` creates world-writeable cached schema files | [#76676](https://github.com/kubernetes/kubernetes/issues/76676) | | [CVE-2019-1002100](https://github.com/kubernetes/kubernetes/issues/74534) | json-patch requests can exhaust apiserver resources | [#74534](https://github.com/kubernetes/kubernetes/issues/74534) | | [CVE-2018-1002105](https://github.com/kubernetes/kubernetes/issues/71411) | proxy request handling in kube-apiserver can leave vulnerable TCP connections | [#71411](https://github.com/kubernetes/kubernetes/issues/71411) | | [CVE-2018-1002101](https://github.com/kubernetes/kubernetes/issues/65750) | smb mount security issue | [#65750](https://github.com/kubernetes/kubernetes/issues/65750) | | [CVE-2018-1002100](https://github.com/kubernetes/kubernetes/issues/61297) | Kubectl copy doesn't check for paths outside of it's destination directory. | [#61297](https://github.com/kubernetes/kubernetes/issues/61297) | | [CVE-2017-1002102](https://github.com/kubernetes/kubernetes/issues/60814) | atomic writer volume handling allows arbitrary file deletion in host filesystem | [#60814](https://github.com/kubernetes/kubernetes/issues/60814) | | [CVE-2017-1002101](https://github.com/kubernetes/kubernetes/issues/60813) | subpath volume mount handling allows arbitrary file access in host filesystem | [#60813](https://github.com/kubernetes/kubernetes/issues/60813) | | [CVE-2017-1002100](https://github.com/kubernetes/kubernetes/issues/47611) | Azure PV should be Private scope not Container scope | [#47611](https://github.com/kubernetes/kubernetes/issues/47611) | | [CVE-2017-1000056](https://github.com/kubernetes/kubernetes/issues/43459) | PodSecurityPolicy admission plugin authorizes incorrectly | [#43459](https://github.com/kubernetes/kubernetes/issues/43459) | Список автоматически обновляется с заметной, но небольшой задержкой (от нескольких минут до нескольких часов) с момента анонса CVE до момента его появления в этом фиде. В качестве источника используется набор GitHub Issues, отфильтрованный по контролируемому и ограниченному лейблу `official-cve-feed`. Исходные данные хранятся в бакете Google Cloud, право на запись в который есть только у небольшого числа доверенных представителей сообщества. --- # Extender la API de Kubernetes | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/tasks/access-kubernetes-api/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/tasks/access-kubernetes-api/) . Extender la API de Kubernetes ============================= * 1: [Usar recursos personalizados](https://kubernetes.io/es/docs/tasks/access-kubernetes-api/_print/#pg-5b9d7df11699e8cb1a5a4414ff770efe) 1 - Usar recursos personalizados ================================ --- # Speicher | Kubernetes Das ist eine für den Ausdruck optimierte Ansicht des gesamten Kapitels inkl. Unterseiten. [Druckvorgang starten](https://kubernetes.io/de/docs/concepts/storage/_print/#) . [Zur Standardansicht zurückkehren](https://kubernetes.io/de/docs/concepts/storage/) . Speicher ======== Methoden, um volatilen oder persistenten Speicher für Pods im Cluster zur Verfügung zu stellen. * 1: [Persistente Volumes](https://kubernetes.io/de/docs/concepts/storage/_print/#pg-bc2d5c19a92b520ebf7e0a2161a236f0) 1 - Persistente Volumes ======================= --- # Inyectar datos en las aplicaciones | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/tasks/inject-data-application/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/tasks/inject-data-application/) . Inyectar datos en las aplicaciones ================================== --- # 네트워킹 레퍼런스 | Kubernetes 이 섹션의 다중 페이지 출력 화면임. [여기를 클릭하여 프린트](https://kubernetes.io/ko/docs/reference/networking/_print/#) . [이 페이지의 일반 화면으로 돌아가기](https://kubernetes.io/ko/docs/reference/networking/) . 네트워킹 레퍼런스 ========= * 1: [서비스가 지원하는 프로토콜](https://kubernetes.io/ko/docs/reference/networking/_print/#pg-a097017db59d2768c0422adcd3f79efd) * 2: [포트와 프로토콜](https://kubernetes.io/ko/docs/reference/networking/_print/#pg-5927c7cb60e78293efad3e86e45df77f) * 3: [가상 IP 및 서비스 프록시](https://kubernetes.io/ko/docs/reference/networking/_print/#pg-d59bf31808ffbe549a5b9ecfc354cfad) 이 섹션에서는 쿠버네티스 네트워킹의 레퍼런스 상세를 제공한다. 1 - 서비스가 지원하는 프로토콜 ================== [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/ "네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법") 를 구성하여, 쿠버네티스가 지원하는 네트워크 프로토콜 중 하나를 선택할 수 있다. 쿠버네티스는 서비스에 대해 다음의 프로토콜을 지원한다. * [`SCTP`](https://kubernetes.io/ko/docs/reference/networking/_print/#protocol-sctp) * [`TCP`](https://kubernetes.io/ko/docs/reference/networking/_print/#protocol-tcp) _(기본값)_ * [`UDP`](https://kubernetes.io/ko/docs/reference/networking/_print/#protocol-udp) 서비스를 정의할 때, 서비스가 사용할 [애플리케이션 프로토콜](https://kubernetes.io/ko/docs/concepts/services-networking/service/#%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C) 을 지정할 수도 있다. 이 문서에서는 몇 가지 특수 사례에 대해 설명하며, 이들 모두는 일반적으로 전송 프로토콜(transport protocol)로 TCP를 사용한다. * [HTTP](https://kubernetes.io/ko/docs/reference/networking/_print/#protocol-http-special) 및 [HTTPS](https://kubernetes.io/ko/docs/reference/networking/_print/#protocol-http-special) * [PROXY 프로토콜](https://kubernetes.io/ko/docs/reference/networking/_print/#protocol-proxy-special) * 로드밸런서에서의 [TLS](https://kubernetes.io/ko/docs/reference/networking/_print/#protocol-tls-special) 터미네이션 지원하는 프로토콜 --------- 서비스 포트의 `protocol`에 대해 다음 3개의 값이 유효하다. ### `SCTP` 기능 상태: `Kubernetes v1.20 [stable]` SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우, 대부분의 서비스에 SCTP를 사용할 수 있다. `type: LoadBalancer` 서비스의 경우 SCTP 지원 여부는 이 기능을 제공하는 클라우드 공급자에 따라 다르다. (대부분 지원하지 않음) SCTP는 윈도우 노드에서는 지원되지 않는다. #### 멀티홈(multihomed) SCTP 연결 지원 멀티홈 SCTP 연결 지원을 위해서는 CNI 플러그인이 파드에 복수개의 인터페이스 및 IP 주소를 할당하는 기능을 지원해야 한다. 멀티홈 SCTP 연결에서의 NAT는 상응하는 커널 모듈 내의 특수한 로직을 필요로 한다. ### `TCP` 모든 종류의 서비스에 TCP를 사용할 수 있으며, 이는 기본 네트워크 프로토콜이다. ### `UDP` 대부분의 서비스에 UDP를 사용할 수 있다. `type: LoadBalancer` 서비스의 경우, UDP 지원 여부는 이 기능을 제공하는 클라우드 공급자에 따라 다르다. 특수 케이스 ------ ### HTTP 클라우드 공급자가 이를 지원하는 경우, LoadBalancer 모드의 서비스를 사용하여, 쿠버네티스 클러스터 외부에, HTTP / HTTPS 리버스 프록싱을 통해 해당 서비스의 백엔드 엔드포인트로 트래픽을 전달하는 로드밸런서를 구성할 수 있다. 일반적으로, 트래픽을 HTTP 수준에서 제어하려면 해당 서비스의 프로토콜을 `TCP`로 지정하고 로드밸런서를 구성하는 [어노테이션](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/annotations "임의의 식별되지 않는 메타데이터를 오브젝트에 첨부할 때 이용하는 키-밸류 쌍.") (보통 클라우드 공급자마다 다름)을 추가한다. 이 구성은 워크로드로의 HTTPS (HTTP over TLS) 지원 및 평문 HTTP 리버스 프록시도 포함할 수 있다. #### 참고: 서비스 대신 [인그레스](https://kubernetes.io/ko/docs/concepts/services-networking/ingress/ "클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.") 를 사용하여 HTTP/HTTPS 서비스를 노출할 수도 있다. 특정 연결의 [애플리케이션 프로토콜](https://kubernetes.io/ko/docs/concepts/services-networking/service/#%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C) 을 `http` 또는 `https`로 추가적으로 명시하고 싶을 수도 있다. 로드밸런서에서 워크로드로 가는 세션이 HTTP without TLS이면 `http`를 사용하고, 로드밸런서에서 워크로드로 가는 세션이 TLS 암호화를 사용하면 `https`를 사용한다. ### PROXY 프로토콜 클라우드 공급자가 지원하는 경우에, `type: LoadBalancer`로 설정된 서비스를 사용하여, 쿠버네티스 외부에 존재하면서 연결들을 [PROXY 프로토콜](https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt) 로 감싸 전달하는 로드밸런서를 구성할 수 있다. 이러한 로드 밸런서는 들어오는 연결을 설명하는 초기 일련의 옥텟(octets)을 전송하며, 이는 다음의 예시(PROXY 프로토콜 v1)와 유사하다. PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n 프록시 프로토콜 프리앰블(preamble) 뒤에 오는 데이터는 클라이언트가 전송한 원본 데이터이다. 양쪽 중 한쪽에서 연결을 닫으면, 로드밸런서도 연결 종료를 트리거하며 남아있는 데이터를 수신 가능한 쪽으로 보낸다. 일반적으로는, 프로토콜을 `TCP`로 설정한 서비스를 정의한다. 또한, 클라우드 공급자별로 상이한 어노테이션을 설정하여 로드밸런서가 각 인커밍 연결을 PROXY 프로토콜로 감싸도록 구성할 수도 있다. ### TLS 클라우드 공급자가 지원하는 경우에, `type: LoadBalancer`로 설정된 서비스를 사용하여, 쿠버네티스 외부에 존재하는 리버스 프록시를 구축할 수 있으며, 이 때 클라이언트로부터 로드밸런서까지의 연결은 TLS 암호화되고 로드밸런서는 TLS 서버 피어가 된다. 로드밸런서로부터 워크로드까지의 연결은 TLS일 수도 있으며, 평문일 수도 있다. 사용 가능한 정확한 옵션의 범위는 클라우드 공급자 또는 커스텀 서비스 구현에 따라 다를 수 있다. 일반적으로는, 프로토콜을 `TCP`로 설정하고 어노테이션(보통 클라우드 공급자별로 상이함)을 설정하여 로드밸런서가 TLS 서버로 작동하도록 구성한다. 클라우드 공급자별로 상이한 메커니즘을 사용하여 TLS 아이덴티티(서버, 그리고 경우에 따라 워크로드로 연결하는 클라이언트도 가능)를 구성할 수도 있다. 2 - 포트와 프로토콜 ============ 물리적 네트워크 방화벽이 있는 온프레미스 데이터 센터 또는 퍼블릭 클라우드의 가상 네트워크와 같이 네트워크 경계가 엄격한 환경에서 쿠버네티스를 실행할 때, 쿠버네티스 구성 요소에서 사용하는 포트와 프로토콜을 알고 있는 것이 유용하다. 컨트롤 플레인 ------- | 프로토콜 | 방향 | 포트 범위 | 용도 | 사용 주체 | | --- | --- | --- | --- | --- | | TCP | 인바운드 | 6443 | 쿠버네티스 API 서버 | 전부 | | TCP | 인바운드 | 2379-2380 | etcd 서버 클라이언트 API | kube-apiserver, etcd | | TCP | 인바운드 | 10250 | Kubelet API | Self, 컨트롤 플레인 | | TCP | 인바운드 | 10259 | kube-scheduler | Self | | TCP | 인바운드 | 10257 | kube-controller-manager | Self | etcd 포트가 컨트롤 플레인 섹션에 포함되어 있지만, 외부 또는 사용자 지정 포트에서 자체 etcd 클러스터를 호스팅할 수도 있다. 워커 노드 ----- | 프로토콜 | 방향 | 포트 범위 | 용도 | 사용 주체 | | --- | --- | --- | --- | --- | | TCP | 인바운드 | 10250 | Kubelet API | Self, 컨트롤 플레인 | | TCP | 인바운드 | 30000-32767 | NodePort 서비스† | 전부 | † [노드포트(NodePort) 서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/) 의 기본 포트 범위. 모든 기본 포트 번호를 재정의할 수 있다. 사용자 지정 포트를 사용하는 경우 여기에 언급된 기본값 대신 해당 포트를 열어야 한다. 종종 발생하는 한 가지 일반적인 예는 API 서버 포트를 443으로 변경하는 경우이다. 또는, API 서버의 기본 포트를 그대로 유지하고, 443 포트에서 수신 대기하는 로드 밸런서 뒤에 API 서버를 두고, 로드 밸런서에서 API 서버로 가는 요청을 API 서버의 기본 포트로 라우팅할 수도 있다. 3 - 가상 IP 및 서비스 프록시 =================== 쿠버네티스 클러스터의 모든 [노드](https://kubernetes.io/ko/docs/concepts/architecture/nodes/ "노드는 쿠버네티스의 작업 장비(worker machine)이다.") 는 [`kube-proxy`](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/kube-proxy/) 를 실행한다(`kube-proxy`를 대체하는 구성요소를 직접 배포한 경우가 아니라면). `kube-proxy`는 [`ExternalName`](https://kubernetes.io/ko/docs/concepts/services-networking/service/#externalname) 외의 `type`의 [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/ "네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법") 를 위한 _가상 IP_ 메커니즘의 구현을 담당한다. 항상 발생하는 질문은, 왜 쿠버네티스가 인바운드 트래픽을 백엔드로 전달하기 위해 프록시에 의존하는가 하는 점이다. 다른 접근법이 있는가? 예를 들어, 여러 A 값 (또는 IPv6의 경우 AAAA)을 가진 DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 취할 수 있는가? There are a few reasons for using proxying for Services: * 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를 캐싱하는 DNS 구현에 대한 오래된 역사가 있다. * 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다. * 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이 낮거나 0이면 DNS에 부하가 높아 관리하기가 어려워질 수 있다. 본 페이지의 뒷 부분에서 다양한 kube-proxy 구현이 동작하는 방식에 대해 읽을 수 있다. 우선 알아두어야 할 것은, `kube-proxy`를 구동할 때, 커널 수준의 규칙이 수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고, 이는 때로는 리부트 전까지 정리되지 않을 수도 있다. 그래서, kube-proxy는 컴퓨터에서 저수준의, 특권을 가진(privileged) 네트워킹 프록시 서비스가 구동됨으로써 발생하는 결과를 이해하고 있는 관리자에 의해서만 구동되어야 한다. 비록 `kube-proxy` 실행 파일이 `cleanup` 기능을 지원하기는 하지만, 이 기능은 공식적인 기능이 아니기 때문에 구현된 그대로만 사용할 수 있다. 예를 들어, 3개의 레플리카로 실행되는 스테이트리스 이미지-처리 백엔드를 생각해보자. 이러한 레플리카는 대체 가능하다. 즉, 프론트엔드는 그것들이 사용하는 백엔드를 신경쓰지 않는다. 백엔드 세트를 구성하는 실제 파드는 변경될 수 있지만, 프론트엔드 클라이언트는 이를 인식할 필요가 없으며, 백엔드 세트 자체를 추적해야 할 필요도 없다. 프록시 모드들 ------- kube-proxy는 여러 모드 중 하나로 기동될 수 있으며, 이는 환경 설정에 따라 결정됨에 유의한다. * kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다. * kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다. * kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. ### `iptables` 프록시 모드 이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스, 엔드포인트슬라이스 오브젝트의 추가와 제거를 감시한다. 각 서비스에 대해, 서비스의 `clusterIP` 및 `port`에 대한 트래픽을 캡처하고 해당 트래픽을 서비스의 백엔드 세트 중 하나로 리다이렉트(redirect)하는 iptables 규칙을 설치한다. 각 엔드포인트 오브젝트에 대해, 백엔드 파드를 선택하는 iptables 규칙을 설치한다. 기본적으로, iptables 모드의 kube-proxy는 백엔드를 임의로 선택한다. 트래픽을 처리하기 위해 iptables를 사용하면 시스템 오버헤드가 줄어드는데, 유저스페이스와 커널 스페이스 사이를 전환할 필요없이 리눅스 넷필터(netfilter)가 트래픽을 처리하기 때문이다. 이 접근 방식은 더 신뢰할 수 있기도 하다. kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드가 응답하지 않으면, 연결이 실패한다. 이는 이전의 `userspace` 모드와 다르다. 이전의 `userspace` 시나리오에서는, kube-proxy는 첫 번째 파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다. 파드 [준비성 프로브(readiness probe)](https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/#%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%ED%94%84%EB%A1%9C%EB%B8%8C-probe) 를 사용하여 백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는 정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해 실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다. ![](https://kubernetes.io/images/docs/services-iptables-overview.svg) #### iptables 프록시에 대한 서비스 개요 다이어그램 #### 예시 다시 한번, [위](https://kubernetes.io/ko/docs/reference/networking/_print/#example) 에서 설명한 이미지 처리 애플리케이션을 고려한다. 백엔드 서비스가 생성되면, 쿠버네티스 컨트롤 플레인은 가상 IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하자. 클러스터의 모든 kube-proxy 인스턴스는 새 서비스의 생성을 관찰할 수 있다. 프록시가 새로운 서비스를 발견하면, 가상 IP 주소에서 서비스-별 규칙으로 리다이렉션되는 일련의 iptables 규칙을 설치한다. 서비스-별 규칙은 트래픽을 (목적지 NAT를 사용하여) 백엔드로 리다이렉션하는 엔드포인트-별 규칙에 연결한다. 클라이언트가 서비스의 가상 IP 주소에 연결하면 iptables 규칙이 시작한다. (세션 어피니티(Affinity)에 따라 또는 무작위로) 백엔드가 선택되고, 패킷의 클라이언트 IP 주소를 덮어쓰지 않고 백엔드로 리다이렉션된다. 트래픽이 노드-포트 또는 로드 밸런서를 통해 들어오는 경우에도, 이와 동일한 기본 흐름이 실행되지만, 클라이언트 IP는 변경된다. ### IPVS 프록시 모드 `ipvs` 모드에서, kube-proxy는 쿠버네티스 서비스와 엔드포인트슬라이스를 감시하고, `netlink` 인터페이스를 호출하여 그에 따라 IPVS 규칙을 생성하고 IPVS 규칙을 쿠버네티스 서비스 및 엔드포인트슬라이스와 주기적으로 동기화한다. 이 제어 루프는 IPVS 상태가 원하는 상태와 일치하도록 보장한다. 서비스에 접근하면, IPVS는 트래픽을 백엔드 파드 중 하나로 보낸다. IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을 기반으로 하지만, 해시 테이블을 기본 데이터 구조로 사용하고 커널 스페이스에서 동작한다. 이는 IPVS 모드의 kube-proxy는 iptables 모드의 kube-proxy보다 지연 시간이 짧은 트래픽을 리다이렉션하고, 프록시 규칙을 동기화할 때 성능이 훨씬 향상됨을 의미한다. 다른 프록시 모드와 비교했을 때, IPVS 모드는 높은 네트워크 트래픽 처리량도 지원한다. IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공하며, 그 목록은 다음과 같다. * `rr`: 라운드-로빈 * `lc`: 최소 연결 (가장 적은 수의 열려있는 연결) * `dh`: 목적지 해싱 * `sh`: 소스 해싱 * `sed`: 최단 예상 지연 (shortest expected delay) * `nq`: 큐 미사용 (never queue) #### 참고: IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를 사용 가능하도록 해야 한다. kube-proxy가 IPVS 프록시 모드로 시작될 때, IPVS 커널 모듈이 사용 가능한지 확인한다. IPVS 커널 모듈이 감지되지 않으면, kube-proxy는 iptables 프록시 모드로 다시 실행된다. ![](https://kubernetes.io/images/docs/services-ipvs-overview.svg) #### IPVS 프록시에 대한 서비스 개요 다이어그램 세션 어피니티 ------- 이러한 프록시 모델에서, 클라이언트가 쿠버네티스/서비스/파드에 대해 전혀 모르더라도 서비스의 IP:포트로 향하는 트래픽은 적절한 백엔드로 프록시된다. 특정 클라이언트의 연결이 매번 동일한 파드로 전달되도록 하려면, 서비스의 `.spec.sessionAffinity`를 `ClientIP`로 설정하여 클라이언트의 IP 주소를 기반으로 세션 어피니티를 선택할 수 있다. (기본값은 `None`) ### 세션 고정(Session stickiness) 타임아웃 서비스의 `.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 적절히 설정하여 최대 세션 고정 시간을 설정할 수도 있다. (기본값은 10800으로, 이는 3시간에 해당됨) #### 참고: 윈도우에서는, 서비스의 최대 세션 고정 시간(maximum session sticky time)을 설정하는 것이 지원되지 않는다. 서비스에 IP 주소 할당 ------------- 고정된 목적지로 실제로 라우팅되는 파드 IP 주소와 달리, 서비스 IP는 실제로는 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는 패킷 처리 로직(예: 리눅스의 iptables)을 사용하여, 필요에 따라 투명하게 리다이렉션되는 _가상_ IP 주소를 정의한다. 클라이언트가 VIP에 연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다. 환경 변수와 서비스 용 DNS는 실제로는 서비스의 가상 IP 주소 (및 포트)로 채워진다. ### 충돌 방지하기 쿠버네티스의 주요 철학 중 하나는, 사용자가 잘못한 것이 없는 경우에는 실패할 수 있는 상황에 노출되어서는 안된다는 것이다. 서비스 리소스 설계 시, 다른 사람의 포트 선택과 충돌할 경우에 대비해 자신의 포트 번호를 선택하지 않아도 된다. 만약 그러한 일이 발생한다면 그것은 격리 실패이다. 서비스에 대한 포트 번호를 사용자가 선택할 수 있도록 하려면, 두 개의 서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서 각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다. 각 서비스가 고유한 IP를 받도록 하기 위해, 각 서비스를 만들기 전에 내부 할당기가 [etcd](https://kubernetes.io/ko/docs/tasks/administer-cluster/configure-upgrade-etcd/ "모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.") 에서 글로벌 할당 맵을 원자적으로(atomically) 업데이트한다. 서비스가 IP 주소 할당을 가져오려면 레지스트리에 맵 오브젝트가 있어야 하는데, 그렇지 않으면 IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다. 컨트롤 플레인에서, 백그라운드 컨트롤러는 해당 맵을 생성해야 한다(인-메모리 잠금을 사용하는 이전 버전의 쿠버네티스에서의 마이그레이션 지원을 위해 필요함). 쿠버네티스는 또한 컨트롤러를 사용하여 유효하지 않은 할당(예: 관리자 개입에 의한)을 체크하고 더 이상 어떠한 서비스도 사용하지 않는 할당된 IP 주소를 정리한다. #### 서비스 가상 IP 주소의 IP 주소 범위 기능 상태: `Kubernetes v1.25 [beta]` 쿠버네티스는 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진 `service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며, 여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다. 쿠버네티스는 서비스에 대한 동적 IP 할당 시 상위 대역에서 우선적으로 선택하며, 이는 곧 만약 사용자가 `type: ClusterIP` 서비스에 특정 IP 주소를 할당하고 싶다면 **하위** 대역에서 골라야 함을 의미한다. 이렇게 함으로써 할당 시 충돌의 위험을 줄일 수 있다. 만약 `ServiceIPStaticSubrange` [기능 게이트](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 비활성화하면 쿠버네티스는 `type: ClusterIP` 서비스에 대해 수동 및 동적 할당 IP 주소를 위한 하나의 공유되는 풀을 사용한다. 트래픽 폴리시 ------- `.spec.internalTrafficPolicy` 및 `.spec.externalTrafficPolicy` 필드를 설정하여 쿠버네티스가 트래픽을 어떻게 정상(healthy, “ready”) 백엔드로 라우팅할지를 제어할 수 있다. ### 내부 트래픽 폴리시 기능 상태: `Kubernetes v1.22 [beta]` `spec.internalTrafficPolicy` 필드를 설정하여 내부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다. 이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 내부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며, `Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬 엔드포인트가 하나도 없는 경우, kube-proxy는 트래픽을 드롭시킨다. ### 외부 트래픽 폴리시 `spec.externalTrafficPolicy` 필드를 설정하여 외부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다. 이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 외부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며, `Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬 엔드포인트가 하나도 없는 경우, kube-proxy는 연관된 서비스로의 트래픽을 포워드하지 않는다. ### 종료 중인 엔드포인트로 가는 트래픽 기능 상태: `Kubernetes v1.26 [beta]` kube-proxy에 대해 `ProxyTerminatingEndpoints` [기능 게이트](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화되어 있고 트래픽 폴리시가 `Local`이면, 해당 노드의 kube-proxy는 서비스에 대한 엔드포인트를 선택할 때 좀 더 복잡한 알고리즘을 사용한다. 이 기능이 활성화되어 있으면, kube-proxy는 노드가 로컬 엔드포인트를 갖고 있는지, 그리고 모든 로컬 엔드포인트가 '종료 중'으로 표시되어 있는지 여부를 확인한다. 만약 로컬 엔드포인트가 존재하고 **모든** 로컬 엔드포인트가 종료 중이면, kube-proxy는 종료 중인 해당 엔드포인트로 트래픽을 전달한다. 이외의 경우, kube-proxy는 종료 중이 아닌 엔드포인트로 트래픽을 전달하는 편을 선호한다. 종료 중인 엔드포인트에 대한 이러한 포워딩 정책 덕분에, `externalTrafficPolicy: Local`을 사용하는 경우에 `NodePort` 및 `LoadBalancer` 서비스가 연결들을 자비롭게(gracefully) 종료시킬 수 있다. 디플로이먼트가 롤링 업데이트될 때, 로드밸런서 뒤에 있는 노드가 해당 디플로이먼트의 레플리카를 N개에서 0개 갖도록 변경될 수 있다. 일부 경우에, 외부 로드 밸런서가 헬스 체크 프로브 사이의 기간에 레플리카 0개를 갖는 노드로 트래픽을 전송할 수 있다. 종료 중인 엔드포인트로의 트래픽 라우팅 기능을 통해 파드를 스케일 다운 중인 노드가 해당 종료 중인 파드로의 트래픽을 자비롭게 수신 및 드레인할 수 있다. 파드 종료가 완료되면, 외부 로드 밸런서는 이미 노드의 헬스 체크가 실패했음을 확인하고 해당 노드를 백엔드 풀에서 완전히 제거했을 것이다. 다음 내용 ----- 서비스에 대해 더 알아보려면, [서비스와 애플리케이션 연결](https://kubernetes.io/ko/docs/tutorials/services/connect-applications-service/) 을 읽어 본다. 또한, * [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/) 에 대해 읽어 본다. * 서비스 API에 대한 [API 레퍼런스](https://kubernetes.io/docs/reference/kubernetes-api/service-resources/service-v1/) 를 읽어 본다. --- # Administrar un clúster | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/tasks/administer-cluster/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/tasks/administer-cluster/) . Administrar un clúster ====================== * 1: [Administrar un clúster con kubeadm](https://kubernetes.io/es/docs/tasks/administer-cluster/_print/#pg-8e16d69617b175d61e2e7a6e1642c9d6) * 2: [Administrar recursos de memoria, CPU y API](https://kubernetes.io/es/docs/tasks/administer-cluster/_print/#pg-47be5dd51f686017f1766e6ec7aa6f41) * 3: [Instalar un proveedor de políticas de red](https://kubernetes.io/es/docs/tasks/administer-cluster/_print/#pg-8c31aafd38fad5b0de0bd191758d6f93) 1 - Administrar un clúster con kubeadm ====================================== 2 - Administrar recursos de memoria, CPU y API ============================================== 3 - Instalar un proveedor de políticas de red ============================================= --- # Herramientas de configuración | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/reference/setup-tools/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/reference/setup-tools/) . Herramientas de configuración ============================= * 1: [kubeadm](https://kubernetes.io/es/docs/reference/setup-tools/_print/#pg-f351ced098abbb076bc8c4be1053672b) * 1.1: [kubeadm (auto-generado)](https://kubernetes.io/es/docs/reference/setup-tools/_print/#pg-36c22b52e8447eb3d2452d4f56fbea9b) * 2: [kubefed](https://kubernetes.io/es/docs/reference/setup-tools/_print/#pg-d8df553bae844c94dada72f2d4a75485) 1 - kubeadm =========== 1.1 - kubeadm (auto-generado) ============================= 2 - kubefed =========== --- # ターンキークラウドソリューション | Kubernetes ターンキークラウドソリューション ================ このページは、Kubernetes認定ソリューションプロバイダーのリストを提供します。 各プロバイダーのページから、本番環境でも利用可能なクラスターのインストール方法やセットアップ方法を学ぶことができます。 フィードバック ------- このページは役に立ちましたか？ はい いいえ Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Open an issue in the GitHub repo if you want to [問題を報告する](https://github.com/kubernetes/website/issues/new?title=Issue%20with%20k8s.io) or [改善を提案](https://github.com/kubernetes/website/issues/new?title=Improvement%20for%20k8s.io) . 最終更新 January 18, 2024 at 10:32 AM PST: [Update references to CNCF landscape (v2) (26e760da6e)](https://github.com/kubernetes/website/commit/26e760da6e76da033d69051a240b58bad9a5fa8f) --- # স্টোরেজ | Kubernetes এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। [মুদ্রণ করতে এখানে ক্লিক করুন](https://kubernetes.io/bn/docs/concepts/storage/_print/#) . [এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন](https://kubernetes.io/bn/docs/concepts/storage/) . স্টোরেজ ======= আপনার ক্লাস্টারে পডগুলোতে দীর্ঘমেয়াদী এবং অস্থায়ী উভয় স্টোরেজ সরবরাহ করার উপায়। --- # ネットワーキングのリファレンス | Kubernetes これは、このセクションの複数ページの印刷可能なビューです。 [印刷するには、ここをクリックしてください](https://kubernetes.io/ja/docs/reference/networking/_print/#) . [このページの通常のビューに戻る](https://kubernetes.io/ja/docs/reference/networking/) . ネットワーキングのリファレンス =============== * 1: [ポートとプロトコル](https://kubernetes.io/ja/docs/reference/networking/_print/#pg-5927c7cb60e78293efad3e86e45df77f) このセクションでは、Kubernetesネットワーキングの詳細を提供します。 1 - ポートとプロトコル ============= パブリッククラウドにおける仮想ネットワークや、物理ネットワークファイアウォールを持つオンプレミスのデータセンターのような、ネットワークの境界が厳格な環境でKubernetesを実行する場合、Kubernetesのコンポーネントが使用するポートやプロトコルを認識しておくと便利です。 コントロールプレーン ---------- | プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 | | --- | --- | --- | --- | --- | | TCP | Inbound | 6443 | Kubernetes API server | 全て | | TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd | | TCP | Inbound | 10250 | Kubelet API | 自身, コントロールプレーン | | TCP | Inbound | 10259 | kube-scheduler | 自身 | | TCP | Inbound | 10257 | kube-controller-manager | 自身 | etcdポートはコントロールプレーンノードに含まれていますが、独自のetcdクラスターを外部またはカスタムポートでホストすることもできます。 ワーカーノード ------- | プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 | | --- | --- | --- | --- | --- | | TCP | Inbound | 10250 | Kubelet API | 自身, コントロールプレーン | | TCP | Inbound | 30000-32767 | NodePort Services† | 全て | † [NodePort Services](https://kubernetes.io/ja/docs/concepts/services-networking/service/) のデフォルトのポート範囲。 すべてのデフォルトのポート番号が書き換え可能です。 カスタムポートを使用する場合、ここに記載されているデフォルトではなく、それらのポートを開く必要があります。 よくある例としては、API Serverのポートを443に変更することがあります。 または、デフォルトポートをそのままにし、API Serverを443でリッスンしているロードバランサーの後ろに置き、APIサーバのデフォルトポートにリクエストをルーティングする方法もあります。 --- # সার্ভিস, লোড ব্যালেন্সিং এবং নেটওয়ার্কিং | Kubernetes এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। [মুদ্রণ করতে এখানে ক্লিক করুন](https://kubernetes.io/bn/docs/concepts/services-networking/_print/#) . [এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন](https://kubernetes.io/bn/docs/concepts/services-networking/) . সার্ভিস, লোড ব্যালেন্সিং এবং নেটওয়ার্কিং ========================================= কুবারনেটিসে নেটওয়ার্কিংয়ের পিছনে থাকা ধারণা এবং রিসোর্স। কুবারনেটিস নেটওয়ার্ক মডেল -------------------------- একটি ক্লাস্টারের প্রতিটি [`পড`](https://kubernetes.io/bn/docs/concepts/workloads/pods/) তার নিজস্ব ক্লাস্টার-ওয়াইড আইপি ঠিকানা পায় (প্রতি আইপি এড্রেস ফ্যামিলিতে একটি আইপি এড্রেস)। এর অর্থ হলো আপনাকে `পডের` মধ্যে স্পষ্টভাবে লিঙ্ক তৈরি করার দরকার নেই এবং পোর্টগুলো হোস্ট করার জন্য আপনাকে ম্যাপিং কন্টেইনার পোর্টগুলোর সাথে মোকাবিলা করতে হবে না। এটি একটি পরিষ্কার, পিছনের-সামঞ্জস্যপূর্ণ মডেল (backwards-compatible model) তৈরি করে যেখানে পোর্ট বরাদ্দকরণ, নামকরণ, সার্ভিস আবিষ্কার (service discovery), [লোড ব্যালেন্সিং](https://kubernetes.io/bn/docs/concepts/services-networking/ingress/#load-balancing) , অ্যাপ্লিকেশন কনফিগারেশন এবং মাইগ্রেশনের দৃষ্টিকোণ থেকে `পডগুলোকে` অনেকটা ভিএম (Virtual Machine) বা ফিজিক্যাল হোস্টের মতোই বিবেচনা করা যেতে পারে। কুবারনেটিস যেকোন নেটওয়ার্কিং বাস্তবায়নে নিম্নলিখিত মৌলিক প্রয়োজনীয়তাগুলো আরোপ করে (যেকোনো ইচ্ছাকৃত নেটওয়ার্ক বিভাজন নীতি ব্যতীত): * পড NAT ছাড়া অন্য কোনো [নোডে](https://kubernetes.io/bn/docs/concepts/architecture/nodes/) অন্য সব পডের সঙ্গে যোগাযোগ করতে পারে * একটি নোডের এজেন্ট (যেমন system daemons, kubelet) সেই নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে #### বিঃদ্রঃ: হোস্ট নেটওয়ার্কে (যেমন লিনাক্স) চলমান `পডগুলোকে` সমর্থন করে এমন প্ল্যাটফর্মগুলোর জন্য, যখন পডগুলো একটি নোডের হোস্ট নেটওয়ার্কের সাথে সংযুক্ত থাকে তখনও তারা সমস্ত নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে NAT ছাড়া ৷ এই মডেলটি শুধুমাত্র সামগ্রিকভাবে কম জটিল নয়, এটি প্রধানত কুবারনেটিসের ইচ্ছার সাথে সামঞ্জস্যপূর্ণ যাতে ভিএম থেকে কন্টেইনারে অ্যাপের লো-ফ্রিকশন পোর্টিং সক্ষম করা যায়। যদি আপনার কাজ আগে কোনো ভিএম-এ চলত, তাহলে আপনার ভিএম-এর IP ছিল এবং আপনার প্রোজেক্টের অন্যান্য ভিএম-এর সাথে কথা বলতে পারে। এটি একই মৌলিক মডেল। কুবারনেটিস আইপি ঠিকানাগুলো `পড` স্কোপে বিদ্যমান - একটি `পডের` মধ্যে থাকা কন্টেনারগুলো তাদের নেটওয়ার্ক নেমস্পেসগুলো ভাগ করে - তাদের IP ঠিকানা এবং MAC ঠিকানা সহ। এর মানে হলো যে একটি `পডের` মধ্যে থাকা কন্টেইনারগুলো একে অপরের পোর্টে `লোকালহোস্টে` পৌঁছাতে পারে। এটি আরো বোঝায় যে একটি `পডের` মধ্যে থাকা কন্টেইনারগুলোকে পোর্ট ব্যবহারের সমন্বয় করতে হবে, তবে এটি একটি ভিএম-এর প্রক্রিয়াগুলোর থেকে আলাদা নয়। এটিকে "IP-per-pod" মডেল বলা হয়। এটি কীভাবে প্রয়োগ করা হয় তা ব্যবহার করা নির্দিষ্ট কন্টেইনার রানটাইমের একটি ডিটেইল। `নোডেই` পোর্টের জন্য অনুরোধ করা সম্ভব যা আপনার `পডে` ফরোয়ার্ড করা হয় (যাকে হোস্ট পোর্ট বলা হয়), কিন্তু এটি একটি খুব বিশিষ্ট অপারেশন। সেই ফরোয়ার্ডিং কীভাবে বাস্তবায়িত হয় তাও কন্টেইনার রানটাইমের ডিটেইল। `পড` নিজেই হোস্ট পোর্টের অস্তিত্ব বা অ-অস্তিত্ব সম্পর্কে অন্ধ। কুবারনেটিস নেটওয়ার্কিং চারটি উদ্বেগের সমাধান করে: * লুপব্যাকের মাধ্যমে একটি পডের মধ্যে কন্টেইনার [যোগাযোগের জন্য নেটওয়ার্কিং ব্যবহার করে](https://kubernetes.io/bn/docs/concepts/services-networking/dns-pod-service/) । * ক্লাস্টার নেটওয়ার্কিং বিভিন্ন পডের মধ্যে যোগাযোগ প্রদান করে। * [সার্ভিস](https://kubernetes.io/bn/docs/concepts/services-networking/service/) API আপনাকে আপনার ক্লাস্টারের বাইরে থেকে পৌঁছানোর জন্য [পডসে চলমান একটি অ্যাপ্লিকেশন প্রকাশ](https://kubernetes.io/bn/docs/tutorials/services/connect-applications-service/) করতে দেয় । * [ইনগ্রেস](https://kubernetes.io/bn/docs/concepts/services-networking/ingress/) বিশেষত HTTP অ্যাপ্লিকেশন, ওয়েবসাইট এবং এপিআই প্রকাশ করার জন্য অতিরিক্ত কার্যকারিতা প্রদান করে। * [গেটওয়ে API](https://kubernetes.io/bn/docs/concepts/services-networking/gateway/) হলো একটি [অ্যাড-অন](https://kubernetes.io/bn/docs/concepts/cluster-administration/addons/ "কুবারনেটিসের কার্যকারিতা প্রসারিত করে এমন রিসোর্স।") যেটি মডেলিং সার্ভিস নেটওয়ার্কিংয়ের জন্য API ধরণের একটি অভিব্যক্তিপূর্ণ (expressive), এক্সটেনসিবল, এবং ভূমিকা-ভিত্তিক পরিবার প্রদান করে। * এছাড়া আপনি [শুধুমাত্র আপনার ক্লাস্টারের মধ্যে ব্যবহারের জন্য সার্ভিসগুলো প্রকাশ করতে](https://kubernetes.io/bn/docs/concepts/services-networking/service-traffic-policy/) সার্ভিসগুলো ব্যবহার করতে পারেন । [কানেক্টিং অ্যাপ্লিকেশানস উইথ সার্ভিস](https://kubernetes.io/bn/docs/tutorials/services/connect-applications-service/) টিউটোরিয়াল আপনাকে একটি হ্যান্ডস-অন উদাহরণ সহ পরিষেবা এবং কুবারনেটিস নেটওয়ার্কিং সম্পর্কে শিখতে দেয়। [ক্লাস্টার নেটওয়ার্কিং](https://kubernetes.io/bn/docs/concepts/cluster-administration/networking/) ব্যাখ্যা করে কিভাবে আপনার ক্লাস্টারের জন্য নেটওয়ার্কিং সেট আপ করতে হয় এবং এর সাথে জড়িত প্রযুক্তিগুলোর একটি ওভারভিউ প্রদান করে। --- # 最佳实践 | Kubernetes 这是本节的多页打印视图。 [点击此处打印](https://kubernetes.io/zh-cn/docs/setup/best-practices/_print/#) . [返回本页常规视图](https://kubernetes.io/zh-cn/docs/setup/best-practices/) . 最佳实践 ==== * 1: [大规模集群的注意事项](https://kubernetes.io/zh-cn/docs/setup/best-practices/_print/#pg-c797ee17120176c685455db89ae091a9) * 2: [运行于多可用区环境](https://kubernetes.io/zh-cn/docs/setup/best-practices/_print/#pg-970615c97499e3651fd3a98e0387cefc) * 3: [校验节点设置](https://kubernetes.io/zh-cn/docs/setup/best-practices/_print/#pg-f89867de1d34943f1524f67a241f5cc9) * 4: [强制实施 Pod 安全性标准](https://kubernetes.io/zh-cn/docs/setup/best-practices/_print/#pg-92a61cf5b0575aa3500f7665b68127d1) * 5: [PKI 证书和要求](https://kubernetes.io/zh-cn/docs/setup/best-practices/_print/#pg-0394f813094b7a35058dffe5b8bacd20) 1 - 大规模集群的注意事项 ============== 集群包含多个运行着 Kubernetes 代理程序、 由[控制平面](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-control-plane "控制平面是指容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。") 管理的一组[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/ "Kubernetes 中的工作机器称作节点。") （物理机或虚拟机）。 Kubernetes v1.35 单个集群支持的最大节点数为 5,000。 更具体地说，Kubernetes 设计为满足以下**所有**标准的配置： * 每个节点的 Pod 数量不超过 110 * 节点数不超过 5,000 * Pod 总数不超过 150,000 * 容器总数不超过 300,000 你可以通过添加或删除节点来对集群扩缩容。集群扩缩容的方式取决于集群的部署方式。 云供应商资源配额 -------- 为避免遇到云供应商配额问题，在创建具有大规模节点的集群时，请考虑以下事项： * 请求增加云资源的配额，例如： * 计算实例 * CPU * 存储卷 * 使用中的 IP 地址 * 数据包过滤规则集 * 负载均衡数量 * 网络子网 * 日志流 * 由于某些云供应商限制了创建新实例的速度，因此通过分批启动新节点来控制集群扩展操作，并在各批之间有一个暂停。 控制面组件 ----- 对于大型集群，你需要一个具有足够计算能力和其他资源的控制平面。 通常，你将在每个故障区域运行一个或两个控制平面实例， 先垂直缩放这些实例，然后在到达下降点（垂直）后再水平缩放。 你应该在每个故障区域至少应运行一个实例，以提供容错能力。 Kubernetes 节点不会自动将流量引向相同故障区域中的控制平面端点。 但是，你的云供应商可能有自己的机制来执行此操作。 例如，使用托管的负载均衡器时，你可以配置负载均衡器发送源自故障区域 **A** 中的 kubelet 和 Pod 的流量， 并将该流量仅定向到也位于区域 **A** 中的控制平面主机。 如果单个控制平面主机或端点故障区域 **A** 脱机，则意味着区域 **A** 中的节点的所有控制平面流量现在都在区域之间发送。 在每个区域中运行多个控制平面主机能降低出现这种结果的可能性。 ### etcd 存储 为了提高大规模集群的性能，你可以将事件对象存储在单独的专用 etcd 实例中。 在创建集群时，你可以（使用自定义工具）： * 启动并配置额外的 etcd 实例 * 配置 [API 服务器](https://kubernetes.io/zh-cn/docs/concepts/architecture/#kube-apiserver "提供 Kubernetes API 服务的控制面组件。") ，将它用于存储事件 有关为大型集群配置和管理 etcd 的详细信息， 请参阅[为 Kubernetes 运行 etcd 集群](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/) 和使用 [kubeadm 创建一个高可用 etcd 集群](https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) 。 ### 插件资源 Kubernetes [资源限制](https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/) 有助于最大程度地减少内存泄漏的影响以及 Pod 和容器可能对其他组件的其他方式的影响。 这些资源限制适用于[插件](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/addons/ "扩展 Kubernetes 功能的资源。") 资源， 就像它们适用于应用程序工作负载一样。 例如，你可以对日志组件设置 CPU 和内存限制： ... containers: - name: fluentd-cloud-logging image: fluent/fluentd-kubernetes-daemonset:v1 resources: limits: cpu: 100m memory: 200Mi 插件的默认限制通常基于从中小规模 Kubernetes 集群上运行每个插件的经验收集的数据。 插件在大规模集群上运行时，某些资源消耗常常比其默认限制更多。 如果在不调整这些值的情况下部署了大规模集群，则插件可能会不断被杀死，因为它们不断达到内存限制。 或者，插件可能会运行，但由于 CPU 时间片的限制而导致性能不佳。 为避免遇到集群插件资源问题，在创建大规模集群时，请考虑以下事项： * 部分垂直扩展插件 —— 总有一个插件副本服务于整个集群或服务于整个故障区域。 对于这些附加组件，请在扩大集群时加大资源请求和资源限制。 * 许多水平扩展插件 —— 你可以通过运行更多的 Pod 来增加容量——但是在大规模集群下， 可能还需要稍微提高 CPU 或内存限制。 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) 可以在 **recommender** 模式下运行，以提供有关请求和限制的建议数字。 * 一些插件在每个节点上运行一个副本，并由 DaemonSet 控制： 例如，节点级日志聚合器。与水平扩展插件的情况类似， 你可能还需要稍微提高 CPU 或内存限制。 优先处理集群关键组件 ---------- 为确保集群关键组件（例如 CoreDNS、metrics-server 和其他关键插件）优先于其他工作负载运行， 并且不会被低优先级 Pod 抢占，请使用系统 [PriorityClass](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) 运行它们，例如 `system-cluster-critical` 或 `system-node-critical`。 接下来 --- * `VerticalPodAutoscaler` 是一种自定义资源，你可以将其部署到集群中，帮助你管理 Pod 的资源请求和资源限制。 了解有关 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) 的更多信息，了解如何用它扩展集群组件（包括对集群至关重要的插件）的信息。 * 阅读关于[节点自动扩缩](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/node-autoscaling/) 的信息。 * [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) 可帮助你在集群规模变化时自动调整插件的大小。 2 - 运行于多可用区环境 ============= 本页描述如何跨多个区（Zone）运行集群。 背景 -- Kubernetes 从设计上允许同一个 Kubernetes 集群跨多个失效区来运行， 通常这些区位于某个称作 **区域（Region）** 逻辑分组中。 主要的云提供商都将区域定义为一组失效区的集合（也称作 **可用区（Availability Zones**））， 能够提供一组一致的功能特性：每个区域内，各个可用区提供相同的 API 和服务。 典型的云体系结构都会尝试降低某个区中的失效影响到其他区中服务的概率。 控制面行为 ----- 所有的[控制面组件](https://kubernetes.io/zh-cn/docs/concepts/architecture/#control-plane-components) 都支持以一组可相互替换的资源池的形式来运行，每个组件都有多个副本。 当你部署集群控制面时，应将控制面组件的副本跨多个失效区来部署。 如果可用性是一个很重要的指标，应该选择至少三个失效区， 并将每个控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本， 跨至少三个失效区来部署。如果你在运行云控制器管理器， 则也应该将该组件跨所选的三个失效区来部署。 #### 说明： Kubernetes 并不会为 API 服务器端点提供跨失效区的弹性。 你可以为集群 API 服务器使用多种技术来提升其可用性，包括使用 DNS 轮转、SRV 记录或者带健康检查的第三方负载均衡解决方案等等。 节点行为 ---- Kubernetes 自动为负载资源（如 [Deployment](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/ "管理集群上的多副本应用。") 或 [StatefulSet](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/ "StatefulSet 用来管理某 Pod 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符。") ） 跨集群中不同节点来部署其 Pod。 这种分布逻辑有助于降低失效带来的影响。 节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node 对象添加[标签](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/ "用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。") 。 这些标签可能包含[区信息](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesiozone) 。 如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合 [Pod 拓扑分布约束](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/) 来控制如何在你的集群中多个失效域之间分布 Pod。这里的失效域可以是地理区域、可用区甚至是特定节点。 这些提示信息使得[调度器](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/ "控制平面组件，负责监视新创建的、未指定运行节点的 Pod，选择节点让 Pod 在上面运行。") 能够更好地调度 Pod，以实现更好的可用性，降低因为某种失效给整个工作负载带来的风险。 例如，你可以设置一种约束，确保某个 StatefulSet 中的 3 个副本都运行在不同的可用区中， 只要其他条件允许。你可以通过声明的方式来定义这种约束， 而不需要显式指定每个工作负载使用哪些可用区。 ### 跨多个区分布节点 Kubernetes 的核心逻辑并不会帮你创建节点，你需要自行完成此操作，或者使用类似 [Cluster API](https://cluster-api.sigs.k8s.io/) 这类工具来替你管理节点。 使用类似 Cluster API 这类工具，你可以跨多个失效域来定义一组用做你的集群工作节点的机器， 以及当整个区的服务出现中断时如何自动治愈集群的策略。 为 Pod 手动指定区 ----------- 你可以应用[节点选择算符约束](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) 到你所创建的 Pod 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源中的 Pod 模板设置此类约束。 跨区的存储访问 ------- 当创建持久卷时，Kubernetes 会自动向那些链接到特定区的 PersistentVolume 添加区标签。 [调度器](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/ "控制平面组件，负责监视新创建的、未指定运行节点的 Pod，选择节点让 Pod 在上面运行。") 通过其 `NoVolumeZoneConflict` 断言确保申领给定 PersistentVolume 的 Pod 只会被调度到该卷所在的可用区。 请注意，添加区标签的方法可能取决于你的云提供商和存储制备器。 请参阅具体的环境文档，确保配置正确。 请注意，添加区标签的方法可能会根据你所使用的云提供商和存储制备器而有所不同。 为确保配置正确，请始终参阅你的环境的特定文档。 你可以为 PersistentVolumeClaim 指定 [StorageClass](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/ "StorageClass 是管理员用来描述可用的不同存储类型的一种方法。") 以设置该类中的存储可以使用的失效域（区）。 要了解如何配置能够感知失效域或区的 StorageClass， 请参阅[可用的拓扑逻辑](https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#allowed-topologies) 。 网络 -- Kubernetes 自身不提供与可用区相关的联网配置。 你可以使用[网络插件](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。 例如，如果你的云提供商支持 `type=LoadBalancer` 的 Service， 则负载均衡器可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。 请查阅云提供商的文档了解详细信息。 对于自定义的或本地集群部署，也可以考虑这些因素。 [Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/ "将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。") 和 [Ingress](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/ "Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。") 的行为， 包括处理不同失效区的方法，在很大程度上取决于你的集群是如何搭建的。 失效恢复 ---- 在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何恢复服务。 例如，你是否要求在某个区中至少有一个节点能够运行 Pod？ 请确保任何对集群很关键的修复工作都不要指望集群中至少有一个健康节点。 例如：当所有节点都不健康时，你可能需要运行某个修复性的 Job， 该 Job 要设置特定的[容忍度](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/ "容忍度是一种核心对象，包含三个必需的属性：key、value 和 effect。 容忍度允许将 Pod 调度到具有对应污点的节点或节点组上。") ， 以便修复操作能够至少将一个节点恢复为可用状态。 Kubernetes 对这类问题没有现成的解决方案；不过这也是要考虑的因素之一。 接下来 --- 要了解调度器如何在集群中放置 Pod 并遵从所配置的约束， 可参阅[调度与驱逐](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/) 。 3 - 校验节点设置 ========== 节点一致性测试 ------- **节点一致性测试**是一个容器化的测试框架，提供了针对节点的系统验证和功能测试。 测试验证节点是否满足 Kubernetes 的最低要求；通过测试的节点有资格加入 Kubernetes 集群。 该测试主要检测节点是否满足 Kubernetes 的最低要求，通过检测的节点有资格加入 Kubernetes 集群。 节点的前提条件 ------- 要运行节点一致性测试，节点必须满足与标准 Kubernetes 节点相同的前提条件。 节点至少应安装以下守护程序： * 与 CRI 兼容的容器运行时，例如 Docker、Containerd 和 CRI-O * kubelet 运行节点一致性测试 --------- 要运行节点一致性测试，请执行以下步骤： 1. 得出 kubelet 的 `--kubeconfig` 的值；例如：`--kubeconfig=/var/lib/kubelet/config.yaml`。 由于测试框架启动了本地控制平面来测试 kubelet，因此使用 `http://localhost:8080` 作为API 服务器的 URL。 一些其他的 kubelet 命令行参数可能会被用到： * `--cloud-provider`：如果使用 `--cloud-provider=gce`，需要移除这个参数来运行测试。 2. 使用以下命令运行节点一致性测试： # $CONFIG_DIR 是你 kubelet 的 Pod manifest 路径。 # $LOG_DIR 是测试的输出路径。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ registry.k8s.io/node-test:0.2 针对其他硬件体系结构运行节点一致性测试 ------------------- Kubernetes 也为其他硬件体系结构的系统提供了节点一致性测试的 Docker 镜像： | 架构 | 镜像 | | --- | --- | | amd64 | node-test-amd64 | | arm | node-test-arm | | arm64 | node-test-arm64 | 运行特定的测试 ------- 要运行特定测试，请使用你希望运行的测试的特定表达式覆盖环境变量 `FOCUS`。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e FOCUS=MirrorPod \ # Only run MirrorPod test registry.k8s.io/node-test:0.2 要跳过特定的测试，请使用你希望跳过的测试的常规表达式覆盖环境变量 `SKIP`。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e SKIP=MirrorPod \ # 运行除 MirrorPod 测试外的所有一致性测试内容 registry.k8s.io/node-test:0.2 节点一致性测试是 [节点端到端测试](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md) 的容器化版本。 默认情况下，它会运行所有一致性测试。 理论上，只要合理地配置容器和挂载所需的卷，就可以运行任何的节点端到端测试用例。 但是这里**强烈建议只运行一致性测试**，因为运行非一致性测试需要很多复杂的配置。 注意事项 ---- * 测试会在节点上遗留一些 Docker 镜像，包括节点一致性测试本身的镜像和功能测试相关的镜像。 * 测试会在节点上遗留一些死的容器。这些容器是在功能测试的过程中创建的。 4 - 强制实施 Pod 安全性标准 ================== 本页提供实施 [Pod 安全标准（Pod Security Standards）](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards) 时的一些最佳实践。 使用内置的 Pod 安全性准入控制器 ------------------ 特性状态： `Kubernetes v1.25 [stable]` [Pod 安全性准入控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podsecurity) 尝试替换已被废弃的 PodSecurityPolicies。 ### 配置所有集群名字空间 完全未经配置的名字空间应该被视为集群安全模型中的重大缺陷。 我们建议花一些时间来分析在每个名字空间中执行的负载的类型， 并通过引用 Pod 安全性标准来确定每个负载的合适级别。 未设置标签的名字空间应该视为尚未被评估。 针对所有名字空间中的所有负载都具有相同的安全性需求的场景， 我们提供了一个[示例](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) 用来展示如何批量应用 Pod 安全性标签。 ### 拥抱最小特权原则 在一个理想环境中，每个名字空间中的每个 Pod 都会满足 `restricted` 策略的需求。 不过，这既不可能也不现实，某些负载会因为合理的原因而需要特权上的提升。 * 允许 `privileged` 负载的名字空间需要建立并实施适当的访问控制机制。 * 对于运行在特权宽松的名字空间中的负载，需要维护其独特安全性需求的文档。 如果可能的话，要考虑如何进一步约束这些需求。 ### 采用多种模式的策略 Pod 安全性标准准入控制器的 `audit` 和 `warn` 模式（mode） 能够在不影响现有负载的前提下，让该控制器更方便地收集关于 Pod 的重要的安全信息。 针对所有名字空间启用这些模式是一种好的实践，将它们设置为你最终打算 `enforce` 的 _期望的_ 级别和版本。这一阶段中所生成的警告和审计注解信息可以帮助你到达这一状态。 如果你期望负载的作者能够作出变更以便适应期望的级别，可以启用 `warn` 模式。 如果你希望使用审计日志了监控和驱动变更，以便负载能够适应期望的级别，可以启用 `audit` 模式。 当你将 `enforce` 模式设置为期望的取值时，这些模式在不同的场合下仍然是有用的： * 通过将 `warn` 设置为 `enforce` 相同的级别，客户可以在尝试创建无法通过合法检查的 Pod （或者包含 Pod 模板的资源）时收到警告信息。这些信息会帮助于更新资源使其合规。 * 在将 `enforce` 锁定到特定的非最新版本的名字空间中，将 `audit` 和 `warn` 模式设置为 `enforce` 一样的级别而非 `latest` 版本， 这样可以方便看到之前版本所允许但当前最佳实践中被禁止的设置。 第三方替代方案 ------- **说明：** 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) ，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读[内容指南](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) 。 Kubernetes 生态系统中也有一些其他强制实施安全设置的替代方案处于开发状态中： * [Kubewarden](https://github.com/kubewarden) . * [Kyverno](https://kyverno.io/policies/) . * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) . 采用 _内置的_ 方案（例如 PodSecurity 准入控制器）还是第三方工具， 这一决策完全取决于你自己的情况。在评估任何解决方案时，对供应链的信任都是至关重要的。 最终，使用前述方案中的 _任何_ 一种都好过放任自流。 5 - PKI 证书和要求 ============= Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果你是使用 [kubeadm](https://kubernetes.io/zh-cn/docs/reference/setup-tools/kubeadm/) 安装的 Kubernetes， 则会自动生成集群所需的证书。 你也可以自己生成证书 --- 例如，不将私钥存储在 API 服务器上， 可以让私钥更加安全。此页面说明了集群必需的证书。 集群是如何使用证书的 ---------- Kubernetes 需要 PKI 才能执行以下操作： ### 服务器证书 * API 服务器端点的证书 * etcd 服务器的服务器证书 * 每个 kubelet 的服务器证书（每个[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/ "Kubernetes 中的工作机器称作节点。") 运行一个 kubelet） * 可选的[前端代理](https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的服务器证书 ### 客户端证书 * 针对每个 kubelet 的客户端证书，用于 API 服务器作为 Kubernetes API 的客户端进行身份验证 * 每个 API 服务器的客户端证书，用于向 etcd 进行身份验证 * 控制器管理器与 API 服务器进行安全通信的客户端证书 * 调度程序与 API 服务器进行安全通信的客户端证书 * 客户端证书（每个节点一个），用于 kube-proxy 向 API 服务器进行身份验证 * 集群管理员向 API 服务器进行身份验证的可选客户端证书 * [前端代理](https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的可选客户端证书 ### kubelet 的服务器和客户端证书 为了建立安全连接并向 kubelet 进行身份验证，API 服务器需要客户端证书和密钥对。 在此场景中，证书的使用有两种方法： * 共享证书：kube-apiserver 可以使用与验证其客户端相同的证书和密钥对。 这意味着现有证书（例如 `apiserver.crt` 和 `apiserver.key`）可用于与 kubelet 服务器进行通信。 * 单独的证书：或者，kube-apiserver 可以生成新的客户端证书和密钥对，以验证其与 kubelet 服务器的通信。 在这种情况下，将创建一个名为 `kubelet-client.crt` 的不同证书及其对应的私钥 `kubelet-client.key`。 #### 说明： 只有当你运行 kube-proxy 并要支持[扩展 API 服务器](https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/) 时， 才需要 `front-proxy` 证书。 etcd 还实现了双向 TLS 来对客户端和对其他对等节点进行身份验证。 证书存储位置 ------ 假如你通过 kubeadm 安装 Kubernetes，大多数证书会被存储在 `/etc/kubernetes/pki` 中。 本文档中的所有路径都是相对于该目录的，但用户账号证书除外，kubeadm 将其放在 `/etc/kubernetes` 中。 手动配置证书 ------ 如果你不想通过 kubeadm 生成所需证书，你可以使用一个单根 CA 来创建这些证书，或者直接提供所有证书。 参见[证书](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/certificates/) 以进一步了解如何创建自己的证书授权机构。 更多关于管理证书的信息，请参阅[使用 kubeadm 进行证书管理](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) 。 ### 单根 CA 你可以创建由管理员控制的单根 CA。这个根 CA 可以创建多个中间 CA， 并将所有进一步的创建委托给 Kubernetes 本身。 需要这些 CA： | 路径 | 默认 CN | 描述 | | --- | --- | --- | | ca.crt、key | kubernetes-ca | Kubernetes 通用 CA | | etcd/ca.crt、key | etcd-ca | 与 etcd 相关的所有功能 | | front-proxy-ca.crt、key | kubernetes-front-proxy-ca | 用于[前端代理](https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) | 上面的 CA 之外，还需要获取用于服务账号管理的密钥对，也就是 `sa.key` 和 `sa.pub`。 下面的例子说明了上表中所示的 CA 密钥和证书文件。 /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/ca.key /etc/kubernetes/pki/etcd/ca.crt /etc/kubernetes/pki/etcd/ca.key /etc/kubernetes/pki/front-proxy-ca.crt /etc/kubernetes/pki/front-proxy-ca.key ### 所有的证书 如果你不想将 CA 的私钥拷贝至你的集群中，你也可以自己生成全部的证书。 需要这些证书： | 默认 CN | 父级 CA | O（位于 Subject 中） | kind | 主机（SAN） | | --- | --- | --- | --- | --- | | kube-etcd | etcd-ca | | server、client | ``、``、`localhost`、`127.0.0.1` | | kube-etcd-peer | etcd-ca | | server、client | ``、``、`localhost`、`127.0.0.1` | | kube-etcd-healthcheck-client | etcd-ca | | client | | | kube-apiserver-etcd-client | etcd-ca | | client | | | kube-apiserver | kubernetes-ca | | server | ``、``、``[1](https://kubernetes.io/zh-cn/docs/setup/best-practices/_print/#fn:1) | | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | #### 说明： 不使用超级用户组 `system:masters` 来控制 `kube-apiserver-kubelet-client`， 可以使用一个权限较低的组。kubeadm 使用 `kubeadm:cluster-admins` 组来达到这个目的。 其中 `kind` 对应一种或多种类型的 x509 密钥用途，也可记录在 [CertificateSigningRequest](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1#CertificateSigningRequest) 类型的 `.spec.usages` 中： | kind | 密钥用途 | | --- | --- | | server | 数字签名、密钥加密、服务端认证 | | client | 数字签名、密钥加密、客户端认证 | #### 说明： 上面列出的 Host/SAN 是获取工作集群的推荐配置方式； 如果需要特殊安装，则可以在所有服务器证书上添加其他 SAN。 #### 说明： 对于 kubeadm 用户： * 不使用私钥并将证书复制到集群 CA 的方案，在 kubeadm 文档中将这种方案称为外部 CA。 * 如果将上表与 kubeadm 生成的 PKI 进行比较，你会注意到，如果使用外部 etcd，则不会生成 `kube-etcd`、`kube-etcd-peer` 和 `kube-etcd-healthcheck-client` 证书。 ### 证书路径 证书应放置在建议的路径中（以便 [kubeadm](https://kubernetes.io/zh-cn/docs/reference/setup-tools/kubeadm/) 使用）。无论使用什么位置，都应使用给定的参数指定路径。 | 默认 CN | 建议的密钥路径 | 建议的证书路径 | 命令 | 密钥参数 | 证书参数 | | --- | --- | --- | --- | --- | --- | | etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | \--etcd-cafile | | kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | \--etcd-keyfile | \--etcd-certfile | | kubernetes-ca | ca.key | ca.crt | kube-apiserver | | \--client-ca-file | | kubernetes-ca | ca.key | ca.crt | kube-controller-manager | \--cluster-signing-key-file | \--client-ca-file, --root-ca-file, --cluster-signing-cert-file | | kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | \--tls-private-key-file | \--tls-cert-file | | kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | \--kubelet-client-key | \--kubelet-client-certificate | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | \--requestheader-client-ca-file | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | \--requestheader-client-ca-file | | front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | \--proxy-client-key-file | \--proxy-client-cert-file | | etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | \--trusted-ca-file, --peer-trusted-ca-file | | kube-etcd | etcd/server.key | etcd/server.crt | etcd | \--key-file | \--cert-file | | kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | \--peer-key-file | \--peer-cert-file | | etcd-ca | | etcd/ca.crt | etcdctl | | \--cacert | | kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | \--key | \--cert | 注意事项同样适用于服务账号密钥对： | 私钥路径 | 公钥路径 | 命令 | 参数 | | --- | --- | --- | --- | | sa.key | | kube-controller-manager | \--service-account-private-key-file | | | sa.pub | kube-apiserver | \--service-account-key-file | 下面的例子展示了自行生成所有密钥和证书时所需要提供的文件路径。 这些路径基于[前面的表格](https://kubernetes.io/zh-cn/docs/setup/best-practices/certificates/#certificate-paths) 。 /etc/kubernetes/pki/etcd/ca.key /etc/kubernetes/pki/etcd/ca.crt /etc/kubernetes/pki/apiserver-etcd-client.key /etc/kubernetes/pki/apiserver-etcd-client.crt /etc/kubernetes/pki/ca.key /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/front-proxy-ca.key /etc/kubernetes/pki/front-proxy-ca.crt /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/etcd/server.key /etc/kubernetes/pki/etcd/server.crt /etc/kubernetes/pki/etcd/peer.key /etc/kubernetes/pki/etcd/peer.crt /etc/kubernetes/pki/etcd/healthcheck-client.key /etc/kubernetes/pki/etcd/healthcheck-client.crt /etc/kubernetes/pki/sa.key /etc/kubernetes/pki/sa.pub 为用户账号配置证书 --------- 你必须手动配置以下管理员账号和服务账号： | 文件名 | 凭据名称 | 默认 CN | O (位于 Subject 中) | | --- | --- | --- | --- | | admin.conf | default-admin | kubernetes-admin | `` | | super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters | | kubelet.conf | default-auth | system:node:``（参阅注释） | system:nodes | | controller-manager.conf | default-controller-manager | system:kube-controller-manager | | | scheduler.conf | default-scheduler | system:kube-scheduler | | #### 说明： `kubelet.conf` 中 `` 的值**必须**与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。 有关更多详细信息，请阅读[节点授权](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/node/) 。 #### 说明： 在上面的例子中，`` 是实现特定的。 一些工具在默认的 `admin.conf` 中签署证书，以成为 `system:masters` 组的一部分。 `system:masters` 是一个紧急情况下的超级用户组，可以绕过 Kubernetes 的授权层，如 RBAC。 另外，某些工具不会生成单独的 `super-admin.conf` 将证书绑定到这个超级用户组。 kubeadm 在 kubeconfig 文件中生成两个单独的管理员证书。 一个是在 `admin.conf` 中，带有 `Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin`。 `kubeadm:cluster-admins` 是绑定到 `cluster-admin` ClusterRole 的自定义组。 这个文件在所有由 kubeadm 管理的控制平面机器上生成。 另一个是在 `super-admin.conf` 中，具有 `Subject: O = system:masters, CN = kubernetes-super-admin`。 这个文件只在调用了 `kubeadm init` 的节点上生成。 1. 对于每个配置，请都使用给定的通用名称（CN）和组织（O）生成 x509 证书/密钥对。 2. 为每个配置运行下面的 `kubectl` 命令： KUBECONFIG=<文件名> kubectl config set-cluster default-cluster --server=https://<主机ip>:6443 --certificate-authority --embed-certs KUBECONFIG=<文件名> kubectl config set-credentials <凭据名称> --client-key <密钥路径>.pem --client-certificate <证书路径>.pem --embed-certs KUBECONFIG=<文件名> kubectl config set-context default-system --cluster default-cluster --user <凭据名称> KUBECONFIG=<文件名> kubectl config use-context default-system 这些文件用途如下： | 文件名 | 命令 | 说明 | | --- | --- | --- | | admin.conf | kubectl | 配置集群的管理员 | | super-admin.conf | kubectl | 为集群配置超级管理员用户 | | kubelet.conf | kubelet | 集群中的每个节点都需要一份 | | controller-manager.conf | kube-controller-manager | 必须添加到 `manifests/kube-controller-manager.yaml` 清单中 | | scheduler.conf | kube-scheduler | 必须添加到 `manifests/kube-scheduler.yaml` 清单中 | 下面是前表中所列文件的完整路径。 /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf * * * 1. 用来连接到集群的不同 IP 或 DNS 名称 （就像 [kubeadm](https://kubernetes.io/zh-cn/docs/reference/setup-tools/kubeadm/) 为负载均衡所使用的固定 IP 或 DNS 名称：`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、 `kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）。 [↩︎](https://kubernetes.io/zh-cn/docs/setup/best-practices/_print/#fnref:1) --- # Расширения Kubernetes | Kubernetes Это многостраничный печатный вид этого раздела. [Нажмите что бы печатать](https://kubernetes.io/ru/docs/concepts/extend-kubernetes/_print/#) . [Вернуться к обычному просмотру страницы](https://kubernetes.io/ru/docs/concepts/extend-kubernetes/) . Расширения Kubernetes ===================== * 1: [Паттерн "Оператор"](https://kubernetes.io/ru/docs/concepts/extend-kubernetes/_print/#pg-3131452556176159fb269593c1a52012) 1 - Паттерн "Оператор" ====================== Операторы — это программные расширения для Kubernetes, которые используют [Custom Resources](https://kubernetes.io/ru/docs/concepts/extend-kubernetes/api-extension/custom-resources/) , чтобы управлять приложениями (или их компонентами). Операторы следуют принципам Kubernetes, в особенности, принципу [цикла управления](https://kubernetes.io/ru/docs/concepts/architecture/controller) . Зачем это нужно --------------- _Паттерн "Оператор"_ пытается воспроизвести основную цель оператора — человека, который управляет сервисом (или их группой). Поскольку операторы поддерживают приложения и сервисы и знакомы с их спецификой, у них есть глубокое понимание того, как приложения должны работать, как их разворачивать и как решать возникающие с ними проблемы. Зачастую инженеры, использующие Kubernetes, автоматизируют повторяющиеся задачи. Паттерн "Оператор" дает возможность писать код для автоматизации специфических задач, когда это не получается сделать средствами самого Kubernetes. Операторы в Kubernetes ---------------------- Kubernetes создан для автоматизации: из коробки вы получаете множество встроенной автоматизации. Вы можете использовать Kubernetes, чтобы автоматизировать развертывание и запуск приложений, но _кроме того_, можно доработать Kubernetes собственными автоматизациями. [Паттерн "Оператор"](https://kubernetes.io/ru/docs/concepts/extend-kubernetes/operator/ "A specialized controller used to manage a custom resource") позволяет расширить возможности кластера, не меняя код Kubernetes; достаточно привязать [контроллеры](https://kubernetes.io/ru/docs/concepts/architecture/controller/ "Управляющий цикл, который отслеживает общее состояние кластера через API-сервер и вносит изменения, пытаясь привести текущее состояние к желаемому.") к вашим ресурсам. Операторы — это клиенты Kubernetes API, которые выполняют роль контроллеров для [Custom Resources](https://kubernetes.io/ru/docs/concepts/extend-kubernetes/api-extension/custom-resources/) . Пример оператора ---------------- Ниже приведены примеры задач, которые вы можете автоматизировать с помощью операторов: * развернуть приложение по запросу; * создать бэкап состояния этого приложения или восстановиться из бэкапа; * обновить код приложения одновременно с сопутствующими изменениями (например, с обновлением схемы БД или конфигурации); * анонсировать сервис для приложений, которые не поддерживают Kubernetes API, чтобы они смогли обнаружить его самостоятельно; * смоделировать отказ кластера или его частей, чтобы проверить их отказоустойчивость; * выбрать лидера в распределенном приложении, не инициируя внутренний процесс голосования за лидера. Как именно может выглядеть оператор? Рассмотрим на примере: 1. Есть Custom Resource под названием SampleDB, который вы подготовили для кластера. 2. Есть деплоймент; он поддерживает работу пода, в котором содержится контроллерная часть оператора. 3. Есть образ контейнера с кодом оператора. 4. Код контроллера делает запросы к управляющему слою, чтобы узнать, какие ресурсы настроены для SampleDB . 5. Ядром оператора является код, который сообщает серверу API, как ресурсам достичь желаемого состояния: * Когда вы добавляете новый узел SampleDB, оператор создает PersistentVolumeClaims, чтобы предоставить долговременное хранилище данных, StatefulSet для запуска SampleDB и Job, который займется изначальной конфигурацией. * Когда вы удалите этот узел, оператор создаст снимок его состояния, после чего убедится, что StatefulSet и тома также удалены. 6. Кроме того, оператор управляет созданием бэкапов. Для каждого запущенного узла SampleDB оператор запускает под, который подсоединяется к базе данных и создает бэкап. За данными для подключения к БД поды обращаются к ConfigMap или секретам. 7. Поскольку цель оператора — это предоставить простую автоматизацию для ресурса, которым он управляет, в нем может быть еще какой-нибудь полезный код. В нашем примере этот код проверяет, запущена ли база данных нужной версии, и, если это не так, создает Job, чтобы ее обновить. Развертывание операторов ------------------------ Чтобы развернуть оператор в кластере, обычно создают Custom Resource Definition и соответствующий контроллер. Как правило, контроллер запускается как обычное контейнеризованное приложение, то есть, вне [управляющего слоя](https://kubernetes.io/ru/docs/reference/glossary/?all=true#term-control-plane "Уровень оркестрации контейнеров, предоставляющий API и интерфейсы для определения, развёртывания и управления жизненным циклом контейнеров.") ; например, его можно запустить как деплоймент. Использование операторов ------------------------ Когда оператор развернут, вы можете им пользоваться, добавляя, изменяя или удаляя те сущности, которыми он управляет. В примере с оператором, ранее развернутым как деплоймент, вы можете выполнить команды: kubectl get SampleDB # найдем ранее настроенную базу данных kubectl edit SampleDB/example-database # вручную изменим ее настройки …И все готово: оператор позаботится о том, чтобы применить изменения; в то же время он продолжит поддерживать работу уже запущенного приложения. Создание собственного оператора ------------------------------- Если в существующей экосистеме еще нет оператора, который делает то, что вам нужно, вы можете написать свой собственный. Вы можете реализовать оператор (контроллер, если быть точнее) на любом языке или в любой среде, которые могут быть [клиентами Kubernetes API](https://kubernetes.io/ru/docs/reference/using-api/client-libraries/) . Вы можете использовать библиотеки и инструменты ниже, чтобы написать свой Cloud Native-оператор. **Примечание:** Этот раздел ссылается на сторонние проекты, реализующие функциональность, которая требуется Kubernetes. Авторы Kubernetes не несут ответственность за проекты, представленные здесь в алфавитном порядке. Чтобы добавить проект к этому списку, ознакомьтесь с [руководством по контенту](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) перед публикацией изменений. [Подробнее](https://kubernetes.io/ru/docs/concepts/extend-kubernetes/_print/#third-party-content-disclaimer) . * [Charmed Operator Framework](https://juju.is/) * [Java Operator SDK](https://github.com/operator-framework/java-operator-sdk) * [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework) * [kube-rs](https://kube.rs/) (Rust) * [kubebuilder](https://book.kubebuilder.io/) * [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (SDK для написания операторов на .NET) * [Mast](https://docs.ansi.services/mast/user_guide/operator/) * [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html) вместе с веб-хуками, которые вы реализуете самостоятельно * [Operator Framework](https://operatorframework.io/) * [shell-operator](https://github.com/flant/shell-operator) Что дальше ---------- * Прочтите статью [Operator White Paper](https://github.com/cncf/tag-app-delivery/blob/163962c4b1cd70d085107fc579e3e04c2e14d59c/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md) от [CNCF](https://cncf.io/ "Cloud Native Computing Foundation") * Узнайте больше про [Custom Resources](https://kubernetes.io/ru/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * Поищите готовые операторы, которые подходят вашим задачам, на [OperatorHub.io](https://operatorhub.io/) * [Поделитесь](https://operatorhub.io/) вашим оператором с другими * Прочтите [статью](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) , в которой впервые описан паттерн "Оператор", на сайте CoreOS (это архивная версия изначальной статьи) * Прочтите [статью](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) о подходах к созданию операторов от Google Cloud --- # Setup | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/setup/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/setup/) . Setup ===== * 1: [Descargando Kubernetes](https://kubernetes.io/es/docs/setup/_print/#pg-d33663ac044e1981b406949f9124cc04) * 1.1: [Compilando desde código fuente](https://kubernetes.io/es/docs/setup/_print/#pg-10b7970741f3e4925d298f965641410e) * 2: [Desplegando un clúster con kubeadm](https://kubernetes.io/es/docs/setup/_print/#pg-90b984528d308d083434bb6204966789) * 3: [Soluciones sobre IaaS en la nube](https://kubernetes.io/es/docs/setup/_print/#pg-3f0351295afa870d9c1b5d0bf791ce68) * 4: [Soluciones sobre virtualización On-Premises](https://kubernetes.io/es/docs/setup/_print/#pg-2bec15a6732230323d949e1dea7ba346) * 5: [Soluciones personalizadas](https://kubernetes.io/es/docs/setup/_print/#pg-89cb5486440b5e96f31dbb3956f2ad9e) * 6: [Kubernetes sobre Windows](https://kubernetes.io/es/docs/setup/_print/#pg-523ff1969f0bd95db0c8eec795bff8f6) En esta sección encontrarás toda la información necesaria para poder identificar **la solución que mejor se adapta a tus necesidades**. Decidir dónde ejecutar Kubernetes depende principalmente de los recursos que tengas disponibles, de las características del clúster y de cuánta flexibilidad necesites. Puedes ejecutar Kubernetes casi en cualquier lugar, desde su ordenador portátil a máquinas virtuales en la nube o en un rack de servidores físicos on-premises. Puedes configurar un clúster totalmente gestionado ejecutando un solo comando, desplegar una solución parcialmente automatizada que te ofrezca un poco más de control o directamente crear tu propio clúster de forma completamente manual personalizando y controlando cada componente. Soluciones para la máquina en local ----------------------------------- Una solución para la máquina en local es la forma más sencilla de empezar a utilizar Kubernetes. Puedes crear y probar clústeres de Kubernetes sin tener que preocuparte por consumir recursos en el cloud ni disponer de conectividad. Deberías elegir una solución de este tipo si buscas: * Probar o empezar a aprender sobre Kubernetes. * Desarrollar y testear clústeres localmente. Soluciones gestionadas ---------------------- Una solución gestionada es la forma más conveniente de crear y gestionar un clúster de Kubernetes. El proveedor gestiona y opera los clústeres completamente por lo que tú no has de preocuparte de nada. Deberías elegir una solución de este tipo si: * Quieres una solución totalmente gestionada. * Quieres centrarte en desarrollar tus aplicaciones o servicios. * No tienes un equipo dedicado de operaciones pero quieres alta disponibilidad. * No tienes recursos para alojar y monitorizar sus clústeres. Soluciones sobre IaaS en la nube -------------------------------- Un solución sobre IaaS en la nube permite crear clústeres Kubernetes con solo unos pocos comandos, se encuentran en desarrollo activo, tienen el apoyo de la comunidad y algunas de ellas forman parte del proyecto Kubernetes. Se pueden desplegar en la infraestructura como servicio (IaaS) proporcionada por los proveedores en la nube y ofrecen más flexibilidad que las soluciones gestionadas, pero requieren más conocimientos para ponerlos en marcha y más esfuerzo para operarlos. Deberías elegir una solución de este tipo si: * Necesitas más control que el permitido en las soluciones gestionadas. * Quieres responsabilizarte de la operativa de los clústeres. Soluciones sobre virtualización On-Premises ------------------------------------------- Una solución sobre virtualización sobre on-premises permite crear clústeres y operarlos de forma segura en tú nube privada con solo unos pocos comandos. Deberías elegir una solución de este tipo si: * Quieres desplegar clústeres en su nube privada dentro de tú red. * Tienes un equipo de operaciones para desplegar y operar el clúster. * Tienes los recursos necesarios para ejecutar y monitorizar el clúster. Soluciones personalizadas ------------------------- Una solución personalizadas proporciona total libertad sobre los clústeres pero requiere más conocimiento y experiencia. 1 - Descargando Kubernetes ========================== 1.1 - Compilando desde código fuente ==================================== Se puede o bien crear una release desde el código fuente o bien descargar una versión pre-built. Si no se pretende hacer un desarrollo de Kubernetes en sí mismo, se sugiere usar una version pre-built de la release actual, que se puede encontrar en [Release Notes](https://kubernetes.io/docs/setup/release/notes/) . El código fuente de Kubernetes se puede descargar desde el repositorio [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) . Compilar desde código fuente ---------------------------- Si simplemente estas compilando una release desde el código fuente, no es necesario hacer una configuración completa del entorno golang ya que toda la compilación se realiza desde un contenedor Docker. Compilar es fácil. git clone https://github.com/kubernetes/kubernetes.git cd kubernetes make release Para más detalles sobre el proceso de compilación de una release, visita la carpeta kubernetes/kubernetes [`build`](http://releases.k8s.io/master/build/) 2 - Desplegando un clúster con kubeadm ====================================== 3 - Soluciones sobre IaaS en la nube ==================================== 4 - Soluciones sobre virtualización On-Premises =============================================== 5 - Soluciones personalizadas ============================= 6 - Kubernetes sobre Windows ============================ --- # Services | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/docs/tutorials/services/_print/#) . [Return to the regular view of this page](https://kubernetes.io/docs/tutorials/services/) . Services ======== * 1: [Connecting Applications with Services](https://kubernetes.io/docs/tutorials/services/_print/#pg-bc0a2760d2865e91c501bc2467cd1a4b) * 2: [Using Source IP](https://kubernetes.io/docs/tutorials/services/_print/#pg-5642e8c51749e4fe2e6a2ccc207f1fab) * 3: [Explore Termination Behavior for Pods And Their Endpoints](https://kubernetes.io/docs/tutorials/services/_print/#pg-3cecc68ef365a9d2ee0b4860dc74cacc) 1 - Connecting Applications with Services ========================================= The Kubernetes model for connecting containers ---------------------------------------------- Now that you have a continuously running, replicated application you can expose it on a network. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model. This tutorial uses a simple nginx web server to demonstrate the concept. Exposing pods to the cluster ---------------------------- We did this in a previous example, but let's do it once again and focus on the networking perspective. Create an nginx Pod, and note that it has a container port specification: [`service/networking/run-my-nginx.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/run-my-nginx.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/run-my-nginx.yaml to clipboard") apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: selector: matchLabels: run: my-nginx replicas: 2 template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 80 This makes it accessible from any node in your cluster. Check the nodes the Pod is running on: kubectl apply -f ./run-my-nginx.yaml kubectl get pods -l run=my-nginx -o wide NAME READY STATUS RESTARTS AGE IP NODE my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd Check your pods' IPs: kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs POD_IP [map[ip:10.244.3.4]] [map[ip:10.244.2.5]] You should be able to ssh into any node in your cluster and use a tool such as `curl` to make queries against both IPs. Note that the containers are _not_ using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same `containerPort`, and access them from any other pod or node in your cluster using the assigned IP address for the pod. If you want to arrange for a specific port on the host Node to be forwarded to backing Pods, you can - but the networking model should mean that you do not need to do so. You can read more about the [Kubernetes Networking Model](https://kubernetes.io/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) if you're curious. Creating a Service ------------------ So we have pods running nginx in a flat, cluster wide, address space. In theory, you could talk to these pods directly, but what happens when a node dies? The pods die with it, and the ReplicaSet inside the Deployment will create new ones, with different IPs. This is the problem a Service solves. A Kubernetes Service is an abstraction which defines a logical set of Pods running somewhere in your cluster, that all provide the same functionality. When created, each Service is assigned a unique IP address (also called clusterIP). This address is tied to the lifespan of the Service, and will not change while the Service is alive. Pods can be configured to talk to the Service, and know that communication to the Service will be automatically load-balanced out to some pod that is a member of the Service. You can create a Service for your 2 nginx replicas with `kubectl expose`: kubectl expose deployment/my-nginx service/my-nginx exposed This is equivalent to `kubectl apply -f` in the following yaml: [`service/networking/nginx-svc.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/nginx-svc.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/nginx-svc.yaml to clipboard") apiVersion: v1 kind: Service metadata: name: my-nginx labels: run: my-nginx spec: ports: - port: 80 protocol: TCP selector: run: my-nginx This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [Service](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#service-v1-core) API object to see the list of supported fields in service definition. Check your Service: kubectl get svc my-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx ClusterIP 10.0.162.149 80/TCP 21s As mentioned previously, a Service is backed by a group of Pods. These Pods are exposed through [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/ "EndpointSlices track the IP addresses of Pods for Services.") . The Service's selector will be evaluated continuously and the results will be POSTed to an EndpointSlice that is connected to the Service using [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels "Tags objects with identifying attributes that are meaningful and relevant to users.") . When a Pod dies, it is automatically removed from the EndpointSlices that contain it as an endpoint. New Pods that match the Service's selector will automatically get added to an EndpointSlice for that Service. Check the endpoints, and note that the IPs are the same as the Pods created in the first step: kubectl describe svc my-nginx Name: my-nginx Namespace: default Labels: run=my-nginx Annotations: Selector: run=my-nginx Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.0.162.149 IPs: 10.0.162.149 Port: 80/TCP TargetPort: 80/TCP Endpoints: 10.244.2.5:80,10.244.3.4:80 Session Affinity: None Events: kubectl get endpointslices -l kubernetes.io/service-name=my-nginx NAME ADDRESSTYPE PORTS ENDPOINTS AGE my-nginx-7vzhx IPv4 80 10.244.2.5,10.244.3.4 21s You should now be able to curl the nginx Service on `:` from any node in your cluster. Note that the Service IP is completely virtual, it never hits the wire. If you're curious about how this works you can read more about the [service proxy](https://kubernetes.io/docs/reference/networking/virtual-ips/) . Accessing the Service --------------------- Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the [CoreDNS cluster addon](https://releases.k8s.io/v1.35.0/cluster/addons/dns/coredns) . #### Note: If the service environment variables are not desired (because possible clashing with expected program ones, too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks` flag to `false` on the [pod spec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#pod-v1-core) . ### Environment Variables When a Pod runs on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx Pods (your Pod name will be different): kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE KUBERNETES_SERVICE_HOST=10.0.0.1 KUBERNETES_SERVICE_PORT=443 KUBERNETES_SERVICE_PORT_HTTPS=443 Note there's no mention of your Service. This is because you created the replicas before the Service. Another disadvantage of doing this is that the scheduler might put both Pods on the same machine, which will take your entire Service down if it dies. We can do this the right way by killing the 2 Pods and waiting for the Deployment to recreate them. This time the Service exists _before_ the replicas. This will give you scheduler-level Service spreading of your Pods (provided all your nodes have equal capacity), as well as the right environment variables: kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2; kubectl get pods -l run=my-nginx -o wide NAME READY STATUS RESTARTS AGE IP NODE my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m You may notice that the pods have different names, since they are killed and recreated. kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE KUBERNETES_SERVICE_PORT=443 MY_NGINX_SERVICE_HOST=10.0.162.149 KUBERNETES_SERVICE_HOST=10.0.0.1 MY_NGINX_SERVICE_PORT=80 KUBERNETES_SERVICE_PORT_HTTPS=443 ### DNS Kubernetes offers a DNS cluster addon Service that automatically assigns dns names to other Services. You can check if it's running on your cluster: kubectl get services kube-dns --namespace=kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m The rest of this section will assume you have a Service with a long lived IP (my-nginx), and a DNS server that has assigned a name to that IP. Here we use the CoreDNS cluster addon (application name `kube-dns`), so you can talk to the Service from any pod in your cluster using standard methods (e.g. `gethostbyname()`). If CoreDNS isn't running, you can enable it referring to the [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) or [Installing CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/#installing-coredns) . Let's run another curl application to test this: kubectl run curl --image=radial/busyboxplus:curl -i --tty --rm Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false Hit enter for command prompt Then, hit enter and run `nslookup my-nginx`: [ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx Server: 10.0.0.10 Address 1: 10.0.0.10 Name: my-nginx Address 1: 10.0.162.149 Securing the Service -------------------- Till now we have only accessed the nginx server from within the cluster. Before exposing the Service to the internet, you want to make sure the communication channel is secure. For this, you will need: * Self signed certificates for https (unless you already have an identity certificate) * An nginx server configured to use the certificates * A [secret](https://kubernetes.io/docs/concepts/configuration/secret/) that makes the certificates accessible to pods You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/master/_archived/https-nginx/) . This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short: make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt secret/nginxsecret created kubectl get secrets NAME TYPE DATA AGE nginxsecret kubernetes.io/tls 2 1m And also the configmap: kubectl create configmap nginxconfigmap --from-file=default.conf You can find an example for `default.conf` in [the Kubernetes examples project repo](https://github.com/kubernetes/examples/tree/bc9ca4ca32bb28762ef216386934bef20f1f9930/staging/https-nginx/) . configmap/nginxconfigmap created kubectl get configmaps NAME DATA AGE nginxconfigmap 1 114s You can view the details of the `nginxconfigmap` ConfigMap using the following command: kubectl describe configmap nginxconfigmap The output is similar to: Name: nginxconfigmap Namespace: default Labels: Annotations: Data ==== default.conf: ---- server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; listen 443 ssl; root /usr/share/nginx/html; index index.html; server_name localhost; ssl_certificate /etc/nginx/ssl/tls.crt; ssl_certificate_key /etc/nginx/ssl/tls.key; location / { try_files $uri $uri/ =404; } } BinaryData ==== Events: Following are the manual steps to follow in case you run into problems running make (on windows for example): # Create a public private key pair openssl req -x509 -noenc -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx" # Convert the keys to base64 encoding cat /d/tmp/nginx.crt | base64 cat /d/tmp/nginx.key | base64 Use the output from the previous commands to create a yaml file as follows. The base64 encoded value should all be on a single line. apiVersion: "v1" kind: "Secret" metadata: name: "nginxsecret" namespace: "default" type: kubernetes.io/tls data: # NOTE: Replace the following values with your own base64-encoded certificate and key. tls.crt: "REPLACE_WITH_BASE64_CERT" tls.key: "REPLACE_WITH_BASE64_KEY" Now create the secrets using the file: kubectl apply -f nginxsecrets.yaml kubectl get secrets NAME TYPE DATA AGE nginxsecret kubernetes.io/tls 2 1m Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443): [`service/networking/nginx-secure-app.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/nginx-secure-app.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/nginx-secure-app.yaml to clipboard") apiVersion: v1 kind: Service metadata: name: my-nginx labels: run: my-nginx spec: type: NodePort ports: - port: 8080 targetPort: 80 protocol: TCP name: http - port: 443 protocol: TCP name: https selector: run: my-nginx --- apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: selector: matchLabels: run: my-nginx replicas: 1 template: metadata: labels: run: my-nginx spec: volumes: - name: secret-volume secret: secretName: nginxsecret - name: configmap-volume configMap: name: nginxconfigmap containers: - name: nginxhttps image: bprashanth/nginxhttps:1.0 ports: - containerPort: 443 - containerPort: 80 volumeMounts: - mountPath: /etc/nginx/ssl name: secret-volume - mountPath: /etc/nginx/conf.d name: configmap-volume Noteworthy points about the nginx-secure-app manifest: * It contains both Deployment and Service specification in the same file. * The [nginx server](https://github.com/kubernetes/examples/blob/master/_archived/https-nginx/default.conf) serves HTTP traffic on port 80 and HTTPS traffic on 443, and nginx Service exposes both ports. * Each container has access to the keys through a volume mounted at `/etc/nginx/ssl`. This is set up _before_ the nginx server is started. kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml At this point you can reach the nginx server from any node. kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs POD_IP [map[ip:10.244.3.5]] node $ curl -k https://10.244.3.5 ...

Welcome to nginx!

Note how we supplied the `-k` parameter to curl in the last step, this is because we don't know anything about the pods running nginx at certificate generation time, so we have to tell curl to ignore the CName mismatch. By creating a Service we linked the CName used in the certificate with the actual DNS name used by pods during Service lookup. Let's test this from a pod (the same secret is being reused for simplicity, the pod only needs nginx.crt to access the Service): [`service/networking/curlpod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/networking/curlpod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/networking/curlpod.yaml to clipboard") apiVersion: apps/v1 kind: Deployment metadata: name: curl-deployment spec: selector: matchLabels: app: curlpod replicas: 1 template: metadata: labels: app: curlpod spec: volumes: - name: secret-volume secret: secretName: nginxsecret containers: - name: curlpod command: - sh - -c - while true; do sleep 1; done image: radial/busyboxplus:curl volumeMounts: - mountPath: /etc/nginx/ssl name: secret-volume kubectl apply -f ./curlpod.yaml kubectl get pods -l app=curlpod NAME READY STATUS RESTARTS AGE curl-deployment-1515033274-1410r 1/1 Running 0 1m kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt ... Welcome to nginx! ... Exposing the Service -------------------- For some parts of your applications you may want to expose a Service onto an external IP address. Kubernetes supports two ways of doing this: NodePorts and LoadBalancers. The Service created in the last section already used `NodePort`, so your nginx HTTPS replica is ready to serve traffic on the internet if your node has a public IP. kubectl get svc my-nginx -o yaml | grep nodePort -C 5 uid: 07191fb3-f61a-11e5-8ae5-42010af00002 spec: clusterIP: 10.0.162.149 ports: - name: http nodePort: 31704 port: 8080 protocol: TCP targetPort: 80 - name: https nodePort: 32453 port: 443 protocol: TCP targetPort: 443 selector: run: my-nginx kubectl get nodes -o yaml | grep ExternalIP -C 1 - address: 104.197.41.11 type: ExternalIP allocatable: -- - address: 23.251.152.56 type: ExternalIP allocatable: ... $ curl https://: -k ...

Welcome to nginx!

Let's now recreate the Service to use a cloud load balancer. Change the `Type` of `my-nginx` Service from `NodePort` to `LoadBalancer`: kubectl edit svc my-nginx kubectl get svc my-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s curl https:// -k ... Welcome to nginx! The IP address in the `EXTERNAL-IP` column is the one that is available on the public internet. The `CLUSTER-IP` is only available inside your cluster/private cloud network. Note that on AWS, type `LoadBalancer` creates an ELB, which uses a (long) hostname, not an IP. It's too long to fit in the standard `kubectl get svc` output, in fact, so you'll need to do `kubectl describe service my-nginx` to see it. You'll see something like this: kubectl describe service my-nginx ... LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com ... What's next ----------- * Learn more about [Using a Service to Access an Application in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/) * Learn more about [Connecting a Front End to a Back End Using a Service](https://kubernetes.io/docs/tasks/access-application-cluster/connecting-frontend-backend/) * Learn more about [Creating an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) 2 - Using Source IP =================== Applications running in a Kubernetes cluster find and communicate with each other, and the outside world, through the Service abstraction. This document explains what happens to the source IP of packets sent to different types of Services, and how you can toggle this behavior according to your needs. Before you begin ---------------- ### Terminology This document makes use of the following terms: [NAT](https://en.wikipedia.org/wiki/Network_address_translation) Network address translation [Source NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT) Replacing the source IP on a packet; in this page, that usually means replacing with the IP address of a node. [Destination NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT) Replacing the destination IP on a packet; in this page, that usually means replacing with the IP address of a [Pod](https://kubernetes.io/docs/concepts/workloads/pods/ "A Pod represents a set of running containers in your cluster.") [VIP](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) A virtual IP address, such as the one assigned to every [Service](https://kubernetes.io/docs/concepts/services-networking/service/ "A way to expose an application running on a set of Pods as a network service.") in Kubernetes [kube-proxy](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) A network daemon that orchestrates Service VIP management on every node ### Prerequisites You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) or you can use one of these Kubernetes playgrounds: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) The examples use a small nginx webserver that echoes back the source IP of requests it receives through an HTTP header. You can create it as follows: #### Note: The image in the following command only runs on AMD64 architectures. kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.10 The output is: deployment.apps/source-ip-app created Objectives ---------- * Expose a simple application through various types of Services * Understand how each Service type handles source IP NAT * Understand the tradeoffs involved in preserving source IP Source IP for Services with `Type=ClusterIP` -------------------------------------------- Packets sent to ClusterIP from within the cluster are never source NAT'd if you're running kube-proxy in [iptables mode](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-iptables) , (the default). You can query the kube-proxy mode by fetching `http://localhost:10249/proxyMode` on the node where kube-proxy is running. kubectl get nodes The output is similar to this: NAME STATUS ROLES AGE VERSION kubernetes-node-6jst Ready 2h v1.13.0 kubernetes-node-cx31 Ready 2h v1.13.0 kubernetes-node-jj1t Ready 2h v1.13.0 Get the proxy mode on one of the nodes (kube-proxy listens on port 10249): # Run this in a shell on the node you want to query. curl http://localhost:10249/proxyMode The output is: iptables You can test source IP preservation by creating a Service over the source IP app: kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080 The output is: service/clusterip exposed kubectl get svc clusterip The output is similar to: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE clusterip ClusterIP 10.0.170.92 80/TCP 51s And hitting the `ClusterIP` from a pod in the same cluster: kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm The output is similar to this: Waiting for pod default/busybox to be running, status is Pending, pod ready: false If you don't see a command prompt, try pressing enter. You can then run a command inside that Pod: # Run this inside the terminal from "kubectl run" ip addr 1: lo: mtu 65536 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0: mtu 1460 qdisc noqueue link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff inet 10.244.3.8/24 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::188a:84ff:feb0:26a5/64 scope link valid_lft forever preferred_lft forever …then use `wget` to query the local webserver # Replace "10.0.170.92" with the IPv4 address of the Service named "clusterip" wget -qO - 10.0.170.92 CLIENT VALUES: client_address=10.244.3.8 command=GET ... The `client_address` is always the client pod's IP address, whether the client pod and server pod are in the same node or in different nodes. Source IP for Services with `Type=NodePort` ------------------------------------------- Packets sent to Services with [`Type=NodePort`](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport) are source NAT'd by default. You can test this by creating a `NodePort` Service: kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort The output is: service/nodeport exposed NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') If you're running on a cloud provider, you may need to open up a firewall-rule for the `nodes:nodeport` reported above. Now you can try reaching the Service from outside the cluster through the node port allocated above. for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done The output is similar to: client_address=10.180.1.1 client_address=10.240.0.5 client_address=10.240.0.3 Note that these are not the correct client IPs, they're cluster internal IPs. This is what happens: * Client sends packet to `node2:nodePort` * `node2` replaces the source IP address (SNAT) in the packet with its own IP address * `node2` replaces the destination IP on the packet with the pod IP * packet is routed to node 1, and then to the endpoint * the pod's reply is routed back to node2 * the pod's reply is sent back to the client Visually: [![source IP nodeport figure 01](https://kubernetes.io/docs/images/tutor-service-nodePort-fig01.svg)](https://mermaid.live/edit#pako:eNqNkV9rwyAUxb-K3LysYEqS_WFYKAzat9GHdW9zDxKvi9RoMIZtlH732ZjSbE970cu5v3s86hFqJxEYfHjRNeT5ZcUtIbXRaMNN2hZ5vrYRqt52cSXV-4iMSuwkZiYtyX739EqWaahMQ-V1qPxDVLNOvkYrO6fj2dupWMR2iiT6foOKdEZoS5Q2hmVSStoH7w7IMqXUVOefWoaG3XVftHbGeZYVRbH6ZXJ47CeL2-qhxvt_ucTe1SUlpuMN6CX12XeGpLdJiaMMFFr0rdAyvvfxjHEIDbbIgcVSohKDCRy4PUV06KQIuJU6OA9MCdMjBTEEt_-2NbDgB7xAGy3i97VJPP0ABRmcqg) Figure. Source IP Type=NodePort using SNAT To avoid this, Kubernetes has a feature to [preserve the client source IP](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) . If you set `service.spec.externalTrafficPolicy` to the value `Local`, kube-proxy only proxies proxy requests to local endpoints, and does not forward traffic to other nodes. This approach preserves the original source IP address. If there are no local endpoints, packets sent to the node are dropped, so you can rely on the correct source-ip in any packet processing rules you might apply a packet that make it through to the endpoint. Set the `service.spec.externalTrafficPolicy` field as follows: kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}' The output is: service/nodeport patched Now, re-run the test: for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done The output is similar to: client_address=198.51.100.79 Note that you only got one reply, with the _right_ client IP, from the one node on which the endpoint pod is running. This is what happens: * client sends packet to `node2:nodePort`, which doesn't have any endpoints * packet is dropped * client sends packet to `node1:nodePort`, which _does_ have endpoints * node1 routes packet to endpoint with the correct source IP Visually: ![source IP nodeport figure 02](https://kubernetes.io/docs/images/tutor-service-nodePort-fig02.svg) Figure. Source IP Type=NodePort preserves client source IP address Source IP for Services with `Type=LoadBalancer` ----------------------------------------------- Packets sent to Services with [`Type=LoadBalancer`](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer) are source NAT'd by default, because all schedulable Kubernetes nodes in the `Ready` state are eligible for load-balanced traffic. So if packets arrive at a node without an endpoint, the system proxies it to a node _with_ an endpoint, replacing the source IP on the packet with the IP of the node (as described in the previous section). You can test this by exposing the source-ip-app through a load balancer: kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer The output is: service/loadbalancer exposed Print out the IP addresses of the Service: kubectl get svc loadbalancer The output is similar to this: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m Next, send a request to this Service's external-ip: curl 203.0.113.140 The output is similar to this: CLIENT VALUES: client_address=10.240.0.5 ... However, if you're running on Google Kubernetes Engine/GCE, setting the same `service.spec.externalTrafficPolicy` field to `Local` forces nodes _without_ Service endpoints to remove themselves from the list of nodes eligible for loadbalanced traffic by deliberately failing health checks. Visually: ![Source IP with externalTrafficPolicy](https://kubernetes.io/images/docs/sourceip-externaltrafficpolicy.svg) You can test this by setting the annotation: kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}' You should immediately see the `service.spec.healthCheckNodePort` field allocated by Kubernetes: kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort The output is similar to this: healthCheckNodePort: 32122 The `service.spec.healthCheckNodePort` field points to a port on every node serving the health check at `/healthz`. You can test this: kubectl get pod -o wide -l app=source-ip-app The output is similar to this: NAME READY STATUS RESTARTS AGE IP NODE source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst Use `curl` to fetch the `/healthz` endpoint on various nodes: # Run this locally on a node you choose curl localhost:32122/healthz 1 Service Endpoints found On a different node you might get a different result: # Run this locally on a node you choose curl localhost:32122/healthz No Service Endpoints Found A controller running on the [control plane](https://kubernetes.io/docs/reference/glossary/?all=true#term-control-plane "The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.") is responsible for allocating the cloud load balancer. The same controller also allocates HTTP health checks pointing to this port/path on each node. Wait about 10 seconds for the 2 nodes without endpoints to fail health checks, then use `curl` to query the IPv4 address of the load balancer: curl 203.0.113.140 The output is similar to this: CLIENT VALUES: client_address=198.51.100.79 ... Cross-platform support ---------------------- Only some cloud providers offer support for source IP preservation through Services with `Type=LoadBalancer`. The cloud provider you're running on might fulfill the request for a loadbalancer in a few different ways: 1. With a proxy that terminates the client connection and opens a new connection to your nodes/endpoints. In such cases the source IP will always be that of the cloud LB, not that of the client. 2. With a packet forwarder, such that requests from the client sent to the loadbalancer VIP end up at the node with the source IP of the client, not an intermediate proxy. Load balancers in the first category must use an agreed upon protocol between the loadbalancer and backend to communicate the true client IP such as the HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2) or [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) headers, or the [proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) . Load balancers in the second category can leverage the feature described above by creating an HTTP health check pointing at the port stored in the `service.spec.healthCheckNodePort` field on the Service. Cleaning up ----------- Delete the Services: kubectl delete svc -l app=source-ip-app Delete the Deployment, ReplicaSet and Pod: kubectl delete deployment source-ip-app What's next ----------- * Learn more about [connecting applications via services](https://kubernetes.io/docs/tutorials/services/connect-applications-service/) * Read how to [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) 3 - Explore Termination Behavior for Pods And Their Endpoints ============================================================= Once you connected your Application with Service following steps like those outlined in [Connecting Applications with Services](https://kubernetes.io/docs/tutorials/services/connect-applications-service/) , you have a continuously running, replicated application, that is exposed on a network. This tutorial helps you look at the termination flow for Pods and to explore ways to implement graceful connection draining. Termination process for Pods and their endpoints ------------------------------------------------ There are often cases when you need to terminate a Pod - be it to upgrade or scale down. In order to improve application availability, it may be important to implement a proper active connections draining. This tutorial explains the flow of Pod termination in connection with the corresponding endpoint state and removal by using a simple nginx web server to demonstrate the concept. Example flow with endpoint termination -------------------------------------- The following is the example flow described in the [Termination of Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) document. Let's say you have a Deployment containing a single `nginx` replica (say just for the sake of demonstration purposes) and a Service: [`service/pod-with-graceful-termination.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/pod-with-graceful-termination.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/pod-with-graceful-termination.yaml to clipboard") apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: terminationGracePeriodSeconds: 120 # extra long grace period containers: - name: nginx image: nginx:latest ports: - containerPort: 80 lifecycle: preStop: exec: # Real life termination may take any time up to terminationGracePeriodSeconds. # In this example - just hang around for at least the duration of terminationGracePeriodSeconds, # at 120 seconds container will be forcibly terminated. # Note, all this time nginx will keep processing requests. command: [\ "/bin/sh", "-c", "sleep 180"\ ] [`service/explore-graceful-termination-nginx.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/service/explore-graceful-termination-nginx.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy service/explore-graceful-termination-nginx.yaml to clipboard") apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 Now create the Deployment Pod and Service using the above files: kubectl apply -f pod-with-graceful-termination.yaml kubectl apply -f explore-graceful-termination-nginx.yaml Once the Pod and Service are running, you can get the name of any associated EndpointSlices: kubectl get endpointslice The output is similar to this: NAME ADDRESSTYPE PORTS ENDPOINTS AGE nginx-service-6tjbr IPv4 80 10.12.1.199,10.12.1.201 22m You can see its status, and validate that there is one endpoint registered: kubectl get endpointslices -o json -l kubernetes.io/service-name=nginx-service The output is similar to this: { "addressType": "IPv4", "apiVersion": "discovery.k8s.io/v1", "endpoints": [\ {\ "addresses": [\ "10.12.1.201"\ ],\ "conditions": {\ "ready": true,\ "serving": true,\ "terminating": false\ \ \ Now let's terminate the Pod and validate that the Pod is being terminated respecting the graceful termination period configuration:\ \ kubectl delete pod nginx-deployment-7768647bf9-b4b9s\ \ \ All pods:\ \ kubectl get pods\ \ \ The output is similar to this:\ \ NAME READY STATUS RESTARTS AGE\ nginx-deployment-7768647bf9-b4b9s 1/1 Terminating 0 4m1s\ nginx-deployment-7768647bf9-rkxlw 1/1 Running 0 8s\ \ \ You can see that the new pod got scheduled.\ \ While the new endpoint is being created for the new Pod, the old endpoint is still around in the terminating state:\ \ kubectl get endpointslice -o json nginx-service-6tjbr\ \ \ The output is similar to this:\ \ {\ "addressType": "IPv4",\ "apiVersion": "discovery.k8s.io/v1",\ "endpoints": [\ {\ "addresses": [\ "10.12.1.201"\ ],\ "conditions": {\ "ready": false,\ "serving": true,\ "terminating": true\ },\ "nodeName": "gke-main-default-pool-dca1511c-d17b",\ "targetRef": {\ "kind": "Pod",\ "name": "nginx-deployment-7768647bf9-b4b9s",\ "namespace": "default",\ "uid": "66fa831c-7eb2-407f-bd2c-f96dfe841478"\ },\ "zone": "us-central1-c"\ },\ {\ "addresses": [\ "10.12.1.202"\ ],\ "conditions": {\ "ready": true,\ "serving": true,\ "terminating": false\ },\ "nodeName": "gke-main-default-pool-dca1511c-d17b",\ "targetRef": {\ "kind": "Pod",\ "name": "nginx-deployment-7768647bf9-rkxlw",\ "namespace": "default",\ "uid": "722b1cbe-dcd7-4ed4-8928-4a4d0e2bbe35"\ },\ "zone": "us-central1-c"\ \ \ This allows applications to communicate their state during termination and clients (such as load balancers) to implement connection draining functionality. These clients may detect terminating endpoints and implement a special logic for them.\ \ In Kubernetes, endpoints that are terminating always have their `ready` status set as `false`. This needs to happen for backward compatibility, so existing load balancers will not use it for regular traffic. If traffic draining on terminating pod is needed, the actual readiness can be checked as a condition `serving`.\ \ When Pod is deleted, the old endpoint will also be deleted.\ \ What's next\ -----------\ \ * Learn how to [Connect Applications with Services](https://kubernetes.io/docs/tutorials/services/connect-applications-service/)\ \ * Learn more about [Using a Service to Access an Application in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/)\ \ * Learn more about [Connecting a Front End to a Back End Using a Service](https://kubernetes.io/docs/tasks/access-application-cluster/connecting-frontend-backend/)\ \ * Learn more about [Creating an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) --- # Gestionar y ejecutar aplicaciones | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/tasks/run-application/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/tasks/run-application/) . Gestionar y ejecutar aplicaciones ================================= * 1: [Corre una aplicación stateless usando un Deployment](https://kubernetes.io/es/docs/tasks/run-application/_print/#pg-790ea02857492b3a822e981e93e3a98b) * 2: [Escalar un StatefulSet](https://kubernetes.io/es/docs/tasks/run-application/_print/#pg-7a9b5779e228083ba3fdeaf414fe704e) * 3: [Borrar un StatefulSet](https://kubernetes.io/es/docs/tasks/run-application/_print/#pg-c43537b0ee1da992ecb7488f87e6c934) * 4: [Eliminación Forzosa de Pods de StatefulSet](https://kubernetes.io/es/docs/tasks/run-application/_print/#pg-f5f2f7a74377a9d45325c5253353fa8f) * 5: [Especificando un presupuesto de disrupción para tu aplicación](https://kubernetes.io/es/docs/tasks/run-application/_print/#pg-fbe2744f00d1aa4df4cdf4eea6a082d4) * 6: [Accediendo a la API de Kubernetes desde un Pod](https://kubernetes.io/es/docs/tasks/run-application/_print/#pg-52cd10ee3fc7c74a6c31043a2d489878) 1 - Corre una aplicación stateless usando un Deployment ======================================================= Ésta página enseña como correr una aplicación stateless usando un `deployment` de Kubernetes. Objetivos --------- * Crear un `deployment` de nginx. * Usar kubectl para obtener información acerca del `deployment`. * Actualizar el `deployment`. Antes de empezar ---------------- Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos `kubectl` debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando [Minikube](https://kubernetes.io/docs/setup/minikube) , o puedes utilizar una de las siguientes herramientas en línea: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) * [Play with Kubernetes](https://labs.play-with-k8s.com/) Su versión de Kubernetes debe ser como mínimo v1.9. Para comprobar la versión, introduzca `kubectl version`. Creando y explorando un nginx deployment ---------------------------------------- Puedes correr una aplicación creando un `deployment` de Kubernetes, y puedes describir el `deployment` en un fichero YAML. Por ejemplo, el siguiente fichero YAML describe un `deployment` que corre la imágen Docker nginx:1.7.9: [`application/deployment.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/es/examples/application/deployment.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy application/deployment.yaml to clipboard") apiVersion: apps/v1 # Usa apps/v1beta2 para versiones anteriores a 1.9.0 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 # indica al controlador que ejecute 2 pods template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 1. Crea un `deployment` basado en el fichero YAML: kubectl apply -f https://k8s.io/examples/application/deployment.yaml 2. Obtén información acerca del `deployment`: kubectl describe deployment nginx-deployment El resultado es similar a esto: Name: nginx-deployment Namespace: default CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700 Labels: app=nginx Annotations: deployment.kubernetes.io/revision=1 Selector: app=nginx Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 1 max unavailable, 1 max surge Pod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.7.9 Port: 80/TCP Environment: Mounts: Volumes: Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created) No events. 3. Lista los pods creados por el `deployment`: kubectl get pods -l app=nginx El resultado es similar a esto: NAME READY STATUS RESTARTS AGE nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h nginx-deployment-1771418926-r18az 1/1 Running 0 16h 4. Muestra información acerca del pod: kubectl describe pod donde `` es el nombre de uno de los pods. Actualizando el deployment -------------------------- Puedes actualizar el `deployment` aplicando un nuevo fichero YAML. El siguiente fichero YAML especifica que el `deployment` debería ser actualizado para usar nginx 1.8. [`application/deployment-update.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/es/examples/application/deployment-update.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy application/deployment-update.yaml to clipboard") apiVersion: apps/v1 # Usa apps/v1beta2 para versiones anteriores a 1.9.0 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.8 # Actualiza la versión de nginx de 1.7.9 a 1.8 ports: - containerPort: 80 1. Aplica el nuevo fichero YAML: kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml 2. Comprueba como el `deployment` crea nuevos pods con la nueva imagen mientras va eliminando los pods con la especificación antigua: kubectl get pods -l app=nginx Escalando la aplicación aumentado el número de replicas ------------------------------------------------------- Puedes aumentar el número de pods en tu `deployment` aplicando un nuevo fichero YAML. El siguiente fichero YAML especifica un total de 4 `replicas`, lo que significa que el `deployment` debería tener cuatro pods: [`application/deployment-scale.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/es/examples/application/deployment-scale.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy application/deployment-scale.yaml to clipboard") apiVersion: apps/v1 # Usa apps/v1beta2 para versiones anteriores a 1.9.0 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 4 # Actualiza el número de réplicas de 2 a 4 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.8 ports: - containerPort: 80 1. Aplica el nuevo fichero YAML: kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml 2. Verifica que el `deployment` tiene cuatro pods: kubectl get pods -l app=nginx El resultado es similar a esto: NAME READY STATUS RESTARTS AGE nginx-deployment-148880595-4zdqq 1/1 Running 0 25s nginx-deployment-148880595-6zgi1 1/1 Running 0 25s nginx-deployment-148880595-fxcez 1/1 Running 0 2m nginx-deployment-148880595-rwovn 1/1 Running 0 2m Eliminando un deployment ------------------------ Elimina el `deployment` por el nombre: kubectl delete deployment nginx-deployment ReplicationControllers ---------------------- La manera preferida de crear una aplicación con múltiples instancias es usando un Deployment, el cual usa un ReplicaSet. Antes de que Deployment y ReplicaSet fueran introducidos en Kubernetes, aplicaciones con múltiples instancias eran configuradas usando un [ReplicationController](https://kubernetes.io/es/docs/concepts/workloads/controllers/replicationcontroller/) . Siguientes pasos ---------------- * Aprende más acerca de [Deployments](https://kubernetes.io/es/docs/concepts/workloads/controllers/deployment/) . 2 - Escalar un StatefulSet ========================== Esta página muestra cómo escalar un StatefulSet. Escalar un StatefulSet es incrementar o decrementar el número de réplicas. Antes de empezar ---------------- * Los StatefulSets están solamente disponibles en Kubernetes 1.5 o posterior. Para verificar su versión de Kubernetes puede ejecutar `kubectl version`. * No todas las aplicaciones que manejan estados escalan correctamente. Si no está seguro sobre si puede escalar sus StatefulSets, visite los [conceptos de StatefulSet](https://kubernetes.io/docs/es/concepts/workloads/controllers/statefulset/) o el [tutorial sobre StatefulSet](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/) para más información. * Solamente se debe realizar un escalamiento cuando esté lo suficientemente seguro del buen funcionamiento de su clúster y de las aplicaciones que manejan estados. Escalando StatefulSets ---------------------- ### Uso de kubectl para escalar StatefulSets Como primer paso, identifica el StatefulSet que deseas escalar. kubectl get statefulsets Cambia el número de réplicas de tu StatefulSet: kubectl scale statefulsets --replicas= ### Hacer actualizaciones "in-place" en los StatefulSets De manera alternativa, se pueden hacer [actualizaciones in-place](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) en tus StatefulSets. Si el StatefulSet fue inicialmente creado con `kubectl apply`, puedes actualizar `.spec.replicas` en el manifiesto previamente definido y ahí hacer `kubectl apply`: kubectl apply -f De otra manera, edita esa línea con `kubectl edit`: kubectl edit statefulsets También puedes usar `kubectl patch`: kubectl patch statefulsets -p '{"spec":{"replicas":}}' Solución de Problemas --------------------- ### El escalamiento hacia abajo no funciona correctamente No se puede escalar hacia abajo un StatefulSet cuando alguno de los Pods que administra está dañado. Desescalar solo tiene lugar después de tener los Pods disponibles. Si spec.replicas > 1, Kubernetes no puede determinar la razón de un Pod dañado. Esto puede ser el resultado de una falla permanente o una falla transitoria. Una falla transitoria puede ser causada por un reinicio necesario para una actualización o mantenimiento. Si el Pod está dañado con una falla permanente, escalar sin corregir la falla puede llevarnos a un estado donde el StatefulSet cae en una cantidad de miembros inferior a la cantidad de replicas que son necesarias para funcionar correctamente. Esto puede causar que el StatefulSet no este disponible. Si el Pod está dañado por una falla transitoria y el Pod puede volver a estar disponible nuevamente, el error transitorio puede interferir con la operación de escalar. Algunas bases de datos distribuidas tienen errores cuando los nodos se unen y abandonan en el mismo momento. Es mejor analizar acerca de escalar la operación a nivel de la aplicación y realizar el escalamiento solamente cuando está seguro que el clúster de la aplicación está funcionando y en buen estado. Siguientes pasos ---------------- * Aprenda más acerca de [borrar un StatefulSet](https://kubernetes.io/es/docs/tasks/run-application/delete-stateful-set/) . 3 - Borrar un StatefulSet ========================= Esta página muestra cómo se debe eliminar un [StatefulSet](https://kubernetes.io/es/docs/concepts/workloads/controllers/statefulset/ "Gestiona el despliegue y escalado de un conjunto de Pods, y garantiza el orden y unicidad de dichos Pods.") . Antes de empezar ---------------- * Se asume que se tiene una aplicación del tipo StatefulSet corriendo en tu clúster. Borrando un StatefulSet ----------------------- Se puede eliminar un StatefulSet de la misma manera que se eliminan el resto de los recursos en Kubernetes: Usa el comando `kubectl delete` y especifica el StatefulSet, usando su nombre o el archivo con el que fue creado. kubectl delete -f kubectl delete statefulsets Puede suceder que necesites eliminar los servicios headless asociados después de eliminar el StatefulSet. kubectl delete service Cuando se elimina un StatefulSet utilizando `kubectl`, el StatefulSet escala a 0. Todos los Pods que eran parte de esta carga de trabajo son eliminados. Si tú quieres eliminar solo el StatefulSet y no los Pods utiliza `--cascade=orphan`. Por ejemplo: kubectl delete -f --cascade=orphan Agregando `--cascade=orphan` al comando `kubectl delete`, los Pods administrados por el StatefulSet dejan de pertenecer al StatefulSet cuando es eliminado. Si los pods tienen una etiqueta `app.kubernetes.io/name=MyApp` se los puede eliminar de la siguiente manera: kubectl delete pods -l app.kubernetes.io/name=MyApp ### Volúmenes Persistentes Eliminar los Pods de un StatefulSet no va a eliminar los volúmenes asociados. Esto es para asegurar que se tiene una oportunidad de copiar los datos fuera del volumen antes de eliminarlo. Borrar el PVC después de que los pods estén terminados puede disparar la eliminación del Volumen Persistente que hay detrás dependiendo de la clase de almacenamiento y la política de reclamo. Nunca debes asumir la capacidad de acceder a un volumen después de la eliminación del claim. #### Nota: Ten cuidado al borrar un PVC ya que puede llevar una pérdida de datos. ### Eliminación completa de un StatefulSet Para eliminar todo en un StatefulSet, incluyendo los pods asociados, se puede correr una serie de comandos similares a los siguientes: grace=$(kubectl get pods --template '{{.spec.terminationGracePeriodSeconds}}') kubectl delete statefulset -l app.kubernetes.io/name=MyApp sleep $grace kubectl delete pvc -l app.kubernetes.io/name=MyApp En este ejemplo, los Pods tienen la etiqueta `app.kubernetes.io/name=MyApp`, sustituye la misma por tu propia etiqueta. ### Forzar la eliminación de los Pods de un StatefulSet Si encuentras algunos pods bloqueados en tu StatefulSet en el estado 'Terminating' o 'Unknown' por un largo período de tiempo, puede ser que necesites intervenir manualmente para forzar la eliminación de los pods del apiserver. Ésta es una tarea potencialmente riesgosa. Visita [Forzar eliminación de Pods en StatefulSet](https://kubernetes.io/es/docs/tasks/run-application/force-delete-stateful-set-pod/) para más detalles. Siguientes pasos ---------------- Aprende más sobre [Forzar eliminación de Pods en StatefulSet](https://kubernetes.io/es/docs/tasks/run-application/force-delete-stateful-set-pod/) . 4 - Eliminación Forzosa de Pods de StatefulSet ============================================== Esta página muestra cómo eliminar Pods que son parte de un [StatefulSet](https://kubernetes.io/es/docs/concepts/workloads/controllers/statefulset/ "Gestiona el despliegue y escalado de un conjunto de Pods, y garantiza el orden y unicidad de dichos Pods.") , y explica las consideraciones a tener en cuenta al hacerlo. Antes de empezar ---------------- * Esta es una tarea bastante avanzada y tiene el potencial de violar algunas de las propiedades inherentes de StatefulSet. * Antes de proceder, familiarízate con las consideraciones enumeradas a continuación. Consideraciones de StatefulSet ------------------------------ En la operación normal de un StatefulSet, **nunca** hay necesidad de eliminar forzosamente un Pod de StatefulSet. El [controlador de StatefulSet](https://kubernetes.io/es/docs/concepts/workloads/controllers/statefulset/) es responsable de crear, escalar y eliminar miembros del StatefulSet. Intenta asegurar que el número especificado de Pods, desde el ordinal 0 hasta N-1, estén vivos y listos. StatefulSet asegura que, en cualquier momento, exista como máximo un Pod con una identidad dada, corriendo en un clúster. Esto se refiere a la semántica de _como máximo uno_ proporcionada por un StatefulSet. La eliminación manual forzada debe realizarse con precaución, ya que tiene el potencial de violar la semántica de como máximo uno, inherente a StatefulSet. Los StatefulSets pueden usarse para ejecutar aplicaciones distribuidas y agrupadas que necesitan una identidad de red estable y almacenamiento estable. Estas aplicaciones a menudo tienen configuraciones que dependen de un conjunto de un número fijo de miembros con identidades fijas. Tener múltiples miembros con la misma identidad puede ser desastroso y puede llevar a pérdida de datos (por ejemplo, escenario de cerebro dividido en sistemas basados en quórum). Eliminar Pods ------------- Puedes realizar una eliminación de Pod paulatina con el siguiente comando: kubectl delete pods Para que lo anterior conduzca a una terminación paulatina, el Pod no debe especificar un `pod.Spec.TerminationGracePeriodSeconds` de 0. La práctica de establecer un `pod.Spec.TerminationGracePeriodSeconds` de 0 segundos es insegura y se desaconseja rotundamente para los Pods de StatefulSet. La eliminación paulatina es segura y garantizará que el Pod se apague de [manera paulatina](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) , antes de que kubelet elimine el nombre en el apiserver. Un Pod no se elimina automáticamente cuando un nodo no es accesible. Los Pods que se ejecutan en un Nodo inaccesible entran en el estado 'Terminating' o 'Unknown' después de un [tiempo de espera](https://kubernetes.io/es/docs/tasks/run-application/_print/es/docs/concepts/architecture/nodes/#Estados) . Los Pods también pueden entrar en estos estados cuando el usuario intenta la eliminación paulatina de un Pod en un nodo inaccesible. Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes: * El objeto Node es eliminado (ya sea por ti, o por el [Controlador de Nodo](https://kubernetes.io/es/docs/concepts/architecture/nodes/#controlador-de-nodos) ).). * Kubelet, en el nodo no responsivo, comienza a responder, mata el Pod y elimina la entrada del apiserver. * Eliminación forzada del Pod por el usuario. La mejor práctica recomendada es usar el primer o segundo enfoque. Si un nodo está confirmado como muerto (por ejemplo, desconectado permanentemente de la red, apagado, etc.), entonces elimina el objeto Node. Si el nodo es afectado de una partición de red, entonces trata de resolver esto o espera a que se resuelva. Cuando la partición se solucione, kubelet completará la eliminación del Pod y liberará su nombre en el apiserver. Normalmente, el sistema completa la eliminación una vez que el Pod ya no se está ejecutando en un nodo, o el nodo es eliminado por un administrador. Puedes anular esto forzando la eliminación del Pod. ### Eliminación Forzosa Las eliminaciones forzosas **no** esperan confirmación de kubelet de que el Pod ha sido terminado. Independientemente de si una eliminación forzosa tiene éxito en matar un Pod, inmediatamente liberará el nombre del apiserver. Esto permitiría que el controlador de StatefulSet cree un Pod de reemplazo con esa misma identidad; esto puede llevar a la duplicación de un Pod que aún está en ejecución, y si dicho Pod todavía puede comunicarse con los otros miembros del StatefulSet, violará la semántica de como máximo uno que StatefulSet está diseñado para garantizar. Cuando eliminas forzosamente un Pod de StatefulSet, estás afirmando que el Pod en cuestión nunca volverá a hacer contacto con otros Pods en el StatefulSet y su nombre puede ser liberado de forma segura para que se cree un reemplazo. Si quieres eliminar un Pod de forma forzosa usando la versión de kubectl >= 1.5, haz lo siguiente: kubectl delete pods --grace-period=0 --force Si estás usando cualquier versión de kubectl <= 1.4, deberías omitir la opción `--force` y usar: kubectl delete pods --grace-period=0 Si incluso después de estos comandos el pod está atascado en el estado `Unknown`, usa el siguiente comando para eliminar el Pod del clúster: kubectl patch pod -p '{"metadata":{"finalizers":null}}' Siempre realiza la eliminación forzosa de Pods de StatefulSet con cuidado y con pleno conocimiento de los riesgos involucrados. Siguientes pasos ---------------- Aprende más sobre [depurar un StatefulSet](https://kubernetes.io/docs/tasks/debug/debug-application/debug-statefulset/) . 5 - Especificando un presupuesto de disrupción para tu aplicación ================================================================= Ésta pagina enseña como limitar el numero de disrupciones concurrentes que afectan a tu aplicación definiendo presupuestos de disrupción de pods, Pod Disruption Budgets (PDB) en inglés. Estos presupuestos definen el mínimo número de pods que deben estar ejecutándose en todo momento para asegurar la disponibilidad de la aplicación durante operaciones de mantenimiento efectuadas sobre los nodos por los administradores del cluster. Antes de empezar ---------------- * Tener permisos de administrador sobre la aplicación que esta corriendo en Kubernetes y requiere alta disponibilidad * Deberías saber como desplegar [Múltiples réplicas de aplicaciones stateless](https://kubernetes.io/es/docs/tasks/run-application/run-stateless-application-deployment/) y/o [Múltiples réplicas de aplicaciones stateful](https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/) . * Deberías haber leido acerca de [Disrupciones de un Pod](https://kubernetes.io/es/docs/concepts/workloads/pods/disruptions/) . * Deberías confirmar con el propietario del cluster o proveedor de servicio que respetan Presupuestos de Disrupción para Pods. Protegiendo una aplicación con un PodDisruptionBudget ----------------------------------------------------- 1. Identifica la aplicación que quieres proteger con un PodDisruptionBudget (PDB). 2. Revisa como afectan las disrupciones a tú aplicación. 3. Crea un PDB usando un archivo YAML. 4. Crea el objecto PDB desde el archivo YAML. Identifica la applicación que quieres proteger ---------------------------------------------- El caso más común es proteger aplicaciones que usan uno de los controladores incorporados en Kubernetes: * Deployment * Replicationcontrolador * ReplicaSet * StatefulSet En este caso, toma nota del `.spec.selector` que utiliza el controlador; el mismo se utilizará en el `spec.selector` del PDB. También puedes utilizar PDBs para proteger pods que no estan gestionados por uno de los controladores listados arriba, o agrupaciones arbitrarias de pods, con algunas restricciones descritas en [Controladores Arbitrarios y Selectors](https://kubernetes.io/es/docs/tasks/run-application/_print/#arbitrary-controladores-and-selectors) . Revisa como afectan las disrupciones a tú aplicación ---------------------------------------------------- Decide cuántas instancias de tu aplicación pueden estar fuera de servicio al mismo tiempo debido a disrupciones voluntarias de corto plazo. * Frontend stateless: * Objetivo: evitar reducir capacidad para servir por mas de 10%. * Solución: usar un PDB que especifica minAvailable 90%. * Aplicación Stateful con una sola instancia: * Objetivo: no terminar esta aplicación sin primero confirmar conmigo. * Posible Solución 1: No usar un PDB y tolerar inactividad ocasional. * Posible Solución 2: Crea un PDB con maxUnavailable=0. Entiende que el operador del cluster debe consultar contigo antes de terminar tu aplicación. Cuando el operador te contacte, prepara tu aplicación para downtime y elimina el PDB para indicar que estas preparado para la disrupción. Crea el PDB de nuevo al terminar la disrupción. * Aplicación Stateful con múltiples instancias como Consul, ZooKeeper, etcd, Redis o MySQL: * Objetivo: no reducir el numero de instancias por debajo del quorum, de lo contrario, las escrituras fallarían. * Posible Solución 1: fijar maxUnavailable a 1 (funciona con diferentes escalas de aplicación). * Posible Solución 2: fijar minAvailable al tamaño del quorum (e.g. 3 cuando hay un total de 5 instancias). (Permite mas disrupciones a la vez.). * Trabajos por lote reiniciables: * Objetivo: El trabajo debe completarse en caso de una interrupción voluntaria. * Posible solución: No cree un PDB. El controlador de Jobs creará un pod de reemplazo. Especificando un PodDisruptionBudget ------------------------------------ Un `PodDisruptionBudget` tiene tres atributos: * Un label selector `.spec.selector` para especificar el grupo de pods donde aplicar el presupuesto. Este campo es requerido. * `.spec.minAvailable` que es una descripción del número de pods del grupo que deben estar disponibles después del desalojo, incluso en ausencia del pod desalojado. `minAvailable` puede ser un número absoluto o un porcentaje. * `.spec.maxUnavailable` (disponible en Kubernetes 1.7 y superior) que es una descripción del numero de pods del grupo que pueden estar indisponibles despues del desalojo. Puede ser un número absoluto o un porcentaje. #### Nota: Para las versiones 1.8 y anteriores: al crear un `PodDisruptionBudget` utilizando la herramienta de línea de comandos `kubectl`, el campo `minAvailable` es 1 por defecto si no se especifica `minAvailable` ni `maxUnavailable`. Puedes especificar únicamente un valor para `maxUnavailable` y `minAvailable` por `PodDisruptionBudget`. `maxUnavailable` solo se puede usar para controlar el desalojo de pods que tienen un controlador asociado manejándolos. En los ejemplos a continuación, "réplicas deseadas" hace referencia al valor 'scale' del controlador que gestiona el grupo de pods seleccionados por el `PodDisruptionBudget`. Ejemplo 1: Con un `minAvailable` de 5, se permiten los desalojos siempre que dejen 5 o más pods disponibles entre las seleccionadas por el `selector` del PodDisruptionBudget. Ejemplo 2: Con un `minAvailable` del 30%, se permiten los desalojos mientras que al menos 30% de la cantidad de réplicas se mantengan disponibles. Ejemplo 3: Con un `maxUnavailable` de 5, se permiten desalojos siempre que haya como máximo 5 réplicas indisponibles entre el número total de réplicas deseadas. Ejemplo 4: Con un `maxUnavailable` de 30%, se permiten los desalojos siempre y cuando no más del 30% de las réplicas esten indisponibles. En el uso típico, se usaría un solo presupuesto para una colección de pods administrados por un controlador, por ejemplo, los pods en un solo ReplicaSet o StatefulSet. #### Nota: Un presupuesto de disrupción no garantiza que el número/porcentaje de pods especificado siempre estarán disponibles. Por ejemplo, un nodo que alberga un pod del grupo puede fallar cuando el grupo está en el tamaño mínimo especificados en el presupuesto, lo que hace que el número de pods disponibles este por debajo del tamaño especificado. El presupuesto solo puede proteger contra desalojos voluntarios, pero no todas las causas de indisponibilidad. Un `maxUnavailable` de 0% (o 0) o un `minAvailable` de 100% (o igual al número de réplicas) puede prevenir que los nodos sean purgados completamente. Esto está permitido según la semántica de `PodDisruptionBudget`. Puedes encontrar ejemplos de presupuestos de disrupción de pods definidas a continuación. Los ejemplos aplican al grupo de pods que tienen la etiqueta `app: zookeeper`. Ejemplo de PDB usando minAvailable: apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: minAvailable: 2 selector: matchLabels: app: zookeeper Ejemplo de PDB usando maxUnavailable (Kubernetes 1.7 o superior): apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: maxUnavailable: 1 selector: matchLabels: app: zookeeper Por ejemplo, si el objeto anterior `zk-pdb` selecciona los pods de un StatefulSet de tamaño 3, ambas especificaciones tienen el mismo significado exacto. Se recomienda el uso de `maxUnavailable` ya que responde automáticamente a los cambios en el número de réplicas del controlador correspondiente. Crea el objeto PDB ------------------ Puedes crear el objeto PDB con el comando `kubectl apply -f mypdb.yaml`. No puedes actualizar objetos PDB. Deben ser eliminados y recreados. Comprueba el estado del PDB --------------------------- Utiliza kubectl para comprobar que se ha creado tu PDB. Suponiendo que en realidad no tengas pods que coincidan con `app: zookeeper` en su namespace, entonces verás algo como esto: kubectl get poddisruptionbudgets NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE zk-pdb 2 0 7s Si hay pods que coinciden (por ejemplo, 3), entonces debes ver algo similar a esto: kubectl get poddisruptionbudgets NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE zk-pdb 2 1 7s El valor distinto a cero de `ALLOWED-DISRUPTIONS` significa que el controlador de disrupción ha visto los pods, contó los pods coincidentes, y actualizó el estado del PDB. Puedes obtener más información sobre el estado de un PDB con este comando: kubectl get poddisruptionbudgets zk-pdb -o yaml apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: creationTimestamp: 2017-08-28T02:38:26Z generation: 1 name: zk-pdb ... status: currentHealthy: 3 desiredHealthy: 3 disruptedPods: null disruptionsAllowed: 1 expectedPods: 3 observedGeneration: 1 Por último, los PodDisruptionBudgets también se pueden consultar con kubectl utilizando el nombre corto pdb: kubectl get pdb NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE zk-pdb 2 0 7s Controladores y selectors arbitrarios ------------------------------------- Puedes omitir esta sección si solo utilizas PDBs con los controladores integrados de aplicaciones (Deployment, Replicationcontrolador, ReplicaSet y StatefulSet), con el selector de PDB coincidiendo con el selector del controlador. Puedes utilizar un PDB con pods controlados por otro tipo de controlador, por un "Operator", o pods individuales, pero con las siguientes restricciones: * solo puedes usar `.spec.minAvailable`, no `.spec.maxUnavailable`. * solo puedes usar un número entero en `.spec.minAvailable`, no un porcentaje. Puedes usar un selector que selecciona un subconjunto o superconjunto de los pods que pertenecen a un controlador incorporado. Sin embargo, cuando hay varios PDB en un namespace, debes tener cuidado de no crear PDBs cuyos selectores se superponen. 6 - Accediendo a la API de Kubernetes desde un Pod ================================================== Esta guía muestra como acceder a la API de Kubernetes desde de un Pod. Antes de empezar ---------------- Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos `kubectl` debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando [Minikube](https://kubernetes.io/docs/setup/minikube) , o puedes utilizar una de las siguientes herramientas en línea: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) * [Play with Kubernetes](https://labs.play-with-k8s.com/) Accediendo a la API desde un Pod -------------------------------- El acceder a la API desde un Pod, la ubicacion y autentication del servidor de la API es ligeramente diferente que en el caso de un cliente externo. La forma más fácil de usar la API de Kubernetes desde un Pod es utilizando una de las bibliotecas de [cliente oficiales](https://kubernetes.io/docs/reference/using-api/client-libraries/) . Estas bibliotecas pueden automáticamente descubrir el servidor de la API y autenticarse. ### Usando Bibliotecas de Cliente Oficiales Desde un Pod, las formas recomendadas de conectarse a la API de Kubernetes son: * Para un cliente de Go, utilice la [biblioteca oficial del cliente de Go](https://github.com/kubernetes/client-go/) . La función `rest.InClusterConfig()` maneja automáticamente el descubrimiento del host de la API y la autenticación. Vea [un ejemplo aqui](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) . * Para un cliente de Python, utilice la [biblioteca oficial del cliente de Python](https://github.com/kubernetes-client/python/) . La función `config.load_incluster_config()` maneja automáticamente el descubrimiento del host de la API y la autenticación. Vea [un ejemplo aqui](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py) . * Existen varias bibliotecas disponibles, por favor consulte la página de [Bibliotecas de Clientes](https://kubernetes.io/docs/reference/using-api/client-libraries/) . En cada caso, las credenciales de la cuenta de servicio del Pod se utilizan para comunicarse de manera segura con el servidor de la API. ### Accediendo directamente a la API REST Al ejecutarse en un Pod, su contenedor puede crear una URL HTTPS para el servidor de la API de Kubernetes obteniendo las variables de entorno `KUBERNETES_SERVICE_HOST`y `KUBERNETES_SERVICE_PORT_HTTPS`. La dirección del servidor de la API dentro del clúster también se publica en un Servicio llamado `kubernetes` en el namespace `default`, de modo que los pods pueden hacer referencia a `kubernetes.default.svc` como el nombre DNS para el servidor de la API local. #### Nota: Kubernetes no garantiza que el servidor de API tenga un certificado válido para el nombre de host `kubernetes.default.svc`; Sin embargo, se espera que el plano de control presente un certificado válido para el nombre de host o la dirección IP que representa `$KUBERNETES_SERVICE_HOST` La forma recomendada para autenticarse con el servidor de la API es con una credencial de [cuenta de servicio](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) . Por defecto, un Pod esta asociado con una cuenta de servicio, esta asociado con una cuenta de servicio, y una credencial (token) para esa cuenta de servicio se coloca en el sistema de archivos de cada contenedor en ese Pod en la ruta `/var/run/secrets/kubernetes.io/serviceaccount/token`. Si está disponible, un paquete de certificados se coloca en el sistema de archivos de cada contenedor en la ruta `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, y debe usarse para verificar el certificado de servicio del servidor API. Finalmente, el Namespace default puede ser utilizado en las operaciones de API con ámbito de espacio de nombres que se colocan en un archivo con la ruta `/var/run/secrets/kubernetes.io/serviceaccount/namespace` de cada contenedor ### Usando kubectl proxy Si deseas consultar la API sin una biblioteca de cliente oficial, puedes ejecutar `kubectl proxy` como el [comando](https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/) de un nuevo contenedor sidecar en el Pod. De esta manera, `kubectl proxy` se autenticará en la API y la expondrá en la interfaz `localhost` del Pod, para que otros contenedores en el Pod puedan usarla directamente. ### Sin usar un proxy Es posible evitar el uso del proxy de kubectl pasando el token de autenticación directamente al servidor de la API. El certificado interno asegura la conexión. # Apuntar nombre de host del servidor API interno. APISERVER=https://kubernetes.default.svc # Ruta del token de ServiceAccount SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount # Lectura del Namespace del Pod NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace) # Lectura del bearer token del ServiceAccount TOKEN=$(cat ${SERVICEACCOUNT}/token) # Referencia a la autoridad de certificación interna (CA) CACERT=${SERVICEACCOUNT}/ca.crt # Explora la API con TOKEN curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api La salida será similar a esto: { "kind": "APIVersions", "versions": ["v1"], "serverAddressByClientCIDRs": [\ {\ "clientCIDR": "0.0.0.0/0",\ "serverAddress": "10.0.1.149:443"\ }\ ] } --- # Praktek-praktek Terbaik | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/id/docs/setup/best-practices/_print/#) . [Return to the regular view of this page](https://kubernetes.io/id/docs/setup/best-practices/) . Praktek-praktek Terbaik ======================= * 1: [Menjalankan klaster dalam beberapa zona](https://kubernetes.io/id/docs/setup/best-practices/_print/#pg-970615c97499e3651fd3a98e0387cefc) * 2: [Pertimbangan untuk klaster besar](https://kubernetes.io/id/docs/setup/best-practices/_print/#pg-c797ee17120176c685455db89ae091a9) * 3: [Validasi Pengaturan Node](https://kubernetes.io/id/docs/setup/best-practices/_print/#pg-f89867de1d34943f1524f67a241f5cc9) * 4: [Memberlakukan Standar Keamanan Pod](https://kubernetes.io/id/docs/setup/best-practices/_print/#pg-92a61cf5b0575aa3500f7665b68127d1) 1 - Menjalankan klaster dalam beberapa zona =========================================== Laman ini menjelaskan tentang bagaimana menjalankan sebuah klaster dalam beberapa zona. Pendahuluan ----------- Kubernetes 1.2 menambahkan dukungan untuk menjalankan sebuah klaster dalam beberapa zona kegagalan (_multiple failure zones_) (GCE secara sederhana menyebutnya sebagai _"zones"_, AWS menyebutnya sebagai _"availability zones"_, dan di sini kita akan menyebutnya sebagai "zona"). Fitur ini adalah versi sederhana dari fitur federasi klaster yang lebih luas (yang sebelumnya ditujukan pada sebuah nama panggilan yang ramah (_affectionate nickname_) ["Ubernetes"](https://github.com/kubernetes/community/blob/main/contributors/design-proposals/multicluster/federation.md) ). Federasi klaster yang penuh memungkinkan untuk menggabungkan klaster Kubernetes terpisah, yang berjalan pada wilayah atau penyedia cloud yang berbeda (baik dalam _datacenter_ atau _on-premise_). Namun banyak pengguna yang ingin menjalankan klaster Kubernetes dengan tingkat ketersediaan yang lebih, dalam beberapa zona dari satu penyedia cloud mereka, dan dukungan inilah yang akhirnya memperbolehkan fitur multi-zona dalam versi Kubernetes 1.2 (sebelumnya fitur ini dikenal dengan nama panggilan "Ubernetes Lite"). Dukungan multi-zona sengaja dibuat terbatas: dimana satu klaster Kubernetes hanya dapat berjalan dalam beberapa zona, tetapi hanya pada wilayah yang sama (dan penyedia cloud yang sama pula). Hanya GCE dan AWS yang saat ini mendukung fitur ini secara otomatis (meskipun cukup mudah untuk menambahkan dukungan serupa untuk penyedia cloud yang lain atau bahkan untuk perangkat _baremetal_, hanya dengan mengatur label yang sesuai untuk ditambahkan ke Node dan volume). Fungsionalitas -------------- Ketika Node mulai dijalankan, kubelet secara otomatis menambahkan label informasi pada Node tersebut. Kubernetes akan menyebarkan Pod secara otomatis dalam sebuah _controller_ replikasi atau Service lintas Node dalam sebuah klaster zona tunggal (untuk mengurangi dampak kegagalan). Dengan klaster multi-zona, perilaku penyebaran ini akan dilanjutkan hingga melintasi zona (untuk mengurangi dampak kegagalan dalam satu zona.) (Ini dicapai melalui opsi `SelectorSpreadPriority`). Hal tersebut adalah untuk upaya penempatan terbaik, apabila zona pada klaster kamu bersifat heterogen (mis. jumlah Node yang berbeda, tipe Node yang berbeda, atau persyaratan sumber daya Pod yag berbeda), yang akan mencegah dengan sempurna penyebaran Pod kamu untuk melintasi zona yang berbeda. Jika diinginkan, kamu bisa menggunakan zona yang homogen (jumlah dan jenis Node yang sama) untuk mengurangi probabilitas penyebaran yang tidak merata. Pada saat volume persisten dibuat, _controller_ penerima `PersistentVolumeLabel` akan secara otomatis menambahkan label zona pada volume tersebut. Penjadwal (melalui predikat `VolumeZonePredicate`) kemudian akan memastikan bahwa Pod yang mengklaim suatu volume hanya akan ditempatkan pada zona yang sama dengan volume tersebut, karena volume tidak dapat di-_attach_ melintasi zona yang berbeda. Batasan ------- Ada beberapa batasan penting dari dukungan multi-zona: * Kami berasumsi bahwa zona yang berbeda terletak secara berdekatan satu sama lain dalam jaringan, jadi kami tidak melakukan _routing_ yang sadar akan zona. Secara khusus, lalu lintas (_traffic_) yang berjalan melalui Service mungkin melintasi beberapa zona (bahkan ketika beberapa Pod yang mendukung Service itu berada pada zona yang sama dengan klien), dan hal ini dapat menimbulkan latensi dan biaya tambahan. * Volume _zone-afinity_ hanya akan bekerja dengan PersistentVolume, dan tidak akan berfungsi apabila kamu secara langsung menentukan volume EBS dalam spesifikasi Pod (misalnya). * Klaster tidak dapat melebarkan jangkauan cloud atau _region_ (fungsi ini akan membutuhkan dukungan penuh federasi). * Meskipun Node kamu berada dalam beberapa zona, saat ini kube-up hanya membuat satu Node master secara bawaan (_default_). Karena Service memerlukan ketersediaan (_availability_) yang tinggi dan dapat mentolerir akan hilangnya sebuah zona, maka _control plane_ diletakkan pada setiap zona. Pengguna yang menginginkan _control plane_ yang memiliki ketersediaan tinggi harus mengikuti instruksi [ketersediaan tinggi](https://kubernetes.io/docs/admin/high-availability) . ### Batasan Volume Batasan berikut ditunjukkan dengan menggunakan [pengikatan volume yang sadar topologi](https://kubernetes.io/id/docs/concepts/storage/storage-classes/#mode-volume-_binding_) . * Penyebaran zona volume StatefulSet yang menggunakan penyediaan secara dinamis, saat ini tidak sesuai dengan kebijakan afinitas atau anti-afinitas Pod. * Jika nama StatefulSet berisi tanda hubung ("-"), maka penyebaran zona volume mungkin saja tidak menyediakan distribusi penyimpanan (_storage_) yang seragam di seluruh zona yang berbeda. * Ketika menentukan beberapa PVC dalam spesifikasi Deployment atau Pod, StorageClass perlu dikonfigurasi untuk zona tunggal tertentu, atau PV perlu disediakan secara statis pada zona tertentu. Solusi lainnya adalah menggunakan sebuah StatefulSet, yang akan memastikan bahwa semua volume untuk sebuah replika disediakan dalam zona yang sama. Panduan ------- Kita sekarang akan berjalan melalui pengaturan dan menggunakan multi-zona klaster pada GCE & AWS. Untuk melakukannya, kamu perlu mengaktifkan klaster penuh (dengan menentukan `MULTIZONE=true`), dan kemudian kamu menambahkan Node di zona tambahan dengan menjalankan `kube-up` lagi (dengan menetapkan opsi `KUBE_USE_EXISTING_MASTER=true`). ### Mengaktifkan klaster kamu Buatlah klaster seperti biasa, tetapi teruskan opsi MULTIZONE untuk memberi tahu klaster untuk mengelola beberapa zona; dan membuat Node di zona us-central1-a. GCE: curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash AWS: curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash Langkah ini akan mengaktifkan klaster seperti biasa, namun masih berjalan dalam satu zona (tetapi opsi `MULTIZONE=true` telah mengaktifkan kapabilitas multi-zona). ### Node yang telah diberi label Lihatlah Node; dimana kamu bisa melihat Node tersebut diberi label sesuai dengan informasi zona. Node tersebut sejauh ini berada di zona `us-central1-a` (GCE) atau zona `us-west-2a` (AWS). Label dari Node itu adalah `failure-domain.beta.kubernetes.io/region` untuk informasi wilayah, dan `failure-domain.beta.kubernetes.io/zone` untuk informasi zona: kubectl get nodes --show-labels Tampilan akan seperti dibawah ini: NAME STATUS ROLES AGE VERSION LABELS kubernetes-master Ready,SchedulingDisabled 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master kubernetes-minion-87j9 Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 kubernetes-minion-9vlv Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv kubernetes-minion-a12q Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q ### Menambah lebih banyak Node di zona kedua Mari kita tambahkan sekumpulan Node ke dalam klaster yang ada, dengan menggunakan kembali master yang ada, namun dijalankan pada zona yang berbeda (zona `us-central1-b` atau zona `us-west-2b`). Kemudian kita jalankan kube-up lagi, tetapi dengan menentukan opsi `KUBE_USE_EXISTING_MASTER=true` sehingga kube-up tidak akan membuat master baru, tetapi akan menggunakan kembali master yang dibuat sebelumnya. GCE: KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh Pada AWS, kita juga perlu menentukan CIDR jaringan sebagai tambahan subnet, bersama dengan alamat IP internal dari master: KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh Lihat lagi Node; dimana 3 Node lainnya harus sudah dijalankan dan ditandai berada di `us-central1-b`: kubectl get nodes --show-labels Hasil tampilan akan terlihat seperti dibawah ini: NAME STATUS ROLES AGE VERSION LABELS kubernetes-master Ready,SchedulingDisabled 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master kubernetes-minion-281d Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d kubernetes-minion-87j9 Ready 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 kubernetes-minion-9vlv Ready 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv kubernetes-minion-a12q Ready 17m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q kubernetes-minion-pp2f Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f kubernetes-minion-wf8i Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i ### Afinitas Volume Buatlah sebuah volume dengan menggunakan pembuatan volume yang dinamis (hanya PersistentVolume yang didukung untuk afinitas zona): kubectl apply -f - < 34m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv kubernetes-minion-281d Ready 20m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d kubernetes-minion-olsh Ready 3m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh _Load-balancer_ menjangkau semua zona dalam satu klaster; program contoh guestbook-go sudah termasuk contoh Service dengan beban seimbang (_load-balanced service_): kubectl describe service guestbook | grep LoadBalancer.Ingress Hasil tampilan akan terlihat seperti di bawah ini: LoadBalancer Ingress: 130.211.126.21 Atur alamat IP di atas: export IP=130.211.126.21 Telusurilah dengan curl melalui alamat IP tersebut: curl -s http://${IP}:3000/env | grep HOSTNAME Hasil tampilan akan terlihat seperti di bawah ini: "HOSTNAME": "guestbook-44sep", Kemudian, telusurilah beberapa kali: (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq Hasil tampilan akan terlihat seperti dibawah ini: "HOSTNAME": "guestbook-44sep", "HOSTNAME": "guestbook-hum5n", "HOSTNAME": "guestbook-ppm40", _Load balancer_ telah menargetkan ke semua Pod dengan benar, meskipun semuanya berada di beberapa zona yang berbeda. ### Menghentikan Klaster ### Shutting down the cluster Apabila kamu sudah selesai, maka bersihkanlah: GCE: KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh AWS: KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh 2 - Pertimbangan untuk klaster besar ==================================== Klaster adalah kumpulan ([node](https://kubernetes.io/id/docs/concepts/architecture/nodes/ "A node is a worker machine in Kubernetes.") ) berupa mesin fisik ataupun virtual yang menjalankan agen Kubernetes, dan dikelola oleh [bidang kontrol](https://kubernetes.io/id/docs/reference/glossary/?all=true#term-control-plane "Merupakan lapisan orkestrasi Container yang mengekspos API dan antarmuka untuk mendefinisikan, menggelar, dan mengelola siklus hidup suatu Container.") . Kubernetes v1.35 mendukung klaster hingga 5000 _node_. Lebih tepatnya, Kubernetes didesain untuk mengakomodasi konfigurasi yang mendukung kriteria dibawah ini: * Jumlah pods tidak lebih dari 110 pods per _node_ * Jumlah _node_ tidak lebih dari 5000 * Total pods tidak lebih dari 150000 * Total kontainer tidak lebih dari 300000 Kamu dapat mengubah ukuran klaster dengan menambah atau menghapus _node_. Cara yang digunakan untuk pengubahan ukuran ini tergantung dari bagaimana kamu membangun klaster. Kuota sumber daya penyedia cloud -------------------------------- Untuk menghindari masalah kuota penyedia _cloud_, ketika membuat klaster dengan banyak _node_, pertimbangkanlah hal berikut ini: * Mengajukan penambahan kuota untuk sumber daya _cloud_ berikut ini: * Jumlah mesin virtual * CPU * Volume penyimpanan * Penggunaan alamat IP * Aturan penyaringan paket * Jumlah penyeimbang beban (_load balancer_) * Subnet jaringan * Aliran log * Mengatur pengubahan ukuran klaster untuk menambah _node_ baru menggunakan mode _batches_, dengan jeda antar _batches_, karena sejumlah penyedia _cloud_ membatasi laju (_rate limit_) pembuatan mesin baru. Komponen bidang kontrol ----------------------- Untuk klaster besar, kamu membutuhkan bidang kontrol dengan komputasi yang cukup dan sumber daya lainnya. Biasanya, kamu akan menjalankan satu atau dua bidang kontrol untuk tiap zona kegagalan (_failure zone_), mengubah ukuran bidang kontrol secara vertikal terlebih dahulu dan kemudian mengubah ukurannya secara horizontal setelah mencapai batas dari mengubah ukuran secara vertikal. Kamu harus menjalankan paling tidak satu bidang kontrol per zona kegagalan untuk memberikan toleransi kegagalan (_fault-tolerance_). _node_ Kubernetes tidak secara otomatis mengendalikan arus ke bidang kontrol yang berada di zona kegagalan yang sama; bagaimanapun, penyedia _cloud_ kamu mungkin memiliki mekanisme toleransi kegagalan mereka sendiri untuk menangani hal tersebut. Sebagai contoh, dengan menggunakan penyeimbang beban bawaan (_managed load balancer_), kamu dapat mengonfigurasi penyeimbang beban untuk mengirim arus yang berasal dari kubelet dan pods di zona A, kemudian hanya mengarahkan arus tersebut ke bidang kontrol yang hanya ada di zona _A_. Jika salah satu bidang kontrol atau zona kegagalan _A_ mati, artinya semua arus bidang kontrol untuk _node_ di zona _A_ akan dikirim ke zona lain. Menjalankan banyak bidang kontrol di setiap zona dapat mencegah masalah tersebut. ### Penyimpanan etcd Untuk meningkatkan performa klaster besar, kamu dapat menyimpan objek _Event_ di _instance_ etcd terpisah. Ketika membangun sebuah klaster, kamu dapat (menggunakan alat khusus): * Nyalakan dan konfigurasikan _instance_ tambahan etcd * konfigurasikan _[API server](https://kubernetes.io/id/docs/reference/generated/kube-apiserver/ "Komponen control plane yang mengekspos API Kubernetes. Merupakan front-end dari control plane Kubernetes.") _ untuk menggunakan _instance_ etcd tambahan tersebut dalam penyimpanan _events_ Lihat juga [Mengoperasikan klaster etcd untuk Kubernetes](https://kubernetes.io/id/docs/tasks/administer-cluster/configure-upgrade-etcd/) dan [Membangun klaster etcd dengan ketersediaan tinggi (_high-availability_) menggunakan kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) untuk detail tentang konfigurasi dan mengelola etcd untuk klaster besar. Resource tambahan ----------------- [Batas sumber daya](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) Kubernetes membantu untuk meminimalisasi dampak dari kebocoran memori dan hal lainnya yang dapat membuat pods dan kontainer memberikan dampak terhadap komponen lainnya. Batasan sumber daya ini berlaku untuk sumber daya _[addon](https://kubernetes.io/id/docs/concepts/cluster-administration/addons/ "Resources that extend the functionality of Kubernetes.") _ layaknya berlaku untuk _workload_ aplikasi. Sebagai contoh, kamu dapat mengatur batas CPU dan memori untuk komponen _logging_ berikut ini: ... containers: - name: fluentd-cloud-logging image: fluent/fluentd-kubernetes-daemonset:v1 resources: limits: cpu: 100m memory: 200Mi Batas bawaan _addon_ biasanya diatur berdasarkan data yang dikumpulkan dari pengalaman menjalankan _addon_ pada klaster Kubernetes kecil atau menengah. Ketika menjalankan klaster besar, _addon_ biasanya menggunakan lebih banyak sumber daya dibanding batasnya. Jika klaster besar dijalankan tanpa mengubah nilai batasan, _addon_ dapat terhenti terus menerus karena mencapai batas memori. Selain itu, _addon_ dapat berjalan dengan performa buruk karena pembatasan potongan waktu (_time slice_) CPU. Untuk mencegah masalah sumber daya _addon_ di Kubernetes, saat membangun klaster dengan _node_ yang banyak, pertimbangkanlah beberapa hal berikut ini: * Beberapa _addon_ memperbesar ukurannya secara vertikal - terdapat satu replika dari _addon_ untuk satu klaster atau melayani hanya satu zona kegagalan. Untuk _addon_ tersebut, tambahkan permintaan (_request_) dan batasan ketika kamu memperbesar ukuran klaster. * Banyak _addon_ memperbesar ukurannya secara horizontal - kamu dapat menambah kapasitas dengan menjalankan lebih banyak pods - tapi dengan klaster yang sangat besar, kamu juga perlu untuk menaikan batas CPU atau memori secukupnya. [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) dapat berjalan dalam mode _recommender_ untuk menyediakan angka yang disarankan bagi permintaan dan batasan. * Beberapa _addon_ berjalan di setiap _node_ yang dikontrol oleh [DaemonSet](https://kubernetes.io/id/docs/concepts/workloads/controllers/daemonset "Memastikan salinan Pod dijalankan pada sekumpulan Node dalam satu klaster.") . Sebagai contoh, agregator log tingkat _node_. Mirip dengan kasus _addon_ yang memperbesar ukuran secara horizontal, kamu juga dapat menaikkan batas CPU dan memori secukupnya. Selanjutnya ----------- * `VerticalPodAutoscaler` adalah _custom resource_ yang dapat dijalankan di klaster untuk membantu kamu mengelola permintaan sumber daya dan batasan untuk pods. Pelajari lebih lanjut tentang [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) dan bagaimana kamu dapat menggunakannya untuk mengubah ukuran klaster. * Baca juga tentang [Node autoscaling](https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/) . * [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) membantu kamu mengubah ukuran _addon_ secara otomatis ketika ukuran klaster kamu berubah. 3 - Validasi Pengaturan Node ============================ Tes Kesesuaian _Node_ --------------------- _Node conformance test_ atau tes kesesuaian _Node_ adalah kerangka kerja tes berbasis kontainer yang menyediakan sistem verifikasi dan tes untuk _Node_. Tes memvalidasi apakah _Node_ memenuhi syarat minimum untuk Kubernetes; _Node_ yang lolos tes dianggap lolos untuk bergabung dengan klaster Kubernetes. Prasyarat Node -------------- Untuk menjalankan tes kesesuaian _Node_, sebuah _Node_ harus memenuhi prasyarat yang sama dengan _Node_ Kubernetes standar. Sekurang - kurangnya, _daemon_ dibawah ini harus terpasang di _Node_: * _runtime_ kontainer yang kompatibel dengan CRI seperti Docker, containerd dan CRI-O * kubelet Menjalankan Tes Kesesuaian Node ------------------------------- Untuk menjalankan tes kesesuaian _Node_, lakukanlah langkah-langkah berikut ini: 1. Sesuaikan nilai opsi dari `--kubeconfig` untuk kubelet; sebagai contoh: `--kubeconfig=/var/lib/kubelet/config.yaml`. Karena kerangka kerja tes akan menjalankan panel kontrol lokal untuk menguji kubelet, menggunakan `http://localhost:8080` sebagai URL dari API Server. Terdapat beberapa parameter _command line_ untuk kubelet yang mungkin bisa kamu gunakan: * `--cloud-provider`: Jika kamu menggunakan `--cloud-provider=gce`, maka kamu harus menghapus _flag_ untuk menjalankan tes 2. Jalankan tes kesesuaian _Node_ dengan perintah: # $CONFIG_DIR adalah path dari manifest untuk kubelet kamu # $LOG_DIR adalah path untuk output sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ registry.k8s.io/node-test:0.2 Menjalankan Tes Kesesuaian Node untuk Arsitektur lainnya -------------------------------------------------------- Kubernetes juga menyediakan _image_ tes kesesuaian _Node_ untuk arsitektur lainnya: | Arch | Image | | --- | --- | | amd64 | node-test-amd64 | | arm | node-test-arm | | arm64 | node-test-arm64 | Menjalankan Tes Tertentu ------------------------ Untuk menjalankan tes-tes tertentu, ganti nilai _environment variable_ `FOCUS` dengan ekspresi reguler dari tes-tes yang ingin kamu jalankan. sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e FOCUS=MirrorPod \ # Hanya menjalankan tes MirrorPod registry.k8s.io/node-test:0.2 Untuk melewat tes-tes tertentu, ganti nilai _environment variable_ `SKIP` dengan ekspresi reguler dari tes-tes yang ingin kamu lewati. sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e SKIP=MirrorPod \ # Menjalankan semua tes skesesuaian dengan melewat tes MirrorPod registry.k8s.io/node-test:0.2 Tes kesesuaian _Node_ adalah versi kontainer dari [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md) . Secara bawaan, tes ini menjalankan semua tes kesesuaian. Secara teori, kamu dapat menjalankan tes node-e2e manapun jika kamu mengkonfigurasi kontainer dan _mount_ yang dibutuhkan _volume_ dengan benar. Tapi **sangat direkomendasikan hanya untuk menjalankan tes kesesuaian**, karena banyak sekali konfigurasi yang dibutuhkan untuk menjalankan tes ketidaksesuaian dan tentunya lebih kompleks. Kekurangan ---------- * Tes ini meninggalkan sisa-sisa _image_ Docker di dalam _Node_, termasuk _image_ dari tes kesesuaian _Node_ dan _image_ kontainer yang digunakan untuk tes fungsionalitas. * Tes ini meninggalkan kontainer mati di dalam _Node_. Kontainer-kontainer ini dibuat selama tes fungsionalitas. 4 - Memberlakukan Standar Keamanan Pod ====================================== Laman ini memberikan sebuah gambaran umum tentang cara memberlakukan [Standar Keamanan Pod](https://kubernetes.io/docs/concepts/security/pod-security-standards) . Menggunakan Kontroler _Pod Security Admission_ Bawaan ----------------------------------------------------- FEATURE STATE: `Kubernetes v1.25 [stable]` [Kontroler _Pod Security Admission_](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podsecurity) bermaksud untuk menggantikan _PodSecurityPolicies_ yang sudah tidak berlaku lagi (_deprecated_). ### Mengkonfigurasi semua Namespace di klaster Namespace yang tidak memiliki konfigurasi apapun sebaiknya dianggap sebagai _gap_ dalam model keamanan klaster kamu. Kami menyarankan agar mengambil waktu untuk menganalisis jenis-jenis beban kerja yang terjadi di setiap Namespace, dan dengan merujuk pada Standar Keamanan Pod, lalu tentukan tingkat yang sesuai pada setiap Namespace. Namespace yang tidak berlabel sebaiknya hanya menunjukkan bahwa Namespace tersebut belum dievaluasi. Dalam skenario dimana semua beban kerja di semua Namespace memiliki persyaratan keamanan yang sama, Kami menyediakan sebuah [contoh](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) yang mengilustrasikan bagaimana label _PodSecurity_ dapat diterapkan secara massal. ### Mengikuti prinsip hak istimewa paling sedikit Di dunia yang ideal, semua pod di semua Namespace akan memenuhi persyaratan dari kebijakan `terbatas` . Namun, hal ini tidak mungkin dan tidak praktis, karena beberapa beban kerja akan memerlukan hak istimewa lebih untuk alasan yang sah. * Namespace memperbolehkan beban kerja yang `memiliki hak istimewa` sebaiknya mendirikan dan memberlakukan kontrol akses yang sesuai. * Untuk beban kerja yang berjalan di Namespace permisif, jagalah keunikan persyaratan keamanan dokumentasi tersebut. Jika memungkinkan, pertimbangkan bagaimana persyaratan tersebut dapat dibatasi lebih lanjut. ### Mengadopsi strategi multi mode Mode `audit` dan `warn` pada kontroler _Pod Security Admission_ memudahkan pengumpulan wawasan keamanan penting tentang pod tanpa mengganggu beban kerja yang sudah ada. Merupakan praktik yang baik untuk mengaktifkan mode-mode ini untuk semua Namespace, dan mengaturnya ke tingkat yang _diinginkan_ dan versi yang akan kamu `enforce`. Notasi peringatan dan audit yang dihasilkan di fase ini bisa memandu kamu menuju keadaan yang diinginkan. Jika kamu mengharapkan pembuat beban kerja akan membuat perubahan untuk memenuhi tingkat yang diinginkan, maka aktifkan mode `warn`. Jika kamu berharap akan menggunakan log audit untuk memantau/mendorong perubahan untuk memenuhi tingkat yang diinginkan, maka aktifkan mode `audit`. Ketika kamu memiliki mode `enforce` dipasang ke tingkat yang kamu inginkan, mode-mode ini masih dapat berguna dalam beberapa cara berbeda: * Dengan menetapkan `warn` ke tingkat yang sama dengan `enforce`, maka klien akan menerima peringatan ketika mencoba membuat Pod-pod (atau sumber daya yang memiliki template Pod) yang tidak memenuhi validasi. Hal ini akan membantu mereka memperbarui sumber daya tersebut untuk menjadi patuh. * Dalam Namespace yang menyematkan `enforce` ke spesifik versi yang tidak terbaru, menetapkan mode `audit` dan `warn` ke tingkat yang sama dengan `enforce`, tetapi ke versi `terakhir` akan memberikan visibilitas tentang pengaturan yang diperbolehkan oleh versi-versi sebelumnya namun tidak diperbolehkan per praktik terbaik saat ini. Alternatif Pihak Ketiga ----------------------- **Catatan:** Bagian ini tertaut ke proyek-proyek pihak ketiga yang menyediakan fungsionalitas yang dibutuhkan oleh Kubernetes. Pencipta proyek Kubernetes tidak bertanggung jawab atas proyek-proyek tersebut. Laman ini mengikuti [pedoman website CNCF](https://github.com/cncf/foundation/blob/master/website-guidelines.md) dengan membuat daftar proyek menurut abjad. Untuk menambakan proyek ke dalam daftar ini, bacalah [panduan](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) sebelum mengirimkan perubahan. Alternatif pihak ketiga untuk memberlakukan profil keamanan yang dibuat di ekosistem Kubernetes: * [Kubewarden](https://github.com/kubewarden) . * [Kyverno](https://kyverno.io/policies/) . * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) . Keputusan untuk menggunakan solusi bawaan (misalnya Kontroler _PodSecurity Admission_ ) dengan alat pihak ketiga sepenuhnya bergantung pada situasimu. Ketika mengevaluasi solusi apapun, kepercayaanmu terhadap rantai pasokmu adalah yang terpenting. Pada akhirnya, menggunakan _salah satu_ dari pendekatan yang disebutkan akan lebih baik dari tidak menggunakan apapun. --- # Tổng quan | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/vi/docs/concepts/overview/_print/#) . [Return to the regular view of this page](https://kubernetes.io/vi/docs/concepts/overview/) . Tổng quan ========= * 1: [Kubernetes là gì](https://kubernetes.io/vi/docs/concepts/overview/_print/#pg-45bdca6129cf540121623e903c18ba46) 1 - Kubernetes là gì ==================== Trang tổng quan của Kubernetes. Kubernetes là một nền tảng nguồn mở, khả chuyển, có thể mở rộng để quản lý các ứng dụng được đóng gói và các service, giúp thuận lợi trong việc cấu hình và tự động hoá việc triển khai ứng dụng. Kubernetes là một hệ sinh thái lớn và phát triển nhanh chóng. Các dịch vụ, sự hỗ trợ và công cụ có sẵn rộng rãi. Tên gọi Kubernetes có nguồn gốc từ tiếng Hy Lạp, có ý nghĩa là người lái tàu hoặc hoa tiêu. Google mở mã nguồn Kubernetes từ năm 2014. Kubernetes xây dựng dựa trên [một thập kỷ rưỡi kinh nghiệm mà Google có được với việc vận hành một khối lượng lớn workload trong thực tế](https://research.google/pubs/pub43438) , kết hợp với các ý tưởng và thực tiễn tốt nhất từ cộng đồng. Quay ngược thời gian -------------------- Chúng ta hãy xem tại sao Kubernetes rất hữu ích bằng cách quay ngược thời gian. ![Deployment evolution](https://kubernetes.io/images/docs/Container_Evolution.svg) **Thời đại triển khai theo cách truyền thống:** Ban đầu, các ứng dụng được chạy trên các máy chủ vật lý. Không có cách nào để xác định ranh giới tài nguyên cho các ứng dụng trong máy chủ vật lý và điều này gây ra sự cố phân bổ tài nguyên. Ví dụ, nếu nhiều ứng dụng cùng chạy trên một máy chủ vật lý, có thể có những trường hợp một ứng dụng sẽ chiếm phần lớn tài nguyên hơn và kết quả là các ứng dụng khác sẽ hoạt động kém đi. Một giải pháp cho điều này sẽ là chạy từng ứng dụng trên một máy chủ vật lý khác nhau. Nhưng giải pháp này không tối ưu vì tài nguyên không được sử dụng đúng mức và rất tốn kém cho các tổ chức để có thể duy trì nhiều máy chủ vật lý như vậy. **Thời đại triển khai ảo hóa:** Như một giải pháp, ảo hóa đã được giới thiệu. Nó cho phép bạn chạy nhiều Máy ảo (VM) trên CPU của một máy chủ vật lý. Ảo hóa cho phép các ứng dụng được cô lập giữa các VM và cung cấp mức độ bảo mật vì thông tin của một ứng dụng không thể được truy cập tự do bởi một ứng dụng khác. Ảo hóa cho phép sử dụng tốt hơn các tài nguyên trong một máy chủ vật lý và cho phép khả năng mở rộng tốt hơn vì một ứng dụng có thể được thêm hoặc cập nhật dễ dàng, giảm chi phí phần cứng và hơn thế nữa. Với ảo hóa, bạn có thể có một tập hợp các tài nguyên vật lý dưới dạng một cụm các máy ảo sẵn dùng. Mỗi VM là một máy tính chạy tất cả các thành phần, bao gồm cả hệ điều hành riêng của nó, bên trên phần cứng được ảo hóa. **Thời đại triển khai Container:** Các container tương tự như VM, nhưng chúng có tính cô lập để chia sẻ Hệ điều hành (HĐH) giữa các ứng dụng. Do đó, container được coi là nhẹ (lightweight). Tương tự như VM, một container có hệ thống tệp (filesystem), CPU, bộ nhớ, process space, v.v. Khi chúng được tách rời khỏi cơ sở hạ tầng bên dưới, chúng có thể khả chuyển (portable) trên cloud hoặc các bản phân phối Hệ điều hành. Các container đã trở nên phổ biến vì chúng có thêm nhiều lợi ích, chẳng hạn như: * Tạo mới và triển khai ứng dụng Agile: gia tăng tính dễ dàng và hiệu quả của việc tạo các container image so với việc sử dụng VM image. * Phát triển, tích hợp và triển khai liên tục: cung cấp khả năng build và triển khai container image thường xuyên và đáng tin cậy với việc rollbacks dễ dàng, nhanh chóng. * Phân biệt giữa Dev và Ops: tạo các images của các application container tại thời điểm build/release thay vì thời gian triển khai, do đó phân tách các ứng dụng khỏi hạ tầng. * Khả năng quan sát không chỉ hiển thị thông tin và các metric ở mức Hệ điều hành, mà còn cả application health và các tín hiệu khác. * Tính nhất quán về môi trường trong suốt quá trình phát triển, testing và trong production: Chạy tương tự trên laptop như trên cloud. * Tính khả chuyển trên cloud và các bản phân phối HĐH: Chạy trên Ubuntu, RHEL, CoreOS, on-premises, Google Kubernetes Engine và bất kì nơi nào khác. * Quản lý tập trung ứng dụng: Tăng mức độ trừu tượng từ việc chạy một Hệ điều hành trên phần cứng ảo hóa sang chạy một ứng dụng trên một HĐH bằng logical resources. * Các micro-services phân tán, elastic: ứng dụng được phân tách thành các phần nhỏ hơn, độc lập và thể được triển khai và quản lý một cách linh hoạt - chứ không phải một app nguyên khối (monolithic). * Cô lập các tài nguyên: dự đoán hiệu năng ứng dụng * Sử dụng tài nguyên: hiệu quả Tại sao bạn cần Kubernetes và nó có thể làm những gì? ----------------------------------------------------- Các container là một cách tốt để đóng gói và chạy các ứng dụng của bạn. Trong môi trường production, bạn cần quản lý các container chạy các ứng dụng và đảm bảo rằng không có khoảng thời gian downtime. Ví dụ, nếu một container bị tắt đi, một container khác cần phải khởi động lên. Điều này sẽ dễ dàng hơn nếu được xử lý bởi một hệ thống. Đó là cách Kubernetes đến với chúng ta. Kubernetes cung cấp cho bạn một framework để chạy các hệ phân tán một cách mạnh mẽ. Nó đảm nhiệm việc nhân rộng và chuyển đổi dự phòng cho ứng dụng của bạn, cung cấp các mẫu deployment và hơn thế nữa. Ví dụ, Kubernetes có thể dễ dàng quản lý một triển khai canary cho hệ thống của bạn. Kubernetes cung cấp cho bạn: * **Service discovery và cân bằng tải** Kubernetes có thể expose một container sử dụng DNS hoặc địa chỉ IP của riêng nó. Nếu lượng traffic truy cập đến một container cao, Kubernetes có thể cân bằng tải và phân phối lưu lượng mạng (network traffic) để việc triển khai được ổn định. * **Điều phối bộ nhớ** Kubernetes cho phép bạn tự động mount một hệ thống lưu trữ mà bạn chọn, như local storages, public cloud providers, v.v. * **Tự động rollouts và rollbacks** Bạn có thể mô tả trạng thái mong muốn cho các container được triển khai dùng Kubernetes và nó có thể thay đổi trạng thái thực tế sang trạng thái mong muốn với tần suất được kiểm soát. Ví dụ, bạn có thể tự động hoá Kubernetes để tạo mới các container cho việc triển khai của bạn, xoá các container hiện có và áp dụng tất cả các resource của chúng vào container mới. * **Đóng gói tự động** Bạn cung cấp cho Kubernetes một cluster gồm các node mà nó có thể sử dụng để chạy các tác vụ được đóng gói (containerized task). Bạn cho Kubernetes biết mỗi container cần bao nhiêu CPU và bộ nhớ (RAM). Kubernetes có thể điều phối các container đến các node để tận dụng tốt nhất các resource của bạn. * **Tự phục hồi** Kubernetes khởi động lại các containers bị lỗi, thay thế các container, xoá các container không phản hồi lại cấu hình health check do người dùng xác định và không cho các client biết đến chúng cho đến khi chúng sẵn sàng hoạt động. * **Quản lý cấu hình và bảo mật** Kubernetes cho phép bạn lưu trữ và quản lý các thông tin nhạy cảm như: password, OAuth token và SSH key. Bạn có thể triển khai và cập nhật lại secret và cấu hình ứng dụng mà không cần build lại các container image và không để lộ secret trong cấu hình stack của bạn. Kubernetes không phải là gì? ---------------------------- Kubernetes không phải là một hệ thống PaaS (Nền tảng như một Dịch vụ) truyền thống, toàn diện. Do Kubernetes hoạt động ở tầng container chứ không phải ở tầng phần cứng, nó cung cấp một số tính năng thường áp dụng chung cho các dịch vụ PaaS, như triển khai, nhân rộng, cân bằng tải, ghi nhật ký và giám sát. Tuy nhiên, Kubernetes không phải là cấu trúc nguyên khối và các giải pháp mặc định này là tùy chọn và có thể cắm được (pluggable). Kubernetes: * Không giới hạn các loại ứng dụng được hỗ trợ. Kubernetes nhằm mục đích hỗ trợ một khối lượng công việc cực kỳ đa dạng, bao gồm cả stateless, stateful và xử lý dữ liệu. Nếu một ứng dụng có thể chạy trong một container, nó sẽ chạy rất tốt trên Kubernetes. * Không triển khai mã nguồn và không build ứng dụng của bạn. Quy trình CI/CD được xác định bởi tổ chức cũng như các yêu cầu kỹ thuật. * Không cung cấp các service ở mức ứng dụng, như middleware (ví dụ, các message buses), các framework xử lý dữ liệu (ví dụ, Spark), cơ sở dữ liệu (ví dụ, MySQL), bộ nhớ cache, cũng như hệ thống lưu trữ của cluster (ví dụ, Ceph). Các thành phần như vậy có thể chạy trên Kubernetes và/hoặc có thể được truy cập bởi các ứng dụng chạy trên Kubernetes thông qua các cơ chế di động, chẳng hạn như [Open Service Broker](https://openservicebrokerapi.org/) . * Không bắt buộc các giải pháp ghi lại nhật ký (logging), giám sát (monitoring) hoặc cảnh báo (alerting). Nó cung cấp một số sự tích hợp như proof-of-concept, và cơ chế để thu thập và xuất các số liệu. * Không cung cấp, không bắt buộc một cấu hình ngôn ngữ/hệ thống (ví dụ: Jsonnet). Nó cung cấp một API khai báo có thể được targeted bởi các hình thức khai báo tùy ý. * Không cung cấp cũng như áp dụng bất kỳ cấu hình toàn diện, bảo trì, quản lý hoặc hệ thống tự phục hồi. * Ngoài ra, Kubernetes không phải là một hệ thống điều phối đơn thuần. Trong thực tế, nó loại bỏ sự cần thiết của việc điều phối. Định nghĩa kỹ thuật của điều phối là việc thực thi một quy trình công việc được xác định: đầu tiên làm việc A, sau đó là B rồi sau chót là C. Ngược lại, Kubernetes bao gồm một tập các quy trình kiểm soát độc lập, có thể kết hợp, liên tục điều khiển trạng thái hiện tại theo trạng thái mong muốn đã cho. Nó không phải là vấn đề làm thế nào bạn có thể đi được từ A đến C. Kiểm soát tập trung cũng không bắt buộc. Điều này dẫn đến một hệ thống dễ sử dụng hơn, mạnh mẽ hơn, linh hoạt hơn và có thể mở rộng. Tiếp theo là gì --------------- * Xem thêm về [các thành phần của Kubernetes](https://kubernetes.io/docs/concepts/overview/components/) * Sẵn sàng [bắt đầu](https://kubernetes.io/vi/docs/setup/) ? --- # Среда обучения | Kubernetes Это многостраничный печатный вид этого раздела. [Нажмите что бы печатать](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#) . [Вернуться к обычному просмотру страницы](https://kubernetes.io/ru/docs/setup/learning-environment/) . Среда обучения ============== * 1: [Установка Kubernetes с помощью Minikube](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#pg-8b996bf57bd8e67340235da1a1fb8e95) * 2: [Установка Kubernetes с помощью Kind](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#pg-861dedab439fb9a133b35009a34655ec) 1 - Установка Kubernetes с помощью Minikube =========================================== Minikube — это инструмент, позволяющий легко запускать Kubernetes на локальной машине. Для тех, кто хочет попробовать Kubernetes или рассмотреть возможность его использования в повседневной разработке, Minikube станет отличным вариантом, потому что он запускает одноузловой кластер Kubernetes внутри виртуальной машины (VM) на компьютере пользователя. Возможности Minikube -------------------- Minikube поддерживает следующие возможности Kubernetes: * DNS * Сервисы NodePort * Словари конфигурации (ConfigMaps) и секреты (Secrets) * Панель управления (Dashboard) * Среда выполнения контейнера: Docker, [CRI-O](https://cri-o.io/) и [containerd](https://github.com/containerd/containerd) * Поддержка CNI (Container Network Interface) * Ingress Установка --------- Посмотрите страницу [Установка Minikube](https://kubernetes.io/ru/docs/tasks/tools/install-minikube/) . Краткое руководство ------------------- Эта простая демонстрация поможет запустить, использовать и удалить Minikube на локальной машине. Следуйте перечисленным ниже шагам, чтобы начать знакомство с Minikube. 1. Запустите Minikube и создайте кластер: minikube start Вывод будет примерно следующим: Starting local Kubernetes cluster... Running pre-create checks... Creating machine... Starting local Kubernetes cluster... Дополнительную информацию о запуске кластера в определенной версии Kubernetes, виртуальной машине или среде выполнения контейнера смотрите в разделе [Запуск кластера](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#%D0%B7%D0%B0%D0%BF%D1%83%D1%81%D0%BA-%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%B0) . 2. Теперь вы можете работать со своим кластером через CLI-инструмент kubectl. Для получения дополнительной информации смотрите раздел [Работа с кластером](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0-%D1%81-%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%BE%D0%BC) . Давайте создадим развёртывание (Deployment) в Kubernetes, используя существующий образ `echoserver`, представляющий простой HTTP-сервер, и сделаем его доступным на порту 8080 с помощью `--port`. kubectl create deployment hello-minikube --image=registry.k8s.io/echoserver:1.10 Вывод будет примерно следующим: deployment.apps/hello-minikube created 3. Чтобы получить доступ к объекту Deployment `hello-minikube` извне, создайте объект сервиса (Service): kubectl expose deployment hello-minikube --type=NodePort --port=8080 Опция `--type=NodePort` определяет тип сервиса. Вывод будет примерно следующим: service/hello-minikube exposed 4. Под (Pod) `hello-minikube` теперь запущен, но нужно подождать, пока он начнёт функционировать, прежде чем обращаться к нему. Проверьте, что под работает: kubectl get pod Если в столбце вывода `STATUS` выводится `ContainerCreating`, значит под все еще создается: NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s Если в столбце `STATUS` указано `Running`, то под теперь в рабочем состоянии: NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 1/1 Running 0 13s 5. Узнайте URL-адрес открытого (exposed) сервиса, чтобы просмотреть подробные сведения о сервисе: minikube service hello-minikube --url 6. Чтобы ознакомиться с подробной информацией о локальном кластере, скопируйте и откройте полученный из вывода команды на предыдущем шаге URL-адрес в браузере. Вывод будет примерно следующим: Hostname: hello-minikube-7c77b68cff-8wdzq Pod Information: -no pod information available- Server values: server_version=nginx: 1.13.3 - lua: 10008 Request Information: client_address=172.17.0.1 method=GET real path=/ query= request_version=1.1 request_scheme=http request_uri=http://192.168.99.100:8080/ Request Headers: accept=*/* host=192.168.99.100:30674 user-agent=curl/7.47.0 Request Body: -no body in request- Если сервис и кластер вам больше не нужны, их можно удалить. 7. Удалите сервис `hello-minikube`: kubectl delete services hello-minikube Вывод будет примерно следующим: service "hello-minikube" deleted 8. Удалите развёртывание `hello-minikube`: kubectl delete deployment hello-minikube Вывод будет примерно следующим: deployment.extensions "hello-minikube" deleted 9. Остановите локальный кластер Minikube: minikube stop Вывод будет примерно следующим: Stopping "minikube"... "minikube" stopped. Подробности смотрите в разделе [Остановка кластера](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0-%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%B0) . 10. Удалите локальный кластер Minikube: minikube delete Вывод будет примерно следующим: Deleting "minikube" ... The "minikube" cluster has been deleted. Подробности смотрите в разделе [Удаление кластера](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#%D1%83%D0%B4%D0%B0%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%B0) . Управление кластером -------------------- ### Запуск кластера Команда `minikube start` используется для запуска кластера. Эта команда создаёт и конфигурирует виртуальную машину, которая запускает одноузловой кластер Kubernetes. Эта команда также настраивает вашу установку [kubectl](https://kubernetes.io/docs/user-guide/kubectl-overview/) для взаимодействия с этим кластером. #### Примечание: Если вы работаете из-под веб-прокси, вам нужно указать данные прокси в команде `minikube start`: https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 К сожалению, установка переменных окружения не cработает. Minikube также создает контекст "minikube" и устанавливает его по умолчанию в kubectl. Чтобы вернуться к этому контексту, выполните следующую команду: `kubectl config use-context minikube`. #### Указание версии Kubernetes Вы можете указать используемую версию Kubernetes в Minikube, добавив параметр `--kubernetes-version` в команду `minikube start`. Например, чтобы запустить Minikube из-под версии 1.35.0, вам нужно выполнить следующую команду: minikube start --kubernetes-version 1.35.0 #### Указание драйвера виртуальной машины Вы можете изменить драйвер виртуальной машины, добавив флаг `--vm-driver=` в команду `minikube start`. Тогда команда будет выглядеть так: minikube start --vm-driver= Minikube поддерживает следующие драйверы: #### Примечание: Смотрите страницу [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) для получения подробной информации о поддерживаемых драйверах и как устанавливать плагины. * virtualbox * vmwarefusion * docker (ЭКСПЕРИМЕНТАЛЬНЫЙ) * kvm2 ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/) ) * hyperkit ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/) ) * hyperv ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/) ) Обратите внимание, что указанный IP-адрес на этой странице является динамическим и может изменяться. Его можно получить с помощью `minikube ip`. * vmware ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/) ) (VMware unified driver) * parallels ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/) ) * none (Запускает компоненты Kubernetes на хосте, а не на виртуальной машине. Использование этого драйвера требует использование Linux и установленного [Docker](https://docs.docker.com/engine/ "Docker — это программное обеспечение, реализующее виртуализацию на уровне операционной системы, которая известна как контейнеризация.") .) #### Внимание: Если вы используете драйвер `none`, некоторые компоненты Kubernetes запускаются как привилегированные контейнеры, которые имеют побочные эффекты вне окружения Minikube. Эти побочные эффекты означают, что драйвер `none` не рекомендуется использовать в личных рабочих станций. #### Запуск кластера в других средах выполнения контейнеров Вы можете запустить Minikube в следующих средах выполнения контейнеров. * [containerd](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#container-runtimes-0) * [CRI-O](https://kubernetes.io/ru/docs/setup/learning-environment/_print/#container-runtimes-1) Чтобы использовать [containerd](https://github.com/containerd/containerd) в качестве среды выполнения контейнера, выполните команду ниже: minikube start \ --network-plugin=cni \ --enable-default-cni \ --container-runtime=containerd \ --bootstrapper=kubeadm Также можете использовать расширенную вариант команды: minikube start \ --network-plugin=cni \ --enable-default-cni \ --extra-config=kubelet.container-runtime=remote \ --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \ --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ --bootstrapper=kubeadm Чтобы использовать [CRI-O](https://cri-o.io/) в качестве среды выполнения контейнера, выполните команду ниже: minikube start \ --network-plugin=cni \ --enable-default-cni \ --container-runtime=cri-o \ --bootstrapper=kubeadm Также можете использовать расширенную вариант команды: minikube start \ --network-plugin=cni \ --enable-default-cni \ --extra-config=kubelet.container-runtime=remote \ --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \ --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ --bootstrapper=kubeadm #### Использование локальных образов путём повторного использования демона Docker При использовании одной виртуальной машины для Kubernetes легко повторно использовать демон Docker, встроенный в Minikube. В этом случае нет необходимости создавать реестр Docker на вашей хост-машине и отправлять образ туда. Вместо этого вы можете создать реестр внутри того же демона Docker, который использует Minikube, что позволит ускорить локальные запуски. #### Примечание: Обязательно пометьте собственным тегом Docker-образ, и затем при получении образа всегда указывайте его. Так как `:latest` — это тег по умолчанию, поэтому наряду с соответствующей стандартной политикой получения образа, равной `Always`, в конечном итоге возникнет ошибка при получении образа (`ErrImagePull`), если Docker-образ не найден в базовом реестре Docker (как правило, в DockerHub). Для работы с Docker-демоном на вашем хосте под управлением Mac/Linux, запустите последнюю строку из вывода команды `minikube docker-env`. Теперь вы можете использовать Docker в командной строке вашего хост-компьютера на Mac/Linux для взаимодействия с демоном Docker внутри виртуальной машины Minikube: docker ps #### Примечание: На Centos 7 Docker может возникнуть следующая ошибка: Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory Для исправления этой ошибки обновите файл `/etc/sysconfig/docker`, чтобы учитывались изменения в среде Minikube: < DOCKER_CERT_PATH=/etc/docker --- > if [ -z "${DOCKER_CERT_PATH}" ]; then > DOCKER_CERT_PATH=/etc/docker > fi ### Конфигурация Kubernetes Minikube имеет такую возможность как "конфигуратор" ("configurator"), позволяющая пользователям настраивать компоненты Kubernetes произвольными значениями. Чтобы использовать эту возможность, используйте флаг `--extra-config` в команде `minikube start`. Этот флаг можно дублировать, поэтому вы можете указать его несколько раз с несколькими разными значениями, чтобы установить несколько опций. Этот флаг принимает строку вида `component.key=value`, где `component` — это одно из значение в приведённом ниже списка, `key` — ключ из структуры конфигурации, а `value` — значение, которое нужно установить. Допустимые ключи можно найти в документации по `componentconfigs` в Kubernetes каждого компонента. Ниже вы найдете документации по каждой поддерживаемой конфигурации: * [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration) * [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions) * [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration) * [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration) * [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig) * [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration) #### Примеры Чтобы изменить настройку `MaxPods` на значение 5 в Kubelet, передайте этот флаг `--extra-config=kubelet.MaxPods=5`. Эта возможность также поддерживает вложенные структуры. Для изменения настройки `LeaderElection.LeaderElect` на значение `true` в планировщике, передайте флаг `--extra-config=scheduler.LeaderElection.LeaderElect=true`. Чтобы изменить настройку `AuthorizationMode` в `apiserver` на значение `RBAC`, используйте флаг `--extra-config=apiserver.authorization-mode=RBAC`. ### Остановка кластера Команда `minikube stop` используется для остановки кластера. Эта команда выключает виртуальную машины Minikube, но сохраняет всё состояние кластера и данные. Повторный запуск кластера вернет его в прежнее состояние. ### Удаление кластера Команда `minikube delete` используется для удаления кластера. Эта команда выключает и удаляет виртуальную машину Minikube. Данные или состояние не сохраняются. ### Обновление minikube Смотрите [инструкцию по обновлению minikube](https://minikube.sigs.k8s.io/docs/start/macos/) . Работа с кластером ------------------ ### Kubectl Команда `minikube start` создает [контекст kubectl](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) под именем "minikube". Этот контекст содержит конфигурацию для взаимодействия с кластером Minikube. Minikube автоматически устанавливает этот контекст, но если вам потребуется явно использовать его в будущем, выполните команду ниже: kubectl config use-context minikube Либо передайте контекст при выполнении команды следующим образом: `kubectl get pods --context=minikube`. ### Панель управления Чтобы получить доступ к [веб-панели управления Kubernetes](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) , запустите эту команду в командной оболочке после запуска Minikube, чтобы получить адрес: minikube dashboard ### Сервисы Чтобы получить доступ к сервису, открытой через порт узла, выполните команду в командной оболочке после запуска Minikube, чтобы получить адрес: minikube service [-n NAMESPACE] [--url] NAME Организация сети ---------------- Виртуальная машина Minikube доступна только хост-системе через IP-адрес, который можно получить с помощью команды `minikube ip`. Вы можете использовать IP-адрес для доступа к любому сервису типа `NodePort`. Чтобы определить NodePort для вашего сервиса, вы можете использовать такую команду `kubectl`: kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"' Постоянные тома --------------- Minikube поддерживает [PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) типа `hostPath`. Эти постоянные тома монтируются в виртуальную машину Minikube. Виртуальная машина Minikube загружается в файловую систему tmpfs, поэтому большинство директорий не будет сохранено при перезагрузках (`minikube stop`). Однако Minikube сконфигурирован на сохранение файлов, хранящихся в перечисленных ниже директорий хоста. * `/data` * `/var/lib/minikube` * `/var/lib/docker` Пример конфигурации PersistentVolume для сохранения данных в директории `/data`: apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 spec: accessModes: - ReadWriteOnce capacity: storage: 5Gi hostPath: path: /data/pv0001/ Смонтированные директории хоста ------------------------------- Некоторые драйверы монтируют директорию хоста в виртуальную машину, чтобы можно было легко обмениваться файлами между виртуальной машиной и хостом. В настоящее время это не настраивается и отличается от используемого драйвера и ОС. #### Примечание: Совместное использование директории хоста еще не реализовано в драйвере KVM. | Driver | OS | HostFolder | VM | | --- | --- | --- | --- | | VirtualBox | Linux | /home | /hosthome | | VirtualBox | macOS | /Users | /Users | | VirtualBox | Windows | C://Users | /c/Users | | VMware Fusion | macOS | /Users | /mnt/hgfs/Users | | Xhyve | macOS | /Users | /Users | Приватные реестры контейнеров ----------------------------- Для доступа к реестру приватных контейнеров, выполните шаги, описанные на [этой странице](https://kubernetes.io/ru/docs/concepts/containers/images/) . Мы рекомендуем использовать `ImagePullSecrets`, но если вам нужно обратиться к нему из виртуальной машины Minikube, нужно поместить файл `.dockercfg` в директорию `/home/docker` или `config.json` в директорию `/home/docker/.docker`. Дополнения ---------- Для того, чтобы Minikube смог запустить или перезапустить пользовательские дополнения, поместите дополнения, которые вы хотите запускать с помощью Minikube, в директорию `~/.minikube/addons`. Дополнения в этой директории будут перемещены в виртуальную машину Minikube и запускаться каждый раз при запуске или перезапуске Minikube. Использование Minikube с помощью HTTP-прокси -------------------------------------------- Minikube создаёт виртуальную машину, включающая в себя Kubernetes и демон Docker. Когда Kubernetes планирует выполнение контейнеров с использованием Docker, демону Docker может потребоваться доступ к внешней сети для получения контейнеров. Если вы работаете через HTTP-прокси, вам нужно сконфигурировать настройки прокси для Docker. Для этого нужно передать необходимые переменные окружения в флаги перед выполнением команды `minikube start`. Например: minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ --docker-env https_proxy=https://$YOURPROXY:PORT Если адрес вашей виртуальной машины 192.168.99.100, то, скорее всего, настройки прокси помешают `kubectl` обратиться к ней. Чтобы прокси игнорировал этот IP-адрес, нужно скорректировать настройки no\_proxy следующим образом: export no_proxy=$no_proxy,$(minikube ip) Известные проблемы ------------------ Функциональность, для которой требуется несколько узлов, не будет работать в Minikube. Реализация ---------- Minikube использует [libmachine](https://github.com/docker/machine/tree/master/libmachine) для подготовки виртуальных машин и [kubeadm](https://github.com/kubernetes/kubeadm) для инициализации кластера Kubernetes. Для получения дополнительной информации о Minikube посмотрите [статью](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md) . Дополнительные ссылки --------------------- * **Цели**: цели проекта Minikube смотрите в [дорожной карте](https://git.k8s.io/minikube/docs/contributors/roadmap.md) . * **Руководство по разработке**: посмотрите [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) , чтобы ознакомиться с тем, как отправлять пулрексты. * **Сборка Minikube**: инструкции по сборке/тестированию Minikube из исходного кода смотрите в [руководстве по сборке](https://git.k8s.io/minikube/docs/contributors/build_guide.md) . * **Добавление новой зависимости**: инструкции по добавлению новой зависимости в Minikube смотрите в [руководстве по добавлению зависимостей](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md) . * **Добавление нового дополнения**: инструкции по добавлению нового дополнения для Minikube смотрите в [руководстве по добавлению дополнений](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md) . * **MicroK8**: пользователи Linux, которые не хотят использовать виртуальную машину, могут в качестве альтернативы посмотреть в сторону [MicroK8s](https://microk8s.io/) . Сообщество ---------- Помощь, вопросы и комментарии приветствуются и поощряются! Разработчики Minikube проводят время на [Slack](https://kubernetes.slack.com/) в канале #minikube (получить приглашение можно [здесь](http://slack.kubernetes.io/) ). У нас также есть [список рассылки dev@kubernetes на Google Groups](https://groups.google.com/a/kubernetes.io/g/dev/) . Если вы отправляете сообщение в список, пожалуйста, начните вашу тему с "minikube: ". 2 - Установка Kubernetes с помощью Kind ======================================= Kind — это инструмент для запуска локальных кластеров Kubernetes с помощью "узлов" контейнера Docker. Установка --------- Смотрите страницу [по установке Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) . --- # Monitoreo, Logging y Depuración | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/tasks/debug/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/tasks/debug/) . Monitoreo, Logging y Depuración =============================== Configurar el monitoreo y el logging para solucionar problemas de un clúster o depurar una aplicación en contenedores. * 1: [Solución de Problemas de Aplicaciones](https://kubernetes.io/es/docs/tasks/debug/_print/#pg-4a26f4e7f9ffe4b86dea8b77906d3d5c) * 1.1: [Depurar Contenedores de Inicialización](https://kubernetes.io/es/docs/tasks/debug/_print/#pg-43445f3208669d4078e87dbdbeed8473) * 2: [Solución de Problemas de Clústeres](https://kubernetes.io/es/docs/tasks/debug/_print/#pg-ce321f5c35198a1d9b64d52a98ba705c) * 2.1: [Auditoría](https://kubernetes.io/es/docs/tasks/debug/_print/#pg-38387ad04dd284933cb502944ea3515b) * 2.2: [Escribiendo Logs con Elasticsearch y Kibana](https://kubernetes.io/es/docs/tasks/debug/_print/#pg-1bc8fc9f1d5034c9b78d97a77cb1e958) * 2.3: [Pipeline de métricas de recursos](https://kubernetes.io/es/docs/tasks/debug/_print/#pg-5ff0cdcf7701f887e45d629f5cfe0424) A veces las cosas salen mal. Esta guía tiene como objetivo solucionarlas. Tiene dos secciones: * [Depuración de tu aplicación](https://kubernetes.io/es/docs/tasks/debug/debug-application/) - Útil para usuarios que están implementando código en Kubernetes y se preguntan por qué no funciona. * [Depuración de tu clúster](https://kubernetes.io/es/docs/tasks/debug/debug-cluster/) - Útil para administradores de clústeres y personas cuyo clúster de Kubernetes no funciona correctamente. También debe comprobar los problemas conocidos del [release](https://github.com/kubernetes/kubernetes/releases) usado. Obteniendo Ayuda ---------------- Si ninguna de las guías anteriores resuelve su problema, existen varias formas de obtener ayuda de la comunidad de Kubernetes. ### Preguntas La documentación de este sitio ha sido estructurada para brindar respuestas a una amplia gama de preguntas. [Conceptos](https://kubernetes.io/es/docs/concepts/) explican la arquitectura de Kubernetes y cómo funciona cada componente, mientras [Configuración](https://kubernetes.io/es/docs/setup/) proporciona instrucciones prácticas para empezar. [Tareas](https://kubernetes.io/es/docs/tasks/) muestran cómo realizar tareas de uso común, y [Tutoriales](https://kubernetes.io/es/docs/tutorials/) son recorridos más completos de escenarios de desarrollo reales, específicos de la industria o de extremo a extremo. La sección de [Referencia](https://kubernetes.io/es/docs/reference/) proporciona documentación detallada sobre el [Kubernetes API](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/) y las interfaces de línea de comandos (CLIs), tal como [`kubectl`](https://kubernetes.io/es/docs/reference/kubectl/) . ¡Ayuda! ¡Mi pregunta no está tratada! ¡Necesito ayuda ahora! ------------------------------------------------------------ ### Stack Exchange, Stack Overflow o Server Fault Si tienes preguntas relacionadas con _desarrollo de software_ para tu aplicación en contenedores, puedes preguntar en [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) . Si tienes preguntas sobre Kubernetes relacionadas con _administración de clústeres_ o _configuración_, puedes preguntar en [Server Fault](https://serverfault.com/questions/tagged/kubernetes) . También hay varios sitios de Stack Exchange que podrían ser el lugar adecuado para hacer preguntas sobre Kubernetes en áreas como [DevOps](https://devops.stackexchange.com/questions/tagged/kubernetes) , [Ingeniería de Software](https://softwareengineering.stackexchange.com/questions/tagged/kubernetes) , o [InfoSec](https://security.stackexchange.com/questions/tagged/kubernetes) . Es posible que otra persona de la comunidad ya haya hecho una pregunta similar o pueda ayudar con su problema. El equipo de Kubernetes también monitoreará [publicaciones etiquetadas con Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes) . Si no hay ninguna pregunta existente que te ayude, **asegúrate de que tu pregunta sea [sobre el tema en Stack Overflow](https://stackoverflow.com/help/on-topic) , [Server Fault](https://serverfault.com/help/on-topic) , o el Stack Exchange correcto en el que estás preguntando**, y lee las instrucciones sobre [Cómo hacer una nueva pregunta](https://stackoverflow.com/help/how-to-ask) , antes de preguntar una nueva! ### Slack Muchas personas de la comunidad de Kubernetes se reúnen en Kubernetes Slack en el canal `#kubernetes-users`. Slack requiere registro; puedes [solicitar una invitación](https://slack.kubernetes.io/) , el registro está abierto a todos. No dudes en participar y hacer todas y cada una de las preguntas. Una vez registrado, ingresa a la [Organización de Kubernetes en Slack](https://kubernetes.slack.com/) a través de tu navegador web o mediante la aplicación dedicada de Slack. Una vez que estés registrado, explora la creciente lista de canales para diversos temas de interés. Por ejemplo, las personas nuevas en Kubernetes también pueden querer unirse al canal [`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice) . Como otro ejemplo, los desarrolladores deberían unirse al canal [`#kubernetes-contributors`](https://kubernetes.slack.com/messages/kubernetes-contributors) . También hay muchos canales en idiomas locales o específicos de cada país. Siéntete libre de unirte a estos canales para obtener soporte e información localizados: | | | | --- | --- |País / Idioma en el canal de Slack | Región | Canal(es) | | --- | --- | | China | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users)
, [`#cn-events`](https://kubernetes.slack.com/messages/cn-events) | | Finlandia | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users) | | Francia | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users)
, [`#fr-events`](https://kubernetes.slack.com/messages/fr-events) | | Alemania | [`#de-users`](https://kubernetes.slack.com/messages/de-users)
, [`#de-events`](https://kubernetes.slack.com/messages/de-events) | | India | [`#in-users`](https://kubernetes.slack.com/messages/in-users)
, [`#in-events`](https://kubernetes.slack.com/messages/in-events) | | Italia | [`#it-users`](https://kubernetes.slack.com/messages/it-users)
, [`#it-events`](https://kubernetes.slack.com/messages/it-events) | | Japon | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users)
, [`#jp-events`](https://kubernetes.slack.com/messages/jp-events) | | Corea | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users) | | Países Bajos | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users) | | Noruega | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users) | | Polonia | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users) | | Rusia | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users) | | Países Hispanos | [`#es-users`](https://kubernetes.slack.com/messages/es-users) | | Suecia | [`#se-users`](https://kubernetes.slack.com/messages/se-users) | | Turquia | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users)
, [`#tr-events`](https://kubernetes.slack.com/messages/tr-events) | ### Foro Te invitamos a unirte al Foro oficial de Kubernetes: [discuss.kubernetes.io](https://discuss.kubernetes.io/) . ### Bugs y solicitudes de funcionalidades Si tienes lo que parece ser un error (bug) o deseas realizar una solicitud de funcionalidades, por favor utiliza el [sistema de seguimiento de asuntos en el GitHub](https://github.com/kubernetes/kubernetes/issues) . Antes de presentar un problema, busca problemas existentes para ver si tu problema ya está cubierto. Si presenta un error, incluya información detallada sobre cómo reproducir el problema, como por ejemplo: * Versión de Kubernetes: `kubectl version` * Proveedor de nube, distribución del sistema operativo, configuración de red y versión del contenedor runtime * Pasos para reproducir el problema 1 - Solución de Problemas de Aplicaciones ========================================= 1.1 - Depurar Contenedores de Inicialización ============================================ Esta página muestra cómo investigar problemas relacionados con la ejecución de los contenedores de inicialización (init containers). Las líneas de comando del ejemplo de abajo se refieren al Pod como `` y a los Init Containers como `` e `` respectivamente. Antes de empezar ---------------- Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos `kubectl` debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando [Minikube](https://kubernetes.io/docs/setup/minikube) , o puedes utilizar una de las siguientes herramientas en línea: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) * [Play with Kubernetes](https://labs.play-with-k8s.com/) Para comprobar la versión, introduzca `kubectl version`. * Deberías estar familizarizado con el concepto de [Init Containers](https://kubernetes.io/docs/concepts/abstractions/init-containers/) . * Deberías conocer la [Configuración de un Init Container](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/) . Comprobar el estado de los Init Containers ------------------------------------------ Muestra el estado de tu pod: kubectl get pod Por ejemplo, un estado de `Init:1/2` indica que uno de los Init Containers se ha ejecutado satisfactoriamente: NAME READY STATUS RESTARTS AGE 0/1 Init:1/2 0 7s Echa un vistazo a [Comprender el estado de un Pod](https://kubernetes.io/es/docs/tasks/debug/_print/#understanding-pod-status) para más ejemplos de valores de estado y sus significados. Obtener detalles acerca de los Init Containers ---------------------------------------------- Para ver información detallada acerca de la ejecución de un Init Container: kubectl describe pod Por ejemplo, un Pod con dos Init Containers podría mostrar lo siguiente: Init Containers: : Container ID: ... ... State: Terminated Reason: Completed Exit Code: 0 Started: ... Finished: ... Ready: True Restart Count: 0 ... : Container ID: ... ... State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: Error Exit Code: 1 Started: ... Finished: ... Ready: False Restart Count: 3 ... También puedes acceder al estado del Init Container de forma programática mediante la lectura del campo `status.initContainerStatuses` dentro del Pod Spec: kubectl get pod nginx --template '{{.status.initContainerStatuses}}' Este comando devolverá la misma información que arriba en formato JSON. Acceder a los logs de los Init Containers ----------------------------------------- Indica el nombre del Init Container así como el nombre del Pod para acceder a sus logs. kubectl logs -c Los Init Containers que ejecutan secuencias de línea de comandos muestran los comandos conforme se van ejecutando. Por ejemplo, puedes hacer lo siguiente en Bash indicando `set -x` al principio de la secuencia. Comprender el estado de un Pod ------------------------------ Un estado de un Pod que comienza con `Init:` especifica el estado de la ejecución de un Init Container. La tabla a continuación muestra algunos valores de estado de ejemplo que puedes encontrar al depurar Init Containers. | Estado | Significado | | --- | --- | | `Init:N/M` | El Pod tiene `M` Init Containers, y por el momento se han completado `N`. | | `Init:Error` | Ha fallado la ejecución de un Init Container. | | `Init:CrashLoopBackOff` | Un Init Container ha fallado de forma repetida. | | `Pending` | El Pod todavía no ha comenzado a ejecutar sus Init Containers. | | `PodInitializing` o `Running` | El Pod ya ha terminado de ejecutar sus Init Containers. | 2 - Solución de Problemas de Clústeres ====================================== 2.1 - Auditoría =============== La auditoría de Kubernetes proporciona un conjunto de registros cronológicos referentes a la seguridad que documentan la secuencia de actividades que tanto los usuarios individuales, como los administradores y otros componentes del sistema ha realizado en el sistema. Así, permite al administrador del clúster responder a las siguientes cuestiones: * ¿qué ha pasado? * ¿cuándo ha pasado? * ¿quién lo ha iniciado? * ¿sobre qué ha pasado? * ¿dónde se ha observado? * ¿desde dónde se ha iniciado? * ¿hacia dónde iba? El componente [Kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver) lleva a cabo la auditoría. Cada petición en cada fase de su ejecución genera un evento, que se pre-procesa según un cierto reglamento y se escribe en un backend. Este reglamento determina lo que se audita y los backends persisten los registros. Las implementaciones actuales de backend incluyen los archivos de logs y los webhooks. Cada petición puede grabarse junto con una "etapa" asociada. Las etapas conocidas son: * `RequestReceived` - La etapa para aquellos eventos generados tan pronto como el responsable de la auditoría recibe la petición, pero antes de que sea delegada al siguiente responsable en la cadena. * `ResponseStarted` - Una vez que las cabeceras de la respuesta se han enviado, pero antes de que el cuerpo de la respuesta se envíe. Esta etapa sólo se genera en peticiones de larga duración (ej. watch). * `ResponseComplete` - El cuerpo de la respuesta se ha completado y no se enviarán más bytes. * `Panic` - Eventos que se generan cuando ocurre una situación de pánico. #### Nota: La característica de registro de auditoría incrementa el consumo de memoria del servidor API porque requiere de contexto adicional para lo que se audita en cada petición. De forma adicional, el consumo de memoria depende de la configuración misma del registro. Reglamento de Auditoría ----------------------- El reglamento de auditoría define las reglas acerca de los eventos que deberían registrarse y los datos que deberían incluir. La estructura del objeto de reglas de auditoría se define en el [`audit.k8s.io` grupo de API](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go) . Cuando se procesa un evento, se compara con la lista de reglas en orden. La primera regla coincidente establece el "nivel de auditoría" del evento. Los niveles de auditoría conocidos son: * `None` - no se registra eventos que disparan esta regla. * `Metadata` - se registra los metadatos de la petición (usuario que la realiza, marca de fecha y hora, recurso, verbo, etc.), pero no la petición ni el cuerpo de la respuesta. * `Request` - se registra los metadatos del evento y el cuerpo de la petición, pero no el cuerpo de la respuesta. Esto no aplica para las peticiones que no son de recurso. * `RequestResponse` - se registra los metadatos del evento, y los cuerpos de la petición y la respuesta. Esto no aplica para las peticiones que no son de recurso. Es posible indicar un archivo al definir el reglamento en el [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver) usando el parámetro `--audit-policy-file`. Si dicho parámetros se omite, no se registra ningún evento. Nótese que el campo `rules` **debe** proporcionarse en el archivo del reglamento de auditoría. Un reglamento sin (0) reglas se considera ilegal. Abajo se presenta un ejemplo de un archivo de reglamento de auditoría: [`audit/audit-policy.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/es/examples/audit/audit-policy.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy audit/audit-policy.yaml to clipboard") apiVersion: audit.k8s.io/v1 # Esto es obligatorio. kind: Policy # No generar eventos de auditoría para las peticiones en la etapa RequestReceived. omitStages: - "RequestReceived" rules: # Registrar los cambios del pod al nivel RequestResponse - level: RequestResponse resources: - group: "" # Los recursos "pods" no hacen coincidir las peticiones a cualquier sub-recurso de pods, # lo que es consistente con la regla RBAC. resources: ["pods"] # Registrar "pods/log", "pods/status" al nivel Metadata - level: Metadata resources: - group: "" resources: ["pods/log", "pods/status"] # No registrar peticiones al configmap denominado "controller-leader" - level: None resources: - group: "" resources: ["configmaps"] resourceNames: ["controller-leader"] # No registrar peticiones de observación hechas por "system:kube-proxy" sobre puntos de acceso o servicios - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" # Grupo API base resources: ["endpoints", "services"] # No registrar peticiones autenticadas a ciertas rutas URL que no son recursos. - level: None userGroups: ["system:authenticated"] nonResourceURLs: - "/api*" # Coincidencia por comodín. - "/version" # Registrar el cuerpo de la petición de los cambios de configmap en kube-system. - level: Request resources: - group: "" # Grupo API base resources: ["configmaps"] # Esta regla sólo aplica a los recursos en el Namespace "kube-system". # La cadena vacía "" se puede usar para seleccionar los recursos sin Namespace. namespaces: ["kube-system"] # Registrar los cambios de configmap y secret en todos los otros Namespaces al nivel Metadata. - level: Metadata resources: - group: "" # Grupo API base resources: ["secrets", "configmaps"] # Registrar todos los recursos en core y extensions al nivel Request. - level: Request resources: - group: "" # Grupo API base - group: "extensions" # La versión del grupo NO debería incluirse. # Regla para "cazar" todos las demás peticiones al nivel Metadata. - level: Metadata # Las peticiones de larga duración, como los watches, que caen bajo esta regla no # generan un evento de auditoría en RequestReceived. omitStages: - "RequestReceived" Puedes usar un archivo mínimo de reglamento de auditoría para registrar todas las peticiones al nivel `Metadata` de la siguiente forma: # Log all requests at the Metadata level. apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata El [perfil de auditoría utilizado por GCE](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh#L735) debería servir como referencia para que los administradores construyeran sus propios perfiles de auditoría. Backends de auditoría --------------------- Los backends de auditoría persisten los eventos de auditoría en un almacenamiento externo. El [Kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver) por defecto proporciona tres backends: * Backend de logs, que escribe los eventos en disco * Backend de webhook, que envía los eventos a una API externa * Backend dinámico, que configura backends de webhook a través de objetos de la API AuditSink. En todos los casos, la estructura de los eventos de auditoría se define por la API del grupo `audit.k8s.io`. La versión actual de la API es [`v1`](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go) . #### Nota: En el caso de parches, el cuerpo de la petición es una matriz JSON con operaciones de parcheado, en vez de un objeto JSON que incluya el objeto de la API de Kubernetes apropiado. Por ejemplo, el siguiente cuerpo de mensaje es una petición de parcheado válida para `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`. [\ {\ "op": "replace",\ "path": "/spec/parallelism",\ "value": 0\ },\ {\ "op": "remove",\ "path": "/spec/template/spec/containers/0/terminationMessagePolicy"\ }\ ] ### Backend de Logs El backend de logs escribe los eventos de auditoría a un archivo en formato JSON. Puedes configurar el backend de logs de auditoría usando el siguiente parámetro de [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver) flags: * `--audit-log-path` especifica la ruta al archivo de log que el backend utiliza para escribir los eventos de auditoría. Si no se especifica, se deshabilita el backend de logs. `-` significa salida estándar * `--audit-log-maxage` define el máximo número de días a retener los archivos de log * `--audit-log-maxbackup` define el máximo número de archivos de log a retener * `--audit-log-maxsize` define el tamaño máximo en megabytes del archivo de logs antes de ser rotado ### Backend de Webhook El backend de Webhook envía eventos de auditoría a una API remota, que se supone es la misma API que expone el [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver) . Puedes configurar el backend de webhook de auditoría usando los siguientes parámetros de kube-apiserver: * `--audit-webhook-config-file` especifica la ruta a un archivo con configuración del webhook. La configuración del webhook es, de hecho, un archivo [kubeconfig](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) . * `--audit-webhook-initial-backoff` especifica la cantidad de tiempo a esperar tras una petición fallida antes de volver a intentarla. Los reintentos posteriores se ejecutan con retraso exponencial. El archivo de configuración del webhook usa el formato kubeconfig para especificar la dirección remota del servicio y las credenciales para conectarse al mismo. En la versión 1.13, los backends de webhook pueden configurarse [dinámicamente](https://kubernetes.io/es/docs/tasks/debug/_print/#dynamic-backend) . ### Procesamiento por lotes Tanto el backend de logs como el de webhook permiten procesamiento por lotes. Si usamos el webhook como ejemplo, aquí se muestra la lista de parámetros disponibles. Para aplicar el mismo parámetro al backend de logs, simplemente sustituye `webhook` por `log` en el nombre del parámetro. Por defecto, el procesimiento por lotes está habilitado en `webhook` y deshabilitado en `log`. De forma similar, por defecto la regulación (throttling) está habilitada en `webhook` y deshabilitada en `log`. * `--audit-webhook-mode` define la estrategia de memoria intermedia (búfer), que puede ser una de las siguientes: * `batch` - almacenar eventos y procesarlos de forma asíncrona en lotes. Esta es la estrategia por defecto. * `blocking` - bloquear todas las respuestas del servidor API al procesar cada evento de forma individual. * `blocking-strict` - igual que blocking, pero si ocurre un error durante el registro de la audtoría en la etapa RequestReceived, la petición completa al apiserver fallará. Los siguientes parámetros se usan únicamente en el modo `batch`: * `--audit-webhook-batch-buffer-size` define el número de eventos a almacenar de forma intermedia antes de procesar por lotes. Si el ritmo de eventos entrantes desborda la memoria intermedia, dichos eventos se descartan. * `--audit-webhook-batch-max-size` define el número máximo de eventos en un único proceso por lotes. * `--audit-webhook-batch-max-wait` define la cantidad máxima de tiempo a esperar de forma incondicional antes de procesar los eventos de la cola. * `--audit-webhook-batch-throttle-qps` define el promedio máximo de procesos por lote generados por segundo. * `--audit-webhook-batch-throttle-burst` define el número máximo de procesos por lote generados al mismo tiempo si el QPS permitido no fue usado en su totalidad anteriormente. #### Ajuste de parámetros Los parámetros deberían ajustarse a la carga del apiserver. Por ejemplo, si kube-apiserver recibe 100 peticiones por segundo, y para cada petición se audita las etapas `ResponseStarted` y `ResponseComplete`, deberías esperar unos ~200 eventos de auditoría generados por segundo. Asumiendo que hay hasta 100 eventos en un lote, deberías establecer el nivel de regulación (throttling) por lo menos a 2 QPS. Además, asumiendo que el backend puede tardar hasta 5 segundos en escribir eventos, deberías configurar el tamaño de la memoria intermedia para almacenar hasta 5 segundos de eventos, esto es, 10 lotes, o sea, 1000 eventos. En la mayoría de los casos, sin embargo, los valores por defecto de los parámetros deberían ser suficientes y no deberías preocuparte de ajustarlos manualmente. Puedes echar un vistazo a la siguientes métricas de Prometheus que expone kube-apiserver y también los logs para monitorizar el estado del subsistema de auditoría: * `apiserver_audit_event_total` métrica que contiene el número total de eventos de auditoría exportados. * `apiserver_audit_error_total` métrica que contiene el número total de eventos descartados debido a un error durante su exportación. ### Truncado Tanto el backend de logs como el de webhook permiten truncado. Como ejemplo, aquí se indica la lista de parámetros disponible para el backend de logs: * `audit-log-truncate-enabled` indica si el truncado de eventos y por lotes está habilitado. * `audit-log-truncate-max-batch-size` indica el tamaño máximo en bytes del lote enviado al backend correspondiente. * `audit-log-truncate-max-event-size` indica el tamaño máximo en bytes del evento de auditoría enviado al backend correspondiente. Por defecto, el truncado está deshabilitado tanto en `webhook` como en `log`; un administrador del clúster debe configurar bien el parámetro `audit-log-truncate-enabled` o `audit-webhook-truncate-enabled` para habilitar esta característica. ### Backend dinámico FEATURE STATE: `Kubernetes v1.13 [alpha]` En la versión 1.13 de Kubernetes, puedes configurar de forma dinámica los backends de auditoría usando objetos de la API AuditSink. Para habilitar la auditoría dinámica, debes configurar los siguientes parámetros de apiserver: * `--audit-dynamic-configuration`: el interruptor principal. Cuando esta característica sea GA, el único parámetro necesario. * `--feature-gates=DynamicAuditing=true`: en evaluación en alpha y beta. * `--runtime-config=auditregistration.k8s.io/v1alpha1=true`: habilitar la API. Cuando se habilita, un objeto AuditSink se provisiona de la siguiente forma: apiVersion: auditregistration.k8s.io/v1alpha1 kind: AuditSink metadata: name: mysink spec: policy: level: Metadata stages: - ResponseComplete webhook: throttle: qps: 10 burst: 15 clientConfig: url: "https://audit.app" Para una definición completa de la API, ver [AuditSink](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#auditsink-v1alpha1-auditregistration) . Múltiples objetos existirán como soluciones independientes. Aquellos backends estáticos que se configuran con parámetros en tiempo de ejecución no se ven impactados por esta característica. Sin embargo, estos backends dinámicos comparten las opciones de truncado del webhook estático, de forma que si dichas opciones se configura con parámetros en tiempo de ejecución, entonces se aplican a todos los backends dinámicos. #### Reglamento El reglamento de AuditSink es diferente del de la auditoría en tiempo de ejecución. Esto es debido a que el objeto de la API sirve para casos de uso diferentes. El reglamento continuará evolucionando para dar cabida a más casos de uso. El campo `level` establece el nivel de auditoría indicado a todas las peticiones. El campo `stages` es actualmente una lista de las etapas que se permite registrar. #### Seguridad Los administradores deberían tener en cuenta que permitir el acceso en modo escritura de esta característica otorga el modo de acceso de lectura a toda la información del clúster. Así, el acceso debería gestionarse como un privilegio de nivel `cluster-admin`. #### Rendimiento Actualmente, esta característica tiene implicaciones en el apiserver en forma de incrementos en el uso de la CPU y la memoria. Aunque debería ser nominal cuando se trata de un número pequeño de destinos, se realizarán pruebas adicionales de rendimiento para entender su impacto real antes de que esta API pase a beta. Configuración multi-clúster --------------------------- Si estás extendiendo la API de Kubernetes mediante la [capa de agregación](https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation) , puedes también configurar el registro de auditoría para el apiserver agregado. Para ello, pasa las opciones de configuración en el mismo formato que se describe arriba al apiserver agregado y configura el mecanismo de ingestión de logs para que recolecte los logs de auditoría. Cada uno de los apiservers puede tener configuraciones de auditoría diferentes con diferentes reglamentos de auditoría. Ejemplos de recolectores de Logs -------------------------------- ### Uso de fluentd para recolectar y distribuir eventos de auditoría a partir de un archivo de logs [Fluentd](http://www.fluentd.org/) es un recolector de datos de libre distribución que proporciona una capa unificada de registros. En este ejemplo, usaremos fluentd para separar los eventos de auditoría por nombres de espacio: 1. Instala [fluentd](https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd) , fluent-plugin-forest y fluent-plugin-rewrite-tag-filter en el nodo donde corre kube-apiserver #### Nota: Fluent-plugin-forest y fluent-plugin-rewrite-tag-filter son plugins de fluentd. Puedes obtener detalles de la instalación de estos plugins en el documento \[fluentd plugin-management\]\[fluentd\_plugin\_management\_doc\]. 2. Crea un archivo de configuración para fluentd: cat <<'EOF' > /etc/fluentd/config # fluentd conf runs in the same host with kube-apiserver @type tail # audit log path of kube-apiserver path /var/log/kube-audit pos_file /var/log/audit.pos format json time_key time time_format %Y-%m-%dT%H:%M:%S.%N%z tag audit #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13 @type record_transformer enable_ruby namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ? "none":record["objectRef"]["namespace"])} # route audit according to namespace element in context @type rewrite_tag_filter key namespace pattern /^(.+)/ tag ${tag}.$1 @type record_transformer remove_keys namespace @type forest subtype file remove_prefix audit EOF 3. Arranca fluentd: fluentd -c /etc/fluentd/config -vv 4. Arranca el componente kube-apiserver con las siguientes opciones: --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json 5. Comprueba las auditorías de los distintos espacios de nombres en `/var/log/audit-*.log` ### Uso de logstash para recolectar y distribuir eventos de auditoría desde un backend de webhook [Logstash](https://www.elastic.co/products/logstash) es una herramienta de libre distribución de procesamiento de datos en servidor. En este ejemplo, vamos a usar logstash para recolectar eventos de auditoría a partir de un backend de webhook, y grabar los eventos de usuarios diferentes en archivos distintos. 1. Instala [logstash](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html) 2. Crea un archivo de configuración para logstash: cat < /etc/logstash/config input{ http{ #TODO, figure out a way to use kubeconfig file to authenticate to logstash #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl port=>8888 } } filter{ split{ # Webhook audit backend sends several events together with EventList # split each event here. field=>[items] # We only need event subelement, remove others. remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host] } mutate{ rename => {items=>event} } } output{ file{ # Audit events from different users will be saved into different files. path=>"/var/log/kube-audit-%{[event][user][username]}/audit" } } EOF 3. Arranca logstash: bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/ 4. Crea un [archivo kubeconfig](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) para el webhook del backend de auditoría de kube-apiserver: cat < /etc/kubernetes/audit-webhook-kubeconfig apiVersion: v1 clusters: - cluster: server: http://:8888 name: logstash contexts: - context: cluster: logstash user: "" name: default-context current-context: default-context kind: Config preferences: {} users: [] EOF 5. Arranca kube-apiserver con las siguientes opciones: --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig 6. Comprueba las auditorías en los directorios `/var/log/kube-audit-*/audit` de los nodos de logstash Nótese que además del plugin para salida en archivos, logstash ofrece una variedad de salidas adicionales que permiten a los usuarios enviar la información donde necesiten. Por ejemplo, se puede enviar los eventos de auditoría al plugin de elasticsearch que soporta búsquedas avanzadas y analíticas. 2.2 - Escribiendo Logs con Elasticsearch y Kibana ================================================= En la plataforma Google Compute Engine (GCE), por defecto da soporte a la escritura de logs haciendo uso de [Stackdriver Logging](https://cloud.google.com/logging/) , el cual se describe en detalle en [Logging con Stackdriver Logging](https://kubernetes.io/docs/user-guide/logging/stackdriver) . Este artículo describe cómo configurar un clúster para la ingesta de logs en [Elasticsearch](https://www.elastic.co/products/elasticsearch) y su posterior visualización con [Kibana](https://www.elastic.co/products/kibana) , a modo de alternativa a Stackdriver Logging cuando se utiliza la plataforma GCE. #### Nota: No se puede desplegar de forma automática Elasticsearch o Kibana en un clúster alojado en Google Kubernetes Engine. Hay que desplegarlos de forma manual. Para utilizar Elasticsearch y Kibana para escritura de logs del clúster, deberías configurar la siguiente variable de entorno que se muestra a continuación como parte de la creación del clúster con kube-up.sh: KUBE_LOGGING_DESTINATION=elasticsearch También deberías asegurar que `KUBE_ENABLE_NODE_LOGGING=true` (que es el valor por defecto en la plataforma GCE). Así, cuando crees un clúster, un mensaje te indicará que la recolección de logs de los daemons de Fluentd que corren en cada nodo enviará dichos logs a Elasticsearch: cluster/kube-up.sh ... Project: kubernetes-satnam Zone: us-central1-b ... calling kube-up Project: kubernetes-satnam Zone: us-central1-b +++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel +++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d) +++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0) Looking for already existing resources Starting master and configuring firewalls Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd]. NAME ZONE SIZE_GB TYPE STATUS kubernetes-master-pd us-central1-b 20 pd-ssd READY Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip]. +++ Logging using Fluentd to elasticsearch Tanto los pods por nodo de Fluentd, como los pods de Elasticsearch, y los pods de Kibana deberían ejecutarse en el namespace de kube-system inmediatamente después de que el clúster esté disponible. kubectl get pods --namespace=kube-system NAME READY STATUS RESTARTS AGE elasticsearch-logging-v1-78nog 1/1 Running 0 2h elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h kibana-logging-v1-bhpo8 1/1 Running 0 2h kube-dns-v3-7r1l9 3/3 Running 0 2h monitoring-heapster-v4-yl332 1/1 Running 1 2h monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h Los pods de `fluentd-elasticsearch` recogen los logs de cada nodo y los envían a los pods de `elasticsearch-logging`, que son parte de un [servicio](https://kubernetes.io/es/docs/concepts/services-networking/service/) llamado `elasticsearch-logging`. Estos pods de Elasticsearch almacenan los logs y los exponen via una API REST. El pod de `kibana-logging` proporciona una UI via web donde leer los logs almacenados en Elasticsearch, y es parte de un servicio denominado `kibana-logging`. Los servicios de Elasticsearch y Kibana ambos están en el namespace `kube-system` y no se exponen de forma directa mediante una IP accesible públicamente. Para poder acceder a dichos logs, sigue las instrucciones acerca de cómo [Acceder a servicios corriendo en un clúster](https://kubernetes.io/docs/concepts/cluster-administration/access-clusater/#accessing-services-running-on-the-cluster) . Si tratas de acceder al servicio de `elasticsearch-logging` desde tu navegador, verás una página de estado que se parece a la siguiente: ![Estado de Elasticsearch](https://kubernetes.io/images/docs/es-browser.png) A partir de ese momento, puedes introducir consultas de Elasticsearch directamente en el navegador, si lo necesitas. Echa un vistazo a la [documentación de Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) para más detalles acerca de cómo hacerlo. De forma alternativa, puedes ver los logs de tu clúster en Kibana (de nuevo usando las [instrucciones para acceder a un servicio corriendo en un clúster](https://kubernetes.io/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster) ). La primera vez que visitas la URL de Kibana se te presentará una página que te pedirá que configures una vista de los logs. Selecciona la opción de valores de serie temporal y luego `@timestamp`. En la página siguiente selecciona la pestaña de `Discover` y entonces deberías ver todos los logs. Puedes establecer el intervalo de actualización en 5 segundos para refrescar los logs de forma regular. Aquí se muestra una vista típica de logs desde el visor de Kibana: ![Kibana logs](https://kubernetes.io/images/docs/kibana-logs.png) Siguientes pasos ---------------- ¡Kibana te permite todo tipo de potentes opciones para explorar tus logs! Puedes encontrar algunas ideas para profundizar en el tema en la [documentación de Kibana](https://www.elastic.co/guide/en/kibana/current/discover.html) . 2.3 - Pipeline de métricas de recursos ====================================== Desde Kubernetes 1.8, las métricas de uso de recursos, tales como el uso de CPU y memoria del contenedor, están disponibles en Kubernetes a través de la API de métricas. Estas métricas son accedidas directamente por el usuario, por ejemplo usando el comando `kubectl top`, o usadas por un controlador en el cluster, por ejemplo el Horizontal Pod Autoscaler, para la toma de decisiones. La API de Métricas ------------------ A través de la API de métricas, Metrics API en inglés, puedes obtener la cantidad de recursos usados actualmente por cada nodo o pod. Esta API no almacena los valores de las métricas, así que no es posible, por ejemplo, obtener la cantidad de recursos que fueron usados por un nodo hace 10 minutos. La API de métricas está completamente integrada en la API de Kubernetes: * se expone a través del mismo endpoint que las otras APIs de Kubernetes bajo el path `/apis/metrics.k8s.io/` * ofrece las mismas garantías de seguridad, escalabilidad y confiabilidad La API está definida en el repositorio [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) . Puedes encontrar más información sobre la API ahí. #### Nota: La API requiere que el servidor de métricas esté desplegado en el clúster. En otro caso no estará disponible. Servidor de Métricas -------------------- El [Servidor de Métricas](https://github.com/kubernetes-incubator/metrics-server) es un agregador de datos de uso de recursos de todo el clúster. A partir de Kubernetes 1.8, el servidor de métricas se despliega por defecto como un objeto de tipo [Deployment](https://github.com/docs/concepts/workloads/controllers/deployment/) en clústeres creados con el script `kube-up.sh`. Si usas otro mecanismo de configuración de Kubernetes, puedes desplegarlo usando los [yamls de despliegue](https://github.com/kubernetes-sigs/metrics-server/releases) proporcionados. Está soportado a partir de Kubernetes 1.7 (más detalles al final). El servidor reune métricas de la Summary API, que es expuesta por el [Kubelet](https://kubernetes.io/docs/admin/kubelet/) en cada nodo. El servidor de métricas se añadió a la API de Kubernetes utilizando el [Kubernetes aggregator](https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation/) introducido en Kubernetes 1.7. Puedes aprender más acerca del servidor de métricas en el [documento de diseño](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/metrics-server.md) . --- # Políticas | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/concepts/policy/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/concepts/policy/) . Políticas ========= Políticas configurables que se aplican a grupos de recursos. * 1: [Rangos de límites (Limit Ranges)](https://kubernetes.io/es/docs/concepts/policy/_print/#pg-a935ff8c59eb116b43494255cc67f69a) La sección de Políticas describe las diferentes políticas configurables que se aplican a grupos de recursos: 1 - Rangos de límites (Limit Ranges) ==================================== Aplica límites de recursos a un Namespace para restringir y garantizar la asignación y consumo de recursos informáticos. ### Contexto Por defecto, los contenedores se ejecutan sin restricciones sobre los [recursos informáticos disponibles en un clúster de Kubernetes](https://kubernetes.io/es/docs/concepts/configuration/manage-resources-containers/) . Si el [Nodo](https://kubernetes.io/es/docs/concepts/architecture/nodes/ "Un Node, nodo en castellano, es una de las máquinas del clúster de Kubernetes.") dispone de los recursos informáticos, un [Pod](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/ "El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.") o sus [Contenedores](https://kubernetes.io/es/docs/concepts/overview/what-is-kubernetes/#why-containers "Una imagen ligera y portátil que contiene un software y todas sus dependencias.") tienen permitido consumir por encima de la cuota solicitada si no superan el límite establecido en su especificación. Existe la preocupación de que un Pod o Contenedor pueda monopolizar todos los recursos disponibles. ### Utilidad Aplicando restricciones de asignación de recursos, los administradores de clústeres se aseguran del cumplimiento del consumo de recursos por espacio de nombre ([Namespace](https://kubernetes.io/es/docs/concepts/overview/working-with-objects/namespaces/ "Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales en el mismo clúster físico.") ). Un **[LimitRange](https://kubernetes.io/es/docs/concepts/policy/limit-range/ "Proporciona restricciones para limitar el consumo de recursos por Contenedores o Pods en un espacio de nombres") ** es la política que permite: * Imponer restricciones de requisitos de recursos a [Pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/ "El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.") o [Contenedores](https://kubernetes.io/es/docs/concepts/overview/what-is-kubernetes/#why-containers "Una imagen ligera y portátil que contiene un software y todas sus dependencias.") por Namespace. * Imponer las limitaciones de recursos mínimas/máximas para Pods o Contenedores dentro de un Namespace. * Especificar requisitos y límites de recursos predeterminados para Pods o Contenedores de un Namespace. * Imponer una relación de proporción entre los requisitos y el límite de un recurso. * Imponer el cumplimiento de las demandas de almacenamiento mínimo/máximo para [Solicitudes de Volúmenes Persistentes](https://kubernetes.io/es/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims "Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor.") . ### Habilitar el LimitRange La compatibilidad con LimitRange está habilitada por defecto en Kubernetes desde la versión 1.10. Para que un LimitRange se active en un [Namespace](https://kubernetes.io/es/docs/concepts/overview/working-with-objects/namespaces/ "Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales en el mismo clúster físico.") en particular, el LimitRange debe definirse con el Namespace, o aplicarse a éste. El nombre de recurso de un objeto LimitRange debe ser un [nombre de subdominio DNS](https://kubernetes.io/es/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names) válido. ### Aplicando LimitRanges * El administrador crea un LimitRange en un [Namespace](https://kubernetes.io/es/docs/concepts/overview/working-with-objects/namespaces/ "Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales en el mismo clúster físico.") . * Los usuarios crean recursos como [Pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/ "El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.") , [Contenedores](https://kubernetes.io/es/docs/concepts/overview/what-is-kubernetes/#why-containers "Una imagen ligera y portátil que contiene un software y todas sus dependencias.") o [Solicitudes de Volúmenes Persistentes](https://kubernetes.io/es/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims "Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor.") en el Namespace. * El controlador de admisión `LimitRanger` aplicará valores predeterminados y límites, para todos los Pods o Contenedores que no establezcan requisitos de recursos informáticos. Y realizará un seguimiento del uso para garantizar que no excedan el mínimo, el máximo, y la proporción de ningún LimitRange definido en el Namespace. * Si al crear o actualizar un recurso del ejemplo (Pods, Contenedores, [Solicitudes de Volúmenes Persistentes](https://kubernetes.io/es/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims "Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor.") ) se viola una restricción al LimitRange, la solicitud al servidor API fallará con un código de estado HTTP "403 FORBIDDEN" y un mensaje que explica la restricción que se ha violado. * En caso de que en se active un LimitRange para recursos de cómputos como `cpu` y `memory`, los usuarios deberán especificar los requisitos y/o límites de recursos a dichos valores. De lo contrario, el sistema puede rechazar la creación del Pod. * Las validaciones de LimitRange ocurren solo en la etapa de Admisión de Pod, no en Pods que ya se han iniciado (Running [Pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/ "El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.") ). Algunos ejemplos de políticas que se pueden crear utilizando rangos de límites son: * En un clúster de 2 nodos con una capacidad de 8 GiB de RAM y 16 núcleos, podría restringirse los [Pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/ "El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.") en un [Namespace](https://kubernetes.io/es/docs/concepts/overview/working-with-objects/namespaces/ "Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales en el mismo clúster físico.") a requerir `100m` de CPU con un límite máximo de `500m` para CPU y requerir `200Mi` de memoria con un límite máximo de `600Mi` de memoria. * Definir el valor por defecto de límite y requisitos de CPU a `150m` y el valor por defecto de requisito de memoria a `300Mi` [Contenedores](https://kubernetes.io/es/docs/concepts/overview/what-is-kubernetes/#why-containers "Una imagen ligera y portátil que contiene un software y todas sus dependencias.") que se iniciaron sin requisitos de CPU y memoria en sus especificaciones. En el caso de que los límites totales del [Namespace](https://kubernetes.io/es/docs/concepts/overview/working-with-objects/namespaces/ "Abstracción utilizada por Kubernetes para soportar múltiples clústeres virtuales en el mismo clúster físico.") sean menores que la suma de los límites de los [Pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/ "El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.") , puede haber contienda por los recursos. En este caso, los contenedores o pods no seran creados. Ni la contención ni los cambios en un LimitRange afectarán a los recursos ya creados. Siguientes pasos ---------------- Consulte el [documento de diseño del LimitRanger](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) para más información. Los siguientes ejemplos utilizan límites y están pendientes de su traducción: * [how to configure minimum and maximum CPU constraints per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) . * [how to configure minimum and maximum Memory constraints per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) . * [how to configure default CPU Requests and Limits per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) . * [how to configure default Memory Requests and Limits per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) . * [how to configure minimum and maximum Storage consumption per namespace](https://kubernetes.io/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage) . * [a detailed example on configuring quota per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) . --- # 클러스터 아키텍처 | Kubernetes 이 섹션의 다중 페이지 출력 화면임. [여기를 클릭하여 프린트](https://kubernetes.io/ko/docs/concepts/architecture/_print/#) . [이 페이지의 일반 화면으로 돌아가기](https://kubernetes.io/ko/docs/concepts/architecture/) . 클러스터 아키텍처 ========= 쿠버네티스 뒤편의 구조와 설계 개념들 * 1: [노드](https://kubernetes.io/ko/docs/concepts/architecture/_print/#pg-9ef2890698e773b6c0d24fd2c20146f5) * 2: [컨트롤 플레인-노드 간 통신](https://kubernetes.io/ko/docs/concepts/architecture/_print/#pg-c0251def6da29b30afebfb04549f1703) * 3: [리스(Lease)](https://kubernetes.io/ko/docs/concepts/architecture/_print/#pg-d5e64235fa89f107957072cd8a39e4c5) * 4: [컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/_print/#pg-ca8819042a505291540e831283da66df) * 5: [클라우드 컨트롤러 매니저](https://kubernetes.io/ko/docs/concepts/architecture/_print/#pg-bc804b02614d67025b4c788f1ca87fbc) * 6: [cgroup v2에 대하여](https://kubernetes.io/ko/docs/concepts/architecture/_print/#pg-c20ec7d296cc2c8668bb204c2af31180) * 7: [쿠버네티스 자가 치유](https://kubernetes.io/ko/docs/concepts/architecture/_print/#pg-f992b9b0f5b827e6fe522de5dde184cc) * 8: [가비지(Garbage) 수집](https://kubernetes.io/ko/docs/concepts/architecture/_print/#pg-44a2e2e592af0846101e970aff9243e5) 쿠버네티스 클러스터는 컨트롤 플레인과 노드라고 불리는 일련의 워커 머신으로 구성되어 있으며, 이 노드들은 컨테이너화된 애플리케이션을 실행한다. 모든 클러스터는 파드를 실행하기 위해 최소한 하나의 워커 노드가 필요하다. 워커 노드는 애플리케이션 워크로드의 구성 요소인 파드를 호스팅한다. 컨트롤 플레인은 클러스터 내의 워커 노드와 파드를 관리한다. 프로덕션 환경에서, 컨트롤 플레인은 보통 여러 대의 컴퓨터에서 실행되며, 클러스터는 일반적으로 여러 개의 노드를 실행하여, 장애 허용성과 고가용성을 제공한다. 이 문서는 완전하고 동작하는 쿠버네티스 클러스터를 구성하기 위해 필요한 다양한 컴포넌트를 설명한다. ![컨트롤 플레인 (kube-apiserver, etcd, kube-controller-manager, kube-scheduler)과 여러 노드이다. 각 노드는 kubelet과 kube-proxy를 실행한다.](https://kubernetes.io/images/docs/kubernetes-cluster-architecture.svg) 그림 1. 쿠버네티스 클러스터 컴포넌트. 이 아키텍처에 대해서 그림 1의 다이어그램은 쿠버네티스 클러스터에 대한 예시 참조 아키텍처를 나타낸다. 실제 컴포넌트의 분포는 특정 클러스터의 설정과 요구사항에 따라 달라질 수 있다. 다이어그램에서, 각 노드는 [`kube-proxy`](https://kubernetes.io/ko/docs/concepts/architecture/_print/#kube-proxy) 컴포넌트를 실행한다. 클러스터 네트워크에서 [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/ "네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법") API와 관련 동작을 사용할 수 있도록 각 노드에는 네트워크 프록시 컴포넌트가 필요하다. 그러나, 일부 네트워크 플러그인은 자체 서드파티 프록시 구현을 제공한다. 그러한 네트워크 플러그인을 사용할 경우, 해당 노드에서 `kube-proxy`를 실행할 필요가 없다. 컨트롤 플레인 컴포넌트 ------------ 컨트롤 플레인의 컴포넌트는 클러스터에 대한 전역적인 결정(예를 들어, 스케줄링)뿐만 아니라, 클러스터의 이벤트를 감지하고 대응한다. (예를 들면, 디플로이먼트의 `[레플리카](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-replica "Replicas are copies of pods, ensuring availability, scalability, and fault tolerance by maintaining identical instances.") ` 필드가 충족되지 않을 때 [파드](https://kubernetes.io/ko/docs/concepts/workloads/pods/ "파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.") 를 새로 시작) 컨트롤 플레인 컴포넌트는 클러스터 안의 어떤 머신에서도 실행될 수 있다. 그러나 설정 스크립트는 일반적으로 모든 컨포넌트를 동일한 머신에서 시작하며, 이 머신에서는 사용자 컨테이너를 실행하지 않는다. 여러 머신에 걸쳐 컨트롤 플레인을 실행하는 예시 설정은 [kubeadm을 사용한 고가용성 클러스터 생성](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) 에서 참고한다. ### kube-apiserver API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 [컨트롤 플레인](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-control-plane "컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어.") 컴포넌트이다. API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다. 쿠버네티스 API 서버의 주요 구현은 [kube-apiserver](https://kubernetes.io/docs/reference/generated/kube-apiserver/) 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다. ### etcd 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소. 쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 [백업](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) 하는 계획은 필수이다. etcd에 대한 자세한 정보는, 공식 [문서](https://etcd.io/docs) 를 참고한다. ### kube-scheduler [노드](https://kubernetes.io/ko/docs/concepts/architecture/nodes/ "노드는 쿠버네티스의 작업 장비(worker machine)이다.") 가 배정되지 않은 새로 생성된 [파드](https://kubernetes.io/ko/docs/concepts/workloads/pods/ "파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.") 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트. 스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다. ### kube-controller-manager [컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/controller/ "API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.") 프로세스를 실행하는 컨트롤 플레인 컴포넌트. 논리적으로, 각 [컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/controller/ "API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.") 는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다. 컨트롤러에는 여러 가지 유형이 있다. 몇 가지 예시는 다음과 같다. * 노드 컨트롤러(Node Controller): 노드가 다운될 때 이를 감지하고 대응한다. * 잡 컨트롤러(Job Controller): 일회성 작업을 나타내는 잡(Job) 오브젝트를 감시하고, 해당 작업을 수행하기 위한 파드를 생성한다. * 엔드포인트슬라이스 컨트롤러(EndpointSlice controller): 엔드포인트슬라이스 오브젝트를 채워서 파드와 서비스 사이의 연결을 제공한다. * 서비스어카운트 컨트롤러(ServiceAccount controller): 신규 네임스페이스에 기본 서비스어카운트를 생성한다. 위 목록이 전부는 아니다. ### 클라우드 컨트롤러 매니저 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 [컨트롤 플레인](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-control-plane "컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어.") 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다. 클라우드 컨트롤러 매니저는 오직 클라우드 공급자에 특화된 컨트롤러만 실행한다. 쿠버네티스를 온프레미스 환경이나, 개인 PC의 학습환경에서 실행하는 경우, 클러스터에는 클라우드 컨트롤러 매니저가 없다. kube-controller-manager와 마찬가지로, 클라우드 컨트롤러 매니저는 여러 개의 논리적으로 독립된 컨트롤 루프를 단일 바이너리로 결합하여 하나의 프로세스로 실행한다. 성능을 향상시키거나 장애 허용성을 높이기 위해 수평 확장(하나 이상의 복제본을 실행)할 수 있다. 다음과 같은 컨트롤러는 클라우드 공급자 의존성을 가질 수 있다. * 노드 컨트롤러(Node controller): 노드가 응답을 멈춘 뒤 클라우드에서 해당 노드가 삭제되었는지를 판단하기 위해 클라우드 공급자를 확인한다. * 라우트 컨트롤러(Route controller): 클라우드 인프라스트럭처 기반에서 라우트를 설정한다. * 서비스 컨트롤러(Service controller): 클라우드 공급자의 로드 밸런서를 생성, 업데이트, 삭제한다. * * * 노드 컴포넌트 ------- 노드 컴포넌트는 모든 노드에서 실행되며, 실행 중인 파드를 유지하고 쿠버네티스 런타임 환경을 제공한다. ### kubelet 클러스터의 각 [노드](https://kubernetes.io/ko/docs/concepts/architecture/nodes/ "노드는 쿠버네티스의 작업 장비(worker machine)이다.") 에서 실행되는 에이전트. Kubelet은 [파드](https://kubernetes.io/ko/docs/concepts/workloads/pods/ "파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.") 에서 [컨테이너](https://kubernetes.io/ko/docs/concepts/containers/ "소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지.") 가 확실하게 동작하도록 관리한다. Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다. ### kube-proxy (선택 사항) kube-proxy는 클러스터의 각 [노드](https://kubernetes.io/ko/docs/concepts/architecture/nodes/ "노드는 쿠버네티스의 작업 장비(worker machine)이다.") 에서 실행되는 네트워크 프록시로, 쿠버네티스의 [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/ "네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법") 개념의 구현부이다. [kube-proxy](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/kube-proxy/) 는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다. 서비스에 대한 패킷 포워딩을 자체적으로 구현하고, kube-proxy와 동등한 동작을 제공하는 [네트워크 플러그인](https://kubernetes.io/ko/docs/concepts/architecture/_print/#network-plugins) 을 사용하는 경우, 클러스터 노드에서 kube-proxy를 실행할 필요가 없다. ### 컨테이너 런타임 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다. 쿠버네티스는 [containerd](https://containerd.io/docs/ "A container runtime with an emphasis on simplicity, robustness and portability") , [CRI-O](https://cri-o.io/#what-is-cri-o "A lightweight container runtime specifically for Kubernetes") 와 같은 컨테이너 런타임 및 모든 [Kubernetes CRI (컨테이너 런타임 인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) 구현체를 지원한다. 애드온 --- 애드온은 쿠버네티스 리소스([데몬셋 (원문, DaemonSet)](https://kubernetes.io/ko/docs/concepts/workloads/controllers/daemonset "파드의 복제본을 클러스터 노드 집합에서 동작하게 한다.") , [디플로이먼트 (원문, Deployment)](https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/ "클러스터에서 복제된 애플리케이션을 관리한다.") , 등)를 사용하여, 클러스터의 기능을 구현한다. 클러스터 수준의 기능을 제공하기 때문에, 애드온의 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다. 선택된 애드온은 아래에 설명되어 있다. 사용 가능한 애드온의 더 많은 목록은, [애드온](https://kubernetes.io/ko/docs/concepts/cluster-administration/addons/) 을 참고한다. ### DNS 다른 애드온들은 반드시 필요하지 않지만, 많은 예제가 이를 기반으로 하기에, 모든 클러스터에는 [클러스터 DNS](https://kubernetes.io/ko/docs/concepts/services-networking/dns-pod-service/) 가 있어야 한다. 클러스터 DNS는 쿠버네티스 서비스에 대한 DNS 레코드를 제공하는 DNS 서버로, 사용자 환경에 있는 다른 DNS 서버와 별개로 동작한다. 쿠버네티스에 의해 실행된 컨테이너는 자동으로 이 DNS 서버를 DNS 검색에 포함한다. ### 웹 UI (대시보드) [대시보드](https://kubernetes.io/ko/docs/tasks/access-application-cluster/web-ui-dashboard/) 는 쿠버네티스 클러스터를 위한 범용 웹 기반 UI이다. 이를 통해 사용자는 클러스터 자체 뿐만 아니라, 클러스터에서 실행중인 애플리케이션을 관리하고 문제를 해결할 수 있다. ### 컨테이너 리소스 모니터링 [컨테이너 리소스 모니터링](https://kubernetes.io/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) 은 컨테이너에 대한 일반적인 시계열 메트릭을 중앙 데이터베이스에 기록하고, 해당 데이터를 탐색할 수 있는 UI를 제공한다. ### 클러스터 수준 로깅 [클러스터 수준 로깅](https://kubernetes.io/ko/docs/concepts/cluster-administration/logging/) 메커니즘은 컨테이너 로그를 검색/탐색 인터페이스를 갖춘 중앙 로그 저장소에 저장하는 역할을 한다. ### 네트워크 플러그인 [네트워크 플러그인](https://kubernetes.io/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins) 은 컨테이너 네트워크 인터페이스(CNI) 사양을 구현하는 소프트웨어 컴포넌트이다. 이는 파드에 IP 주소를 할당하고 클러스터 내에서 서로 통신할 수 있도록 하는 역할을 한다. 아키텍처 변형 ------- 쿠버네티스의 핵심 컴포넌트는 일관성을 유지하지만, 배포되고 관리되는 방식은 달라질 수 있다. 이러한 변형을 이해하는 것은 특정 운영 요구 사항을 충족하는 쿠버네티스 클러스터를 설계하고 유지하는 데 매우 중요하다. ### 컨트롤 플레인 배포 옵션 컨트롤 플레인 컴포넌트는 여러 방식으로 배포될 수 있다. 전통적인 배포 컨트롤 플레인 컴포넌트가 전용 머신이나 VM에서 직접적으로 실행되며, 보통 systemd 서비스로 관리된다. 정적 파드 컨트롤 플레인 컴포넌트가 정적 파드로 배포되며, 특정 노드의 kubelet에 의해 관리된다. 이는 kubeadm과 같은 도구에서 사용하는 일반적인 방식이다. 셀프 호스팅(Self-hosted) 컨트롤 플레인이 쿠버네티스 클러스터 자체 내에서 파드로 실행되며, 디플로이먼트(Deployment)와 스테이트풀셋(StatefulSet) 또는 다른 쿠버네티스 리소스에 의해 관리된다. 매니지드 쿠버네티스 서비스(Managed Kubernetes services) 클라우드 공급자는 종종 컨트롤 플레인을 추상화하여, 자사 서비스 제공의 일부로 컴포넌트를 관리해 준다. ### 워크로드 배치 고려사항 컨트롤 플레인 컨포넌트를 포함한 워크로드 배치는 클러스터의 크기, 성능 요구사항, 운영 정책에 따라 달라질 수 있다. * 작은 규모의 클러스터나 개발용 클러스터에서는, 컨트롤 플레인 컴포넌트와 사용자 워크로드가 동일한 노드에서 실행될 수 있다. * 대규모 프로덕션 클러스터에서는 보통 컨트롤 플레인 컴포넌트 전용 노드를 두어, 사용자 워크로드와 분리한다. * 일부 조직은 중요한 애드온이나 모니터링 도구를 컨트롤 플레인에서 실행한다. ### 클러스터 관리 도구 kubeadm, kops 그리고 Kubespray 같은 도구들은 클러스터를 배포하고 관리하는 데 서로 다른 접근 방식을 제공하며, 각 도구는 고유한 컴포넌트 배치 및 관리 방식을 가진다. 쿠버네티스 아키텍처의 유연성 덕분에 조직은 기능 복잡성, 성능, 그리고 관리 부담과 같은 요소들을 균형있게 고려하여 클러스터를 특정 요구사항에 맞게 조정할 수 있다. ### 커스터마이제이션과 확장성 쿠버네티스 아키텍처는 다양한 커스터마이제이션을 허용한다. * 기본 쿠버네티스 스케줄러와 함께 동작하거나 완전히 대체하기 위해 커스텀 스케줄러를 배포할 수 있다. * API 서버는 커스텀리소스정의(CustomResourceDefinitions)와 API 집계를 통해 확장될 수 있다. * 클라우드 공급자는 클라우드 컨트롤러 매니저를 사용하여 쿠버네티스와 긴밀하게 통합할 수 있다. 쿠버네티스 아키텍처의 유연성 덕분에 조직은 기능 복잡성, 성능, 그리고 관리 부담과 같은 요소들을 균형있게 고려하여 클러스터를 특정 요구사항에 맞게 조정할 수 있다. 다음 내용 ----- 다음 내용을 통해 더 알아보자. * [노드](https://kubernetes.io/ko/docs/concepts/architecture/nodes/) 와 컨트롤 플레인과의 [통신](https://kubernetes.io/ko/docs/concepts/architecture/control-plane-node-communication/) . * 쿠버네티스 [컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/controller/) . * 쿠버네티스의 기본 스케줄러인 [kube-scheduler](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/kube-scheduler/) . * Etcd의 공식 [문서](https://etcd.io/docs/) . * 쿠버네티스에서 사용되는 여러 [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/) . * [클라우드 컨트롤러 매니저](https://kubernetes.io/ko/docs/concepts/architecture/cloud-controller/) 를 사용한 클라우드 공급자 통합. * [kubectl](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands) 명령어. 1 - 노드 ====== 쿠버네티스는 컨테이너를 파드내에 배치하고 _노드_ 에서 실행함으로 [워크로드](https://kubernetes.io/ko/docs/concepts/workloads/ "워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다.") 를 구동한다. 노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는 [컨트롤 플레인](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-control-plane "컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어.") 에 의해 관리되며 [파드](https://kubernetes.io/ko/docs/concepts/workloads/pods/ "파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.") 를 실행하는 데 필요한 서비스를 포함한다. 일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는 환경에서는 하나만 있을 수도 있다. 노드의 [컴포넌트](https://kubernetes.io/ko/docs/concepts/overview/components/#%EB%85%B8%EB%93%9C-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8) 에는 [kubelet](https://kubernetes.io/ko/docs/reference/generated/kubelet "클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.") , [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/ "컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.") 그리고 [kube-proxy](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/kube-proxy/ "kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다.") 가 포함된다. 관리 -- [API 서버](https://kubernetes.io/ko/docs/concepts/overview/components/#kube-apiserver "쿠버네티스 API를 제공하는 컨트롤 플레인 컴포넌트.") 에 노드를 추가하는 두가지 주요 방법이 있다. 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록 2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가 노드 [오브젝트](https://kubernetes.io/ko/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects "클러스터 상태의 일부를 나타내는 쿠버네티스 시스템의 엔티티이다.") 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. 예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다. { "kind": "Node", "apiVersion": "v1", "metadata": { "name": "10.240.79.157", "labels": { "name": "my-first-k8s-node" } } } 쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는 kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어 있는지 확인한다. 노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다. 그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에 대해 무시된다. #### 참고: 쿠버네티스는 유효하지 않은 노드 오브젝트를 유지하고, 노드가 정상적인지 확인한다. 상태 확인을 중지하려면 사용자 또는 [컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/controller/ "API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.") 에서 노드 오브젝트를 명시적으로 삭제해야 한다. 노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/names/#dns-%EC%84%9C%EB%B8%8C%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%9D%B4%EB%A6%84) 이어야 한다. ### 노드 이름 고유성 [이름](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/names#names) 은 노드를 식별한다. 두 노드는 동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가 동일한 객체라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한 상태(예: 네트워크 설정, 루트 디스크 내용)와 노드 레이블과 같은 동일한 속성(attribute)을 갖는다고 암시적으로 가정한다. 인스턴스가 이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나 업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고 업데이트 후 다시 추가해야 한다. ### 노드에 대한 자체-등록(self-registration) kubelet 플래그 `--register-node`가 참(기본값)일 경우, kubelet은 API 서버에 스스로 등록을 시도할 것이다. 이는 선호되는 패턴이며, 대부분의 배포판에서 사용된다. 자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다. * `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로. * `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 [클라우드 제공자](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-cloud-provider "클라우드 컴퓨팅 플랫폼을 제공하는 조직.") 와 소통할지에 대한 방법. * `--register-node` - 자동으로 API 서버에 등록. * `--register-with-taints` - 주어진 [테인트(taint)](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/ "세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.") 리스트(콤마로 분리된 `=:`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안 함. * `--node-ip` - 선택적인, 쉼표로 구분된 노드의 IP 주소의 리스트. 각 주소 체계마다 하나의 주소만 지정 가능. 예를 들어, 단일 스택 IPv4 클러스터에서는 kubelet이 노드의 주소로 쓸 수 있게 IPv4 주소로 설정함. 이중 스택 클러스터 실행에 관한 상세 정보는 [IPv4/IPv6 이중 스택 구성](https://kubernetes.io/ko/docs/concepts/services-networking/dual-stack/#ipv4/ipv6-%EC%9D%B4%EC%A4%91-%EC%8A%A4%ED%83%9D-%EA%B5%AC%EC%84%B1) 을 참고. 이 인자를 사용하지 않으면 kubelet은 노드의 기본 IPv4 주소를 사용함. 만약 노드가 IPv4 주소가 없으면 kubelet은 노드의 기본 IPv6 주소를 사용함. * `--node-labels` - 클러스터에 노드를 등록할 때 추가 할 [레이블](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels "사용자에게 의미 있고 관련성 높은 특징으로 식별할 수 있도록 오브젝트에 태그를 붙인다.") ([NodeRestriction admission plugin](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 에 의해 적용되는 레이블 제한 사항 참고). * `--node-status-update-frequency` - 얼마나 자주 kubelet이 API 서버에 해당 노드 상태를 게시할 지 정의. [Node authorization mode](https://kubernetes.io/docs/reference/access-authn-authz/node/) 와 [NodeRestriction admission plugin](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 이 활성화 되면, 각 kubelet은 자신이 속한 노드의 리소스에 대해서만 생성/수정할 권한을 가진다. #### 참고: [노드 이름 고유성](https://kubernetes.io/ko/docs/concepts/architecture/_print/#%EB%85%B8%EB%93%9C-%EC%9D%B4%EB%A6%84-%EA%B3%A0%EC%9C%A0%EC%84%B1) 섹션에서 언급했듯이, 노드 구성을 업데이트해야 하는 경우 API 서버에 노드를 다시 등록하는 것이 좋다. 예를 들어 kubelet이 `--node-labels`의 새로운 구성으로 다시 시작되더라도, 동일한 노드 이름이 사용된 경우 레이블이 해당 노드의 등록에 설정되기 때문에 변경 사항이 적용되지 않는다. 노드에 이미 스케줄된 파드는 해당 노드 구성이 kubelet 재시작에 의해 변경된 경우 오작동하거나 문제를 일으킬 수 있다. 예를 들어 이미 실행 중인 파드가 노드에 할당된 새 레이블에 대해 테인트(taint)될 수 있는 반면 해당 파드와 호환되지 않는 다른 파드는 새 레이블을 기반으로 스케줄링된다. 노드 재등록(re-registration)은 모든 파드를 비우고(drain) 다시 적절하게 스케줄링되도록 한다. #### 수동 노드 관리 [kubectl](https://kubernetes.io/ko/docs/user-guide/kubectl-overview/ "쿠버네티스 클러스터와 통신하기 위한 커맨드라인 툴.") 을 사용해서 노드 오브젝트를 생성하고 수정할 수 있다. 노드 오브젝트를 수동으로 생성하려면 kubelet 플래그를 `--register-node=false` 로 설정한다. `--register-node` 설정과 관계 없이 노드 오브젝트를 수정할 수 있다. 예를 들어 기존 노드에 레이블을 설정하거나, 스케줄 불가로 표시할 수 있다. 파드의 노드 셀렉터와 함께 노드의 레이블을 사용해서 스케줄링을 제어할 수 있다. 예를 들어, 사용 가능한 노드의 하위 집합에서만 실행되도록 파드를 제한할 수 있다. 노드를 스케줄 불가로 표시하면 스케줄러가 해당 노드에 새 파드를 배치할 수 없지만, 노드에 있는 기존 파드에는 영향을 미치지 않는다. 이는 노드 재부팅 또는 기타 유지보수 준비 단계에서 유용하다. 노드를 스케줄 불가로 표시하려면 다음을 실행한다. kubectl cordon $NODENAME 보다 자세한 내용은 [안전하게 노드를 드레인(drain)하기](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) 를 참고한다. #### 참고: [데몬셋 (원문, DaemonSet)](https://kubernetes.io/ko/docs/concepts/workloads/controllers/daemonset "파드의 복제본을 클러스터 노드 집합에서 동작하게 한다.") 에 포함되는 일부 파드는 스케줄 불가 노드에서 실행될 수 있다. 일반적으로 데몬셋은 워크로드 애플리케이션을 비우는 경우에도 노드에서 실행되어야 하는 노드 로컬 서비스를 제공한다. 노드 상태 ----- 노드의 상태는 다음의 정보를 포함한다. * [주소](https://kubernetes.io/ko/docs/reference/node/node-status/#addresses) * [컨디션](https://kubernetes.io/ko/docs/reference/node/node-status/#condition) * [용량과 할당가능](https://kubernetes.io/ko/docs/reference/node/node-status/#capacity) * [정보](https://kubernetes.io/ko/docs/reference/node/node-status/#info) `kubectl` 을 사용해서 노드 상태와 기타 세부 정보를 볼수 있다. kubectl describe node 자세한 정보는 [노드 상태](https://kubernetes.io/ko/docs/reference/node/node-status/) 를 참고. 노드 하트비트 ------- 쿠버네티스 노드가 보내는 하트비트는 클러스터가 개별 노드가 가용한지를 판단할 수 있도록 도움을 주고, 장애가 발견된 경우 조치를 할 수 있게한다. 노드에는 두 가지 형태의 하트비트가 있다. * 노드의 `.status`에 대한 업데이트 * `kube-node-lease` [네임스페이스](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/ "쿠버네티스에서, 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상화.") 내의 [리스(Lease)](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트. 각 노드는 연관된 리스 오브젝트를 갖는다. 노드 컨트롤러 ------- 노드 [컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/controller/ "API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.") 는 노드의 다양한 측면을 관리하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에 (CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다. 두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다. 세 번째는 노드의 동작 상태를 모니터링하는 것이다. 노드 컨트롤러는 다음을 담당한다. * 노드가 접근 불가능(unreachable) 상태가 되는 경우, 노드의 `.status` 필드의 `Ready` 컨디션을 업데이트한다. 이 경우에는 노드 컨트롤러가 `Ready` 컨디션을 `Unknown`으로 설정한다. * 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서 [API를 이용한 축출](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/api-eviction/) 을 트리거한다. 기본적으로, 노드 컨트롤러는 노드를 `Unknown`으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다. 기본적으로, 노드 컨트롤러는 5 초마다 각 노드의 상태를 체크한다. 체크 주기는 `kube-controller-manager` 구성 요소의 `--node-monitor-period` 플래그를 이용하여 설정할 수 있다. ### 축출 빈도 제한 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여 파드 축출을 하지 않는다는 의미가 된다. 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 체크한다(`Ready` 컨디션은 `Unknown` 또는 `False` 값을 가진다). * 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold` (기본값 0.55)가 되면 축출 속도가 감소한다. * 클러스터가 작으면 (즉 `--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출이 중지된다. * 이외의 경우, 축출 속도는 초당 `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 컨트롤 플레인으로부터 분할되어 질 수도 있기 때문이다. 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않는 이상, 축출 매커니즘은 영역 별 가용성을 고려하지 않는다. 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 `--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이 완전히 상태불량(클러스터 내 양호한 노드가 없는 경우)한 경우이다. 이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 나머지 노드에서 파드를 축출한다.) 또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의 노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다. 추가로, 노드 컨틀로러는 연결할 수 없거나, 준비되지 않은 노드와 같은 노드 문제에 상응하는 [테인트](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/ "세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.") 를 추가한다. 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다. 리소스 용량 추적 --------- 노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의 양과 CPU의 수를 추적한다. 노드의 [자체 등록](https://kubernetes.io/ko/docs/concepts/architecture/_print/#%EB%85%B8%EB%93%9C%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9E%90%EC%B2%B4-%EB%93%B1%EB%A1%9D) 은 등록하는 중에 용량을 보고한다. [수동](https://kubernetes.io/ko/docs/concepts/architecture/_print/#%EC%88%98%EB%8F%99-%EB%85%B8%EB%93%9C-%EA%B4%80%EB%A6%AC) 으로 노드를 추가하는 경우 추가할 때 노드의 용량 정보를 설정해야 한다. 쿠버네티스 [스케줄러](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/kube-scheduler/ "노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.") 는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다. 스케줄러는 노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다. 요청의 합은 kubelet에서 관리하는 모든 컨테이너를 포함하지만, 컨테이너 런타임에 의해 직접적으로 시작된 컨 테이너는 제외되고 kubelet의 컨트롤 범위 밖에서 실행되는 모든 프로세스도 제외된다. #### 참고: 파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, [시스템 데몬에 사용할 리소스 예약하기](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 을 본다. 노드 토폴로지 ------- 기능 상태: `Kubernetes v1.27 [stable]`(enabled by default) `TopologyManager` [기능 게이트(feature gate)](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다. 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/) 을 본다. 다음 내용 ----- * 노드를 구성하는 [컴포넌트](https://kubernetes.io/ko/docs/concepts/overview/components/#%EB%85%B8%EB%93%9C-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8) 에 대해 알아본다. * [노드에 대한 API 정의](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#node-v1-core) 를 읽어본다. * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) 섹션을 읽어본다. * [그레이스풀(Graceful)/논 그레이스풀 노드 셧다운](https://kubernetes.io/ko/docs/concepts/cluster-administration/node-shutdown/) 을 읽어본다. * 클러스터에서 노드의 수와 크기를 조절하기 위해 [노드 오토스케일링](https://kubernetes.io/ko/docs/concepts/cluster-administration/node-autoscaling/) 을 읽어본다. * [테인트와 톨러레이션](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/) 을 읽어본다. * [노드 리소스 매니저](https://kubernetes.io/ko/docs/concepts/policy/node-resource-managers/) 를 읽어본다. * [윈도우 노드를 위한 리소스 관리](https://kubernetes.io/ko/docs/concepts/configuration/windows-resource-management/) 를 읽어본다. 2 - 컨트롤 플레인-노드 간 통신 =================== 이 문서는 [API 서버](https://kubernetes.io/ko/docs/concepts/overview/components/#kube-apiserver "쿠버네티스 API를 제공하는 컨트롤 플레인 컴포넌트.") 와 쿠버네티스 [클러스터](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-cluster "컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.") 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다. 노드에서 컨트롤 플레인으로의 통신 ------------------ 쿠버네티스는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 [인증](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다. 특히 [익명의 요청](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) 이 허용되는 경우, 하나 이상의 [권한 부여](https://kubernetes.io/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다. 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 [인증서](https://kubernetes.io/ko/docs/tasks/tls/managing-tls-in-a-cluster/ "암호화된 안전한 파일로 쿠버네티스 클러스터 접근 검증에 사용한다.") (root certificate)로 프로비전해야 한다. 클라이언트 인증서(client certificate) 형식으로 kubelet의 클라이언트 자격 증명을 사용하는 것은 좋은 방법이다. kubelet 클라이언트 인증서(client certificate)의 자동 프로비저닝은 [kubelet TLS 부트스트랩](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 을 참고한다. API 서버에 연결하려는 [파드](https://kubernetes.io/ko/docs/concepts/workloads/pods/ "파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.") 는 서비스 어카운트를 활용하여 안전하게 쿠버네티스가 공개 루트 인증서(root certificate)와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입할 수 있다. `kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(`[kube-proxy](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/kube-proxy/ "kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다.") `를 통해)로 구성되어 있다. 컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다. 결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다. 컨트롤 플레인에서 노드로의 통신 ----------------- 컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 [kubelet](https://kubernetes.io/ko/docs/reference/generated/kubelet "클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.") 프로세스이다. 두 번째는 API 서버의 _프록시_ 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다. ### API 서버에서 kubelet으로의 통신 API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. * 파드에 대한 로그를 가져온다. * 실행 중인 파드에 (보통의 경우 kubectl을 통해) 연결한다. * kubelet의 포트-포워딩 기능을 제공한다. 위와 같은 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 제공(serving) 인증서를 확인하지 않는다. 이는 연결이 중간자 공격(man-in-the-middle)에 시달리게 하며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** . 이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여 API 서버에 kubelet의 제공(serving) 인증서를 확인하는데 사용할 루트 인증서 번들을 제공한다. 이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우, API 서버와 kubelet 간 [SSH 터널링](https://kubernetes.io/ko/docs/concepts/architecture/_print/#ssh-%ED%84%B0%EB%84%90) 을 사용한다. 마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 인가](https://kubernetes.io/ko/docs/reference/access-authn-authz/kubelet-authn-authz/) 를 활성화해야 한다. ### API 서버에서 노드, 파드 및 서비스로의 통신 API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. 이 연결에서 URL을 노드, 파드 또는 서비스 이름에 접두어 `https:` 을 붙여 보안 HTTPS 연결이 되도록 실행할 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않으며 클라이언트 자격 증명도 제공하지 않는다. 그래서 연결이 암호화되는 동안 그 어떤 무결성도 보장되지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** . ### SSH 터널 쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고 (포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다. 이 터널은 노드가 실행 중인 네트워크의 외부로 트래픽이 노출되지 않도록 한다. #### 참고: SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다. [Konnectivity 서비스](https://kubernetes.io/ko/docs/concepts/architecture/_print/#konnectivity-service) 가 SSH 통신 채널을 대체한다. ### Konnectivity 서비스 기능 상태: `Kubernetes v1.18 [beta]` SSH 터널을 대체로, Konnectivity 서비스는 컨트롤 플레인과 클러스터 간 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다. Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다. [Konnectivity 서비스 태스크](https://kubernetes.io/ko/docs/tasks/extend-kubernetes/setup-konnectivity/) 을 따라 클러스터에서 Konnectivity 서비스를 설정한다. 다음 내용 ----- * [쿠버네티스 컨트롤 플레인 컴포넌트](https://kubernetes.io/ko/docs/concepts/architecture/#control-plane-components) 에 대해 읽어보자 * [Hubs와 Spoke model](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors) 에 대해 더 배워보자 * [클러스터 보안](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) 방법에 대해 배워보자 * [쿠버네티스 API](https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/) 에 대해 더 알아보자 * [Konnectivity 서비스 설정하기](https://kubernetes.io/ko/docs/tasks/extend-kubernetes/setup-konnectivity/) * [포트 포워딩을 사용해서 클러스터 내 애플리케이션에 접근하기](https://kubernetes.io/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) * [파드 로그 확인하기](https://kubernetes.io/ko/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs) , [kubectl port-forward 사용하기](https://kubernetes.io/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod) 에 대해 알아보자 3 - 리스(Lease) ============= 분산 시스템에는 종종 공유 리소스를 잠그고 노드 간의 활동을 조정하는 메커니즘을 제공하는 "리스(Lease)"가 필요하다. 쿠버네티스에서 "리스" 개념은 `coordination.k8s.io` API 그룹에 있는 `Lease` 오브젝트로 표현되며, 노드 하트비트 및 컴포넌트 수준의 리더 선출과 같은 시스템 핵심 기능에서 사용된다. 노드 하트비트 ------- 쿠버네티스는 리스 API를 사용하여 kubelet 노드의 하트비트를 쿠버네티스 API 서버에 전달한다. 모든 `노드`에는 같은 이름을 가진 `Lease` 오브젝트가 `kube-node-lease` 네임스페이스에 존재한다. 내부적으로, 모든 kubelet 하트비트는 이 `Lease` 오브젝트에 대한 업데이트 요청이며, 이 업데이트 요청은 `spec.renewTime` 필드를 업데이트한다. 쿠버네티스 컨트롤 플레인은 이 필드의 타임스탬프를 사용하여 해당 `노드`의 가용성을 확인한다. 자세한 내용은 [노드 리스 오브젝트](https://kubernetes.io/ko/docs/concepts/architecture/nodes/#heartbeats) 를 참조한다. 리더 선출 ----- 리스는 쿠버네티스에서도 특정 시간 동안 컴포넌트의 인스턴스 하나만 실행되도록 보장하는 데에도 사용된다. 이는 구성 요소의 한 인스턴스만 활성 상태로 실행되고 다른 인스턴스는 대기 상태여야 하는 `kube-controller-manager` 및 `kube-scheduler`와 같은 컨트롤 플레인 컴포넌트의 고가용성 설정에서 사용된다. API 서버 신원 --------- 기능 상태: `Kubernetes v1.26 [beta]` 쿠버네티스 v1.26부터, 각 `kube-apiserver`는 리스 API를 사용하여 시스템의 나머지 부분에 자신의 신원을 게시한다. 그 자체로는 특별히 유용하지는 않지만, 이것은 클라이언트가 쿠버네티스 컨트롤 플레인을 운영 중인 `kube-apiserver` 인스턴스 수를 파악할 수 있는 메커니즘을 제공한다. kube-apiserver 리스의 존재는 향후 각 kube-apiserver 간의 조정이 필요할 때 기능을 제공해 줄 수 있다. 각 kube-apiserver가 소유한 리스는 `kube-system` 네임스페이스에서`apiserver-`라는 이름의 리스 오브젝트를 확인하여 볼 수 있다. 또는 `k8s.io/component=kube-apiserver` 레이블 설렉터를 사용하여 볼 수도 있다. $ kubectl -n kube-system get lease -l k8s.io/component=kube-apiserver NAME HOLDER AGE kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4 5m33s kube-apiserver-dz2dqprdpsgnm756t5rnov7yka kube-apiserver-dz2dqprdpsgnm756t5rnov7yka_84f2a85d-37c1-4b14-b6b9-603e62e4896f 4m23s kube-apiserver-fyloo45sdenffw2ugwaz3likua kube-apiserver-fyloo45sdenffw2ugwaz3likua_c5ffa286-8a9a-45d4-91e7-61118ed58d2e 4m43s 리스 이름에 사용된 SHA256 해시는 kube-apiserver가 보는 OS 호스트 이름을 기반으로 한다. 각 kube-apiserver는 클러스터 내에서 고유한 호스트 이름을 사용하도록 구성해야 한다. 동일한 호스트명을 사용하는 새로운 kube-apiserver 인스턴스는 새 리스 오브젝트를 인스턴스화하는 대신 새로운 소유자 ID를 사용하여 기존 리스를 차지할 수 있다. kube-apiserver가 사용하는 호스트네임은 `kubernetes.io/hostname` 레이블의 값을 확인하여 확인할 수 있다. $ kubectl -n kube-system get lease kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a -o yaml apiVersion: coordination.k8s.io/v1 kind: Lease metadata: creationTimestamp: "2022-11-30T15:37:15Z" labels: k8s.io/component: kube-apiserver kubernetes.io/hostname: kind-control-plane name: kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a namespace: kube-system resourceVersion: "18171" uid: d6c68901-4ec5-4385-b1ef-2d783738da6c spec: holderIdentity: kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4 leaseDurationSeconds: 3600 renewTime: "2022-11-30T18:04:27.912073Z" 더 이상 존재하지 않는 kube-apiserver의 만료된 임대는 1시간 후에 새로운 kube-apiserver에 의해 가비지 컬렉션된다. 4 - 컨트롤러 ======== 로보틱스와 자동화에서 _컨트롤 루프_ 는 시스템 상태를 조절하는 종료되지 않는 루프이다. 컨트롤 루프의 예시: 실내 온도 조절기 사용자는 온도를 설정해서, 사용자가 _의도한 상태_ 를 온도 조절기에 알려준다. 실제 실내 온도는 _현재 상태_ 이다. 온도 조절기는 장비를 켜거나 꺼서 현재 상태를 의도한 상태에 가깝게 만든다. 쿠버네티스에서 컨트롤러는 [클러스터](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-cluster "컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.") 의 상태를 관찰 한 다음, 필요한 경우에 생성 또는 변경을 요청하는 컨트롤 루프이다. 각 컨트롤러는 현재 클러스터 상태를 의도한 상태에 가깝게 이동한다. 컨트롤러 패턴 ------- 컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다. 이 [오브젝트](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 는 의도한 상태를 표현하는 사양 필드를 가지고 있다. 해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 상태에 가깝게 만드는 역할을 한다. 컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로, 쿠버네티스에서는 컨트롤러가 [API 서버](https://kubernetes.io/ko/docs/concepts/overview/components/#kube-apiserver "쿠버네티스 API를 제공하는 컨트롤 플레인 컴포넌트.") 로 유용한 부수적인 효과가 있는 메시지를 발송한다. 그 예시는 아래에서 볼 수 있다. ### API 서버를 통한 제어 [잡 (원문, Job)](https://kubernetes.io/ko/docs/concepts/workloads/controllers/job/ "완료를 목표로 실행되는 유한 또는 배치 작업.") 컨트롤러는 쿠버네티스 내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 상호 작용하며 상태를 관리한다. 잡은 단일 [파드](https://kubernetes.io/ko/docs/concepts/workloads/pods/ "파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.") 또는 여러 파드를 실행하고, 작업을 수행한 다음 중지하는 쿠버네티스 리소스 이다. (일단 [스케줄되면](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/) , 파드 오브젝트는 kubelet 의 의도한 상태 중 일부가 된다.) 잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서 노드 집합의 kubelet이 작업을 수행하기에 적합한 수의 파드를 실행하게 한다. 잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다. 대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록 지시한다. [컨트롤 플레인](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-control-plane "컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어.") 의 다른 컴포넌트는 신규 정보 (예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여, 결국 해당 작업을 완료시킨다. 새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다. 잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게 만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서 잡이 완료에 가까워 지도록 한다. 또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다. 예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는 잡 오브젝트가 `Finished` 로 표시되도록 업데이트한다. (이것은 지금 방 온도가 설정한 온도인 것을 표시하기 위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다). ### 직접 제어 잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을 변경해야 할 필요가 있다. 예를 들어, 만약 컨트롤 루프를 사용해서 클러스터에 충분한 [노드들](https://kubernetes.io/ko/docs/concepts/architecture/nodes/ "노드는 쿠버네티스의 작업 장비(worker machine)이다.") 이 있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록 현재 클러스터 외부의 무언가를 필요로 한다. 외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한 상태를 찾은 다음, 외부 시스템과 직접 통신해서 현재 상태를 보다 가깝게 만든다. (실제로 클러스터의 노드를 수평으로 확장하는 [컨트롤러](https://github.com/kubernetes/autoscaler/) 가 있다.) 여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고, 현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다. 다른 컨트롤 루프는 보고된 데이터를 관찰하고 자체 조치를 할 수 있다. 온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가 서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는 [쿠버네티스 확장](https://kubernetes.io/ko/docs/concepts/extend-kubernetes/) 을 통해 IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API 및 기타 서비스 등과 간접적으로 연동하여 이를 구현한다. 의도한 상태와 현재 상태 ------------- 쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인 변화에 대응할 수 있다. 작업이 발생함에 따라 어떤 시점에서든 클러스터가 변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로, 클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다. 클러스터의 컨트롤러가 실행 중이고 유용한 변경을 수행할 수 있는 한, 전체 상태가 안정적인지 아닌지는 중요하지 않다. 디자인 --- 디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을 관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프 (컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로 만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는 잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면, 잡은 다른 컨트롤러가 생성한다. 컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다, 간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를 허용하도록 디자인되었다. #### 참고: 동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다. 이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에 연결된 리소스에만 주의를 기울인다. 예를 들어, 디플로이먼트와 잡을 가지고 있다. 이 두 가지 모두 파드를 생성한다. 잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다. 이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는 정보([레이블](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels "사용자에게 의미 있고 관련성 높은 특징으로 식별할 수 있도록 오브젝트에 태그를 붙인다.") )가 있기 때문이다. 컨트롤러를 실행하는 방법 ------------- 쿠버네티스에는 [kube-controller-manager](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/kube-controller-manager/ "컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.") 내부에서 실행되는 내장된 컨트롤러 집합이 있다. 이 내장 컨트롤러는 중요한 핵심 동작을 제공한다. 디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의 자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다. 쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로, 어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다. 컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다. 또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다. 소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나, 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에 따라 달라진다. 다음 내용 ----- * [쿠버네티스 컨트롤 플레인](https://kubernetes.io/ko/docs/concepts/overview/components/#%EC%BB%A8%ED%8A%B8%EB%A1%A4-%ED%94%8C%EB%A0%88%EC%9D%B8-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8) 에 대해 읽기 * [쿠버네티스 오브젝트](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 의 몇 가지 기본 사항을 알아보자. * [쿠버네티스 API](https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/) 에 대해 더 배워 보자. * 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](https://kubernetes.io/ko/docs/concepts/extend-kubernetes/#%EC%9D%B5%EC%8A%A4%ED%85%90%EC%85%98-%ED%8C%A8%ED%84%B4) 을 본다. 5 - 클라우드 컨트롤러 매니저 ================= 기능 상태: `Kubernetes v1.11 [beta]` 클라우드 인프라스트럭처 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다. 쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭처를 신뢰한다. 클라우드 컨트롤러 매니저는 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 [컨트롤 플레인](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-control-plane "컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어.") 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다. 쿠버네티스와 기본 클라우드 인프라스터럭처 간의 상호 운용성 로직을 분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 공급자가 주요 쿠버네티스 프로젝트와 다른 속도로 기능들을 릴리스할 수 있도록 한다. 클라우드 컨트롤러 매니저는 다양한 클라우드 공급자가 자신의 플랫폼에 쿠버네티스를 통합할 수 있도록 하는 플러그인 메커니즘을 사용해서 구성된다. 디자인 --- ![쿠버네티스 컴포넌트](https://kubernetes.io/images/docs/components-of-kubernetes.svg) 클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스의 집합으로 실행된다(일반적으로, 파드의 컨테이너). 각 클라우드 컨트롤러 매니저는 단일 프로세스에 여러 [컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/controller/ "API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.") 를 구현한다. #### 참고: 또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스 [애드온](https://kubernetes.io/ko/docs/concepts/cluster-administration/addons/ "쿠버네티스의 기능을 확장하는 리소스.") 으로 실행할 수도 있다. 클라우드 컨트롤러 매니저의 기능 ----------------- 클라우드 컨틀롤러 매니저의 내부 컨트롤러에는 다음 컨트롤러들이 포함된다. ### 노드 컨트롤러 노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 [노드](https://kubernetes.io/ko/docs/concepts/architecture/nodes/ "노드는 쿠버네티스의 작업 장비(worker machine)이다.") 오브젝트를 업데이트하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다. 1. 클라우드 공급자 API를 통해 획득한 해당 서버의 고유 ID를 노드 오브젝트에 업데이트한다. 2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를 사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다. 3. 노드의 호스트 이름과 네트워크 주소를 가져온다. 4. 노드의 상태를 확인한다. 노드가 응답하지 않는 경우, 이 컨트롤러는 사용자가 이용하는 클라우드 공급자의 API를 통해 서버가 비활성화됨 / 삭제됨 / 종료됨인지 확인한다. 노드가 클라우드에서 삭제된 경우, 컨트롤러는 사용자의 쿠버네티스 클러스터에서 노드 오브젝트를 삭제한다. 일부 클라우드 공급자의 구현에서는 이를 노드 컨트롤러와 별도의 노드 라이프사이클 컨트롤러로 분리한다. ### 라우트 컨트롤러 라우트 컨트롤러는 사용자의 쿠버네티스 클러스터의 다른 노드에 있는 각각의 컨테이너가 서로 통신할 수 있도록 클라우드에서 라우트를 적절히 구성해야 한다. 클라우드 공급자에 따라 라우트 컨트롤러는 파드 네트워크 IP 주소 블록을 할당할 수도 있다. ### 서비스 컨트롤러 [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/ "네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법") 는 관리형 로드 밸런서, IP 주소, 네트워크 패킷 필터링 그리고 대상 상태 확인과 같은 클라우드 인프라스트럭처 컴포넌트와 통합된다. 서비스 컨트롤러는 사용자의 클라우드 공급자 API와 상호 작용해서 필요한 서비스 리소스를 선언할 때 로드 밸런서와 기타 인프라스트럭처 컴포넌트를 설정한다. 인가 -- 이 섹션에서는 클라우드 컨트롤러 매니저가 작업을 수행하기 위해 다양한 API 오브젝트에 필요한 접근 권한을 세분화한다. ### 노드 컨트롤러 노드 컨트롤러는 노드 오브젝트에서만 작동한다. 노드 오브젝트를 읽고, 수정하려면 전체 접근 권한이 필요하다. `v1/Node`: * Get * List * Create * Update * Patch * Watch * Delete ### 라우트 컨트롤러 라우트 컨트롤러가 노드 오브젝트의 생성을 수신하고 적절하게 라우트를 구성한다. 노드 오브젝트에 대한 접근 권한이 필요하다. `v1/Node`: * Get ### 서비스 컨트롤러 서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다(엔드포인트슬라이스(EndpointSlice)의 경우, kube-controller-manager가 필요에 따라 이들을 관리한다). 서비스에 접근하려면, 목록과 감시 접근 권한이 필요하다. 서비스를 업데이트하려면, 패치와 업데이트 접근 권한이 필요하다. 서비스에 대한 엔드포인트 리소스를 설정하려면 생성, 목록, 가져오기, 감시 그리고 업데이트에 대한 접근 권한이 필요하다. `v1/Service`: * List * Get * Watch * Patch * Update ### 그 외의 것들 클라우드 컨트롤러 매니저의 핵심 구현을 위해 이벤트 오브젝트를 생성하고, 안전한 작동을 보장하기 위해 서비스어카운트(ServiceAccounts)를 생성해야 한다. `v1/Event`: * Create * Patch * Update `v1/ServiceAccount`: * Create 클라우드 컨트롤러 매니저의 [RBAC](https://kubernetes.io/ko/docs/reference/access-authn-authz/rbac/ "인가 결정을 관리하며, 운영자가 쿠버네티스 API를 통해서 동적으로 액세스 정책을 설정하게 한다.") 클러스터롤(ClusterRole)은 다음과 같다. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cloud-controller-manager rules: - apiGroups: - "" resources: - events verbs: - create - patch - update - apiGroups: - "" resources: - nodes verbs: - '*' - apiGroups: - "" resources: - nodes/status verbs: - patch - apiGroups: - "" resources: - services verbs: - list - patch - update - watch - apiGroups: - "" resources: - serviceaccounts verbs: - create - apiGroups: - "" resources: - persistentvolumes verbs: - get - list - update - watch - apiGroups: - "" resources: - endpoints verbs: - create - get - list - watch - update 다음 내용 ----- [클라우드 컨트롤러 매니저 관리](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) 에는 클라우드 컨트롤러 매니저의 실행과 관리에 대한 지침이 있다. 클라우드 컨트롤러 매니저를 사용하기 위해 HA 컨트롤 플레인을 업그레이드하려면, [클라우드 컨트롤러 매니저를 사용하기 위해 복제된 컨트롤 플레인 마이그레이션 하기](https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/) 를 참고한다. 자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가? 클라우드 컨트롤러 매니저는 Go 인터페이스를 사용함으로써, 어떠한 클라우드에 대한 구현체(implementation)라도 플러그인 될 수 있도록 한다. 구체적으로는, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider) 의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69) 에 정의된 `CloudProvider` 인터페이스를 사용한다. 이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다. 플러그인 개발에 대한 자세한 내용은 [클라우드 컨트롤러 매니저 개발하기](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/) 를 참조한다. 6 - cgroup v2에 대하여 ================== 리눅스에서, [컨트롤 그룹](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-cgroup "선택적으로 리소스를 격리, 관리, 제한하는 리눅스 프로세스의 그룹.") 은 프로세스에 할당되는 자원을 제한한다. [kubelet](https://kubernetes.io/ko/docs/reference/generated/kubelet "클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.") 과 기반 컨테이너 런타임은 컨테이너화된 워크로드에 대한 CPU/메모리 요청 및 제한을 포함하는 [파드와 컨테이너를 위한 자원 관리](https://kubernetes.io/ko/docs/concepts/configuration/manage-resources-containers/) 를 강제하기 위해 cgroup과 연동해야 한다. 리눅스에는 두 가지 버전의 cgroup이 있다. cgroup v1과 cgroup v2. cgroup v2는 `cgroup` API의 새로운 세대이다. cgroup v2란 무엇인가 --------------- 기능 상태: `Kubernetes v1.25 [stable]` cgroup v2는 리눅스 `cgroup` API의 다음 버전이다. cgroup v2는 향상된 자원 관리 기능을 갖춘 통합 제어 시스템을 제공한다. cgroup v2는 cgroup v1에 비해 다음과 같은 여러 개선 사항을 제공한다. * API의 단일 통합 계층 구조 설계 * 컨테이너에 대한 더 안전한 서브트리 위임 * [Pressure Stall Information](https://www.kernel.org/doc/html/latest/accounting/psi.html) 과 같은 새로운 기능 * 다중 자원에 걸친 향상된 자원 할당 관리 및 격리 * 다양한 유형의 메모리 할당(네트워크 메모리, 커널 메모리 등)에 대한 통합 집계 * 페이지 캐시 라이트백(write back)과 같은 즉각적이지 않은 자원 변경에 대한 집계 일부 쿠버네티스 기능은 향상된 자원 관리 및 격리를 위해 오직 cgroup v2만을 사용한다. 예를 들어, [MemoryQoS](https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-qos/#memory-qos-with-cgroup-v2) 기능은 메모리 QoS를 향상시키고 cgroup v2 기본 요소에 의존한다. cgorup v2 사용하기 -------------- cgroup v2를 사용하는 권장 방식은 cgroup v2를 기본적으로 활성화하고 사용하는 리눅스 배포판을 이용하는 것이다. 사용 중인 배포판이 cgroup v2를 사용하는지 확인하려면, [리눅스 노드에서 cgroup 버전 확인하기](https://kubernetes.io/ko/docs/concepts/architecture/_print/#check-cgroup-version) 를 참조한다. ### 요구사항 cgroup v2에는 다음과 같은 요구 사항이 있다. * OS 배포판에서 cgroup v2가 활성화되어 있어야 한다. * 리눅스 커널 버전은 5.8 이상이어야 한다. * 컨테이너 런타임이 cgroup v2를 지원해야 한다. 예를 들어, * [containerd](https://containerd.io/) v1.4 이상 * [cri-o](https://cri-o.io/) v1.20 이상 * kubelet과 컨테이너 런타임은 [systemd cgroup 드라이버](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes#systemd-cgroup-driver) 를 사용하도록 구성되어야 한다. ### 리눅스 배포판 cgroup v2 지원 cgroup v2를 사용하는 리눅스 배포판 목록은, [cgroup v2 문서](https://github.com/opencontainers/runc/blob/main/docs/cgroup-v2.md) 를 참조한다. * Container Optimized OS (M97 버전부터) * Ubuntu (21.10 버전부터, 22.04+ 권장) * Debian GNU/Linux (Debian 11 bullseye 버전부터) * Fedora (31 버전부터) * Arch Linux (2021년 4월부터) * RHEL 및 RHEL 기반 배포판 (9 버전부터) 사용 중인 배포판이 cgroup v2를 사용하는지 확인하려면, 해당 배포판의 문서를 참조하거나 [리눅스 노드에서 cgroup 버전 확인하기](https://kubernetes.io/ko/docs/concepts/architecture/_print/#check-cgroup-version) 의 지침을 따른다. 또한 커널 cmdline 부트 인자를 수정하여 리눅스 배포판에서 cgroup v2를 수동으로 활성화할 수 있다. 사용 중인 배포판이 GRUB을 사용하는 경우, `/etc/default/grub` 파일의 `GRUB_CMDLINE_LINUX`에 `systemd.unified_cgroup_hierarchy=1`을 추가한 다음, `sudo update-grub`을 실행해야 한다. 그러나, 권장되는 접근 방법은 cgroup v2를 기본적으로 활성화하는 배포판을 사용하는 것이다. ### cgroup v2로 마이그레이션 cgroup v2로 마이그레이션하려면, [요구 사항](https://kubernetes.io/ko/docs/concepts/architecture/_print/#requirements) 을 충족하는지 확인한 다음, cgroup v2를 기본적으로 활성화하는 커널 버전으로 업그레이드한다. kubelet은 OS가 cgroup v2에서 실행 중임을 자동으로 감지하며 추가 구성 없이 그에 맞춰 작동한다. 사용자들이 노드나 컨테이너 내부에서 cgroup 파일 시스템에 직접 접근하지 않는 한, cgroup v2로 전환할 때 사용자 경험에서 뚜렷한 차이는 없을 것이다. cgroup v2는 cgroup v1과 다른 API를 사용하므로, cgroup 파일 시스템에 직접 접근하는 애플리케이션이 있다면, cgroup v2를 지원하는 새로운 버전으로 업데이트해야 한다. 예를 들어, * 일부 서드파티 모니터링 및 보안 에이전트는 cgroup 파일 시스템에 의존할 수 있다. 이러한 에이전트들을 cgroup v2를 지원하는 버전으로 업데이트 한다. * [cAdvisor](https://github.com/google/cadvisor) 를 파드 및 컨테이너 모니터링을 위한 독립형 DaemonSet으로 실행하는 경우, v0.43.0 이상으로 업데이트 한다. * 자바 애플리케이션을 배포하는 경우, cgroup v2를 완전히 지원하는 버전을 선호한다. * [OpenJDK / HotSpot](https://bugs.openjdk.org/browse/JDK-8230305) : jdk8u372, 11.0.16, 15 이상 * [IBM Semeru Runtimes](https://www.ibm.com/support/pages/apar/IJ46681) : 8.0.382.0, 11.0.20.0, 17.0.8.0 이상 * [IBM Java](https://www.ibm.com/support/pages/apar/IJ46681) : 8.0.8.6 이상 * [uber-go/automaxprocs](https://github.com/uber-go/automaxprocs) 패키지를 사용하는 경우, 사용하는 버전이 v1.5.1 이상인지 확인한다. 리눅스 노드에서 cgroup 버전 확인하기 ----------------------- cgroup 버전은 사용 중인 리눅스 배포판과 OS에 설정된 기본 cgroup 버전에 따라 결정된다. 배포판이 어떤 cgroup 버전을 사용하는지 확인하려면, 노드에서 `stat -fc %T /sys/fs/cgroup/` 명령을 실행한다. stat -fc %T /sys/fs/cgroup/ cgroup v2의 경우, 출력은 `cgroup2fs`이다. cgroup v1의 경우, 출력은 `tmpfs`이다. 다음 내용 ----- * [cgroup](https://man7.org/linux/man-pages/man7/cgroups.7.html) 에 대해 더 알아보기 * [컨테이너 런타임](https://kubernetes.io/ko/docs/concepts/architecture/cri) 에 대해 더 알아보기 * [cgroup 드라이버](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes#cgroup-%EB%93%9C%EB%9D%BC%EC%9D%B4%EB%B2%84) 에 대해 더 알아보기 7 - 쿠버네티스 자가 치유 =============== 쿠버네티스는 워크로드의 상태와 가용성을 유지할 수 있도록 자가 치유 기능을 제공한다. 실패한 컨테이너를 자동으로 교체하고, 노드가 사용할 수 없게 되면 워크로드를 다시 스케줄하며, 원하는 시스템 상태를 유지하도록 보장한다. 자가 치유 기능 -------- * **컨테이너 단위 재시작:** 파드 내부의 컨테이너가 실패하면, 쿠버네티스는 [`재시작 정책`](https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 에 따라 재시작한다. * **레플리카 교체:** [디플로이먼트(Deployment)](https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/) 또는 [스테이트풀셋(StatefulSet)](https://kubernetes.io/ko/docs/concepts/workloads/controllers/statefulset/) 의 파드가 실패하면, 쿠버네티스는 지정된 레플리카 수를 유지하기 위해 대체 파드를 생성한다. [데몬셋(DaemonSet)](https://kubernetes.io/ko/docs/concepts/workloads/controllers/daemonset/) 의 일부인 파드가 실패한다면, 컨트롤 플레인이 대체 파드를 생성하여 동일한 노드에서 실행되도록 한다. * **영구 스토리지 복구:** 퍼시스턴트볼륨(PersistentVolume)이 연결된 파드를 실행 중일 떄 노드에 장애가 발생하면, 쿠버네티스는 다른 노드에 있는 새로운 파드에 다시 연결할 수 있다. * **서비스 로드 밸런싱:** [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/) 뒤에 있는 파드에 장애가 발생하면, 쿠버네티스는 자동으로 서비스의 엔드포인트에서 해당 파드를 제거하여 정상 파드로만 트래픽을 라우팅한다. 쿠버네티스가 자가 치유를 제공하는 주요 컴포넌트는 다음과 같다. * **[kubelet](https://kubernetes.io/ko/docs/concepts/architecture/#kubelet) :** 컨테이너가 실행 중인지 확인하고, 실패한 컨테이너를 재시작한다. * **레플리카셋(ReplicaSet), 스테이트풀셋, 데몬셋 컨트롤러:** 파드 레플리카를 원하는 수로 유지한다. * **퍼시스턴트볼륨 컨트롤러:** 상태 저장 워크로드의 볼륨 연결 및 연결 해제를 관리한다. 고려 사항 ----- * **스토리지 장애:** 퍼시스턴트볼륨을 사용할 수 없게 되면, 복구 절차가 필요할 수 있다. * **애플리케이션 오류:** 쿠버네티스는 컨테이너를 재시작할 수 있지만, 근본적인 애플리케이션 문제는 별도로 해결해야 한다. 다음 내용 ----- * [파드](https://kubernetes.io/ko/docs/concepts/workloads/pods/) 더 읽어보기 * [쿠버네티스 컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/controller/) 학습하기 * [퍼시스턴트볼륨](https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/) 살펴보기 * [노드 오토스케일링](https://kubernetes.io/ko/docs/concepts/cluster-administration/node-autoscaling/) 읽어보기. 노드 오토스케일링은 클러스터의 노드가 실패할 경우 자동 치유 기능도 제공한다. 8 - 가비지(Garbage) 수집 =================== 쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다. 다음과 같은 리소스를 정리한다: * [종료된 잡](https://kubernetes.io/ko/docs/concepts/workloads/controllers/ttlafterfinished/) * [소유자 참조가 없는 오브젝트](https://kubernetes.io/ko/docs/concepts/architecture/_print/#owners-dependents) * [사용되지 않는 컨테이너와 컨테이너 이미지](https://kubernetes.io/ko/docs/concepts/architecture/_print/#containers-images) * [반환 정책이 삭제인 스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨](https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/#delete) * [Stale 또는 만료된 CertificateSigningRequests (CSRs)](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) * [노드](https://kubernetes.io/ko/docs/concepts/architecture/nodes/ "노드는 쿠버네티스의 작업 장비(worker machine)이다.") 는 다음과 같은 상황에서 삭제된다: * 클러스터가 [클라우드 컨트롤러 매니저](https://kubernetes.io/ko/docs/concepts/architecture/cloud-controller/) 를 사용하는 클라우드 * 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스 * [노드 리스(Lease) 오브젝트](https://kubernetes.io/ko/docs/concepts/architecture/nodes/#heartbeats) 소유자(Owners)와 종속(dependents) --------------------------- 쿠버네티스의 많은 오브젝트는 [_owner references_](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) 를 통해 서로 연결되어 있다. 소유자 참조(Owner references)는 컨트롤 플레인에게 어떤 오브젝트가 서로 종속적인지를 알려준다. 쿠버네티스는 소유자 참조를 사용하여 컨트롤 플레인과 다른 API 클라이언트에게 오브젝트를 삭제하기 전 관련 리소스를 정리하는 기회를 제공한다. 대부분의 경우, 쿠버네티스는 소유자 참조를 자동으로 관리한다. 소유권(Ownership)은 일부 리소스가 사용하는 [레이블과 셀렉터](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/) 메커니즘과는 다르다. 예를 들어, `EndpointSlice` 오브젝트를 생성하는 [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/ "네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법") 를 생각해보자. 서비스는 _레이블_을 사용해 컨트롤 플레인이 어떤 `EndpointSlice` 오브젝트가 해당 서비스에 의해 사용되는지 판단하는 데 도움을 준다. 레이블과 더불어, 서비스를 대신해 관리되는 각 `EndpointSlice` 오브젝트는 소유자 참조를 가진다. 소유자 참조는 쿠버네티스의 다른 부분이 제어하지 않는 오브젝트를 방해하는 것을 방지하는 데 도움을 준다. #### 참고: 교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다. 네임스페이스 종속 오브젝트는 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다. 네임스페이스 소유자는 **반드시** 종속 오브젝트와 동일한 네임스페이스에 존재해야 한다. 그렇지 않다면, 소유자 참조는 없는 것으로 간주되어, 종속 오브젝트는 모든 소유자가 없는 것으로 확인되면 삭제될 수 있다. 클러스터 범위의 종속 오브젝트는 클러스터 범위의 소유자만 지정할 수 있다. v1.20 이상에서, 클러스터 범위의 종속 오브젝트가 네임스페이스 종류를 소유자로 지정하면, 확인할 수 없는 소유자 참조가 있는 것으로 간주되어 가비지 수집이 될 수 없다. v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference` 또는 네임스페이스 종류를 참조하는 `ownerReference`가 있는 클러스터 범위의 종속 항목을 감지하면, `OwnerRefInvalidNamespace`가 원인인 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject`가 보고된다. `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` 를 실행하여 이러한 종류의 이벤트를 확인할 수 있다. 캐스케이딩(Cascading) 삭제 ------------------- 쿠버네티스는 오브젝트를 삭제할 때 더 이상 소유자 참조가 없는지, 예를 들어 레플리카셋을 삭제할 때, 남겨진 파드가 없는지 확인하고 삭제한다. 오브젝트를 삭제할 때 쿠버네티스가 오브젝트의 종속 오브젝트들을 자동으로 삭제할 지 여부를 제어할 수 있다. 이 과정을 `캐스케이딩 삭제`라고 한다. 캐스케이딩 삭제에는 다음과 같은 두 가지 종류가 있다. * 포그라운드 캐스케이딩 삭제(Foreground cascading deletion) * 백그라운드 캐스케이딩 삭제(Background cascading deletion) 또한 쿠버네티스의 [finalizers](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/finalizers/ "쿠버네티스가 오브젝트를 완전히 삭제하기 이전, 삭제 표시를 위해 특정 조건이 충족될 때까지 대기하도록 알려주기 위한 네임스페이스에 속한 키(namespaced key)이다.") 를 사용하여 가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다. ### 포그라운드 캐스케이딩 삭제 포그라운드 캐스케이딩 삭제에서는 삭제하려는 소유자 오브젝트가 먼저 _삭제 중_ 상태가 된다. 이 상태에서는 소유자 오브젝트에게 다음과 같은 일이 일어난다: * 쿠버네티스 API 서버가 오브젝트의 `metadata.deletionTimestamp` 필드를 오브젝트가 삭제 표시된 시간으로 설정한다. * 쿠버네티스 API 서버가 `metadata.finalizers` 필드를 `foregroundDeletion`로 설정한다. * 오브젝트는 삭제 과정이 완료되기 전까지 쿠버네티스 API를 통해 조회할 수 있다. 소유자 오브젝트가 삭제 중 상태가 된 이후, 컨트롤러는 종속 오브젝트들을 삭제한다. 모든 종속 오브젝트들이 삭제되고나면, 컨트롤러가 소유자 오브젝트를 삭제한다. 이 시점에서 오브젝트는 더 이상 쿠버네티스 API를 통해 조회할 수 없다. 포그라운드 캐스케이딩 삭제 중에 소유자 오브젝트의 삭제를 막는 종속 오브젝트는`ownerReference.blockOwnerDeletion=true`필드를 가진 오브젝트다. 더 자세한 내용은 [Use foreground cascading deletion](https://kubernetes.io/ko/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) 를 참고한다. ### 백그라운드 캐스케이딩 삭제 백그라운드 캐스케이딩 삭제에서는 쿠버네티스 API 서버가 소유자 오브젝트를 즉시 삭제하고 백그라운드에서 컨트롤러가 종속 오브젝트들을 삭제한다. 쿠버네티스는 수동으로 포그라운드 삭제를 사용하거나 종속 오브젝트를 분리하지 않는다면, 기본적으로 백그라운드 캐스케이딩 삭제를 사용한다. 더 자세한 내용은 [Use background cascading deletion](https://kubernetes.io/ko/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion) 를 참고한다. ### 분리된 종속 (Orphaned dependents) 쿠버네티스가 소유자 오브젝트를 삭제할 때, 남은 종속 오브젝트는 _분리된_ 오브젝트라고 부른다. 기본적으로 쿠버네티스는 종속 오브젝트를 삭제한다. 이 행동을 오버라이드하는 방법을 보려면, [Delete owner objects and orphan dependents](https://kubernetes.io/ko/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy) 를 참고한다. 사용되지 않는 컨테이너와 이미지 가비지 수집 ------------------------ [kubelet](https://kubernetes.io/ko/docs/reference/generated/kubelet "클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.") 은 사용되지 않는 이미지에 대한 가비지 수집을 5분마다, 컨테이너에 대한 가비지 수집을 1분마다 수행한다. 외부 가비지 수집 도구는 kubelet 의 행동을 중단시키고 존재해야만 하는 컨테이너를 삭제할 수 있으므로 사용을 피해야 한다. 사용되지 않는 컨테이너와 이미지에 대한 가비지 수집 옵션을 구성하려면, [configuration file](https://kubernetes.io/ko/docs/tasks/administer-cluster/kubelet-config-file/) 사용하여 kubelet 을 수정하거나 [`KubeletConfiguration`](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 리소스 타입의 가비지 수집과 관련된 파라미터를 수정한다. ### 컨테이너 이미지 라이프사이클 쿠버네티스는 kubelet의 일부인 _이미지 관리자_가 [cadvisor](https://github.com/google/cadvisor/ "Tool that provides understanding of the resource usage and performance characteristics for containers") 와 협동하여 모든 이미지의 라이프사이클을 관리한다. kubelet은 가비지 수집 결정을 내릴 때, 다음 디스크 사용량 제한을 고려한다. * `HighThresholdPercent` * `LowThresholdPercent` `HighThresholdPercent` 값을 초과한 디스크 사용량은 마지막으로 사용된 시간을 기준으로 오래된 이미지순서대로 이미지를 삭제하는 가비지 수집을 트리거한다. kubelet은 디스크 사용량이 `LowThresholdPercent` 값에 도달할 때까지 이미지를 삭제한다. ### 컨테이너 이미지 가비지 수집 kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로 사용되지 않는 컨테이너들을 삭제한다: * `MinAge`: kubelet이 가비지 수집할 수 있는 최소 나이. `0`으로 세팅하여 비활성화할 수 있다. * `MaxPerPodContainer`: 각 파드 쌍이 가질 수 있는 죽은 컨테이너의 최대 개수. `0`으로 세팅하여 비활성화할 수 있다. * `MaxContainers`: 클러스터가 가질 수 있는 죽은 컨테이너의 최대 개수 `0`으로 세팅하여 비활성화할 수 있다. 위 변수와 더불어, kubelet은 식별할 수 없고 삭제된 컨테이너들을 오래된 순서대로 가비지 수집한다. `MaxPerPodContainer`와 `MaxContainer`는 파드의 최대 컨테이너 개수(`MaxPerPodContainer`)를 유지하는 것이 전체 죽은 컨테이너의 개수 제한(`MaxContainers`)을 초과하게 될 때, 서로 충돌이 발생할 수 있다. 이 상황에서 kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다. 최악의 시나리오에서는 `MaxPerPodContainer`를 `1`로 다운그레이드하고 가장 오래된 컨테이너들을 축출한다. 또한, 삭제된 파드가 소유한 컨테이너들은 `MinAge`보다 오래되었을 때 삭제된다. #### 참고: kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을 수행한다. 가비지 수집 구성하기 ----------- 자원을 관리하는 컨트롤러의 옵션을 구성하여 가비지 컬렉션을 수정할 수 있다. 다음 페이지에서 어떻게 가비지 수집을 구성할 수 있는지 확인할 수 있다. * [쿠버네티스 오브젝트의 캐스케이딩 삭제 구성하기](https://kubernetes.io/ko/docs/tasks/administer-cluster/use-cascading-deletion/) * [완료된 잡 자동 정리하기](https://kubernetes.io/ko/docs/concepts/workloads/controllers/ttlafterfinished/) 다음 내용 ----- * [쿠버네티스 오브젝트의 소유권](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) 에 대해 알아보자. * 쿠버네티스 [finalizers](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/finalizers/) 에 대해 알아보자. * 완료된 잡을 정리하는 [TTL 컨트롤러](https://kubernetes.io/ko/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) 에 대해 알아보자. --- # Contribuir a la documentación de Kubernetes | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/contribute/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/contribute/) . Contribuir a la documentación de Kubernetes =========================================== * 1: [Empieza a contribuir](https://kubernetes.io/es/docs/contribute/_print/#pg-3609b0e10614f1dc39ed781858319204) * 2: [Cómo escribir documentación](https://kubernetes.io/es/docs/contribute/_print/#pg-a2d946282df02cdeb47d9f54dfef198e) * 3: [Documentación de referencia](https://kubernetes.io/es/docs/contribute/_print/#pg-29765496ca296ad24e34e5c0cd42a63f) * 4: [Contribuir a la documentación de Kubernetes en español](https://kubernetes.io/es/docs/contribute/_print/#pg-e31405a7931983caad2a55bbfa16e4e1) Kubernetes es posible gracias a la participación de la comunidad y la documentación es vital para facilitar el acceso al proyecto. Cualquiera puede contribuir en el proyecto de Kubernetes, tanto si acabas de descubrir la plataforma como si lleves años involucrado. Tampoco importa si eres desarrollador, usuario final o alguien que simplemente no soporta ver errores tipográficos. **¡Cualquier contribución será bien recibida!** Para conocer más formas de involucrarse en la comunidad de Kubernetes o de aprender sobre nosotros, visite la sección [comunidad de Kubernetes](https://kubernetes.io/es/community/) . Para obtener información cómo escribir documentación de Kubernetes, consulte la [guía de estilo](https://kubernetes.io/docs/contribute/style/style-guide/) . Tipos de contribuidores ----------------------- * _**Kubernetes Member**_, un miembro de la organziación de Kubernetes que ha [firmado el CLA](https://kubernetes.io/es/docs/contribute/start/#sign-the-cla) y contribuido al projecto. Puedes consultar más información en el documento sobre los requisitos para ser miembro de Kubernetes en el documento _[Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) _. * _**SIG Docs reviewer**_, un revisor del grupo de interés de documentación es un miembro de la organización Kubernetes que tiene interés en revisar las _pull requests_ relacionadas con el site y la documentación. Para poder ser revisor, un aprobador de SIG Docs debe añadirlo al grupo adecuado de GitHub y al fichero `OWNERS` del contenido que está interesado en revisar. * _**SIG Docs approver**_, un aprobador del grupo de interés de documentación es un miembro de la organización de Kubernetes con buena reputación y que ha mostrado una compromiso continuado con el proyecto. Un aprobador se responsabiliza de mergear las _pull requests_ y publicar contenido en nombre de la organización Kubernetes. Los aprobadores también pueden representar a SIG Docs en la comunidad de Kubernetes en general. Algunas de las responsabilidades de un aprobador de SIG Docs, como por ejemplo coordinar una _release_, requieren un compromiso de tiempo significativo. Cómo contribuir --------------- La siguiente lista está organizada por el nivel de implicación con la comunidad, desde las contribuciones que cualquiera puede hacer hasta las que requieren un compromiso con el equipo de documentación y estar familiarizado con los procesos de SIG Docs. Contribuir consistentemente a lo largo del tiempo puede ayudarte a comprender algunas de las herramientas y decisiones organizativas que se han ido tomando a lo largo del proyecto. La lista no contiene todas las formas de contribución posibles, está pensada para proporcionar un punto de partida. * [Todo el mundo](https://kubernetes.io/es/docs/contribute/start/) * Abrir issues accionables para que el equipo pueda trabajar en ello * [Miembro](https://kubernetes.io/es/docs/contribute/start/) * Mejorar la documetanción existente * Proponer ideas de mejora en [Slack](http://slack.k8s.io/) o en [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) * Mejorar la accesibilidad de la documentación * Proporcionar comentarios no vinculantes sobre PRs * Escribir una entrada para el blog o un caso de estudio * [Revisor](https://kubernetes.io/docs/contribute/intermediate/) * Documentar nuevas funcionalidades * Selección y clasificacion de nuevos Issues * Revisar PRs * Crear diagramas, material gráfico y screencasts / videos * Localización del contenido * Contribuye a otros repos como representante del equipo de documentación * Edit user-facing strings in code * Mejorar los comentarios de código, Godoc * [Aprobador](https://kubernetes.io/docs/contribute/advanced/) * Publicar el contenido de colaboradores aprobando y mergeando las PRs * Participar en el equipo de Release de Kubernetes como representeante del equipo de Docs * Proponer mejoras a la guía de estilo * Proponer mejoras a los tests de la documentación * Proponer mejoras al sitio web de Kubernetes y otras herramientas Siguientes pasos ---------------- También puedes leer la [guía de localización para español](https://kubernetes.io/es/docs/contribute/localization_es/) . 1 - Empieza a contribuir ======================== Si quieres empezar a contribuir a la documentación de Kubernetes esta página y su temas enlazados pueden ayudarte a empezar. No necesitas ser un desarrollador o saber escribir de forma técnica para tener un gran impacto en la documentación y experiencia de usuario en Kubernetes! Todo lo que necesitas para los temas en esta página es una [Cuenta en GitHub](https://github.com/join) y un navegador web. Si estas buscando información sobre cómo comenzar a contribuir a los repositorios de Kubernetes, entonces dirígete a [las guías de la comunidad Kubernetes](https://github.com/kubernetes/community/blob/master/governance.md) Lo básico sobre nuestra documentación ------------------------------------- La documentación de Kubernetes esta escrita usando Markdown, procesada y desplegada usando Hugo. El código fuente está en GitHub accessible en [git.k8s.io/website/](https://github.com/kubernetes/website) . La mayoría de la documentación en castellano está en `/content/es/docs`. Alguna de la documentación de referencia se genera automática con los scripts del directorio `/update-imported-docs`. Puedes clasificar incidencias, editar contenido y revisar cambios de otros, todo ello desde la página de GitHub. También puedes usar la historia embebida de GitHub y las herramientas de búsqueda. No todas las tareas se pueden realizar desde la interfaz web de GitHub, también se discute en las guías de contribución a la documentación [intermedia](https://kubernetes.io/docs/contribute/intermediate/) y [avanzada](https://kubernetes.io/docs/contribute/advanced/) ### Participar en la documentación de los SIG La documentación de Kubernetes es mantenida por el [Special Interest Group](https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups "Grupo de miembros de la comunidad que gestionan una pieza o parte del proyecto Kubernetes de forma colectiva.") (SIG) denominado SIG Docs. Nos comunicamos usando un canal de Slack, una lista de correo y una reunión semana por video-conferencia. Siempre son bienvenidos nuevos participantes al grupo. Para más información ver [Participar en SIG Docs](https://kubernetes.io/docs/contribute/participating/) . ### Guías de estilo Se mantienen unas [guías de estilo](https://kubernetes.io/docs/contribute/style/style-guide/) con la información sobre las elecciones que cada comunidad SIG Docs ha realizado referente a gramática, sintaxis, formato del código fuente y convenciones tipográficas. Revisa la guía de estilos antes de hacer tu primera contribución y úsala para resolver tus dudas. Los cambios en la guía de estilos se hacen desde el SIG Docs como grupo. Para añadir o proponer cambios [añade tus comentarios en la agenda](https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/edit) para las próximas reuniones del SIG Docs y participe en las discusiones durante la reunión. Revisa el apartado [avanzado](https://kubernetes.io/docs/contribute/advanced/) para más información. ### Plantillas para páginas Se usan plantillas para las páginas de documentación con el objeto de que todas tengan la misma presentación. Asegúrate de entender como funcionan estas plantillas y revisa el apartado [Uso de plantillas para páginas](https://kubernetes.io/docs/contribute/style/page-templates/) . Si tienes alguna consulta, no dudes en ponerte en contacto con el resto del equipo en Slack. ### Hugo shortcodes La documentación de Kubernetes se transforma a partir de Markdown para obtener HTML usando Hugo. Hay que conocer los shortcodes estándar de Hugo, así como algunos que son personalizados para la documentación de Kubernetes. Para más información de como usarlos revisa [Hugo shortcodes personalizados](https://kubernetes.io/docs/contribute/style/hugo-shortcodes/) . ### Múltiples idiomas La documentación original está disponible en múltiples idiomas en `/content/`. Cada idioma tiene su propia carpeta con el código de dos letras determinado por el [estándar ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php) . Por ejemplo, la documentación original en inglés se encuentra en `/content/en/docs/`. Para más información sobre como contribuir a la documentación en múltiples idiomas revisa ["Localizar contenido"](https://kubernetes.io/docs/contribute/intermediate#localize-content) Si te interesa empezar una nueva localización revisa ["Localization"](https://kubernetes.io/docs/contribute/localization/) . Registro de incidencias ----------------------- Cualquier persona con una cuenta de GitHub puede reportar una incidencia en la documentación de Kubernetes. Si ves algo erróneo, aunque no sepas como resolverlo, [reporta una incidencia](https://kubernetes.io/es/docs/contribute/_print/#c%C3%B3mo-reportar-una-incidencia) . La única excepción a la regla es si se trata de un pequeño error, como alguno que puedes resolver por ti mismo. En este último caso, puedes tratar de [resolverlo](https://kubernetes.io/es/docs/contribute/_print/#mejorar-contenido-existente) sin necesidad de reportar una incidencia primero. ### Cómo reportar una incidencia * **En una página existente** Si ves un problema en una página existente en la [documentación de Kubernetes](https://kubernetes.io/es/docs/) ve al final de la página y haz clic en el botón **Abrir un Issue**. Si no estas autenticado en GitHub, te pedirá que te identifiques y posteriormente un formulario de nueva incidencia aparecerá con contenido pre-cargado. Utilizando formato Markdown completa todos los detalles que sea posible. En los lugares en que haya corchetes (`[ ]`) pon una `x` en medio de los corchetes para representar la elección de una opción. Si tienes una posible solución al problema añádela. * **Solicitar una nueva página** Si crees que un contenido debería añadirse, pero no estás seguro de donde debería añadirse o si crees que no encaja en las páginas que ya existen, puedes crear un incidente. También puedes elegir una página ya existente donde pienses que pudiera encajar y crear el incidente desde esa página, o ir directamente a [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) y crearlo desde allí. ### Cómo reportar correctamente incidencias Para estar seguros que tu incidencia se entiende y se puede procesar ten en cuenta esta guía: * Usa la plantilla de incidencia y aporta detalles, cuantos más es mejor. * Explica de forma clara el impacto de la incidencia en los usuarios. * Mantén el alcance de una incidencia a una cantidad de trabajo razonable. Para problemas con un alcance muy amplio divídela en incidencias más pequeñas. Por ejemplo, "Arreglar la documentación de seguridad" no es una incidencia procesable, pero "Añadir detalles en el tema 'Restringir acceso a la red'" si lo es. * Si la incidencia está relacionada con otra o con una petición de cambio puedes referirte a ella tanto por la URL como con el número de la incidencia o petición de cambio con el carácter `#` delante. Por ejemplo `Introducido por #987654`. * Se respetuoso y evita desahogarte. Por ejemplo, "La documentación sobre X apesta" no es útil o una crítica constructiva. El [Código de conducta](https://kubernetes.io/es/community/code-of-conduct/) también aplica para las interacciones en los repositorios de Kubernetes en GitHub. Participa en las discusiones de SIG Docs ---------------------------------------- El equipo de SIG Docs se comunica por las siguientes vías: * [Únete al Slack de Kubernetes](http://slack.k8s.io/) y entra al canal `#sig-docs` o `#kubernetes-docs-es` para la documentación en castellano. En Slack, discutimos sobre las incidencias de documentación en tiempo real, nos coordinamos y hablamos de temas relacionados con la documentación. No olvides presentarte cuando entres en el canal para que podamos saber un poco más de ti! * [Únete a la lista de correo `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) , donde tienen lugar las discusiones más amplias y se registran las decisiones oficiales. * Participa en la video-conferencia [semanal de SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) , esta se anuncia en el canal de Slack y la lista de correo. Actualmente esta reunión tiene lugar usando Zoom, por lo que necesitas descargar el [cliente Zoom](https://zoom.us/download) o llamar usando un teléfono. #### Nota: Puedes revisar la reunión semanal de SIG Docs en el [Calendario de reuniones de la comunidad Kubernetes](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles) . Mejorar contenido existente --------------------------- Para mejorar contenido existente crea una _pull request(PR)_ después de crear un _fork_. Estos términos son [específicos de GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/) . No es necesario conocer todo sobre estos términos porque todo se realiza a través del navegador web. Cuando continúes con la [guía de contribución de documentación intermedia](https://kubernetes.io/docs/contribute/intermediate/) entonces necesitarás un poco más de conocimiento de la metodología Git. #### Nota: **Desarrolladores de código de Kubernetes**: Si estás documentando una nueva característica para una versión futura de Kubernetes, entonces el proceso es un poco diferente. Mira el proceso y pautas en [Documentar una característica](https://kubernetes.io/docs/contribute/intermediate/#sig-members-documenting-new-features) así como información sobre plazos. ### Firma el CNCF CLA Antes de poder contribuir o documentar en Kubernetes **es necesario** leer [Guía del contribuidor](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) y [firmar el `Contributor License Agreement` (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md) . No te preocupes esto no lleva mucho tiempo! ### Busca algo con lo que trabajar Si ves algo que quieras arreglar directamente, simplemente sigue las instrucciones más abajo. No es necesario que [reportes una incidencia](https://kubernetes.io/es/docs/contribute/_print/#registro-de-incidencias) (aunque de todas formas puedes). Si quieres empezar por buscar una incidencia existente para trabajar puedes ir [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) y buscar una incidencia con la etiqueta `good first issue` (puedes usar [este](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) atajo). Lee los comentarios y asegurate de que no hay una petición de cambio abierta para esa incidencia y que nadie a dejado un comentario indicando que están trabajando en esa misma incidencia recientemente (3 días es una buena regla). Deja un comentario indicando que te gustaría trabajar en la incidencia. ### Elije que rama de Git usar El aspecto más importante a la hora de mandar una petición de cambio es que rama usar como base para trabajar. Usa estas pautas para tomar la decisión: * Utiliza `master` para arreglar problemas en contenido ya existente publicado, o hacer mejoras en contenido ya existente. * Utiliza una rama de versión (cómo `dev-release-1.35` para la versión release-1.35) para documentar futuras características o cambios para futuras versiones que todavía no se han publicado. * Utiliza una rama de características que haya sido acordada por SIG Docs para colaborar en grandes mejoras o cambios en la documentación existente, incluida la reorganización de contenido o cambios en la apariencia del sitio web. Si todavía no estás seguro con que rama utilizar, pregunta en `#sig-docs`en Slack o atiende una reunión semanal del SIG Docs para aclarar tus dudas. ### Enviar una petición de cambio Sigue estos pasos para enviar una petición de cambio y mejorar la documentación de Kubernetes. 1. En la página que hayas visto una incidencia haz clic en el icono del lápiz arriba a la derecha. Una nueva página de GitHub aparecerá con algunos textos de ayuda. 2. Si nunca has creado un copia del repositorio de documentación de Kubernetes te pedirá que lo haga. Crea la copia bajo tu usuario de GitHub en lugar de otra organización de la que seas miembro. La copia generalmente tiene una URL como `https://github.com//website`, a menos que ya tengas un repositorio con un nombre en conflicto con este. La razón por la que se pide crear una copia del repositorio es porque no tienes permisos para subir cambios directamente a rama en el repositorio original de Kubernetes. 3. Aparecerá el editor Markdown de GitHub con el fichero Markdown fuente cargado. Realiza tus cambios. Debajo del editor completa el formulario **Propose file change**. El primer campo es el resumen del mensaje de tu commit y no debe ser más largo de 50 caracteres. El segundo campo es opcional, pero puede incluir más información y detalles si procede. #### Nota: No incluyas referencias a otras incidencias o peticiones de cambio de GitHub en el mensaje de los commits. Esto lo puedes añadir después en la descripción de la petición de cambio. Haz clic en **Propose file change**. El cambio se guarda como un commit en una nueva rama de tu copia, automáticamente se le asignará un nombre estilo `patch-1`. 4. La siguiente pantalla resume los cambios que has hecho pudiendo comparar la nueva rama (la **head fork** y cajas de selección **compare**) con el estado actual del **base fork** y la rama **base** (`master` en el repositorio por defecto `kubernetes/website`). Puedes cambiar cualquiera de las cajas de selección, pero no lo hagas ahora. Hecha un vistazo a las distintas vistas en la parte baja de la pantalla y si todo parece correcto haz clic en **Create pull request**. #### Nota: Si no deseas crear una petición de cambio puedes hacerlo más delante, solo basta con navegar a la URL principal del repositorio de Kubernetes website o de tu copia. La página de GitHub te mostrará un mensaje para crear una petición de cambio si detecta que has subido una nueva rama a tu repositorio copia. 5. La pantalla **Open a pull request** aparece. El tema de una petición de cambio es el resumen del commit, pero puedes cambiarlo si lo necesitas. El cuerpo está pre-cargado con el mensaje del commit extendido (si lo hay) junto con una plantilla. Lee la plantilla y llena los detalles requeridos, entonces borra el texto extra de la plantilla. Deja la casilla **Allow edits from maintainers** seleccionada. Haz clic en **Create pull request**. Enhorabuena! Tu petición de cambio está disponible en [Pull requests](https://github.com/kubernetes/website/pulls) . Después de unos minutos ya podrás pre-visualizar la página con los cambios de tu PR aplicados. Ve a la pestaña de **Conversation** en tu PR y haz clic en el enlace **Details** para ver el test `deploy/netlify`, localizado casi al final de la página. Se abrirá en la misma ventana del navegado por defecto. 6. Espera una revisión. Generalmente `k8s-ci-robot` sugiere unos revisores. Si un revisor te pide que hagas cambios puedes ir a la pestaña **FilesChanged** y hacer clic en el icono del lápiz para hacer tus cambios en cualquiera de los ficheros en la petición de cambio. Cuando guardes los cambios se creará un commit en la rama asociada a la petición de cambio. 7. Si tu cambio es aceptado, un revisor fusionará tu petición de cambio y tus cambios serán visibles en pocos minutos en la web de [kubernetes.io](https://kubernetes.io/) . Esta es solo una forma de mandar una petición de cambio. Si eres un usuario de Git y GitHub avanzado puedes usar una aplicación GUI local o la linea de comandos con el cliente Git en lugar de usar la UI de GitHub. Algunos conceptos básicos sobre el uso de la línea de comandos Git cliente se discuten en la guía de documentación [intermedia](https://kubernetes.io/docs/contribute/intermediate/) . Revisar peticiones de cambio de documentación --------------------------------------------- Las personas que aún no son aprobadores o revisores todavía pueden revisar peticiones de cambio. Las revisiones no se consideran "vinculantes", lo que significa que su revisión por sí sola no hará que se fusionen las peticiones de cambio. Sin embargo, aún puede ser útil. Incluso si no deja ningún comentario de revisión, puede tener una idea de las convenciones y etiquetas en una petición de cambio y acostumbrarse al flujo de trabajo. 1. Ve a [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls) . Desde ahí podrás ver una lista de todas las peticiones de cambio en la documentación del website de Kubernetes. 2. Por defecto el único filtro que se aplica es `open`, por lo que no puedes ver las que ya se han cerrado o fusionado. Es una buena idea aplicar el filtro `cncf-cla: yes` y para tu primera revisión es una buena idea añadir `size/S` o `size/XS`. La etiqueta `size` se aplica automáticamente basada en el número de lineas modificadas en la PR. Puedes aplicar filtros con las cajas de selección al principio de la página, o usar [estos atajos](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) solo para PRs pequeñas. Los filtros son aplicados con `AND` todos juntos, por lo que no se puede buscar a la vez `size/S` y `size/XS` en la misma consulta. 3. Ve a la pestaña **Files changed**. Mira los cambios introducidos en la PR, y si aplica, mira también los incidentes enlazados. Si ves un algún problema o posibilidad de mejora pasa el cursor sobre la línea y haz click en el símbolo `+` que aparece. Puedes entonces dejar un comentario seleccionando **Add single comment** o **Start a review**. Normalmente empezar una revisión es la forma recomendada, ya que te permite hacer varios comentarios y avisar a propietario de la PR solo cuando tu revisión este completada, en lugar de notificar cada comentario. 4. Cuando hayas acabado de revisar, haz clic en **Review changes** en la parte superior de la página. Puedes ver un resumen de la revisión y puedes elegir entre comentar, aprobar o solicitar cambios. Los nuevos contribuidores siempre deben elegir **Comment**. Gracias por revisar una petición de cambio! Cuando eres nuevo en un proyecto es buena idea solicitar comentarios y opiniones en las revisiones de una petición de cambio. Otro buen lugar para solicitar comentarios es en el canal de Slack `#sig-docs`. ## Escribir un artículo en el blog Cualquiera puede escribir un articulo en el blog y enviarlo para revisión. Los artículos del blog no deben ser comerciales y deben consistir en contenido que se pueda aplicar de la forma más amplia posible a la comunidad de Kubernetes. Para enviar un artículo al blog puedes hacerlo también usando el formulario [Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSch_phFYMTYlrTDuYziURP6nLMijoXx_f7sLABEU5gWBtxJHQ/viewform) , o puedes seguir los siguientes pasos. 1. [Firma el CLA](https://kubernetes.io/es/docs/contribute/_print/#sign-the-cla) si no lo has hecho ya. 2. Revisa el formato Markdown en los artículos del blog existentes en el [repositorio website](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) . 3. Escribe tu artículo usando el editor de texto que prefieras. 4. En el mismo enlace que el paso 2 haz clic en botón **Create new file**. Pega el contenido de tu editor. Nombra el fichero para que coincida con el título del artículo, pero no pongas la fecha en el nombre. Los revisores del blog trabajarán contigo en el nombre final del fichero y la fecha en la que será publicado. 5. Cuando guardes el fichero, GitHub te guiará en el proceso de petición de cambio. 6. Un revisor de artículos del blog revisará tu envío y trabajará contigo aportando comentarios y los detalles finales. Cuando el artículo sea aprobado, se establecerá una fecha de publicación. Envía un caso de estudio ------------------------ Un caso de estudio destaca como organizaciones están usando Kubernetes para resolver problemas del mundo real. Estos se escriben en colaboración con el equipo de marketing de Kubernetes que está dirigido por la [CNCF](https://cncf.io/ "Cloud Native Computing Foundation") . Revisa el código fuente para ver los [casos de estudio existentes](https://github.com/kubernetes/website/tree/master/content/en/case-studies) . Usa el formulario [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/) para enviar tu propuesta. Siguientes pasos ---------------- Cuando entiendas mejor las tareas mostradas en este tema y quieras formar parte del equipo de documentación de Kubernetes de una forma más activa lee la [guía intermedia de contribución](https://kubernetes.io/docs/contribute/intermediate/) . 2 - Cómo escribir documentación =============================== Los temas de esta sección proporcionan información sobre como **escribir**, **formatear** y **organizar** el contenido de la documentación de Kubernetes. También se explican las funciones, templates, variables y otras configuraciones de **[Hugo](https://gohugo.io/) ** utilizadas para generar y dar formato a [kubernetes.io](https://kubernetes.io/) . 3 - Documentación de referencia =============================== Gran parte de la documentación de referencia de **Kubernetes** se genera a partir del propio **código fuente de Kubernetes** utilizando scripts. Los temas de esta sección documentan cómo generar este tipo de contenido. 4 - Contribuir a la documentación de Kubernetes en español ========================================================== ¡Bienvenido(a)! En esta página encontrarás información sobre convenciones utilizadas en la documentación en castellano y un glosario de términos con sus traducciones. Glosario de terminología ------------------------ | English | Español | Género | Commentarios | | --- | --- | --- | --- | | availability zone | zona de disponibilidad | femenino | | | bearer token | bearer token | masculino | | | built-in | incorporados | masculino | | | conditions | condiciones | masculino | para node conditions | | container | contenedor | masculino | | | controller | controlador | masculino | | | deploy | desplegar | | | | Deployment | Deployment | masculino | objeto Kubernetes | | Endpoints | Endpoints | masculino | objeto Kubernetes | | file | archivo | masculino | | | frontend | frontend | masculino | | | healthy | operativo | | | | high availability | alta disponibilidad | | | | hook | hook | masculino | | | instance | instancia | femenino | | | Lease | Lease | masculino | objeto Kubernetes | | Pod | Pod | masculino | objeto Kubernetes | | ratio | ritmo | | | | runtime | motor de ejecución | masculino | Container Runtime | | scheduler | planificador | masculino | | | Secret | Secret | masculino | objeto Kubernetes | | secret | secreto | masculino | información confidencial | | shell | terminal | femenino | | | stateless | stateless | | | | taint | contaminación | | | | worker node | nodo de trabajo | masculino | | --- # Kontainer | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/id/docs/concepts/containers/_print/#) . [Return to the regular view of this page](https://kubernetes.io/id/docs/concepts/containers/) . Kontainer ========= * 1: [Ikhtisar Kontainer](https://kubernetes.io/id/docs/concepts/containers/_print/#pg-8fda96dc403731ceba5e0ddd0ab3ad15) * 2: [Image](https://kubernetes.io/id/docs/concepts/containers/_print/#pg-16042b4652ad19e565c7263824029a43) * 3: [Kontainer Environment](https://kubernetes.io/id/docs/concepts/containers/_print/#pg-643212488f778acf04bebed65ba34441) * 4: [Runtime Class](https://kubernetes.io/id/docs/concepts/containers/_print/#pg-a858027489648786a3b16264e451272b) * 5: [Lifecyle Hook pada Kontainer](https://kubernetes.io/id/docs/concepts/containers/_print/#pg-e6941d969d81540208a3e78bc56f43bc) 1 - Ikhtisar Kontainer ====================== Kontainer adalah teknologi untuk mengemas kode (yang telah dikompilasi) menjadi suatu aplikasi beserta dengan dependensi-dependensi yang dibutuhkannya pada saat dijalankan. Setiap kontainer yang Anda jalankan dapat diulang; standardisasi dengan menyertakan dependensinya berarti Anda akan mendapatkan perilaku yang sama di mana pun Anda menjalankannya. Kontainer memisahkan aplikasi dari infrastruktur host yang ada dibawahnya. Hal ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda. Image-Image Kontainer --------------------- [Kontainer image](https://kubernetes.io/id/docs/concepts/containers/images/) meruapakan paket perangkat lunak yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan sebuah aplikasi: kode dan setiap _runtime_ yang dibutuhkan, _library_ dari aplikasi dan sistem, dan nilai _default_ untuk penganturan yang penting. Secara desain, kontainer tidak bisa berubah: Anda tidak dapat mengubah kode dalam kontainer yang sedang berjalan. Jika Anda memiliki aplikasi yang terkontainerisasi dan ingin melakukan perubahan, maka Anda perlu membuat kontainer baru dengan menyertakan perubahannya, kemudian membuat ulang kontainer dengan memulai dari _image_ yang sudah diubah. Kontainer _runtime_ ------------------- Kontainer _runtime_ adalah perangkat lunak yang bertanggung jawab untuk menjalankan kontainer. Kubernetes mendukung beberapa kontainer _runtime_: [Docker](https://docs.docker.com/engine/ "Docker merupakan suatu teknologi perangkat lunak yang menyediakan virtualisasi pada level sistem operasi yang juga dikenal sebagai Container.") , [containerd](https://containerd.io/docs/ "A container runtime with an emphasis on simplicity, robustness and portability") , [CRI-O](https://cri-o.io/#what-is-cri-o "A lightweight container runtime specifically for Kubernetes") , dan semua implementasi dari [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Selanjutnya ----------- * Baca tentang [image-image kontainer](https://kubernetes.io/docs/concepts/containers/images/) * Baca tentang [Pod](https://kubernetes.io/docs/concepts/workloads/pods/) 2 - Image ========= Kamu membuat Docker _image_ dan mengunduhnya ke sebuah registri sebelum digunakan di dalam Kubernetes Pod. Properti `image` dari sebuah Container mendukung sintaksis yang sama seperti perintah `docker`, termasuk registri privat dan _tag_. Memperbarui Image ----------------- Kebijakan _pull default_ adalah `IfNotPresent` yang membuat Kubelet tidak lagi mengunduh (_pull_) sebuah image jika sudah ada terlebih dahulu. Jika kamu ingin agar selalu diunduh, kamu bisa melakukan salah satu dari berikut: * mengatur `imagePullPolicy` dari Container menjadi `Always`. * buang `imagePullPolicy` dan gunakan `:latest` _tag_ untuk _image_ yang digunakan. * buang `imagePullPolicy` dan juga _tag_ untuk _image_. * aktifkan [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) _admission controller_. Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](https://kubernetes.io/id/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut. Membuat Image Multi-arsitektur dengan Manifest ---------------------------------------------- Docker CLI saat ini mendukung perintah `docker manifest` dengan anak perintah `create`, `annotate`, dan `push`. Perintah-perintah ini dapat digunakan untuk membuat (_build_) dan mengunggah (_push_) manifes. Kamu dapat menggunakan perintah `docker manifest inspect` untuk membaca manifes. Lihat dokumentasi docker di sini: [https://docs.docker.com/edge/engine/reference/commandline/manifest/](https://docs.docker.com/edge/engine/reference/commandline/manifest/) Lihat contoh-contoh bagaimana kami menggunakan ini untuk proses _build harness_: [https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=](https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=) Perintah-perintah ini bergantung pada Docker CLI, dan diimplementasi hanya di sisi CLI. Kamu harus mengubah `$HOME/.docker/config.json` dan mengatur _key_ `experimental` untuk mengaktifkan atau cukup dengan mengatur `DOCKER_CLI_EXPERIMENTAL` variabel _environment_ menjadi `enabled` ketika memanggil perintah-perintah CLI. #### Catatan: Gunakan Docker _18.06 ke atas_, versi-versi di bawahnya memiliki _bug_ ataupun tidak mendukung perintah eksperimental. Contohnya [https://github.com/docker/cli/issues/1135](https://github.com/docker/cli/issues/1135) yang menyebabkan masalah di bawah containerd. Kalau kamu terkena masalah ketika mengunggah manifes-manifes yang rusak, cukup bersihkan manifes-manifes yang lama di `$HOME/.docker/manifests` untuk memulai dari awal. Untuk Kubernetes, kami biasanya menggunakan _image-image_ dengan sufiks `-$(ARCH)`. Untuk kompatibilitas (_backward compatibility_), lakukan _generate image-image_ yang lama dengan sufiks. Idenya adalah men-_generate_, misalnya `pause` image yang memiliki manifes untuk semua arsitektur dan misalnya `pause-amd64` yang punya kompatibilitas terhadap konfigurasi-konfigurasi lama atau berkas-berkas YAML yang bisa saja punya _image-image_ bersufiks yang di-_hardcode_. Menggunakan Registri Privat (_Private Registry_) ------------------------------------------------ Biasanya kita memerlukan _key_ untuk membaca _image-image_ yang tersedia pada suatu registri privat. Kredensial ini dapat disediakan melalui beberapa cara: * Menggunakan Google Container Registry * per-klaster * konfigurasi secara otomatis pada Google Compute Engine atau Google Kubernetes Engine * semua Pod dapat membaca registri privat yang ada di dalam proyek * Menggunakan Amazon Elastic Container Registry (ECR) * menggunakan IAM _role_ dan _policy_ untuk mengontrol akses ke repositori ECR * secara otomatis _refresh_ kredensial login ECR * Menggunakan Oracle Cloud Infrastructure Registry (OCIR) * menggunakan IAM _role_ dan _policy_ untuk mengontrol akses ke repositori OCIR * Menggunakan Azure Container Registry (ACR) * Menggunakan IBM Cloud Container Registry * menggunakan IAM _role_ dan _policy_ untuk memberikan akses ke IBM Cloud Container Registry * Konfigurasi Node untuk otentikasi registri privat * semua Pod dapat membaca registri privat manapun * memerlukan konfigurasi Node oleh admin klaster * Pra-unduh _image_ * semua Pod dapat menggunakan _image_ apapun yang di-_cached_ di dalam sebuah Node * memerlukan akses root ke dalam semua Node untuk pengaturannya * Mengatur ImagePullSecrets dalam sebuah Pod * hanya Pod-Pod yang menyediakan _key_ sendiri yang dapat mengakses registri privat Masing-masing opsi dijelaskan lebih lanjut di bawah ini. ### Menggunakan Google Container Registry Kubernetes memiliki dukungan _native_ untuk [Google Container Registry (GCR)](https://cloud.google.com/tools/container-registry/) , ketika dijalankan pada Google Compute Engine (GCE). Jika kamu menjalankan klaster pada GCE atau Google Kubernetes Engine, cukup gunakan nama panjang _image_ (misalnya gcr.io/my\_project/image:tag). Semua Pod di dalam klaster akan memiliki akses baca _image_ di registri ini. Kubelet akan melakukan otentikasi GCR menggunakan _service account_ yang dimiliki _instance_ Google. _Service acccount_ pada _instance_ akan memiliki sebuah `https://www.googleapis.com/auth/devstorage.read_only`, sehingga dapat mengunduh dari GCR di proyek yang sama, tapi tidak untuk unggah. ### Menggunakan Amazon Elastic Container Registry Kubernetes memiliki dukungan _native_ untuk [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) , ketika Node adalah AWS EC2 _instance_. Cukup gunakan nama panjang _image_ (misalnya `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) di dalam definisi Pod. Semua pengguna klaster yang dapat membuat Pod akan bisa menjalankan Pod yang dapat menggunakan _image-image_ di dalam registri ECR. Kubelet akan mengambil dan secara periodik memperbarui kredensial ECR, yang memerlukan _permission_ sebagai berikut: * `ecr:GetAuthorizationToken` * `ecr:BatchCheckLayerAvailability` * `ecr:GetDownloadUrlForLayer` * `ecr:GetRepositoryPolicy` * `ecr:DescribeRepositories` * `ecr:ListImages` * `ecr:BatchGetImage` Persyaratan: * Kamu harus menggunakan versi kubelet `v1.2.0` atau lebih (misal jalankan `/usr/bin/kubelet --version=true`). * Jika Node yang kamu miliki ada di region A dan registri kamu ada di region yang berbeda misalnya B, kamu perlu versi `v1.3.0` atau lebih. * ECR harus tersedia di region kamu. Cara _troubleshoot_: * Verifikasi semua persyaratan di atas. * Dapatkan kredensial $REGION (misalnya `us-west-2`) pada _workstation_ kamu. Lakukan SSH ke dalam _host_ dan jalankan Docker secara manual menggunakan kredensial tersebut. Apakah berhasil? * Tambahkan verbositas level _log_ kubelet paling tidak 3 dan periksa _log_ kubelet (misal `journalctl -u kubelet`) di baris-baris yang seperti ini: * `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` * `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr..amazonaws.com` ### Menggunakan Azure Container Registry (ACR) Ketika menggunakan [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) kamu dapat melakukan otentikasi menggunakan pengguna admin maupun sebuah _service principal_. Untuk keduanya, otentikasi dilakukan melalui proses otentikasi Docker standar. Instruksi-instruksi ini menggunakan perangkat [azure-cli](https://github.com/azure/azure-cli) . Kamu pertama perlu membuat sebuah registri dan men-_generate_ kredensial, dokumentasi yang lengkap tentang hal ini dapat dilihat pada [dokumentasi Azure container registry](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli) . Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk login: * `DOCKER_USER` : _service principal_, atau pengguna admin * `DOCKER_PASSWORD`: kata sandi dari _service principal_, atau kata sandi dari pengguna admin * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io` * `DOCKER_EMAIL`: `${some-email-address}` Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat [mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](https://kubernetes.io/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) . ### Menggunakan IBM Cloud Container Registry IBM Cloud Container Registry menyediakan sebuah registri _image_ privat yang _multi-tenant_, dapat kamu gunakan untuk menyimpan dan membagikan _image-image_ secara aman. Secara _default_, _image-image_ di dalam registri privat kamu akan dipindai (_scan_) oleh Vulnerability Advisor terintegrasi untuk deteksi isu keamanan dan kerentanan (_vulnerability_) yang berpotensi. Para pengguna di dalam akun IBM Cloud kamu dapat mengakses _image_, atau kamu dapat menggunakan IAM _role_ dan _policy_ untuk memberikan akses ke _namespace_ di IBM Cloud Container Registry. Untuk instalasi _plugin_ CLI di IBM Cloud Containerr Registry dan membuat sebuah _namespace_ untuk _image-image_ kamu, lihat [Mulai dengan IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=registry-getting-started) . Jika kamu menggunakan akun dan wilayah (_region_) yang sama, kamu dapat melakukan _deploy image-image_ yang disimpan di dalam IBM Cloud Container Registry ke dalam _namespace default_ dari klaster IBM Cloud Kubernetes Service yang kamu miliki tanpa konfigurasi tambahan, lihat [Membuat kontainer dari _image_](https://cloud.ibm.com/docs/containers?topic=containers-images) . Untuk opsi konfigurasi lainnya, lihat [Bagaimana cara mengotorasi klaster untuk mengunduh _image_ dari sebuah registri](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth) . ### Konfigurasi Node untuk Otentikasi ke sebuah Registri Privat #### Catatan: Jika kamu jalan di Google Kubernetes Engine, akan ada `.dockercfg` pada setiap Node dengan kredensial untuk Google Container Registry. Kamu tidak bisa menggunakan cara ini. #### Catatan: Jika kamu jalan di AWS EC2 dan menggunakan EC2 Container Registry (ECR), kubelet pada setiap Node akan dapat mengatur dan memperbarui kredensial login ECR. Kamu tidak bisa menggunakan cara ini. #### Catatan: Cara ini cocok jika kamu dapat mengontrol konfigurasi Node. Cara ini tidak akan bekerja dengan baik pada GCE, dan penyedia layanan cloud lainnya yang tidak melakukan penggantian Node secara otomatis. #### Catatan: Kubernetes pada saat ini hanya mendukung bagian `auths` dan `HttpHeaders` dari konfigurasi docker. Hal ini berarti bantuan kredensial (`credHelpers` atau `credsStore`) tidak didukung. Docker menyimpan _key_ untuk registri privat pada `$HOME/.dockercfg` atau berkas `$HOME/.docker/config.json`. Jika kamu menempatkan berkas yang sama pada daftar jalur pencarian (_search path_) berikut, kubelet menggunakannya sebagai penyedia kredensial saat mengunduh _image_. * `{--root-dir:-/var/lib/kubelet}/config.json` * `{cwd of kubelet}/config.json` * `${HOME}/.docker/config.json` * `/.docker/config.json` * `{--root-dir:-/var/lib/kubelet}/.dockercfg` * `{cwd of kubelet}/.dockercfg` * `${HOME}/.dockercfg` * `/.dockercfg` #### Catatan: Kamu mungkin harus mengatur `HOME=/root` secara eksplisit pada berkas _environment_ kamu untuk kubelet. Berikut langkah-langkah yang direkomendasikan untuk mengkonfigurasi Node kamu supaya bisa menggunakan registri privat. Pada contoh ini, coba jalankan pada _desktop/laptop_ kamu: 1. Jalankan `docker login [server]` untuk setiap set kredensial yang ingin kamu gunakan. Ini akan memperbarui `$HOME/.docker/config.json`. 2. Lihat `$HOME/.docker/config.json` menggunakan _editor_ untuk memastikan sudah berisi kredensial yang ingin kamu gunakan. 3. Dapatkan daftar Node, contohnya: * jika kamu ingin mendapatkan nama: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` * jika kamu ingin mendapatkan IP: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` 4. Salin `.docker/config.json` yang ada di lokal kamu pada salah satu jalur pencarian di atas. * contohnya: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done` Verifikasi dengana membuat sebuah Pod yanag menggunakan _image_ privat, contohnya: kubectl apply -f - < --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas, kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret. [Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](https://kubernetes.io/id/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini. Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat, perintah `kubectl create secret docker-registry` akan membuat sebuah Secret yang akan hanya bekerja menggunakan satu registri privat. #### Catatan: Pod-Pod hanya dapat mengacu pada imagePullSecrets di dalam _namespace_, sehingga proses ini perlu untuk diselesaikan satu kali setiap _namespace_. #### Mengacu pada imagePullSecrets di dalam sebuah Pod Sekarang, kamu dapat membuat Pod yang mengacu pada Secret dengan menambahkan bagian `imagePullSecrets` untuk sebuah definisi Pod. cat < pod.yaml apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey EOF cat <> ./kustomization.yaml resources: - pod.yaml EOF Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri privat. Hanya saja, mengatur _field_ ini dapat diotomasi dengan mengatur imagePullSecrets di dalam sumber daya [serviceAccount](https://kubernetes.io/docs/user-guide/service-accounts) . Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](https://kubernetes.io/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail. Kamu dapat menggunakan cara ini bersama `.docker/config.json` pada setiap Node. Kredensial-kredensial akan dapat di-_merged_. Cara ini akan dapat bekerja pada Google Kubernetes Engine. ### Kasus-Kasus Penggunaan (_Use Case_) Ada beberapa solusi untuk konfigurasi registri privat. Berikut beberapa kasus penggunaan dan solusi yang disarankan. 1. Klaster yang hanya menjalankan _image non-proprietary_ (misalnya open-source). Tidak perlu unutuk menyembunyikan _image_. * Gunakan _image_ publik pada Docker hub. * Tidak ada konfigurasi yang diperlukan. * Pada GCE/Google Kubernetes Engine, sebuah _mirror_ lokal digunakan secara otomatis untuk meningkatkan kecepatan dan ketersediaan. 2. Klaster yang menjalankan _image proprietary_ yang seharusnya disembunyikan dari luar perusahaan, tetapi bisa terlihat oleh pengguna klaster. * Gunakan sebuah privat [registri Docker](https://docs.docker.com/registry/) yang _hosted_. * Bisa saja di-_host_ pada [Docker Hub](https://hub.docker.com/signup) , atau lainnya. * Konfigurasi `.docker/config.json` secara manual pada setiap Node seperti dijelaskan di atas. * Atau, jalankan sebuah registri privat internal di belakang _firewall_ kamu dengan akses baca terbuka. * Tidak ada konfigurasi Kubernetes yang diperlukan. * Atau, ketika pada GCE/Google Kubernetes Engine, menggunakan Google Container Registry yang ada di proyek. * Hal ini bisa bekerja baik dengan _autoscaling_ klaster dibandingkan konfigurasi Node manual. * Atau, pada sebuah klaster dimana mengubah konfigurasi Node tidak nyaman, gunakan `imagePullSecrets`. 3. Klaster dengan _image proprietary_, beberapa memerlukan akses kontrol yang lebih ketat. * Pastikan [AlwaysPullImages _admission controller_](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktif. Sebaliknya, semua Pod berpotensi memiliki akses ke semua _image_. * Pindahkan data sensitif pada sumber daya "Secret", daripada mengemasnya menjadi sebuah _image_. 4. Sebuah klaster _multi-tenant_ dimana setiap _tenant_ memerlukan registri privatnya masing-masing. * Pastikan [AlwaysPullImages _admission controller_](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktif. Sebaliknya, semua Pod dari semua tenant berpotensi memiliki akses pada semua _image_. * Jalankan sebuah registri privat dimana otorisasi diperlukan. * Men-_generate_ kredensial registri uuntuk setiap _tenant_, masukkan ke dalam _secret_ uuntuk setiap _namespace tenant_. * _Tenant_ menambahkan _secret_ pada imagePullSecrets uuntuk setiap _namespace_. Jika kamu memiliki akses pada beberapa registri, kamu dapat membuat satu _secret_ untuk setiap registri. Kubelet akan melakukan _merge_ `imagePullSecrets` manapun menjadi sebuah virtual `.docker/config.json`. 3 - Kontainer Environment ========================= Laman ini menjelaskan berbagai _resource_ yang tersedia di dalam Kontainer pada suatu _environment_. _Environment_ Kontainer ----------------------- _Environment_ Kontainer pada Kubernetes menyediakan beberapa _resource_ penting yang tersedia di dalam Kontainer: * Sebuah _Filesystem_, yang merupakan kombinasi antara [image](https://kubernetes.io/id/docs/concepts/containers/images/) dan satu atau banyak [_volumes_](https://kubernetes.io/id/docs/concepts/storage/volumes/) . * Informasi tentang Kontainer tersebut. * Informasi tentang objek-objek lain di dalam klaster. ### Informasi tentang Kontainer _Hostname_ sebuah Kontainer merupakan nama dari Pod dimana Kontainer dijalankan. Informasi ini tersedia melalui perintah `hostname` atau panggilan (_function call_) [`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) pada `libc`. Nama Pod dan _namespace_ tersedia sebagai variabel _environment_ melalui [API _downward_](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) . Variabel _environment_ yang ditulis pengguna dalam Pod _definition_ juga tersedia di dalam Kontainer, seperti halnya variabel _environment_ yang ditentukan secara statis di dalam _image_ Docker. ### Informasi tentang Klaster Daftar semua _Service_ yang dijalankan ketika suatu Kontainer dibuat, tersedia di dalam Kontainer tersebut sebagai variabel _environment_. Variabel-variabel _environment_ tersebut sesuai dengan sintaksis _links_ dari Docker. Untuk suatu _Service_ bernama _foo_ yang terkait dengan Kontainer bernama _bar_, variabel-variabel di bawah ini tersedia: FOO_SERVICE_HOST= FOO_SERVICE_PORT= Semua _Service_ memiliki alamat-alamat IP yang bisa didapatkan di dalam Kontainer melalui DNS, jika [_addon_ DNS](http://releases.k8s.io/main/cluster/addons/dns/) diaktifkan.  Selanjutnya ----------- * Pelajari lebih lanjut tentang [berbagai _hook_ pada _lifecycle_ Kontainer](https://kubernetes.io/id/docs/concepts/containers/container-lifecycle-hooks/) . * Dapatkan pengalaman praktis soal [memberikan _handler_ untuk _event_ dari _lifecycle_ Kontainer](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . 4 - Runtime Class ================= FEATURE STATE: `Kubernetes v1.14 [beta]` Laman ini menjelaskan tentang _resource_ RuntimeClass dan proses pemilihan _runtime_. #### Peringatan: RuntimeClass memiliki _breaking change_ untuk pembaruan ke beta pada v1.14. Jika kamu menggunakan RuntimeClass sebelum v1.14, lihat [Memperbarui RuntimeClass dari Alpha ke Beta](https://kubernetes.io/id/docs/concepts/containers/_print/#memperbarui-runtimeclass-dari-alpha-ke-beta) . `Runtime Class` --------------- RuntimeClass merupakan sebuah fitur untuk memilih konfigurasi _runtime_ kontainer. Konfigurasi tersebut digunakan untuk menjalankan kontainer-kontainer milik suatu Pod. ### Persiapan Pastikan gerbang fitur (_feature gate_) `RuntimeClass` sudah aktif (secara _default_ sudah aktif). Lihat [Gerbang Fitur](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) untuk lebih jelasnya soal pengaktifan gerbang fitur. Gerbang fitur RuntimeClass ini harus aktif pada semua apiserver dan kubelet. 1. Lakukan konfigurasi pada implementasi CRI untuk setiap _node_ (tergantung _runtime_ yang dipilih) 2. Buat _resource_ RuntimeClass yang terkait #### 1\. Lakukan konfigurasi pada implementasi CRI untuk setiap _node_ Pilihan konfigurasi yang tersedia melalui RuntimeClass tergantung pada implementasi _Container Runtime Interface_ (CRI). Lihat bagian ([di bawah ini](https://kubernetes.io/id/docs/concepts/containers/_print/#konfigurasi-cri) ) soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki. #### Catatan: Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](https://kubernetes.io/id/docs/concepts/scheduling-eviction/assign-pod-node/) ). Seluruh konfigurasi memiliki nama `handler` yang terkait, dijadikan referensi oleh RuntimeClass. Nama _handler_ harus berupa valid label 1123 DNS (alfanumerik + karakter `-`). #### 2\. Buat _resource_ `RuntimeClass` yang terkait Masing-masing konfigurasi pada langkah no.1 punya nama `handler` yang merepresentasikan konfigurasi-konfigurasi tersebut. Untuk masing-masing `handler`, buatlah sebuah objek RuntimeClass terkait. _Resource_ RuntimeClass saat ini hanya memiliki 2 _field_ yang penting: nama RuntimeClass tersebut (`metadata.name`) dan _handler_ (`handler`). Definisi objek tersebut terlihat seperti ini: apiVersion: node.k8s.io/v1beta1 # RuntimeClass didefinisikan pada grup API node.k8s.io kind: RuntimeClass metadata: name: myclass # Nama dari RuntimeClass yang nantinya akan dijadikan referensi # RuntimeClass merupakan resource tanpa namespace handler: myconfiguration # Nama dari konfigurasi CRI terkait #### Catatan: Sangat disarankan untuk hanya memperbolehkan admin klaster melakukan operasi _write_ pada RuntimeClass. Biasanya ini sudah jadi _default_. Lihat [Ikhtisar Autorisasi](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) untuk penjelasan lebih jauh. ### Penggunaan Ketika RuntimeClass sudah dikonfigurasi pada klaster, penggunaannya sangatlah mudah. Kamu bisa tentukan `runtimeClassName` di dalam `spec` sebuah Pod, sebagai contoh: apiVersion: v1 kind: Pod metadata: name: mypod spec: runtimeClassName: myclass # ... Kubelet akan mendapat instruksi untuk menggunakan RuntimeClass dengan nama yang sudah ditentukan tersebut untuk menjalankan Pod ini. Jika RuntimeClass dengan nama tersebut tidak ditemukan, atau CRI tidak dapat menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](https://kubernetes.io/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. Lihat [_event_](https://kubernetes.io/id/docs/tasks/debug-application-cluster/debug-application-introspection/) untuk mengetahui pesan error yang terkait. Jika tidak ada `runtimeClassName` yang ditentukan di dalam Pod, maka RuntimeHandler yang _default_ akan digunakan. Untuk kasus ini, perilaku klaster akan seperti saat fitur RuntimeClass dinonaktifkan. ### Konfigurasi CRI Lihat [instalasi CRI](https://kubernetes.io/docs/setup/cri/) untuk lebih detail mengenai pengaturan _runtime_ CRI. #### dockershim _Built-in_ dockershim CRI yang dimiliki Kubernetes tidak mendukung _handler runtime_. #### [containerd](https://containerd.io/) _Handler runtime_ diatur melalui konfigurasi containerd pada `/etc/containerd/config.toml`. _Handler_ yang valid dapat dikonfigurasi pada bagian _runtime_: [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] Lihat dokumentasi konfigurasi containerd untuk lebih detail: [https://github.com/containerd/containerd/blob/main/docs/cri/config.md](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) #### [cri-o](https://cri-o.io/) _Handler runtime_ dapat diatur menggunakan konfigurasi cri-o pada `/etc/crio/crio.conf`. _Handler_ yang valid dapat dikonfigurasi pada [tabel crio.runtime](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) : [crio.runtime.runtimes.${HANDLER_NAME}] runtime_path = "${PATH_TO_BINARY}" Lihat dokumentasi konfigurasi cri-o untuk lebih detail: [https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go](https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go) ### Memperbarui RuntimeClass dari Alpha ke Beta Fitur Beta pada RuntimeClass memiliki perubahan sebagai berikut: * Grup API _resource_ `node.k8s.io` dan `runtimeclasses.node.k8s.io` telah dimigrasi ke suatu API _built-in_ dari CustomResourceDefinition. * Atribut `spec` telah disederhakan pada definisi RuntimeClass (tidak ada lagi yang namanya RuntimeClassSpec). * _Field_ `runtimeHandler` telah berubah nama menjadi `handler`. * _Field_ `handler` sekarang bersifat wajib untuk semua versi API. Artinya, _field_ `runtimeHandler` pada API Alpha juga bersifat wajib. * _Field_ `handler` haruslah berupa label DNS valid ([RFC 1123](https://tools.ietf.org/html/rfc1123) ), yang artinya tidak bisa berisi karakter `.` (pada semua versi). _Handler_ valid harus sesuai dengan _regular expression_ ini: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`. **Tindakan yang diperlukan:** Tindakan-tindaka berikut ini diperlukan untuk melakukan pembaruan fitur RuntimeClass dari versi alpha ke versi beta: * _Resource_ RuntimeClass harus dibuat ulang **setelah** diperbarui ke v.1.14, dan CRD `runtimeclasses.node.k8s.io` harus dihapus secara manual: kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io * Fitur Alpha pada RuntimeClass akan menjadi tidak valid, jika `runtimeHandler` tidak ditentukan atau kosong atau menggunakan karakter `.` pada _handler_. Ini harus dimigrasi ke _handler_ dengan konfigurasi yang valid (lihat petunjuk di atas). 5 - Lifecyle Hook pada Kontainer ================================ Laman ini menjelaskan bagaimana semua Kontainer yang diatur kubelet menggunakan _framework lifecycle hook_ untuk menjalankan kode yang di-_trigger_ oleh _event_ selama _lifecycle_ berlangsung. Ikhtisar -------- Kubernetes menyediakan _hook_ untuk _lifecycle_ Kontainer. Hal ini sejalan dengan _framework_ bahasa pemrograman pada umumnya yang memiliki _hook_ untuk _lifecycle_ komponen, seperti Angular contohnya. _Hook_ tersebut digunakan Kontainer untuk selalu siap menerima _event_ selama _lifecycle_ dan menjalankan kode yang diimplementasi pada suatu _handler_, ketika _hook lifecycle_ terkait telah dieksekusi. Jenis-jenis _hook_ pada Kontainer --------------------------------- Ada dua jenis _hook_ yang diekspos pada Kontainer: `PostStart` _Hook_ ini dijalankan segera setelah suatu kontainer dibuat. Hanya saja, tidak ada jaminan bahwa _hook_ akan tereksekusi sebelum `ENTRYPOINT` dari kontainer. Tidak ada parameter yang diberikan pada _handler_. `PreStop` _Hook_ ini akan dipanggil sesaat sebelum kontainer dimatikan, karena suatu _request_ API atau _event_ pengaturan, contohnya kegagalan pada _liveness probe_, _preemption_, perebutan _resource_, dan lainnya. Sebuah panggilan untuk _hook_ `PreStop` akan gagal jika kontainer tersebut telah ada pada _state terminate_ atau _complete_. Hal ini bersifat _blocking_, yang artinya panggilan bersifat sinkron (_synchronous_), harus menunggu eksekusi selesai, sebelum melakukan panggilan untuk menghapus kontainer tersebut. Tidak ada parameter yang diberikan pada _handler_. Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](https://kubernetes.io/id/docs/concepts/workloads/pods/pod/#termination-of-pods) . ### Implementasi _handler_ untuk _hook_ Kontainer dapat mengakses sebuah _hook_ melalui implementasi dan registrasi sebuah _handler_ untuk _hook_ tersebut. Ada dua jenis _handler_ untuk _hook_ yang dapat diimplementasikan untuk Kontainer: * Exec - Mengeksekusi sebuah perintah tertentu, contohnya `pre-stop.sh`, di dalam cgroups dan _namespace_ suatu Kontainer. _Resource_ yang dikonsumsi oleh perintah tersebut dianggap sebagai bagian dari Kontainer. * HTTP - Mengeksekusi sebuah _request_ HTTP untuk _endpoint_ tertentu pada Kontainer tersebut. ### Eksekusi _handler_ untuk _hook_ Ketika manajemen _hook_ untuk suatu _lifecycle_ Kontainer dipanggil, sistem manajemen internal pada Kubernetes akan mengeksekusi _handler_ di dalam Kontainer yang terdaftar untuk _hook_ tersebut. Panggilan _handler_ untuk _hook_ semuanya bersifat _synchronous_ di dalam konteks Pod yang memiliki Kontainer tersebut. Artinya, untuk _hook_ `PostStart`, Kontainer `ENTRYPOINT` dan _hook_ dieksekusi secara _asyncrhonous_. Akan tetapi, jika _hook_ mengambil waktu terlalu lama, atau _hang_, Kontainer tersebut tidak bisa sampai ke _state_ `running`. Perilaku ini mirip dengan yang terjadi pada _hook_ `PreStop`. Jika _hook_ terlalu lama atau _hang_ saat dieksekusi, Pod tersebut tetap ada pada _state_ `Terminating` dan akan dimatikan setelah `terminationGracePeriodSeconds` Pod selesai. Jika sebuah _hook_ `PostStart` atau `PreStop` gagal dieksekusi, Kontainer akan dimatikan. Para pengguna sangat disarankan membuat _handler_ untuk _hook_ seringan mungkin (_lightweight_). Biar bagaimanapun, ada beberapa kasus yang memang membutuhkan waktu lama untuk mengeksekusi suatu perintah, misalnya saat proses penyimpanan _state_ sebelum Kontainer dimatikan. ### Jaminan pengiriman _hook_ Proses pengiriman _hook_ akan dilakukan **paling tidak satu kali**. Artinya suatu _hook_ boleh dipanggil beberapa kali untuk _event_ yang sama, seperti dalam `PostStart` atau`PreStop`. Namun begitu, implementasi _hook_ masing-masing harus memastikan bagaimana menangani kasus ini dengan benar. Pada umumnya, hanya terjadi satu proses pengiriman. Jika misalnya sebuah penerima HTTP _hook_ mati atau tidak bisa menerima trafik, maka tidak ada usaha untuk mengirimkan kembali. Namun demikian, bisa saja terjadi dua kali proses pengiriman untuk kasus tertentu. Contohnya, jika kubelet _restart_ saat di tengah proses pengiriman _hook_, _hook_ tersebut akan dikirimkan kembali saat kubelet sudah hidup kembali. ### Melakukan _debug_ _handler_ untuk _hook_ _Log_ untuk suatu _handler hook_ tidak terekspos pada _event_ Pod. Jika _handler_ gagal dieksekusi untuk alasan tertentu, _handler_ akan melakukan _broadcast_ sebuah _event_. Untuk `PostStart`, akan dilakukan _broadcast event_ `FailedPostStartHook`, dan untuk `PreStop`, akan dilakukan _broadcast event_ `FailedPreStopHook`. Kamu dapat melihat _event-event_ ini dengan menjalankan perintah `kubectl describe pod `. Berikut merupakan contoh keluaran _event-event_ setelah perintah tersebut dijalankan. Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook Selanjutnya ----------- * Pelajari lebih lanjut tentang [_environment_ Kontainer](https://kubernetes.io/id/docs/concepts/containers/container-environment-variables/) . * Pelajari bagaimana caranya [melakukan _attach handler_ pada _event lifecycle_ sebuah Kontainer](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . --- # Kubernetes Configuration Good Practices | Kubernetes Kubernetes Configuration Good Practices ======================================= By **Kirti Goyal** | Tuesday, November 25, 2025 Configuration is one of those things in Kubernetes that seems small until it's not. Configuration is at the heart of every Kubernetes workload. A missing quote, a wrong API version or a misplaced YAML indent can ruin your entire deploy. This blog brings together tried-and-tested configuration best practices. The small habits that make your Kubernetes setup clean, consistent and easier to manage. Whether you are just starting out or already deploying apps daily, these are the little things that keep your cluster stable and your future self sane. _This blog is inspired by the original _Configuration Best Practices_ page, which has evolved through contributions from many members of the Kubernetes community._ General configuration practices ------------------------------- ### Use the latest stable API version Kubernetes evolves fast. Older APIs eventually get deprecated and stop working. So, whenever you are defining resources, make sure you are using the latest stable API version. You can always check with kubectl api-resources This simple step saves you from future compatibility issues. ### Store configuration in version control Never apply manifest files directly from your desktop. Always keep them in a version control system like Git, it's your safety net. If something breaks, you can instantly roll back to a previous commit, compare changes or recreate your cluster setup without panic. ### Write configs in YAML not JSON Write your configuration files using YAML rather than JSON. Both work technically, but YAML is just easier for humans. It's cleaner to read and less noisy and widely used in the community. YAML has some sneaky gotchas with boolean values: Use only `true` or `false`. Don't write `yes`, `no`, `on` or `off`. They might work in one version of YAML but break in another. To be safe, quote anything that looks like a Boolean (for example `"yes"`). ### Keep configuration simple and minimal Avoid setting default values that are already handled by Kubernetes. Minimal manifests are easier to debug, cleaner to review and less likely to break things later. ### Group related objects together If your Deployment, Service and ConfigMap all belong to one app, put them in a single manifest file. It's easier to track changes and apply them as a unit. See the [Guestbook all-in-one.yaml](https://github.com/kubernetes/examples/blob/master/web/guestbook/all-in-one/guestbook-all-in-one.yaml) file for an example of this syntax. You can even apply entire directories with: kubectl apply -f configs/ One command and boom everything in that folder gets deployed. ### Add helpful annotations Manifest files are not just for machines, they are for humans too. Use annotations to describe why something exists or what it does. A quick one-liner can save hours when debugging later and also allows better collaboration. The most helpful annotation to set is `kubernetes.io/description`. It's like using comment, except that it gets copied into the API so that everyone else can see it even after you deploy. Managing Workloads: Pods, Deployments, and Jobs ----------------------------------------------- A common early mistake in Kubernetes is creating Pods directly. Pods work, but they don't reschedule themselves if something goes wrong. _Naked Pods_ (Pods not managed by a controller, such as [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) or a [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) ) are fine for testing, but in real setups, they are risky. Why? Because if the node hosting that Pod dies, the Pod dies with it and Kubernetes won't bring it back automatically. ### Use Deployments for apps that should always be running A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) ), is almost always preferable to creating Pods directly. You can roll out a new version, and if something breaks, roll back instantly. ### Use Jobs for tasks that should finish A [Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) is perfect when you need something to run once and then stop like database migration or batch processing task. It will retry if the pods fails and report success when it's done. Service Configuration and Networking ------------------------------------ Services are how your workloads talk to each other inside (and sometimes outside) your cluster. Without them, your pods exist but can't reach anyone. Let's make sure that doesn't happen. ### Create Services before workloads that use them When Kubernetes starts a Pod, it automatically injects environment variables for existing Services. So, if a Pod depends on a Service, create a [Service](https://kubernetes.io/docs/concepts/services-networking/service/) **before** its corresponding backend workloads (Deployments or StatefulSets), and before any workloads that need to access it. For example, if a Service named foo exists, all containers will get the following variables in their initial environment: FOO_SERVICE_HOST= FOO_SERVICE_PORT= DNS based discovery doesn't have this problem, but it's a good habit to follow anyway. ### Use DNS for Service discovery If your cluster has the DNS [add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/) (most do), every Service automatically gets a DNS entry. That means you can access it by name instead of IP: curl http://my-service.default.svc.cluster.local It's one of those features that makes Kubernetes networking feel magical. ### Avoid `hostPort` and `hostNetwork` unless absolutely necessary You'll sometimes see these options in manifests: hostPort: 8080 hostNetwork: true But here's the thing: They tie your Pods to specific nodes, making them harder to schedule and scale. Because each <`hostIP`, `hostPort`, `protocol`\> combination must be unique. If you don't specify the `hostIP` and `protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the default `protocol`. Unless you're debugging or building something like a network plugin, avoid them. If you just need local access for testing, try [`kubectl port-forward`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/) : kubectl port-forward deployment/web 8080:80 See [Use Port Forwarding to access applications in a cluster](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to learn more. Or if you really need external access, use a [`type: NodePort` Service](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport) . That's the safer, Kubernetes-native way. ### Use headless Services for internal discovery Sometimes, you don't want Kubernetes to load balance traffic. You want to talk directly to each Pod. That's where [headless Services](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) come in. You create one by setting `clusterIP: None`. Instead of a single IP, DNS gives you a list of all Pods IPs, perfect for apps that manage connections themselves. Working with labels effectively ------------------------------- [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) are key/value pairs that are attached to objects such as Pods. Labels help you organize, query and group your resources. They don't do anything by themselves, but they make everything else from Services to Deployments work together smoothly. ### Use semantics labels Good labels help you understand what's what, even after months later. Define and use [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) that identify semantic attributes of your application or Deployment. For example; labels: app.kubernetes.io/name: myapp app.kubernetes.io/component: web tier: frontend phase: test * `app.kubernetes.io/name` : what the app is * `tier` : which layer it belongs to (frontend/backend) * `phase` : which stage it's in (test/prod) You can then use these labels to make powerful selectors. For example: kubectl get pods -l tier=frontend This will list all frontend Pods across your cluster, no matter which Deployment they came from. Basically you are not manually listing Pod names; you are just describing what you want. See the [guestbook](https://github.com/kubernetes/examples/tree/master/web/guestbook/) app for examples of this approach. ### Use common Kubernetes labels Kubernetes actually recommends a set of [common labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/) . It's a standardized way to name things across your different workloads or projects. Following this convention makes your manifests cleaner, and it means that tools such as [Headlamp](https://headlamp.dev/) , [dashboard](https://github.com/kubernetes/dashboard#introduction) , or third-party monitoring systems can all automatically understand what's running. ### Manipulate labels for debugging Since controllers (like ReplicaSets or Deployments) use labels to manage Pods, you can remove a label to “detach” a Pod temporarily. Example: kubectl label pod mypod app- The `app-` part removes the label key `app`. Once that happens, the controller won’t manage that Pod anymore. It’s like isolating it for inspection, a “quarantine mode” for debugging. To interactively remove or add labels, use [`kubectl label`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_label/) . You can then check logs, exec into it and once done, delete it manually. That’s a super underrated trick every Kubernetes engineer should know. Handy kubectl tips ------------------ These small tips make life much easier when you are working with multiple manifest files or clusters. ### Apply entire directories Instead of applying one file at a time, apply the whole folder: # Using server-side apply is also a good practice kubectl apply -f configs/ --server-side This command looks for `.yaml`, `.yml` and `.json` files in that folder and applies them all together. It's faster, cleaner and helps keep things grouped by app. ### Use label selectors to get or delete resources You don't always need to type out resource names one by one. Instead, use [selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) to act on entire groups at once: kubectl get pods -l app=myapp kubectl delete pod -l phase=test It's especially useful in CI/CD pipelines, where you want to clean up test resources dynamically. ### Quickly create Deployments and Services For quick experiments, you don't always need to write a manifest. You can spin up a Deployment right from the CLI: kubectl create deployment webapp --image=nginx Then expose it as a Service: kubectl expose deployment webapp --port=80 This is great when you just want to test something before writing full manifests. Also, see [Use a Service to Access an Application in a cluster](https://kubernetes.io/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example. Conclusion ---------- Cleaner configuration leads to calmer cluster administrators. If you stick to a few simple habits: keep configuration simple and minimal, version-control everything, use consistent labels, and avoid relying on naked Pods, you'll save yourself hours of debugging down the road. The best part? Clean configurations stay readable. Even after months, you or anyone on your team can glance at them and know exactly what’s happening. * [←Previous](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/) * [Next→](https://kubernetes.io/blog/2025/11/26/kubernetes-v1-35-sneak-peek/) [RSS Feed](https://kubernetes.io/feed.xml) [Submit a Post](https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/) [@kubernetes.io](https://bsky.app/profile/kubernetes.io) [@Kubernetesio](https://x.com/kubernetesio) [on GitHub](https://github.com/kubernetes/kubernetes) [#kubernetes-users](http://slack.k8s.io/) [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) [Forum](https://discuss.kubernetes.io/) [Kubernetes](https://kubernetes.io/docs/setup) --- # Administration d'un cluster | Kubernetes Version imprimable multipages. [Cliquer ici pour imprimer](https://kubernetes.io/fr/docs/concepts/cluster-administration/_print/#) . [Retour à la version par défaut](https://kubernetes.io/fr/docs/concepts/cluster-administration/) . Administration d'un cluster =========================== Administration cluster Kubernetes * 1: [Vue d'ensemble de l'administration d'un cluster](https://kubernetes.io/fr/docs/concepts/cluster-administration/_print/#pg-fb494ea3b1874bd753dcd11c3f35c2dc) * 2: [Certificats](https://kubernetes.io/fr/docs/concepts/cluster-administration/_print/#pg-2bf9a93ab5ba014fb6ff70b22c29d432) * 3: [Architecture de Journalisation d'évènements (logging)](https://kubernetes.io/fr/docs/concepts/cluster-administration/_print/#pg-c4b1e87a84441f8a90699a345ce48d68) 1 - Vue d'ensemble de l'administration d'un cluster =================================================== Administration cluster Kubernetes La vue d'ensemble de l'administration d'un cluster est destinée à toute personne créant ou administrant un cluster Kubernetes. Il suppose une certaine familiarité avec les [concepts](https://kubernetes.io/fr/docs/concepts/) de Kubernetes. Planifier le déploiement d'un cluster ------------------------------------- Voir le guide: [choisir la bonne solution](https://kubernetes.io/fr/docs/setup/pick-right-solution/) pour des exemples de planification, de mise en place et de configuration de clusters Kubernetes. Les solutions répertoriées dans cet article s'appellent des _distributions_. Avant de choisir un guide, voici quelques considérations: * Voulez-vous simplement essayer Kubernetes sur votre machine ou voulez-vous créer un cluster haute disponibilité à plusieurs nœuds? Choisissez les distributions les mieux adaptées à vos besoins. * **Si vous recherchez la haute disponibilité**, apprenez à configurer des [clusters multi zones](https://kubernetes.io/docs/concepts/cluster-administration/federation/) . * Utiliserez-vous **un cluster Kubernetes hébergé**, comme [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) , ou **hébergerez-vous votre propre cluster**? * Votre cluster sera-t-il **on-premises**, ou **sur un cloud (IaaS)**? Kubernetes ne prend pas directement en charge les clusters hybrides. Cependant, vous pouvez configurer plusieurs clusters. * **Si vous configurez Kubernetes on-premises**, choisissez le [modèle réseau](https://kubernetes.io/docs/concepts/cluster-administration/networking/) qui vous convient le mieux. * Voulez-vous faire tourner Kubernetes sur du **bare metal** ou sur des **machines virtuelles (VMs)**? * Voulez-vous **simplement faire tourner un cluster**, ou vous attendez-vous à faire du **développement actif sur le code du projet Kubernetes**? Dans ce dernier cas, choisissez une distribution activement développée. Certaines distributions n’utilisent que des versions binaires, mais offrent une plus grande variété de choix. * Familiarisez-vous avec les [composants](https://kubernetes.io/docs/admin/cluster-components/) nécessaires pour faire tourner un cluster. A noter: Toutes les distributions ne sont pas activement maintenues. Choisissez des distributions qui ont été testées avec une version récente de Kubernetes. Gérer un cluster ---------------- * [Gérer un cluster](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/) décrit plusieurs rubriques relatives au cycle de vie d’un cluster: création d’un nouveau cluster, mise à niveau des nœuds maître et des workers de votre cluster, maintenance des nœuds (mises à niveau du noyau, par exemple) et mise à niveau de la version de l’API Kubernetes d’un cluster en cours d’exécution. * Apprenez comment [gérer les nœuds](https://kubernetes.io/docs/concepts/nodes/node/) . * Apprenez à configurer et gérer les [quotas de ressources](https://kubernetes.io/docs/concepts/policy/resource-quotas/) pour les clusters partagés. Sécuriser un cluster -------------------- * La rubrique [Certificats](https://kubernetes.io/fr/docs/concepts/cluster-administration/certificates/) décrit les étapes à suivre pour générer des certificats à l’aide de différentes suites d'outils. * L' [Environnement de conteneur dans Kubernetes](https://kubernetes.io/fr/docs/concepts/containers/container-environment/) décrit l'environnement des conteneurs gérés par Kubelet sur un nœud Kubernetes. * Le [Contrôle de l'accès à l'API Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/) explique comment configurer les autorisations pour les utilisateurs et les comptes de service. * La rubrique [Authentification](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) explique l'authentification dans Kubernetes, y compris les différentes options d'authentification. * [Autorisations](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) est distinct de l'authentification et contrôle le traitement des appels HTTP. * [Utiliser les Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) explique les plug-ins qui interceptent les requêtes adressées au serveur d'API Kubernetes après authentification et autorisation. * [Utiliser Sysctls dans un cluster Kubernetes](https://kubernetes.io/docs/concepts/cluster-administration/sysctl-cluster/) explique aux administrateurs comment utiliser l'outil de ligne de commande `sysctl` pour définir les paramètres du noyau. * [Auditer](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) explique comment interagir avec les journaux d'audit de Kubernetes. ### Sécuriser la Kubelet * [Communication Master-Node](https://kubernetes.io/docs/concepts/architecture/master-node-communication/) * [TLS bootstrapping](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) * [Kubelet authentification/autorisations](https://kubernetes.io/docs/admin/kubelet-authentication-authorization/) Services de cluster optionnels ------------------------------ * [Integration DNS](https://kubernetes.io/fr/docs/concepts/services-networking/dns-pod-service/) décrit comment résoudre un nom DNS directement vers un service Kubernetes. * [Journalisation des évènements et surveillance de l'activité du cluster](https://kubernetes.io/fr/docs/concepts/cluster-administration/logging/) explique le fonctionnement de la journalisation des évènements dans Kubernetes et son implémentation. 2 - Certificats =============== Certifications cluster Kubernetes Lorsque vous utilisez l'authentification par certificats client, vous pouvez générer des certificats manuellement grâce à `easyrsa`, `openssl` ou `cfssl`. ### easyrsa **easyrsa** peut générer manuellement des certificats pour votre cluster. 1. Téléchargez, décompressez et initialisez la version corrigée de easyrsa3. curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz tar xzf easy-rsa.tar.gz cd easy-rsa-master/easyrsa3 ./easyrsa init-pki 2. Générez une CA. (`--batch` pour le mode automatique. `--req-cn` CN par défaut à utiliser) ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass 3. Générer un certificat de serveur et une clé. L' argument `--subject-alt-name` définit les adresses IP et noms DNS possibles par lesquels l'API serveur peut être atteind. La `MASTER_CLUSTER_IP` est généralement la première adresse IP du CIDR des services qui est spécifié en tant qu'argument `--service-cluster-ip-range` pour l'API Server et le composant controller manager. L'argument `--days` est utilisé pour définir le nombre de jours après lesquels le certificat expire. L’exemple ci-dessous suppose également que vous utilisez `cluster.local` par défaut comme nom de domaine DNS. ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ "IP:${MASTER_CLUSTER_IP},"\ "DNS:kubernetes,"\ "DNS:kubernetes.default,"\ "DNS:kubernetes.default.svc,"\ "DNS:kubernetes.default.svc.cluster,"\ "DNS:kubernetes.default.svc.cluster.local" \ --days=10000 \ build-server-full server nopass 4. Copiez `pki/ca.crt`, `pki/issued/server.crt`, et `pki/private/server.key` dans votre répertoire. 5. Personnalisez et ajoutez les lignes suivantes aux paramètres de démarrage de l'API Server: --client-ca-file=/yourdirectory/ca.crt --tls-cert-file=/yourdirectory/server.crt --tls-private-key-file=/yourdirectory/server.key ### openssl **openssl** peut générer manuellement des certificats pour votre cluster. 1. Générez ca.key en 2048bit: openssl genrsa -out ca.key 2048 2. A partir de la clé ca.key générez ca.crt (utilisez -days pour définir la durée du certificat): openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt 3. Générez server.key en 2048bit: openssl genrsa -out server.key 2048 4. Créez un fichier de configuration pour générer une demande de signature de certificat (CSR). Assurez-vous de remplacer les valeurs marquées par des "< >" (par exemple, ``) avec des valeurs réelles avant de l'enregistrer dans un fichier (par exemple, `csr.conf`). Notez que la valeur de `MASTER_CLUSTER_IP` est celle du service Cluster IP pour l' API Server comme décrit dans la sous-section précédente. L’exemple ci-dessous suppose également que vous utilisez `cluster.local` par défaut comme nom de domaine DNS. [ req ] default_bits = 2048 prompt = no default_md = sha256 req_extensions = req_ext distinguished_name = dn [ dn ] C = ST = L = O = OU = CN = [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = kubernetes DNS.2 = kubernetes.default DNS.3 = kubernetes.default.svc DNS.4 = kubernetes.default.svc.cluster DNS.5 = kubernetes.default.svc.cluster.local IP.1 = IP.2 = [ v3_ext ] authorityKeyIdentifier=keyid,issuer:always basicConstraints=CA:FALSE keyUsage=keyEncipherment,dataEncipherment extendedKeyUsage=serverAuth,clientAuth subjectAltName=@alt_names 5. Générez la demande de signature de certificat basée sur le fichier de configuration: openssl req -new -key server.key -out server.csr -config csr.conf 6. Générez le certificat de serveur en utilisant ca.key, ca.crt et server.csr: openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out server.crt -days 10000 \ -extensions v3_ext -extfile csr.conf -sha256 7. Vérifiez le certificat: openssl x509 -noout -text -in ./server.crt Enfin, ajoutez les mêmes paramètres aux paramètres de démarrage de l'API Server. ### cfssl **cfssl** est un autre outil pour la génération de certificat. 1. Téléchargez, décompressez et préparez les outils de ligne de commande comme indiqué ci-dessous. Notez que vous devrez peut-être adapter les exemples de commandes en fonction du matériel, de l'architecture et de la version de cfssl que vous utilisez. curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl chmod +x cfssl curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson chmod +x cfssljson curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo chmod +x cfssl-certinfo 2. Créez un répertoire pour contenir les artefacts et initialiser cfssl: mkdir cert cd cert ../cfssl print-defaults config > config.json ../cfssl print-defaults csr > csr.json 3. Créez un fichier JSON pour générer le fichier d'autorité de certification, par exemple, `ca-config.json`: { "signing": { "default": { "expiry": "8760h" }, "profiles": { "kubernetes": { "usages": [\ "signing",\ "key encipherment",\ "server auth",\ "client auth"\ ], "expiry": "8760h" } } } } 4. Créez un fichier JSON pour la demande de signature de certificat de l'autorité de certification, par exemple, `ca-csr.json`. Assurez-vous de remplacer les valeurs marquées par des "< >" par les vraies valeurs que vous voulez utiliser. { "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "names":[{\ "C": "",\ "ST": "",\ "L": "",\ "O": "",\ "OU": ""\ }] } 5. Générez la clé de CA (`ca-key.pem`) et le certificat (`ca.pem`): ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca 6. Créer un fichier JSON pour générer des clés et des certificats pour l'API Server, par exemple, `server-csr.json`. Assurez-vous de remplacer les valeurs entre "< >" par les vraies valeurs que vous voulez utiliser. `MASTER_CLUSTER_IP` est le service Cluster IP de l'API Server, comme décrit dans la sous-section précédente. L’exemple ci-dessous suppose également que vous utilisez `cluster.local` par défaut comme nom de domaine DNS. { "CN": "kubernetes", "hosts": [\ "127.0.0.1",\ "",\ "",\ "kubernetes",\ "kubernetes.default",\ "kubernetes.default.svc",\ "kubernetes.default.svc.cluster",\ "kubernetes.default.svc.cluster.local"\ ], "key": { "algo": "rsa", "size": 2048 }, "names": [{\ "C": "",\ "ST": "",\ "L": "",\ "O": "",\ "OU": ""\ }] } 7. Générez la clé et le certificat pour l'API Server, qui sont par défaut sauvegardés respectivement dans les fichiers `server-key.pem` et `server.pem`: ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ --config=ca-config.json -profile=kubernetes \ server-csr.json | ../cfssljson -bare server Distribuer un certificat auto-signé ----------------------------------- Un client peut refuser de reconnaître un certificat auto-signé comme valide. Pour un déploiement hors production ou pour un déploiement exécuté derrière un pare-feu d'entreprise, vous pouvez distribuer un certificat auto-signé à tous les clients et actualiser la liste locale pour les certificats valides. Sur chaque client, effectuez les opérations suivantes: $ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt $ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d.... done. API pour les certificats ------------------------ Vous pouvez utiliser l’API `certificates.k8s.io` pour faire créer des Certificats x509 à utiliser pour l'authentification, comme documenté [ici](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster) . 3 - Architecture de Journalisation d'évènements (logging) ========================================================= La journalisation des évènements systèmes et d'applications peut aider à comprendre ce qui se passe dans un cluster. Les journaux sont particulièrement utiles pour débogguer les problèmes et surveiller l'activité du cluster. La plupart des applications modernes ont un mécanisme de journalisation d'évènements, et la plupart des environnements d'exécution de conteneurs ont été conçus pour supporter la journalisation des évènements. La méthode de journalisation la plus facile et la plus répandue pour des applications conteneurisées est d'écrire dans les flux de sortie standard et d'erreur (`stdout` et `stderr`). Malgré cela, la fonctionnalité de journalisation fournie nativement par l'environnement d'exécution de conteneurs n'est pas suffisante comme solution complète de journalisation. Quand un conteneur crashe, quand un Pod est expulsé ou quand un nœud disparaît, il est utile de pouvoir accéder au journal d'événements de l'application. C'est pourquoi les journaux doivent avoir leur propre espace de stockage et un cycle de vie indépendamment des nœuds, Pods ou conteneurs. Ce concept est appelé _journalisation des évènements au niveau du cluster_ (cluster-level-logging). Un backend dédié pour stocker, analyser et faire des requêtes est alors nécessaire. Kubernetes n'offre pas nativement de solution de stockage pour les journaux mais il est possible d'intégrer de nombreuses solutions de journalisation d'évènements dans un cluster Kubernetes. L'architecture de journalisation des évènements au niveau du cluster est décrite en considérant qu'un backend de journalisation est présent à l'intérieur ou à l'extérieur du cluster. Même sans avoir l'intention de journaliser les évènements au niveau du cluster, il est intéressant de savoir comment les journaux sont conservés et gérés au niveau d'un nœud. Journalisation simple d'évènements dans Kubernetes -------------------------------------------------- Dans cette section, on va utiliser un exemple simple de journalisation d'évènements avec le flux de sortie standard. Cette démonstration utilise un manifeste pour un Pod avec un seul conteneur qui écrit du texte sur le flux de sortie standard toutes les secondes. [`debug/counter-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/fr/examples/debug/counter-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy debug/counter-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: [/bin/sh, -c,\ 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'] Pour lancer ce Pod, utilisez la commande suivante : kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml Le résultat est : pod/counter created Pour récupérer les événements du conteneur d'un pod, utilisez la commande `kubectl logs` de la manière suivante : kubectl logs counter Le résultat est : 0: Mon Jan 1 00:00:00 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001 ... Utilisez `kubectl logs` pour récupérer les évènements de l'instanciation précédente d'un Pod en utilisant l'option `--previous` quand par exemple le conteneur a crashé. Si le Pod a plusieurs conteneurs, il faut spécifier le nom du conteneur dont on veut récupérer le journal d'évènement. Dans notre exemple le conteneur s'appelle `count` donc vous pouvez utiliser `kubectl logs counter count`. Plus de détails dans la \[documentation de `kubectl logs`\] (/docs/reference/generated/kubectl/kubectl-commands#logs) Journalisation d'évènements au niveau du nœud --------------------------------------------- ![Journalisation d'évènements au niveau du\nnœud](https://kubernetes.io/images/docs/user-guide/logging/logging-node-level.png) Tout ce qu'une application conteneurisée écrit sur `stdout` ou `stderr` est pris en compte et redirigé par l'environnement d'exécution des conteneurs. Par exemple, Docker redirige ces deux flux vers un [driver de journalisation (EN)](https://docs.docker.com/config/containers/logging/configure/) qui est configuré dans Kubernetes pour écrire dans un fichier au format json. #### Note: Le driver json de Docker traite chaque ligne comme un message différent. Avec ce driver il n'y a pas de support direct pour des messages multi-lignes. Il faut donc traiter les messages multi-lignes au niveau de l'agent de journalisation ou plus en amont encore. Par défaut quand un conteneur redémarre, le kubelet ne conserve le journal que du dernier conteneur terminé. Quand un Pod est expulsé d'un nœud, tous ses conteneurs sont aussi expulsés avec leurs journaux d'évènements. Quand on utilise la journalisation d'évènements au niveau du nœud, il faut prendre garde à mettre en place une politique de rotation des journaux adéquate afin qu'ils n'utilisent pas tout l'espace de stockage du nœud. Kubernetes n'a pas en charge la rotation des journaux, c'est à l'outil de déploiement de le prendre en compte. Par exemple, dans les clusters Kubernetes déployés avec le script `kube-up.sh` [`logrotate`](https://linux.die.net/man/8/logrotate) est configuré pour s'exécuter toutes les heures. Il est aussi possible de configurer l'environnement d'exécution des conteneurs pour que la rotation des journaux s'exécute automatiquement, e.g. en utilisant le paramètre `log-opt` de Docker. Dans le script `kube-up.sh`, c'est cette méthode qui est utilisée pour des images COS sur GCP et sinon c'est la première méthode dans tous les autres cas. Quelle que soit la méthode choisie par `kube-up.sh` la rotation est configurée par défaut quand la taille d'un journal atteint 10 Mo. Ce [script](https://github.com/kubernetes/kubernetes/blob/main/cluster/gce/gci/configure-helper.sh) montre de manière détaillée comment `kube-up.sh` met en place la journalisation d'évènements pour des images COS sur GCP. Quand [`kubectl logs`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs) s'exécute comme dans le premier exemple de journalisation simple le kubelet du nœud gère la requête et lit directement depuis le fichier de journal et retourne son contenu dans la réponse. #### Note: Si un système externe a effectué la rotation des journaux, seul le contenu du dernier fichier journal sera disponible avec `kubectl logs`. Par exemple quand le journal atteint 10 Mo, `logrotate` effectue une rotation, il y a alors 2 fichers, un de 10 Mo et un de vide, à ce moment là `kubectl logs` retournera une réponse vide. ### Journalisation des évènements des composants système Il y a deux types de composants système selon qu'ils s'exécutent dans un conteneur ou pas. Par exemple : * Le scheduler Kubernetes et kube-proxy s'exécutent dans un conteneur. * Kubelet et l'environnement d'exécution de conteneurs, comme par exemple Docker, ne s'exécutent pas dans un conteneur. Sur les systèmes avec systemd, kubelet et l'environnement d'exécution de conteneurs écrivent dans journald. Si systemd n'est pas présent, ils écrivent dans un fichier `.log` dans le répertoire `/var/log`. Les composants système qui s'exécutent dans un conteneur écrivent toujours dans le répertoire `/var/log`, en contournant le mécanisme de journalisation par défaut. Ils utilisent la bibliothèque de journalisation [klog](https://github.com/kubernetes/klog) . Les conventions pour la sévérité des évènements pour ces composants se trouvent dans cette \[documentation sur les conventions de journalisation des évènements dans kubernetes\] ([https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)) . De la même manière que les journaux des conteneurs, les journaux des composants systèmes doivent avoir une politique de rotation. Dans un cluster créé avec le script `kube-up.sh`, les journaux ont une rotation journalière ou quand leur taille atteint 100 Mo. Architecture de journalisation des évènements au niveau du cluster ------------------------------------------------------------------ Kubernetes ne fournit pas de solution native pour la journalisation des évènements au niveau du cluster. Mais il y a différentes approches qui peuvent être considérées : * Utiliser un agent de journalisation au niveau du nœud sur chacun des nœuds. * Inclure un conteneur side-car pour journaliser les évènements du Pod applicatif. * Envoyer les évènements directement a un backend depuis l'application. ### Utiliser un agent de journalisation au niveau du nœud ![Utiliser un agent de journalisation au niveau du\nnœud](https://kubernetes.io/images/docs/user-guide/logging/logging-with-node-agent.png) Vous pouvez implémenter une journalisation au niveau du cluster en incluant un _agent de journalisation au niveau du nœud_ sur chacun des nœuds. L'agent de journalisation est un outil dédié qui met à disposition ou envoie les journaux à un backend. Communément l'agent de journalisation est un conteneur qui a accès au répertoire qui contient les journaux des conteneurs applicatifs sur ce nœud. Comme l'agent de journalisation doit s'exécuter sur chacun des nœuds, on utilise soit un DaemonSet, soit un manifeste de Pod, soit un processus dédié natif sur le nœud. Ces deux dernières options sont obsolètes et fortement découragées. Utiliser un agent de journalisation au niveau du nœud est l'approche la plus commune et recommandée pour un cluster Kubernetes parce qu'un seul agent par nœud est créé et qu'aucune modification dans l'application n'est nécessaire. Mais cette approche _ne fonctionne correctement que pour les flux standards de sortie et d'erreurs des applications_. Kubernetes ne définit pas d'agent de journalisation, mais deux agents de journalisation optionnels sont fournis avec la version de Kubernetes : [Stackdriver (EN)](https://kubernetes.io/docs/user-guide/logging/stackdriver) pour utiliser sur Google Cloud Platform, et [Elasticsearch (EN)](https://kubernetes.io/docs/user-guide/logging/elasticsearch) . Les deux utilisent [fluentd](http://www.fluentd.org/) avec une configuration spécifique comme agent sur le nœud. Les liens précédents fournissent plus d'informations et les instructions pour les utiliser et configurer. ### Inclure un conteneur side-car pour journaliser les évènements du Pod applicatif Vous pouvez utiliser un conteneur side-car d'une des manières suivantes : * Le conteneur side-car diffuse les journaux de l'application sur son propre `stdout`. * Le conteneur side-car exécute un agent de journalisation qui est configuré pour récupérer les journaux du conteneur applicatif. #### Conteneur side-car diffusant (Streaming sidecar container) ![Conteneur side-car\ndiffusant](https://kubernetes.io/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) Comme le conteneur side-car diffuse les journaux sur ses propres flux `stdout` et `stderr`, on peut bénéficier du kubelet et de l'agent de journalisation qui s'exécute déjà sur chaque nœud. Les conteneurs side-car lisent les journaux depuis un fichier, un socket ou bien journald. Chaque conteneur side-car écrit son journal sur son propre flux `stdout` ou `stderr`. Cette méthode permet de séparer les flux de journaux de différentes parties de votre application même si elles ne supportent pas d'écrire sur `stdout` ou `stderr`. La logique de rediriger les journaux est minime et le surcoût est non significatif. De plus comme les flux standards `stdout` et `stderr` sont gérés par kubelet, les outils natifs comme `kubectl logs` peuvent être utilisés. Regardez l'exemple qui suit. Un Pod exécute un unique conteneur et ce conteneur écrit dans deux fichiers de journaux différents en utilisant deux format différents. Voici le manifeste du Pod : [`admin/logging/two-files-counter-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/fr/examples/admin/logging/two-files-counter-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy admin/logging/two-files-counter-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {} Il serait très désordonné d'avoir des évènements avec des formats différents dans le même journal en redirigeant les évènements dans le flux de sortie `stdout` d'un seul conteneur. Il est plutôt souhaitable d'utiliser deux conteneurs side-car, un pour chaque type de journaux. Chaque conteneur side-car suit un des fichiers et renvoie les évènements sur son propre `stdout`. Ci-dessous se trouve le manifeste pour un Pod avec deux conteneurs side-car. [`admin/logging/two-files-counter-pod-streaming-sidecar.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/fr/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy admin/logging/two-files-counter-pod-streaming-sidecar.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-log-1 image: busybox args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] volumeMounts: - name: varlog mountPath: /var/log - name: count-log-2 image: busybox args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log'] volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {} Quand ce Pod s'exécute, chaque journal peut être diffusé séparément en utilisant les commandes suivantes : kubectl logs counter count-log-1 0: Mon Jan 1 00:00:00 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001 ... kubectl logs counter count-log-2 Mon Jan 1 00:00:00 UTC 2001 INFO 0 Mon Jan 1 00:00:01 UTC 2001 INFO 1 Mon Jan 1 00:00:02 UTC 2001 INFO 2 ... L'agent au niveau du nœud installé dans le cluster récupère les deux flux de journaux sans aucune configuration supplémentaire. Il est possible de configurer l'agent pour qu'il analyse syntaxiquement les évènements en fonction du conteneur source. Notez que bien que la consommation en CPU et mémoire soit faible ( de l'ordre de quelques milicores pour la CPU et quelques mégaoctets pour la mémoire), ecrire les évènements dans un fichier et les envoyer ensuite dans `stdout` peut doubler l'espace disque utilisé. Quand une application écrit dans un seul fichier de journal, il est préférable de configurer `/dev/stdout` comme destination plutôt que d'implémenter un conteneur side-car diffusant. Les conteneurs side-car peuvent être utilisés pour faire la rotation des journaux quand l'application n'en est pas capable elle-même. Un exemple serait un petit conteneur side-car qui effectuerait cette rotation périodiquement. Toutefois, il est recommandé d'utiliser `stdout` et `stderr` directement et de laisser la rotation et les politiques de rétentions au kubelet. ### Conteneur side-car avec un agent de journalisation ![Conteneur side-car avec un agent de\njournalisation](https://kubernetes.io/images/docs/user-guide/logging/logging-with-sidecar-agent.png) Quand un agent de journalisation au niveau du nœud n'est pas assez flexible pour votre utilisation, vous pouvez créer un conteneur side-car avec un agent de journalisation séparé que vous avez configuré spécialement pour qu'il s'exécute avec votre application. #### Note: Utiliser un agent de journalisation dans un conteneur side-car peut entraîner une consommation de ressources significative. De plus vous n'avez plus accès aux journaux avec la commande `kubectl` parce qu'ils ne sont plus gérés par kubelet. Comme exemple, vous pouvez utiliser [Stackdriver](https://kubernetes.io/docs/tasks/debug-application-cluster/logging-stackdriver/) où fluentd est l'agent de journalisation. Ci-dessous se trouvent deux configurations qui implémentent cette méthode. Le premier fichier contient un [ConfigMap](https://kubernetes.io/fr/docs/tasks/configure-pod-container/configure-pod-configmap/) pour configurer fluentd. [`admin/logging/fluentd-sidecar-config.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/fr/examples/admin/logging/fluentd-sidecar-config.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy admin/logging/fluentd-sidecar-config.yaml to clipboard") apiVersion: v1 kind: ConfigMap metadata: name: fluentd-config data: fluentd.conf: | type tail format none path /var/log/1.log pos_file /var/log/1.log.pos tag count.format1 type tail format none path /var/log/2.log pos_file /var/log/2.log.pos tag count.format2 type google_cloud #### Note: La configuration de fluentd est hors du cadre de cet article. Vous trouverez des informations pour configurer fluentd dans la [documentation officielle de fluentd](http://docs.fluentd.org/) . Le second fichier est un manifeste pour un Pod avec un conteneur side-car qui exécute fluentd. Le Pod monte un volume où fluentd peut récupérer sa configuration. [`admin/logging/two-files-counter-pod-agent-sidecar.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/fr/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy admin/logging/two-files-counter-pod-agent-sidecar.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-agent image: registry.k8s.io/fluentd-gcp:1.30 env: - name: FLUENTD_ARGS value: -c /etc/fluentd-config/fluentd.conf volumeMounts: - name: varlog mountPath: /var/log - name: config-volume mountPath: /etc/fluentd-config volumes: - name: varlog emptyDir: {} - name: config-volume configMap: name: fluentd-config Apres quelques minutes, les évènements apparaîtront dans l'interface de Stackdriver. Ce n'est qu'un exemple et vous pouvez remplacer fluentd par n'importe quel agent de journalisation qui lit depuis n'importe quelle source de votre application. ### Envoyer les évènements directement depuis l'application. ![Envoyer les évènements directement a un backend depuis\nl'application.](https://kubernetes.io/images/docs/user-guide/logging/logging-from-application.png) Vous pouvez implémenter la journalisation au niveau cluster en mettant à disposition ou en envoyant les journaux directement depuis chaque application; Toutefois l'implémentation de ce mécanisme de journalisation est hors du cadre de Kubernetes. --- # Настройка | Kubernetes Это многостраничный печатный вид этого раздела. [Нажмите что бы печатать](https://kubernetes.io/ru/docs/setup/_print/#) . [Вернуться к обычному просмотру страницы](https://kubernetes.io/ru/docs/setup/) . Настройка ========= * 1: [Среда обучения](https://kubernetes.io/ru/docs/setup/_print/#pg-0b597086a9d1382f86abadcfeab657d6) * 1.1: [Установка Kubernetes с помощью Minikube](https://kubernetes.io/ru/docs/setup/_print/#pg-8b996bf57bd8e67340235da1a1fb8e95) * 1.2: [Установка Kubernetes с помощью Kind](https://kubernetes.io/ru/docs/setup/_print/#pg-861dedab439fb9a133b35009a34655ec) * 2: [Пользовательские облачные решения](https://kubernetes.io/ru/docs/setup/_print/#pg-89cb5486440b5e96f31dbb3956f2ad9e) Используйте информацию на этой странице, чтобы найти наиболее подходящее для вас решение по установке и настройке. Решение о том, как запускать Kubernetes, зависит от доступных ресурсов и необходимого уровня гибкости использования. Запуск Kubernetes возможен практически на чём угодно, от вашего ноутбука или виртуальных машины у облачного провайдера и до физических серверов. Решения позволяют как настроить полностью управляемый кластер запуском единственной команды так и создать пользовательский кластер на физических серверах. Решения для запуска на локальной машине --------------------------------------- Запуск на локальной машине позволяет легко начать работу с Kubernetes. Можно создавать и тестировать кластер Kubernetes не беспокоясь о трате облачных ресурсов и квотах. Вам следует выбрать запуск на локальной машине, если вы: * Пробуете или начинаете работу с Kubernetes * Локально разрабатываете и тестируете кластер Выбрать [решение для запуска на локальной машине](https://kubernetes.io/ru/docs/setup/learning-environment/) . Управляемые решения ------------------- Управляемые решения позволяют надёжно и удобно создавать и поддерживать кластеры Kubernetes. Они настраивают и управляют кластером самостоятельно, не требуя ручного вмешательства. Вам следует выбрать управляемое решение, если вы: * Хотите получить полностью самоуправляемое решение * Хотите сконцентрироваться на разработке собственных приложений или сервисов * Хотите получить высокую доступность, но у вас нет выделенной команды по обеспечению надёжности приложения (SRE). * Не имеете ресурсов для размещения и мониторинга собственных кластеров Выбрать [управляемое решение](https://kubernetes.io/docs/setup/pick-right-solution/#hosted-solutions) . Облачные решения "под ключ" --------------------------- Такие решения позволяют создавать кластеры Kubernetes с помощью небольшого количества команд. Эти решения имеют большую поддержку сообществом и активно развиваются. Они могут быть размещены на разнообразных IaaS облачных провайдерах, при этом предлагая большую свободу и гибкость в обмен на приложенные усилия. Вам следует выбрать облачное решение "под ключ", если вы: * Хотите получить больший контроль над кластерами, чем позволяют размещённые решения * Хотите получить больше контроля над операциями Выбрать [облачное решение "под ключ"](https://kubernetes.io/docs/setup/pick-right-solution/#turnkey-cloud-solutions) Местное резервное решение "под ключ" ------------------------------------ Такие решения позволяют с помощью небольшого количества команд создавать кластеры Kubernetes в ваших внутренних, защищённых облачных сетях. Вам следует выбрать местное резервное решение "под ключ", если: * Вы хотите развернуть кластер в приватной облачной сети * У вас есть выделенная команда SRE-специалистов * У вас есть ресурсы для размещения и мониторинга собственных кластеров Выбрать [местное резервное решение "под ключ"](https://kubernetes.io/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions) . Пользовательские решения ------------------------ Пользовательские решения позволяют достичь наибольшей свободы в управлении кластерами, но при этом требуют наибольшей экспертизы. Можно найти такие решения как для размещения на физических серверах, так и у облачных провайдеров на разных операционных системах. Выбрать [пользовательское решение](https://kubernetes.io/docs/setup/pick-right-solution/#custom-solutions) . Что дальше ---------- Перейти к [выбору подходящего решения](https://kubernetes.io/docs/setup/pick-right-solution/) , чтобы ознакомить с полным списком доступных решений. 1 - Среда обучения ================== 1.1 - Установка Kubernetes с помощью Minikube ============================================= Minikube — это инструмент, позволяющий легко запускать Kubernetes на локальной машине. Для тех, кто хочет попробовать Kubernetes или рассмотреть возможность его использования в повседневной разработке, Minikube станет отличным вариантом, потому что он запускает одноузловой кластер Kubernetes внутри виртуальной машины (VM) на компьютере пользователя. Возможности Minikube -------------------- Minikube поддерживает следующие возможности Kubernetes: * DNS * Сервисы NodePort * Словари конфигурации (ConfigMaps) и секреты (Secrets) * Панель управления (Dashboard) * Среда выполнения контейнера: Docker, [CRI-O](https://cri-o.io/) и [containerd](https://github.com/containerd/containerd) * Поддержка CNI (Container Network Interface) * Ingress Установка --------- Посмотрите страницу [Установка Minikube](https://kubernetes.io/ru/docs/tasks/tools/install-minikube/) . Краткое руководство ------------------- Эта простая демонстрация поможет запустить, использовать и удалить Minikube на локальной машине. Следуйте перечисленным ниже шагам, чтобы начать знакомство с Minikube. 1. Запустите Minikube и создайте кластер: minikube start Вывод будет примерно следующим: Starting local Kubernetes cluster... Running pre-create checks... Creating machine... Starting local Kubernetes cluster... Дополнительную информацию о запуске кластера в определенной версии Kubernetes, виртуальной машине или среде выполнения контейнера смотрите в разделе [Запуск кластера](https://kubernetes.io/ru/docs/setup/_print/#%D0%B7%D0%B0%D0%BF%D1%83%D1%81%D0%BA-%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%B0) . 2. Теперь вы можете работать со своим кластером через CLI-инструмент kubectl. Для получения дополнительной информации смотрите раздел [Работа с кластером](https://kubernetes.io/ru/docs/setup/_print/#%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0-%D1%81-%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%BE%D0%BC) . Давайте создадим развёртывание (Deployment) в Kubernetes, используя существующий образ `echoserver`, представляющий простой HTTP-сервер, и сделаем его доступным на порту 8080 с помощью `--port`. kubectl create deployment hello-minikube --image=registry.k8s.io/echoserver:1.10 Вывод будет примерно следующим: deployment.apps/hello-minikube created 3. Чтобы получить доступ к объекту Deployment `hello-minikube` извне, создайте объект сервиса (Service): kubectl expose deployment hello-minikube --type=NodePort --port=8080 Опция `--type=NodePort` определяет тип сервиса. Вывод будет примерно следующим: service/hello-minikube exposed 4. Под (Pod) `hello-minikube` теперь запущен, но нужно подождать, пока он начнёт функционировать, прежде чем обращаться к нему. Проверьте, что под работает: kubectl get pod Если в столбце вывода `STATUS` выводится `ContainerCreating`, значит под все еще создается: NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s Если в столбце `STATUS` указано `Running`, то под теперь в рабочем состоянии: NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 1/1 Running 0 13s 5. Узнайте URL-адрес открытого (exposed) сервиса, чтобы просмотреть подробные сведения о сервисе: minikube service hello-minikube --url 6. Чтобы ознакомиться с подробной информацией о локальном кластере, скопируйте и откройте полученный из вывода команды на предыдущем шаге URL-адрес в браузере. Вывод будет примерно следующим: Hostname: hello-minikube-7c77b68cff-8wdzq Pod Information: -no pod information available- Server values: server_version=nginx: 1.13.3 - lua: 10008 Request Information: client_address=172.17.0.1 method=GET real path=/ query= request_version=1.1 request_scheme=http request_uri=http://192.168.99.100:8080/ Request Headers: accept=*/* host=192.168.99.100:30674 user-agent=curl/7.47.0 Request Body: -no body in request- Если сервис и кластер вам больше не нужны, их можно удалить. 7. Удалите сервис `hello-minikube`: kubectl delete services hello-minikube Вывод будет примерно следующим: service "hello-minikube" deleted 8. Удалите развёртывание `hello-minikube`: kubectl delete deployment hello-minikube Вывод будет примерно следующим: deployment.extensions "hello-minikube" deleted 9. Остановите локальный кластер Minikube: minikube stop Вывод будет примерно следующим: Stopping "minikube"... "minikube" stopped. Подробности смотрите в разделе [Остановка кластера](https://kubernetes.io/ru/docs/setup/_print/#%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0-%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%B0) . 10. Удалите локальный кластер Minikube: minikube delete Вывод будет примерно следующим: Deleting "minikube" ... The "minikube" cluster has been deleted. Подробности смотрите в разделе [Удаление кластера](https://kubernetes.io/ru/docs/setup/_print/#%D1%83%D0%B4%D0%B0%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80%D0%B0) . Управление кластером -------------------- ### Запуск кластера Команда `minikube start` используется для запуска кластера. Эта команда создаёт и конфигурирует виртуальную машину, которая запускает одноузловой кластер Kubernetes. Эта команда также настраивает вашу установку [kubectl](https://kubernetes.io/docs/user-guide/kubectl-overview/) для взаимодействия с этим кластером. #### Примечание: Если вы работаете из-под веб-прокси, вам нужно указать данные прокси в команде `minikube start`: https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 К сожалению, установка переменных окружения не cработает. Minikube также создает контекст "minikube" и устанавливает его по умолчанию в kubectl. Чтобы вернуться к этому контексту, выполните следующую команду: `kubectl config use-context minikube`. #### Указание версии Kubernetes Вы можете указать используемую версию Kubernetes в Minikube, добавив параметр `--kubernetes-version` в команду `minikube start`. Например, чтобы запустить Minikube из-под версии 1.35.0, вам нужно выполнить следующую команду: minikube start --kubernetes-version 1.35.0 #### Указание драйвера виртуальной машины Вы можете изменить драйвер виртуальной машины, добавив флаг `--vm-driver=` в команду `minikube start`. Тогда команда будет выглядеть так: minikube start --vm-driver= Minikube поддерживает следующие драйверы: #### Примечание: Смотрите страницу [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) для получения подробной информации о поддерживаемых драйверах и как устанавливать плагины. * virtualbox * vmwarefusion * docker (ЭКСПЕРИМЕНТАЛЬНЫЙ) * kvm2 ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/) ) * hyperkit ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/) ) * hyperv ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/) ) Обратите внимание, что указанный IP-адрес на этой странице является динамическим и может изменяться. Его можно получить с помощью `minikube ip`. * vmware ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/) ) (VMware unified driver) * parallels ([установка драйвера](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/) ) * none (Запускает компоненты Kubernetes на хосте, а не на виртуальной машине. Использование этого драйвера требует использование Linux и установленного [Docker](https://docs.docker.com/engine/ "Docker — это программное обеспечение, реализующее виртуализацию на уровне операционной системы, которая известна как контейнеризация.") .) #### Внимание: Если вы используете драйвер `none`, некоторые компоненты Kubernetes запускаются как привилегированные контейнеры, которые имеют побочные эффекты вне окружения Minikube. Эти побочные эффекты означают, что драйвер `none` не рекомендуется использовать в личных рабочих станций. #### Запуск кластера в других средах выполнения контейнеров Вы можете запустить Minikube в следующих средах выполнения контейнеров. * [containerd](https://kubernetes.io/ru/docs/setup/_print/#container-runtimes-0) * [CRI-O](https://kubernetes.io/ru/docs/setup/_print/#container-runtimes-1) Чтобы использовать [containerd](https://github.com/containerd/containerd) в качестве среды выполнения контейнера, выполните команду ниже: minikube start \ --network-plugin=cni \ --enable-default-cni \ --container-runtime=containerd \ --bootstrapper=kubeadm Также можете использовать расширенную вариант команды: minikube start \ --network-plugin=cni \ --enable-default-cni \ --extra-config=kubelet.container-runtime=remote \ --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \ --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ --bootstrapper=kubeadm Чтобы использовать [CRI-O](https://cri-o.io/) в качестве среды выполнения контейнера, выполните команду ниже: minikube start \ --network-plugin=cni \ --enable-default-cni \ --container-runtime=cri-o \ --bootstrapper=kubeadm Также можете использовать расширенную вариант команды: minikube start \ --network-plugin=cni \ --enable-default-cni \ --extra-config=kubelet.container-runtime=remote \ --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \ --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ --bootstrapper=kubeadm #### Использование локальных образов путём повторного использования демона Docker При использовании одной виртуальной машины для Kubernetes легко повторно использовать демон Docker, встроенный в Minikube. В этом случае нет необходимости создавать реестр Docker на вашей хост-машине и отправлять образ туда. Вместо этого вы можете создать реестр внутри того же демона Docker, который использует Minikube, что позволит ускорить локальные запуски. #### Примечание: Обязательно пометьте собственным тегом Docker-образ, и затем при получении образа всегда указывайте его. Так как `:latest` — это тег по умолчанию, поэтому наряду с соответствующей стандартной политикой получения образа, равной `Always`, в конечном итоге возникнет ошибка при получении образа (`ErrImagePull`), если Docker-образ не найден в базовом реестре Docker (как правило, в DockerHub). Для работы с Docker-демоном на вашем хосте под управлением Mac/Linux, запустите последнюю строку из вывода команды `minikube docker-env`. Теперь вы можете использовать Docker в командной строке вашего хост-компьютера на Mac/Linux для взаимодействия с демоном Docker внутри виртуальной машины Minikube: docker ps #### Примечание: На Centos 7 Docker может возникнуть следующая ошибка: Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory Для исправления этой ошибки обновите файл `/etc/sysconfig/docker`, чтобы учитывались изменения в среде Minikube: < DOCKER_CERT_PATH=/etc/docker --- > if [ -z "${DOCKER_CERT_PATH}" ]; then > DOCKER_CERT_PATH=/etc/docker > fi ### Конфигурация Kubernetes Minikube имеет такую возможность как "конфигуратор" ("configurator"), позволяющая пользователям настраивать компоненты Kubernetes произвольными значениями. Чтобы использовать эту возможность, используйте флаг `--extra-config` в команде `minikube start`. Этот флаг можно дублировать, поэтому вы можете указать его несколько раз с несколькими разными значениями, чтобы установить несколько опций. Этот флаг принимает строку вида `component.key=value`, где `component` — это одно из значение в приведённом ниже списка, `key` — ключ из структуры конфигурации, а `value` — значение, которое нужно установить. Допустимые ключи можно найти в документации по `componentconfigs` в Kubernetes каждого компонента. Ниже вы найдете документации по каждой поддерживаемой конфигурации: * [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration) * [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions) * [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration) * [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration) * [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig) * [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration) #### Примеры Чтобы изменить настройку `MaxPods` на значение 5 в Kubelet, передайте этот флаг `--extra-config=kubelet.MaxPods=5`. Эта возможность также поддерживает вложенные структуры. Для изменения настройки `LeaderElection.LeaderElect` на значение `true` в планировщике, передайте флаг `--extra-config=scheduler.LeaderElection.LeaderElect=true`. Чтобы изменить настройку `AuthorizationMode` в `apiserver` на значение `RBAC`, используйте флаг `--extra-config=apiserver.authorization-mode=RBAC`. ### Остановка кластера Команда `minikube stop` используется для остановки кластера. Эта команда выключает виртуальную машины Minikube, но сохраняет всё состояние кластера и данные. Повторный запуск кластера вернет его в прежнее состояние. ### Удаление кластера Команда `minikube delete` используется для удаления кластера. Эта команда выключает и удаляет виртуальную машину Minikube. Данные или состояние не сохраняются. ### Обновление minikube Смотрите [инструкцию по обновлению minikube](https://minikube.sigs.k8s.io/docs/start/macos/) . Работа с кластером ------------------ ### Kubectl Команда `minikube start` создает [контекст kubectl](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) под именем "minikube". Этот контекст содержит конфигурацию для взаимодействия с кластером Minikube. Minikube автоматически устанавливает этот контекст, но если вам потребуется явно использовать его в будущем, выполните команду ниже: kubectl config use-context minikube Либо передайте контекст при выполнении команды следующим образом: `kubectl get pods --context=minikube`. ### Панель управления Чтобы получить доступ к [веб-панели управления Kubernetes](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) , запустите эту команду в командной оболочке после запуска Minikube, чтобы получить адрес: minikube dashboard ### Сервисы Чтобы получить доступ к сервису, открытой через порт узла, выполните команду в командной оболочке после запуска Minikube, чтобы получить адрес: minikube service [-n NAMESPACE] [--url] NAME Организация сети ---------------- Виртуальная машина Minikube доступна только хост-системе через IP-адрес, который можно получить с помощью команды `minikube ip`. Вы можете использовать IP-адрес для доступа к любому сервису типа `NodePort`. Чтобы определить NodePort для вашего сервиса, вы можете использовать такую команду `kubectl`: kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"' Постоянные тома --------------- Minikube поддерживает [PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) типа `hostPath`. Эти постоянные тома монтируются в виртуальную машину Minikube. Виртуальная машина Minikube загружается в файловую систему tmpfs, поэтому большинство директорий не будет сохранено при перезагрузках (`minikube stop`). Однако Minikube сконфигурирован на сохранение файлов, хранящихся в перечисленных ниже директорий хоста. * `/data` * `/var/lib/minikube` * `/var/lib/docker` Пример конфигурации PersistentVolume для сохранения данных в директории `/data`: apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 spec: accessModes: - ReadWriteOnce capacity: storage: 5Gi hostPath: path: /data/pv0001/ Смонтированные директории хоста ------------------------------- Некоторые драйверы монтируют директорию хоста в виртуальную машину, чтобы можно было легко обмениваться файлами между виртуальной машиной и хостом. В настоящее время это не настраивается и отличается от используемого драйвера и ОС. #### Примечание: Совместное использование директории хоста еще не реализовано в драйвере KVM. | Driver | OS | HostFolder | VM | | --- | --- | --- | --- | | VirtualBox | Linux | /home | /hosthome | | VirtualBox | macOS | /Users | /Users | | VirtualBox | Windows | C://Users | /c/Users | | VMware Fusion | macOS | /Users | /mnt/hgfs/Users | | Xhyve | macOS | /Users | /Users | Приватные реестры контейнеров ----------------------------- Для доступа к реестру приватных контейнеров, выполните шаги, описанные на [этой странице](https://kubernetes.io/ru/docs/concepts/containers/images/) . Мы рекомендуем использовать `ImagePullSecrets`, но если вам нужно обратиться к нему из виртуальной машины Minikube, нужно поместить файл `.dockercfg` в директорию `/home/docker` или `config.json` в директорию `/home/docker/.docker`. Дополнения ---------- Для того, чтобы Minikube смог запустить или перезапустить пользовательские дополнения, поместите дополнения, которые вы хотите запускать с помощью Minikube, в директорию `~/.minikube/addons`. Дополнения в этой директории будут перемещены в виртуальную машину Minikube и запускаться каждый раз при запуске или перезапуске Minikube. Использование Minikube с помощью HTTP-прокси -------------------------------------------- Minikube создаёт виртуальную машину, включающая в себя Kubernetes и демон Docker. Когда Kubernetes планирует выполнение контейнеров с использованием Docker, демону Docker может потребоваться доступ к внешней сети для получения контейнеров. Если вы работаете через HTTP-прокси, вам нужно сконфигурировать настройки прокси для Docker. Для этого нужно передать необходимые переменные окружения в флаги перед выполнением команды `minikube start`. Например: minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ --docker-env https_proxy=https://$YOURPROXY:PORT Если адрес вашей виртуальной машины 192.168.99.100, то, скорее всего, настройки прокси помешают `kubectl` обратиться к ней. Чтобы прокси игнорировал этот IP-адрес, нужно скорректировать настройки no\_proxy следующим образом: export no_proxy=$no_proxy,$(minikube ip) Известные проблемы ------------------ Функциональность, для которой требуется несколько узлов, не будет работать в Minikube. Реализация ---------- Minikube использует [libmachine](https://github.com/docker/machine/tree/master/libmachine) для подготовки виртуальных машин и [kubeadm](https://github.com/kubernetes/kubeadm) для инициализации кластера Kubernetes. Для получения дополнительной информации о Minikube посмотрите [статью](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md) . Дополнительные ссылки --------------------- * **Цели**: цели проекта Minikube смотрите в [дорожной карте](https://git.k8s.io/minikube/docs/contributors/roadmap.md) . * **Руководство по разработке**: посмотрите [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) , чтобы ознакомиться с тем, как отправлять пулрексты. * **Сборка Minikube**: инструкции по сборке/тестированию Minikube из исходного кода смотрите в [руководстве по сборке](https://git.k8s.io/minikube/docs/contributors/build_guide.md) . * **Добавление новой зависимости**: инструкции по добавлению новой зависимости в Minikube смотрите в [руководстве по добавлению зависимостей](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md) . * **Добавление нового дополнения**: инструкции по добавлению нового дополнения для Minikube смотрите в [руководстве по добавлению дополнений](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md) . * **MicroK8**: пользователи Linux, которые не хотят использовать виртуальную машину, могут в качестве альтернативы посмотреть в сторону [MicroK8s](https://microk8s.io/) . Сообщество ---------- Помощь, вопросы и комментарии приветствуются и поощряются! Разработчики Minikube проводят время на [Slack](https://kubernetes.slack.com/) в канале #minikube (получить приглашение можно [здесь](http://slack.kubernetes.io/) ). У нас также есть [список рассылки dev@kubernetes на Google Groups](https://groups.google.com/a/kubernetes.io/g/dev/) . Если вы отправляете сообщение в список, пожалуйста, начните вашу тему с "minikube: ". 1.2 - Установка Kubernetes с помощью Kind ========================================= Kind — это инструмент для запуска локальных кластеров Kubernetes с помощью "узлов" контейнера Docker. Установка --------- Смотрите страницу [по установке Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) . 2 - Пользовательские облачные решения ===================================== --- # কুবারনেটিসে উইন্ডোজ | Kubernetes এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। [মুদ্রণ করতে এখানে ক্লিক করুন](https://kubernetes.io/bn/docs/concepts/windows/_print/#) . [এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন](https://kubernetes.io/bn/docs/concepts/windows/) . কুবারনেটিসে উইন্ডোজ =================== কুবারনেটিস নোড সমর্থন করে যা মাইক্রোসফ্ট উইন্ডোজ চালায়। কুবারনেটিস ওয়ার্কার [নোড](https://kubernetes.io/bn/docs/concepts/architecture/nodes/ "নোড হলো কুবারনেটিসে একটি ওয়ার্কার মেশিন।") লিনাক্স বা মাইক্রোসফ্ট উইন্ডোজ চালাতে সহায়তা করে। 🛇 এই আইটেমটি একটি তৃতীয় পক্ষের প্রকল্প বা পণ্যের সাথে লিঙ্ক করে যা নিজে কুবারনেটিস এর অংশ নয়। [অধিক তথ্য](https://kubernetes.io/bn/docs/concepts/windows/_print/#third-party-content-disclaimer) CNCF এবং এর মূল লিনাক্স ফাউন্ডেশন সামঞ্জস্যের প্রতি বিক্রেতা-নিরপেক্ষ পদ্ধতি গ্রহণ করে। আপনার [উইন্ডোজ সার্ভার](https://www.microsoft.com/en-us/windows-server) এ একটি কুবারনেটিস ক্লাস্টারে একটি ওয়ার্কার নোড হিসাবে যোগদান করা সম্ভব। আপনি [উইন্ডোজে kubectl ইনস্টল এবং সেট আপ](https://kubernetes.io/bn/docs/tasks/tools/install-kubectl-windows/) করতে পারেন আপনার ক্লাস্টারের মধ্যে যে কোন অপারেটিং সিস্টেম ব্যবহার করেন না কেন। আপনি যদি উইন্ডোজে নোড ব্যবহার করেন তবে আপনি পড়তে পারেন: * [উইন্ডোজে নেটওয়ার্কিং](https://kubernetes.io/bn/docs/concepts/services-networking/windows-networking/) * [কুবারনেটিসে উইন্ডোজ স্টোরেজ](https://kubernetes.io/bn/docs/concepts/storage/windows-storage/) * [উইন্ডোজ নোডের জন্য রিসোর্স ব্যবস্থাপনা](https://kubernetes.io/bn/docs/concepts/configuration/windows-resource-management/) * [উইন্ডোজ পড এবং কন্টেইনারগুলির জন্য RunAsUserName কনফিগার করুন](https://kubernetes.io/bn/docs/tasks/configure-pod-container/configure-runasusername/) * [একটি উইন্ডোজ হোস্টপ্রসেস(HostProcess) পড তৈরি করুন](https://kubernetes.io/bn/docs/tasks/configure-pod-container/create-hostprocess-pod/) * [উইন্ডোজ পড এবং কন্টেইনারগুলির জন্য গ্রুপ পরিচালিত পরিষেবা অ্যাকাউন্টগুলি কনফিগার করুন](https://kubernetes.io/bn/docs/tasks/configure-pod-container/configure-gmsa/) * [উইন্ডোজ নোডের জন্য নিরাপত্তা](https://kubernetes.io/bn/docs/concepts/security/windows-security/) * [উইন্ডোজ ডিবাগিং টিপস](https://kubernetes.io/bn/docs/tasks/debug/debug-cluster/windows/) * [কুবারনেটিসে উইন্ডোজ কন্টেইনার নির্ধারণের জন্য নির্দেশিকা](https://kubernetes.io/bn/docs/concepts/windows/user-guide) অথবা, একটি ওভারভিউ জন্য, পড়ুন: --- # 节点参考信息 | Kubernetes 这是本节的多页打印视图。 [点击此处打印](https://kubernetes.io/zh-cn/docs/reference/node/_print/#) . [返回本页常规视图](https://kubernetes.io/zh-cn/docs/reference/node/) . 节点参考信息 ====== * 1: [Kubelet Checkpoint API](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-e9c91b750d5dd5acbbdb9e49c89d35ad) * 2: [Linux 内核版本要求](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-e9a4493b142cccdd4fcb813365f400bd) * 3: [关于 dockershim 移除和使用兼容 CRI 运行时的文章](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-26e96c9d268f9c39dfc525b98f477a12) * 4: [由 kubelet 填充的节点标签](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-634210635d8574632684e291be646c98) * 5: [kubelet 所使用的本地文件和路径](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-20fd618b4c6abae0d0bfdc090d8e6903) * 6: [kubelet 配置目录合并](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-c18723255166e0d71cef8eef93e5392c) * 7: [Kubelet 设备管理器 API 版本](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-a8efd942edb7bc78148bce3c5ec6db99) * 8: [kubelet systemd 看门狗](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-dee45174a808078522a57e09f33b8c43) * 9: [Seccomp 和 Kubernetes](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-7bf7723707a2688483a1bde842667722) * 10: [节点状态](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-8cc3d980ae362cd0e958120dd2072673) * 11: [Linux 节点的交换（Swap）行为](https://kubernetes.io/zh-cn/docs/reference/node/_print/#pg-cb8754a33c0f537d16742b006b8ff78f) 本部分包含以下有关节点的参考主题： * kubelet 的 [Checkpoint API](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-checkpoint-api/) * 一系列[关于 dockershim 移除和使用兼容 CRI 运行时的文章](https://kubernetes.io/zh-cn/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) * [kubelet 设备管理器 API 版本](https://kubernetes.io/zh-cn/docs/reference/node/device-plugin-api-versions) * [由 kubelet 填充的节点标签](https://kubernetes.io/zh-cn/docs/reference/node/node-labels) * [由 kubelet 使用的本地文件和路径](https://kubernetes.io/zh-cn/docs/reference/node/kubelet-files) * [节点 `.status` 信息](https://kubernetes.io/zh-cn/docs/reference/node/node-status/) * [Linux 节点的交换（Swap）行为](https://kubernetes.io/zh-cn/docs/reference/node/swap-behavior/) * [Seccomp 信息](https://kubernetes.io/zh-cn/docs/reference/node/seccomp/) 你还可以从 Kubernetes 文档的其他地方阅读节点的详细参考信息，包括： * [节点指标数据](https://kubernetes.io/zh-cn/docs/reference/instrumentation/node-metrics) 。 * [CRI Pod & 容器指标](https://kubernetes.io/zh-cn/docs/reference/instrumentation/cri-pod-container-metrics) 。 * [了解 PSI 指标](https://kubernetes.io/zh-cn/docs/reference/instrumentation/understand-psi-metrics) 。 1 - Kubelet Checkpoint API ========================== 特性状态： `Kubernetes v1.30 [beta]`（默认启用） 为容器生成检查点这个功能可以为一个正在运行的容器创建有状态的拷贝。 一旦容器有一个有状态的拷贝，你就可以将其移动到其他计算机进行调试或类似用途。 如果你将通过检查点操作生成的容器数据移动到能够恢复该容器的一台计算机， 所恢复的容器将从之前检查点操作执行的时间点继续运行。 你也可以检视所保存的数据，前提是你拥有这类操作的合适工具。 创建容器的检查点可能会产生安全隐患。 通常，一个检查点包含执行检查点操作时容器中所有进程的所有内存页。 这意味着以前存在于内存中的一切内容现在都在本地磁盘上获得。 这里的内容包括一切私密数据和可能用于加密的密钥。 底层 CRI 实现（该节点上的容器运行时）应创建只有 `root` 用户可以访问的检查点存档。 另外重要的是记住：如果检查点存档被转移到另一个系统，该检查点存档的所有者将可以读取所有内存页。 操作 -- ### `post` 对指定的容器执行检查点操作 告知 kubelet 对指定 Pod 中的特定容器执行检查点操作。 查阅 [Kubelet 身份验证/鉴权参考](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz) 了解如何控制对 kubelet 检查点接口的访问。 Kubelet 将对底层 [CRI](https://kubernetes.io/zh-cn/docs/concepts/architecture/cri "在 kubelet 和本地容器运行时之间通讯的协议") 实现请求执行检查点操作。 在该检查点请求中，Kubelet 将检查点存档的名称设置为 `checkpoint--<容器名称>-<时间戳>.tar`， 还会请求将该检查点存档存储到其根目录（由 `--root-dir` 定义）下的 `checkpoints` 子目录中。 这个目录默认为 `/var/lib/kubelet/checkpoints`。 检查点存档的格式为 **tar**，可以使用 [`tar`](https://pubs.opengroup.org/onlinepubs/7908799/xcu/tar.html) 的一种实现来读取。存档文件的内容取决于底层 CRI 实现（该节点的容器运行时）。 #### HTTP 请求 POST /checkpoint/{namespace}/{pod}/{container} #### 参数 * **namespace** (**路径参数**)：string，必需 [名字空间（Namespace）](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/namespaces/ "名字空间是 Kubernetes 用来支持隔离单个集群中的资源组的一种抽象。") * **pod** (**路径参数**)：string，必需 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ "Pod 表示你的集群上一组正在运行的容器。") * **container** (**路径参数**)：string，必需 [容器（Container）](https://kubernetes.io/zh-cn/docs/concepts/containers/ "容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。") * **timeout** (**查询参数**)：integer 等待检查点创建完成的超时时间（单位为秒）。 如果超时值为零或未设定，将使用默认的 [CRI](https://kubernetes.io/zh-cn/docs/concepts/architecture/cri "在 kubelet 和本地容器运行时之间通讯的协议") 超时时间值。 生成检查点所需的时长直接取决于容器所用的内存。容器使用的内存越多，创建相应检查点所需的时间越长。 #### 响应 200: OK 401: Unauthorized 404: Not Found（如果 `ContainerCheckpoint` 特性门控被禁用） 404: Not Found（如果指定的 `namespace`、`pod` 或 `container` 无法被找到） 500: Internal Server Error（如果执行检查点操作期间 CRI 实现遇到一个错误（参阅错误消息了解更多细节）） 500: Internal Server Error（如果 CRI 实现未实现检查点 CRI API（参阅错误消息了解更多细节）） 2 - Linux 内核版本要求 ================ **说明：** 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循[CNCF 网站指南](https://github.com/cncf/foundation/blob/main/policies-guidance/website-guidelines.md) ，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读[内容指南](https://kubernetes.io/zh-cn/docs/contribute/style/content-guide/#third-party-content) 。 许多特性依赖于特定的内核功能，并且有最低的内核版本要求。 然而，单纯依赖内核版本号可能不足以满足某些操作系统发行版， 因为像 RHEL、Ubuntu 和 SUSE 等发行版的维护者们通常会将选定的特性反向移植到较旧的内核版本（保留较旧的内核版本）。 Pod sysctl ---------- 在 Linux 中，`sysctl()` 系统调用在运行时配置内核参数。 你可以使用名为 `sysctl` 的命令行工具来配置这些参数，许多参数通过 `proc` 文件系统暴露。 某些 sysctl 仅可用于足够新的内核上。 以下 sysctl 具有最低的内核版本要求， 并在[安全集](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/#safe-and-unsafe-sysctls) 中得到了支持： * `net.ipv4.ip_local_reserved_ports`（自 Kubernetes 1.27 起，需要内核 3.16+）。 * `net.ipv4.tcp_keepalive_time`（自 Kubernetes 1.29 起，需要内核 4.5+）。 * `net.ipv4.tcp_fin_timeout`（自 Kubernetes 1.29 起，需要内核 4.6+）。 * `net.ipv4.tcp_keepalive_intvl`（自 Kubernetes 1.29 起，需要内核 4.5+）。 * `net.ipv4.tcp_keepalive_probes`（自 Kubernetes 1.29 起，需要内核 4.5+）。 * `net.ipv4.tcp_syncookies`（自内核 4.6+ 添加了命名空间作用域）。 * `net.ipv4.tcp_rmem`（自 Kubernetes 1.32，需要内核 4.15+）。 * `net.ipv4.tcp_wmem`（自 Kubernetes 1.32，需要内核 4.15+）。 * `net.ipv4.vs.conn_reuse_mode`（用于 `ipvs` 代理模式，需要内核 4.1+）。 ### kube proxy `nftables` 代理模式 对于 Kubernetes 1.35，kube-proxy 的 [`nftables` 模式](https://kubernetes.io/zh-cn/docs/reference/networking/virtual-ips/#proxy-mode-nftables) 要求 nft 命令行工具为 v1.0.1 或更高版本，要求内核为 v5.13 或更高版本。 出于测试/开发目的，你可以使用较旧的内核，如果你在 kube-proxy 配置中设置 `nftables.skipKernelVersionCheck` 选项， 最老可以回溯到 v5.4。但在生产环境中不推荐这样做，因为这可能会导致系统上其他 nftables 用户出现问题。 v2 控制组 ------ Kubernetes 对 CGroup v1 的支持从 v1.31 开始处于维护模式；推荐使用 CGroup v2。 在 [Linux 5.8](https://github.com/torvalds/linux/commit/4a7e89c5ec0238017a757131eb9ab8dc111f961c) 中，为了方便使用，系统层面的 `cpu.stat` 文件被添加到根 CGroup。 在 runc 文档中，不推荐使用低于 5.2 的内核，因为其缺少冻结特性。 压力阻塞信息（PSI） ----------- Linux 内核 v4.20 及更高版本支持[压力阻塞信息](https://kubernetes.io/zh-cn/docs/reference/instrumentation/node-metrics#psi) ， 但需要以下配置： * 内核必须使用 `CONFIG_PSI=y` 选项进行编译（大多数现代发行版默认启用此选项）。 你可以通过运行 `zgrep CONFIG_PSI /proc/config.gz` 来检查内核的配置。 * 某些 Linux 发行版可能会将 PSI 编译进内核，但默认情况下是禁用的。 如果是这样，你需要在启动时通过向内核命令行添加 `psi=1` 参数来启用它。 其他内核要求 ------ 某些特性可能依赖于新的内核功能并具有特定的内核要求： 1. [递归只读挂载](https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#recursive-read-only-mounts) ： 这是通过应用 `MOUNT_ATTR_RDONLY` 属性和 `AT_RECURSIVE` 标志来实现的，使用的是在 Linux 内核 v5.12 中添加的 `mount_setattr`(2)。 2. Pod 用户命名空间支持需要最低内核版本 6.5+，参阅 [KEP-127](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-user-namespaces/README.md) 。 3. 对于[节点系统交换](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/#swap-memory) ， 直到内核 6.3 才支持将 tmpfs 设置为 `noswap`。 Linux 内核长期维护 ------------ 你可以在 [kernel.org](https://www.kernel.org/category/releases.html) 找到活动的内核版本。 通常会提供多个**长期维护**内核版本，用于将 Bug 修复反向移植到较旧的内核树。 特别是对于较旧的树，只有重要的 Bug 修复才会被应用到此类内核，这些内核通常不会频繁发布新版本。 请参阅 Linux 内核网站，了解 **Longterm** 类别中的[发布列表](https://www.kernel.org/category/releases.html) 。 接下来 --- * 查阅 [sysctl](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/) 以获取更多细节。 * 允许在 [nftables 模式](https://kubernetes.io/zh-cn/docs/reference/networking/virtual-ips/#proxy-mode-nftables) 下运行 kube-proxy。 * 参阅 [CGroup v2](https://kubernetes.io/zh-cn/docs/concepts/architecture/cgroups/) 。 3 - 关于 dockershim 移除和使用兼容 CRI 运行时的文章 ==================================== 这是关于 Kubernetes 弃用和移除 **dockershim** 或使用兼容 CRI 的容器运行时相关的文章和其他页面的列表。 Kubernetes 项目 ------------- * Kubernetes 博客：[Dockershim 移除常见问题解答](https://kubernetes.io/zh-cn/blog/2020/12/02/dockershim-faq/) （最初发表于 2020/12/02） * Kubernetes 博客：[更新：Dockershim 移除常见问题解答](https://kubernetes.io/zh-cn/blog/2022/02/17/dockershim-faq/) （更新发表于 2020/12/02） * Kubernetes 博客：[Kubernetes 即将移除 Dockershim：承诺和下一步](https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/) （发表于 2022/01/07） * Kubernetes 博客：[移除 Dockershim 即将到来。你准备好了吗？](https://kubernetes.io/zh-cn/blog/2021/11/12/are-you-ready-for-dockershim-removal/) （发表于 2021/11/12） * Kubernetes 文档：[从 dockershim 迁移](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/) * Kubernetes 文档：[容器运行时](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/) * Kubernetes 增强建议：[KEP-2221: 从 kubelet 中移除 dockershim](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2221-remove-dockershim/README.md) * Kubernetes 增强提问：[从 kubelet 中移除 dockershim](https://github.com/kubernetes/enhancements/issues/2221) (_k/enhancements#2221_) 你可以通过 GitHub 问题 [**Dockershim 移除反馈和问题**](https://github.com/kubernetes/kubernetes/issues/106917) 提供反馈。 (_k/kubernetes/#106917_) 外部来源 ---- * Amazon Web Services EKS 文档：[Amazon EKS 将终止对 Dockershim 的支持](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html) * CNCF 会议视频：[将 Kubernetes 从 Docker 迁移到 containerd 运行时的经验教训](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/) （Ana Caylin，在 KubeCon Europe 2019） * Docker.com 博客：[开发人员需要了解的关于 Docker、Docker Engine 和 Kubernetes v1.20 的哪些知识](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/) （发表于 2020/12/04） * YouTube 上的 “**Google Open Source**” 频道：[与 Google 一起学习 Kubernetes - 从 Dockershim 迁移到 Containerd](https://youtu.be/fl7_4hjT52g) * Azure 博客上的 Microsoft 应用：[Dockershim 弃用和 AKS](https://techcommunity.microsoft.com/t5/apps-on-azure-blog/dockershim-deprecation-and-aks/ba-p/3055902) （发表于 2022/01/21） * Mirantis 博客：[Dockershim 的未来是 cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/) （发表于 2021/04/21） * Mirantis: [Mirantis/cri-dockerd](https://mirantis.github.io/cri-dockerd/) 官方文档 * Tripwire：[Dockershim 即将弃用如何影响你的 Kubernetes](https://www.tripwire.com/state-of-security/security-data-protection/cloud/how-dockershim-forthcoming-deprecation-affects-your-kubernetes/) （发表于 2021/07/01） 4 - 由 kubelet 填充的节点标签 ===================== Kubernetes [节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/ "Kubernetes 中的工作机器称作节点。") 预先填充了一组标准 [标签](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/ "用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。") 。 你还可以通过 kubelet 配置或使用 Kubernetes API 在节点上设置自己的标签。 预设标签 ---- Kubernetes 在节点上设置的预设标签有： * [`kubernetes.io/arch`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#kubernetes-io-arch) * [`kubernetes.io/hostname`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#kubernetesiohostname) * [`kubernetes.io/os`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#kubernetes-io-os) * [`node.kubernetes.io/instance-type`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#nodekubernetesioinstance-type) （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签） * [`topology.kubernetes.io/region`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesioregion) （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签） * [`topology.kubernetes.io/zone`](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesiozone) （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签） #### 说明： 这些标签的值是特定于云提供商的，并且不保证其可靠性。 例如，`kubernetes.io/hostname` 的值在某些环境中可能与节点名称相同， 而在其他环境中可能与节点名称不同。 接下来 --- * 有关常见标签的列表，请参阅[众所周知的标签、注释和污点](https://kubernetes.io/zh-cn/docs/reference/labels-annotations-taints/) 。 * 了解如何[向节点添加标签](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node) 。 5 - kubelet 所使用的本地文件和路径 ======================= [kubelet](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet "一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。") 是一个运行在 Kubernetes [节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/ "Kubernetes 中的工作机器称作节点。") 上的无状态进程。本文简要介绍了 kubelet 读写的文件。 #### 说明： 本文仅供参考，而非描述保证会发生的行为或 API。 本文档列举 kubelet 所使用的资源。所给的信息属于实现细节，可能会在后续版本中发生变更。 kubelet 通常使用[控制面](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-control-plane "控制平面是指容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。") 作为需要在 Node 上运行的事物的真实来源，并使用[容器运行时](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes "容器运行时是负责运行容器的软件。") 获取容器的当前状态。 只要你向 kubelet 提供 **kubeconfig**（API 客户端配置），kubelet 就会连接到你的控制面； 否则，节点将以\*\*独立（Standalone）\*\*模式运行。 在 Linux 节点上，kubelet 还需要读取 cgroups 和各种系统文件来收集指标。 在 Windows 节点上，kubelet 不依赖于路径，而是通过其他机制来收集指标。 kubelet 所使用的还有其他文件，包括其使用本地 Unix 域套接字进行通信的文件。 有些文件是 kubelet 要监听的套接字，而其他套接字则是 kubelet 先发现后作为客户端连接的。 #### 说明： 本页列举的路径为 Linux 路径，若要映射到 Windows，你可以添加根磁盘 `C:\` 替换 `/`（除非另行指定）。 例如，`/var/lib/kubelet/device-plugins` 映射到 `C:\var\lib\kubelet\device-plugins`。 配置 -- ### kubelet 配置文件 你可以使用命令行参数 `--config` 指定 kubelet 配置文件的路径。kubelet 还支持[插件（Drop-in）配置文件](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/#kubelet-conf-d) 来增强配置。 ### 证书 证书和私钥通常位于 `/var/lib/kubelet/pki`，但你可以使用 `--cert-dir` kubelet 命令行参数进行配置。 证书文件的名称也是可以配置的。 ### 清单 静态 Pod 的清单通常位于 `/etc/kubernetes/manifests`。 你可以使用 `staticPodPath` kubelet 配置选项进行配置。 ### systemd 单元设置 当 kubelet 作为 systemd 单元运行时，一些 kubelet 配置可以在 systemd 单元设置文件中声明。 这些配置通常包括： * [运行 kubelet 的命令行参数](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet/) * kubelet 所使用的环境变量或[配置 Golang 运行时](https://pkg.go.dev/runtime#hdr-Environment_Variables) 状态 -- ### 资源管理器的检查点文件 所有资源管理器将 Pod 与已分配资源之间的映射保存在状态文件中。 状态文件位于 kubelet 的基础目录，也称为**根目录**（但与节点根目录 `/` 不同）之下。 你可以使用 kubelet 命令行参数 `--root-dir` 来配置 kubelet 的基础目录。 文件名称： * `memory_manager_state` 对应[内存管理器](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/memory-manager/) * `cpu_manager_state` 对应 [CPU 管理器](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/) * `dra_manager_state` 对应 [DRA](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) ### 设备管理器的检查点文件 设备管理器在与套接字文件相同的目录（`/var/lib/kubelet/device-plugins/`）中创建检查点。 对于[设备管理器](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) ， 检查点文件的名称为 `kubelet_internal_checkpoint`。 ### Pod 状态检查点 特性状态： `Kubernetes v1.35 [stable]`（默认启用） 如果某个节点已启用了 `InPlacePodVerticalScaling` [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) ， 则 kubelet 存储有关 Pod 资源**已分配**和**已应用**状态的本地记录。 有关如何使用这些记录的更多细节， 请参阅[调整分配给容器的 CPU 和内存资源](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/) 。 文件名称如下： * `allocated_pods_state`：记录分配给该节点上每个 Pod 的资源。 * `actuated_pods_state`：记录运行时已接受并应用于该节点上每个 Pod 的资源。 这些文件位于 kubelet 的基础目录中（在 Linux 系统中默认是 `/var/lib/kubelet`； 也可以通过 `--root-dir` 参数进行配置）。 ### 容器运行时 kubelet 使用通过配置参数所配置的套接字与容器运行时进行通信： * `containerRuntimeEndpoint` 用于运行时操作 * `imageServiceEndpoint` 用于镜像管理操作 这些端点的实际值取决于所使用的容器运行时。 ### 设备插件 kubelet 在路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 为各个[要注册的设备插件](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-implementation) 公开一个套接字。 当设备插件注册自己时，它会为提供其套接字路径供 kubelet 连接使用。 设备插件套接字应位于 kubelet 基础目录中的 `device-plugins` 目录内。 在典型的 Linux 节点上，这意味着 `/var/lib/kubelet/device-plugins`。 ### Pod Resources API [Pod Resources API](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) 将在路径 `/var/lib/kubelet/pod-resources` 上被公开。 ### DRA、CSI 和设备插件 kubelet 会查找通过 [DRA](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) 设备管理器或存储插件所管理的设备插件所创建的套接字文件，然后尝试连接到这些套接字。 kubelet 查找的目录是 kubelet 基础目录下的 `plugins_registry`， 因此在典型的 Linux 节点上这意味着 `/var/lib/kubelet/plugins_registry`。 请注意，对于设备插件，有两种备选的注册机制。每个给定的插件只能使用其中一种注册机制。 可以将套接字文件放入该目录的插件类型包括： * CSI 插件 * DRA 插件 * 设备管理器插件 （通常是 `/var/lib/kubelet/plugins_registry`）。 ### 节点体面关闭 特性状态： `Kubernetes v1.21 [beta]`（默认启用） [节点体面关闭](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/node-shutdown/#graceful-node-shutdown) 将状态存储在本地目录 `/var/lib/kubelet/graceful_node_shutdown_state`。 ### 镜像拉取记录 特性状态： `Kubernetes v1.35 [beta]`（默认启用） kubelet 存储镜像拉取的尝试记录和成功记录，并使用这些记录来验证镜像是否曾使用相同的凭据被成功拉取过。 这些记录作为文件缓存在 kubelet 基础目录下的 `image_registry` 目录中。 在典型的 Linux 节点上，这个路径通常为 `/var/lib/kubelet/image_manager`。 `image_manager` 目录下包含两个子目录： * `pulling`：存储 kubelet 正在尝试拉取的镜像的相关记录。 * `pulled`：存储 kubelet 成功拉取的镜像记录，以及与拉取所用凭据相关的元数据。 更多细节请参阅[确保镜像拉取凭据验证](https://kubernetes.io/zh-cn/docs/concepts/containers/images#ensureimagepullcredentialverification) 。 安全配置文件和配置 --------- ### Seccomp 被 Pod 引用的 Seccomp 配置文件应放置在 `/var/lib/kubelet/seccomp`。 有关细节请参见 [Seccomp 参考](https://kubernetes.io/zh-cn/docs/reference/node/seccomp/) 。 ### AppArmor kubelet 不会通过特定于 Kubernetes 的路径加载或引用 AppArmor 配置文件。 AppArmor 配置文件通过节点操作系统被加载，而不是通过其路径被引用。 加锁 -- 特性状态： `Kubernetes v1.2 [alpha]` kubelet 的锁文件；通常为 `/var/run/kubelet.lock`。 kubelet 使用此文件确保尝试运行两个不同的、彼此冲突的 kubelet。 你可以使用 `--lock-file` kubelet 命令行参数来配置这个锁文件的路径。 如果同一节点上的两个 kubelet 使用不同的锁文件路径值，则这两个 kubelet 在同时运行时将不会检测到冲突。 接下来 --- * 了解 kubelet [命令行参数](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 。 * 查阅 [kubelet 配置 (v1beta1) 参考文档](https://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) 6 - kubelet 配置目录合并 ================== 当使用 kubelet 的 `--config-dir` 标志来指定存放配置的目录时，不同类型的配置会有一些特定的行为。 以下是在配置合并过程中不同数据类型的一些行为示例： ### 结构字段 在 YAML 结构中有两种结构字段：独立（标量类型）和嵌入式（此结构包含标量类型）。 配置合并过程将处理独立构造字段和嵌入式构造字段的重载，以创建最终的 kubelet 配置。 例如，你可能想要为所有节点设置一个基准 kubelet 配置，但希望自定义 `address` 和 `authorization` 字段。 这种情况下，你可以按以下方式完成： kubelet 主配置文件内容： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration port: 20250 authorization: mode: Webhook webhook: cacheAuthorizedTTL: "5m" cacheUnauthorizedTTL: "30s" serializeImagePulls: false address: "192.168.0.1" `--config-dir` 目录中文件的内容： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration authorization: mode: AlwaysAllow webhook: cacheAuthorizedTTL: "8m" cacheUnauthorizedTTL: "45s" address: "192.168.0.8" 生成的配置如下所示： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration port: 20250 serializeImagePulls: false authorization: mode: AlwaysAllow webhook: cacheAuthorizedTTL: "8m" cacheUnauthorizedTTL: "45s" address: "192.168.0.8" ### 列表 你可以重载 kubelet 配置的切片/列表值。 但在合并过程中整个列表将被重载。 例如，你可以按以下方式重载 `clusterDNS` 列表： kubelet 主配置文件的内容： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration port: 20250 serializeImagePulls: false clusterDNS: - "192.168.0.9" - "192.168.0.8" `--config-dir` 目录中文件的内容： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration clusterDNS: - "192.168.0.2" - "192.168.0.3" - "192.168.0.5" 生成的配置如下所示： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration port: 20250 serializeImagePulls: false clusterDNS: - "192.168.0.2" - "192.168.0.3" - "192.168.0.5" ### 含嵌套结构的映射 映射中的各个字段（无论其值类型是布尔值、字符串等）都可以被选择性地重载。 但对于 `map[string][]string` 类型来说，与特定字段关联的整个列表都将被重载。 让我们通过一个例子更好地理解这一点，特别是 `featureGates` 和 `staticPodURLHeader` 这类字段： kubelet 主配置文件的内容： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration port: 20250 serializeImagePulls: false featureGates: AllAlpha: false MemoryQoS: true staticPodURLHeader: kubelet-api-support: - "Authorization: 234APSDFA" - "X-Custom-Header: 123" custom-static-pod: - "Authorization: 223EWRWER" - "X-Custom-Header: 456" `--config-dir` 目录中文件的内容： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration featureGates: MemoryQoS: false KubeletTracing: true DynamicResourceAllocation: true staticPodURLHeader: custom-static-pod: - "Authorization: 223EWRWER" - "X-Custom-Header: 345" 生成的配置如下所示： apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration port: 20250 serializeImagePulls: false featureGates: AllAlpha: false MemoryQoS: false KubeletTracing: true DynamicResourceAllocation: true staticPodURLHeader: kubelet-api-support: - "Authorization: 234APSDFA" - "X-Custom-Header: 123" custom-static-pod: - "Authorization: 223EWRWER" - "X-Custom-Header: 345" 7 - Kubelet 设备管理器 API 版本 ======================== 本页详述了 Kubernetes [设备插件 API](https://github.com/kubernetes/kubelet/tree/master/pkg/apis/deviceplugin) 与不同版本的 Kubernetes 本身之间的版本兼容性。 兼容性矩阵 ----- | | `v1alpha1` | `v1beta1` | | --- | --- | --- | | Kubernetes 1.21 | \- | ✓ | | Kubernetes 1.22 | \- | ✓ | | Kubernetes 1.23 | \- | ✓ | | Kubernetes 1.24 | \- | ✓ | | Kubernetes 1.25 | \- | ✓ | | Kubernetes 1.26 | \- | ✓ | 简要说明： * `✓` 设备插件 API 和 Kubernetes 版本中的特性或 API 对象完全相同。 * `+` 设备插件 API 具有 Kubernetes 集群中可能不存在的特性或 API 对象， 不是因为设备插件 API 添加了额外的新 API 调用，就是因为服务器移除了旧的 API 调用。 但它们的共同点是（大多数其他 API）都能工作。 请注意，Alpha API 可能会在次要版本的迭代过程中消失或出现重大变更。 * `-` Kubernetes 集群具有设备插件 API 无法使用的特性，不是因为服务器添加了额外的 API 调用， 就是因为设备插件 API 移除了旧的 API 调用。但它们的共同点是（大多数 API）都能工作。 8 - kubelet systemd 看门狗 ======================= 特性状态： `Kubernetes v1.32 [beta]`（默认启用） 在 Linux 节点上，Kubernetes 1.35 支持与 [systemd](https://systemd.io/) 集成，以允许操作系统监视程序恢复失败的 kubelet。 这种集成默认并未被启用。它可以作为一个替代方案，通过定期请求 kubelet 的 `/healthz` 端点进行健康检查。 如果 kubelet 在设定的超时时限内未对看门狗做出响应，看门狗将杀死 kubelet。 systemd 看门狗的工作原理是要求服务定期向 systemd 进程发送一个**保持活跃**的信号。 如果 systemd 进程在指定的超时时限内未接收到某服务发出的信号，则对应的服务被视为无响应并被终止。 之后 systemd 进程可以基于配置重启该服务。 配置 -- 使用 systemd 看门狗需要在 kubelet 服务单元文件的 `[Service]` 部分配置 `WatchdogSec` 参数： [Service] WatchdogSec=30s 设置 `WatchdogSec=30s` 表示服务看门狗超时时限为 30 秒。 在 kubelet 内，`sd_notify()` 函数被调用，以 \\( WatchdogSec \\div 2\\) 的时间间隔， 发送 `WATCHDOG=1`（保持活跃的消息）。如果在超时时限内看门狗未被“投喂”此信号，kubelet 将被杀死。 将 `Restart` 设置为 "always"、"on-failure"、"on-watchdog" 或 "on-abnormal" 将确保服务被自动重启。 systemd 配置相关的一些细节： 1. 如果你将 systemd 的 `WatchdogSec` 值设置为 0，或省略不设置，则对应的单元上不启用 systemd 看门狗。 2. kubelet 支持设置的最小看门狗超时时限为 1.0 秒；这是为了防止 kubelet 被意外杀死。 你可以在 systemd 单元定义中将 `WatchdogSec` 的值设置为短于 1 秒的超时时限， 但 Kubernetes 不支持任何更短的时间间隔。超时时限不必是整数的秒数。 3. Kubernetes 项目建议将 `WatchdogSec` 时限设置为大约 15 秒。 系统支持超过 10 分钟的时限设置，但明确**不**推荐这样做。 ### 示例配置 [Unit] Description=kubelet: The Kubernetes Node Agent Documentation=https://kubernetes.io/docs/home/ Wants=network-online.target After=network-online.target [Service] ExecStart=/usr/bin/kubelet # 配置看门狗的超时时限 WatchdogSec=30s Restart=on-failure StartLimitInterval=0 RestartSec=10 [Install] WantedBy=multi-user.target 接下来 --- 有关 systemd 配置的细节，请参阅 [systemd 文档](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#WatchdogSec=) 。 9 - Seccomp 和 Kubernetes ======================== Seccomp 表示安全计算（Secure Computing）模式，自 2.6.12 版本以来，一直是 Linux 内核的一个特性。 它可以用来沙箱化进程的权限，限制进程从用户态到内核态的调用。 Kubernetes 能使你自动将加载到[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/ "Kubernetes 中的工作机器称作节点。") 上的 seccomp 配置文件应用到你的 Pod 和容器。 Seccomp 字段 ---------- 特性状态： `Kubernetes v1.19 [stable]` 有四种方式可以为 [Pod](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ "Pod 表示你的集群上一组正在运行的容器。") 指定 seccomp 配置文件： * 为整个 Pod 使用 [`spec.securityContext.seccompProfile`](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) * 为单个容器使用 [`spec.containers[*].securityContext.seccompProfile`](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1) * 为（可重启/边车）Init 容器使用 [`spec.initContainers[*].securityContext.seccompProfile`](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1) * 为[临时容器](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ephemeral-containers) 使用 [`spec.ephemeralContainers[*].securityContext.seccompProfile`](https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-2) [`pods/security/seccomp/fields.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/pods/security/seccomp/fields.yaml) ![](https://kubernetes.io/images/copycode.svg "复制 pods/security/seccomp/fields.yaml 到剪贴板") apiVersion: v1 kind: Pod metadata: name: pod spec: securityContext: seccompProfile: type: Unconfined ephemeralContainers: - name: ephemeral-container image: debian securityContext: seccompProfile: type: RuntimeDefault initContainers: - name: init-container image: debian securityContext: seccompProfile: type: RuntimeDefault containers: - name: container image: docker.io/library/debian:stable securityContext: seccompProfile: type: Localhost localhostProfile: my-profile.json 上面的示例中的 Pod 以 `Unconfined` 运行，而 `ephemeral-container` 和 `init-container` 独立设置了 `RuntimeDefault`。 如果临时容器或 Init 容器没有明确设置 `securityContext.seccompProfile` 字段， 则此值将从 Pod 继承。同样的机制也适用于运行 `Localhost` 配置文件 `my-profile.json` 的容器。 一般来说，（临时）容器的字段优先级高于 Pod 层级的值，而未设置 seccomp 字段的容器则从 Pod 继承配置。 #### 说明： 你不可以将 seccomp 配置文件应用到在容器的 `securityContext` 中设置了 `privileged: true` 的 Pod 或容器。特权容器始终以 `Unconfined` 运行。 对于 `seccompProfile.type`，可以使用以下值： `Unconfined` 工作负载在没有任何 seccomp 限制的情况下运行。 `RuntimeDefault` 由[容器运行时](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes "容器运行时是负责运行容器的软件。") 定义的默认 seccomp 配置文件被应用。这个默认的配置文件旨在提供一套强大的安全默认值，同时保持工作负载的功能不受影响。 不同的容器运行时及其版本之间的默认配置文件可能会有所不同， 例如在比较 [CRI-O](https://cri-o.io/#what-is-cri-o "专用于 Kubernetes 的轻量级容器运行时软件") 和 [containerd](https://containerd.io/docs/ "强调简单性、健壮性和可移植性的一种容器运行时") 的默认配置文件时就会发现不同。 `Localhost` `localhostProfile` 将被应用，这一配置必须位于节点磁盘上（在 Linux 上是 `/var/lib/kubelet/seccomp`）。 在创建容器时，[容器运行时](https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes "容器运行时是负责运行容器的软件。") 会验证 seccomp 配置文件的可用性。如果此配置文件不存在，则容器创建将失败，并报错 `CreateContainerError`。 ### `Localhost` 配置文件 Seccomp 配置文件是遵循 [OCI 运行时规范](https://github.com/opencontainers/runtime-spec/blob/f329913/config-linux.md#seccomp) 定义的 JSON 文件。配置文件主要根据所匹配的系统调用来定义操作，但也允许将特定值作为参数传递给系统调用。例如： { "defaultAction": "SCMP_ACT_ERRNO", "defaultErrnoRet": 38, "syscalls": [\ {\ "names": [\ "adjtimex",\ "alarm",\ "bind",\ "waitid",\ "waitpid",\ "write",\ "writev"\ ],\ "action": "SCMP_ACT_ALLOW"\ }\ ] } 上述配置文件中的 `defaultAction` 被定义为 `SCMP_ACT_ERRNO`，并可回退至 `syscalls` 中所定义的操作。 此错误通过 `defaultErrnoRet` 字段被定义为代码 `38`。 通常可以使用以下操作： `SCMP_ACT_ERRNO` 返回指定的错误码。 `SCMP_ACT_ALLOW` 允许执行系统调用。 `SCMP_ACT_KILL_PROCESS` 杀死进程。 `SCMP_ACT_KILL_THREAD` 和 `SCMP_ACT_KILL` 仅杀死线程。 `SCMP_ACT_TRAP` 发送 `SIGSYS` 信号。 `SCMP_ACT_NOTIFY` 和 `SECCOMP_RET_USER_NOTIF` 通知用户空间。 `SCMP_ACT_TRACE` 使用指定的值通知跟踪进程。 `SCMP_ACT_LOG` 在将操作记录到 syslog 或 auditd 之后，允许执行系统调用。 `SCMP_ACT_NOTIFY` 或 `SECCOMP_RET_USER_NOTIF` 这类操作可能不被支持， 具体取决于所使用的容器运行时、OCI 运行时或 Linux 内核版本。也可能存在其他限制， 例如 `SCMP_ACT_NOTIFY` 不能用作 `defaultAction` 或用于某些系统调用（如 `write`）。 所有这些限制由 OCI 运行时 （[runc](https://github.com/opencontainers/runc) 、[crun](https://github.com/containers/crun) ） 或 [libseccomp](https://github.com/seccomp/libseccomp) 所定义。 `syscalls` JSON 数组包含对象列表，每个对象通过系统调用的 `names` 引用系统调用。 例如，`SCMP_ACT_ALLOW` 操作可用于创建包含如上例所示的系统调用的白名单。 也可以使用 `SCMP_ACT_ERRNO` 操作定义另一个列表，但会有不同的返回值（`errnoRet`）。 你还可以指定传递给某些系统调用的参数（`args`）。有关这些高级用例的细节，请参见 [OCI 运行时规范](https://github.com/opencontainers/runtime-spec/blob/f329913/config-linux.md#seccomp) 和 [Seccomp Linux 内核文档](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) 。 进一步阅读 ----- * [使用 seccomp 限制容器的系统调用](https://kubernetes.io/zh-cn/docs/tutorials/security/seccomp/) * [Pod 安全标准](https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/) 10 - 节点状态 ========= 在 Kubernetes 中，[节点](https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/) 的状态是管理 Kubernetes 集群的一个关键方面。在本文中，我们将简要介绍如何监控和维护节点状态以确保集群的健康和稳定。 节点状态字段 ------ 一个节点的状态包含以下信息: * [地址（Addresses）](https://kubernetes.io/zh-cn/docs/reference/node/_print/#addresses) * [状况（Condition）](https://kubernetes.io/zh-cn/docs/reference/node/_print/#condition) * [容量与可分配（Capacity）](https://kubernetes.io/zh-cn/docs/reference/node/_print/#capacity) * [信息（Info）](https://kubernetes.io/zh-cn/docs/reference/node/_print/#info) * [已声明的特性（Declared Features）](https://kubernetes.io/zh-cn/docs/reference/node/_print/#declaredfeatures) 你可以使用 `kubectl` 来查看节点状态和其他细节信息： kubectl describe node <节点名称> 下面对输出的每个部分进行详细描述。 ### 地址 这些字段的用法取决于你的云服务商或者物理机配置。 * HostName：由节点的内核报告。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 * ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。 * InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。 ### 状况 `conditions` 字段描述了所有 `Running` 节点的状况。状况的示例包括： | | | | --- | --- |节点状况及每种状况适用场景的描述 | 节点状况 | 描述 | | --- | --- | | `Ready` | 如节点是健康的并已经准备好接收 Pod 则为 `True`；`False` 表示节点不健康而且不能接收 Pod；`Unknown` 表示节点控制器在最近 `node-monitor-grace-period` 期间（默认 50 秒）没有收到节点的消息 | | `DiskPressure` | `True` 表示节点存在磁盘空间压力，即磁盘可用量低，否则为 `False` | | `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` | | `PIDPressure` | `True` 表示节点存在进程压力，即节点上进程过多；否则为 `False` | | `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | #### 说明： 如果使用命令行工具来打印已保护（Cordoned）节点的细节，其中的 Condition 字段可能包括 `SchedulingDisabled`。`SchedulingDisabled` 不是 Kubernetes API 中定义的 Condition，被保护起来的节点在其规约中被标记为不可调度（Unschedulable）。 在 Kubernetes API 中，节点的状况表示节点资源中 `.status` 的一部分。 例如，以下 JSON 结构描述了一个健康节点： "conditions": [\ {\ "type": "Ready",\ "status": "True",\ "reason": "KubeletReady",\ "message": "kubelet is posting ready status",\ "lastHeartbeatTime": "2019-06-05T18:38:35Z",\ "lastTransitionTime": "2019-06-05T11:41:27Z"\ }\ ] 当节点上出现问题时，Kubernetes 控制面会自动创建与影响节点的状况对应的 [污点](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/) 。 例如当 Ready 状况的 `status` 保持 `Unknown` 或 `False` 的时间长于 kube-controller-manager 的 `NodeMonitorGracePeriod`（默认为 50 秒）时， 会造成 `Unknown` 状态下为节点添加 `node.kubernetes.io/unreachable` 污点或在 `False` 状态下为节点添加 `node.kubernetes.io/not-ready` 污点。 这些污点会影响悬决的 Pod，因为调度器在将 Pod 分配到节点时会考虑节点的污点。 已调度到节点的当前 Pod 可能会由于施加的 `NoExecute` 污点被驱逐。 Pod 还可以设置[容忍度](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/ "容忍度是一种核心对象，包含三个必需的属性：key、value 和 effect。 容忍度允许将 Pod 调度到具有对应污点的节点或节点组上。") ， 使得这些 Pod 仍然能够调度到且继续运行在设置了特定污点的节点上。 进一步的细节可参阅[基于污点的驱逐](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) 和[根据状况为节点设置污点](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) 。 ### 容量（Capacity）与可分配（Allocatable） 这两个值描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。 `capacity` 块中的字段标示节点拥有的资源总量。 `allocatable` 块指示节点上可供普通 Pod 使用的资源量。 你可以通过学习如何在节点上[预留计算资源](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 来进一步了解有关容量和可分配资源的信息。 ### 信息（Info） Info 指的是节点的一般信息，如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、 容器运行时详细信息，以及节点使用的操作系统。 `kubelet` 从节点收集这些信息并将其发布到 Kubernetes API。 声明式特性 ----- 特性状态： `Kubernetes v1.35 [alpha]`（默认禁用） 此字段列出了通过[特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 在节点的 kubelet 上当前已启用的特定 Kubernetes 特性。 kubelet 会将这些特性以字符串列表的形式报告到 Node 对象的 `.status.declaredFeatures` 字段中。 此字段用于记录正在积极开发的新特性； 已完成且不再需要特性门控的功能被视为基线功能，无需在此字段中声明。 这反映的是 Kubernetes 特性的启用情况，而非节点底层操作系统或内核的特性。 有关更多详细信息，请参阅[节点声明特性](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/node-declared-features/) 。 心跳 -- Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。 对于节点，有两种形式的心跳： * 更新节点的 `.status` * `kube-node-lease` [名字空间](https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/namespaces/ "名字空间是 Kubernetes 用来支持隔离单个集群中的资源组的一种抽象。") 中的 [Lease（租约）](https://kubernetes.io/zh-cn/docs/concepts/architecture/leases/) 对象。 每个节点都有一个关联的 Lease 对象。 与节点的 `.status` 更新相比，Lease 是一种轻量级资源。 使用 Lease 来表达心跳在大型集群中可以减少这些更新对性能的影响。 kubelet 负责创建和更新节点的 `.status`，以及更新它们对应的 Lease。 * 当节点状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 `.status`。 `.status` 更新的默认间隔为 5 分钟（比节点不可达事件的 40 秒默认超时时间长很多）。 * `kubelet` 会创建并每 10 秒（默认更新间隔时间）更新 Lease 对象。 Lease 的更新独立于节点的 `.status` 更新而发生。 如果 Lease 的更新操作失败，kubelet 会采用指数回退机制，从 200 毫秒开始重试， 最长重试间隔为 7 秒钟。 11 - Linux 节点的交换（Swap）行为 ======================== 要允许 Kubernetes 工作负载在 Linux 节点上使用交换分区， 你必须禁用 kubelet 在检测到交换分区时失败的默认行为， 并指定内存交换行为为 `LimitedSwap`： 可用的交换行为选项有： `NoSwap` （默认）在此节点上作为 Pod 运行的工作负载不会也不能使用交换分区。 然而，系统守护进程（包括 kubelet 本身！）等这类 Kubernetes 范围之外的进程**可以**利用交换分区。 这种行为有助于保护节点免受系统级别的内存峰值影响， 但这不能保护工作负载本身不受此类峰值的影响。 `LimitedSwap` Kubernetes 工作负载可以使用交换内存，Pod 可用的交换量是自动确定的。 要了解更多，请阅读[交换内存管理](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/swap-memory-management/) 。 --- # কনফিগারেশন | Kubernetes এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। [মুদ্রণ করতে এখানে ক্লিক করুন](https://kubernetes.io/bn/docs/concepts/configuration/_print/#) . [এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন](https://kubernetes.io/bn/docs/concepts/configuration/) . কনফিগারেশন ========== পডস কনফিগার করার জন্য কুবারনেটিস যে রিসোর্সগুলো প্রদান করে । --- # API 접근 제어 | Kubernetes 이 섹션의 다중 페이지 출력 화면임. [여기를 클릭하여 프린트](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#) . [이 페이지의 일반 화면으로 돌아가기](https://kubernetes.io/ko/docs/reference/access-authn-authz/) . API 접근 제어 ========= * 1: [부트스트랩 토큰을 사용한 인증](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#pg-de45b6ca7419a0e308044425b2ac52bb) * 2: [서비스 어카운트 관리하기](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#pg-bea207258f3576b8ec7444a20d498e1d) * 3: [인가 개요](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#pg-342be69d36f174f762c36f4fe11fcb20) * 4: [Kubelet 인증/인가](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#pg-36e1423f0b5caa8eafeb6f53c175d13c) 쿠버네티스가 API 접근을 구현 및 제어하는 방법에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](https://kubernetes.io/ko/docs/concepts/security/controlling-access/) 를 참고한다. 참조 문헌 * [인증](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) * [부트스트랩 토큰 인증](https://kubernetes.io/ko/docs/reference/access-authn-authz/bootstrap-tokens/) * [승인 컨트롤러](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) * [동적 승인 제어](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) * [인가](https://kubernetes.io/ko/docs/reference/access-authn-authz/authorization/) * [역할 기반 접근 제어](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) * [속성 기반 접근 제어](https://kubernetes.io/docs/reference/access-authn-authz/abac/) * [노드 인가](https://kubernetes.io/docs/reference/access-authn-authz/node/) * [웹훅 인가](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) * [인증서 서명 요청](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/) * [CSR 승인](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) 과 [인증서 서명](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#signing) 을 포함함 * 서비스 어카운트 * [개발자 가이드](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) * [관리](https://kubernetes.io/ko/docs/reference/access-authn-authz/service-accounts-admin/) * [kubelet 인증과 인가](https://kubernetes.io/ko/docs/reference/access-authn-authz/kubelet-authn-authz/) * kubelet [TLS 부트스트래핑](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 을 포함함 1 - 부트스트랩 토큰을 사용한 인증 ==================== 기능 상태: `Kubernetes v1.18 [stable]` 부트스트랩 토큰은 새 클러스터를 만들거나 새 노드를 기존 클러스터에 결합할 때 사용되는 간단한 전달자 토큰이다. [kubeadm](https://kubernetes.io/ko/docs/reference/setup-tools/kubeadm/) 을 지원하도록 구축되었지만 `kubeadm` 없이 클러스터를 시작하려는 사용자를 위해 다른 컨텍스트에서 사용할 수 있다. 또한 RBAC 정책을 통해 [Kubelet TLS 부트스트래핑](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 시스템과 함께 동작하도록 구축되었다. 부트스트랩 토큰 개요 ----------- 부트스트랩 토큰은 `kube-system` 네임스페이스에 있는 특정 유형(`bootstrap.kubernetes.io/token`)의 시크릿(Secret)으로 정의된다. API 서버의 부트스트랩 인증자가 이러한 시크릿을 읽는다. 만료된 토큰은 컨트롤러 관리자가 TokenCleaner 컨트롤러로 제거한다. 토큰은 BootstrapSigner 컨트롤러를 통해 "discovery" 프로세스에 사용되는 특정 컨피그맵(ConfigMap)에 대한 서명을 만드는 데도 사용된다. 토큰 형식 ----- 부트스트랩 토큰은 `abcdef.0123456789abcdef` 형식을 취한다. 더 공식적으로는 정규식 `[a-z0-9]{6}\.[a-z0-9]{16}` 와 일치해야 한다. 토큰의 첫 번째 부분은 "Token ID" 이며 공개 정보로 간주된다. 인증에 사용하는 시크릿의 일부를 노출하지 않고 토큰을 참조할 때 사용한다. 두 번째 부분은 "Token Secret"이며 신뢰할 수 있는 당사자와만 공유해야 한다. 부트스트랩 토큰 인증 활성화 --------------- API 서버에서 다음 플래그를 사용하여 부트스트랩 토큰 인증자를 활성화할 수 있다. --enable-bootstrap-token-auth 활성화되면 부트스트랩 토큰을 API 서버에 대한 요청을 인증하기 위한 전달자 토큰 자격 증명으로 사용할 수 있다. Authorization: Bearer 07401b.f395accd246ae52d 토큰은 사용자 이름 `system:bootstrap:` 로 인증되며 `system:bootstrappers` 그룹의 구성원이다. 토큰의 시크릿에 추가 그룹을 지정할 수 있다. 만료된 토큰은 컨트롤러 관리자에서 `tokencleaner` 컨트롤러를 활성화하여 자동으로 삭제할 수 있다. --controllers=*,tokencleaner 부트스트랩 토큰 시크릿 형식 --------------- 각각의 유효한 토큰은 `kube-system` 네임스페이스의 시크릿에 의해 지원된다. 전체 디자인 문서는 [여기](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md) 에서 찾을 수 있다. 시크릿은 다음과 같다. apiVersion: v1 kind: Secret metadata: # Name MUST be of form "bootstrap-token-" name: bootstrap-token-07401b namespace: kube-system # Type MUST be 'bootstrap.kubernetes.io/token' type: bootstrap.kubernetes.io/token stringData: # Human readable description. Optional. description: "The default bootstrap token generated by 'kubeadm init'." # Token ID and secret. Required. token-id: 07401b token-secret: f395accd246ae52d # Expiration. Optional. expiration: 2017-03-10T03:22:11Z # Allowed usages. usage-bootstrap-authentication: "true" usage-bootstrap-signing: "true" # Extra groups to authenticate the token as. Must start with "system:bootstrappers:" auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress 시크릿 유형은 `bootstrap.kubernetes.io/token` 이어야 하고 이름은 `bootstrap-token-`여야 한다. 반드시 `kube-system` 네임스페이스에도 존재해야 한다. `usage-bootstrap-*` 멤버는 이 시크릿의 용도를 나타낸다. 활성화하려면 값을 `true` 로 설정해야 한다. * `usage-bootstrap-authentication` 은 토큰을 API 서버에 베어러 토큰으로 인증하는데 사용할 수 있음을 나타낸다. * `usage-bootstrap-signing` 은 토큰을 사용하여 아래에 설명된 `cluster-info` 컨피그맵에 서명할 수 있음을 나타낸다. `expiration` 필드는 토큰의 만료를 제어한다. 만료된 토큰은 인증에 사용될 때 거부되고 컨피그맵서명 중에 무시된다. 만료된 값은 RFC3339를 사용하여 절대 UTC 시간으로 인코딩된다. 만료된 토큰을 자동으로 삭제하려면 `tokencleaner` 컨트롤러를 활성화한다. kubeadm을 사용한 토큰 관리 ------------------ `kubeadm` 툴을 사용하여 실행중인 클러스터에서 토큰을 관리할 수 있다. 자세한 내용은 [kubeadm token docs](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token/) 에서 찾을 수 있다. 컨피그맵 서명 ------- 토큰은 인증 외에도 컨피그맵에 서명하는데 사용할 수 있다. 이것은 클라이언트가 API 서버를 신뢰하기 전에 클러스터 부트스트랩 프로세스의 초기에 사용된다. 서명된 컨피그맵은 공유 토큰으로 인증할 수 있다. 컨트롤러 관리자에서 `bootstrapsigner` 컨트롤러를 활성화하여 컨피그맵서명을 활성화 한다. --controllers=*,bootstrapsigner 서명된 컨피그맵은 `kube-public` 네임스페이스에 있는 `cluster-info` 이다. 일반적인 흐름은 클라이언트가 인증되지 않고 TLS 오류를 무시하는 동안 컨피그맵을 읽는 것이다. 그런 다음 컨피그맵에 포함된 서명을 확인하여 컨피그맵의 페이로드를 확인한다. 컨피그맵은 다음과 같을 수 있다. apiVersion: v1 kind: ConfigMap metadata: name: cluster-info namespace: kube-public data: jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U kubeconfig: | apiVersion: v1 clusters: - cluster: certificate-authority-data: server: https://10.138.0.2:6443 name: "" contexts: [] current-context: "" kind: Config preferences: {} users: [] 컨피그맵의 `kubeconfig` 멤버는 클러스터 정보만 입력된 구성 파일이다. 여기서 전달되는 핵심은 `certificate-authority-data` 이다. 이는 향후 확대될 수 있다. 서명은 "detached" 모드를 사용하는 JWS 서명이다. 서명을 검증하려면 사용자는 JWS 규칙(뒤로 오는 `=` 를 삭제하는 동안 인코딩된 base64)에 따라 `kubeconfig` 페이로드를 인코딩해야 한다. 그런 다음 인코딩된 페이로드는 두 개의 점 사이에 삽입하여 전체 JWS를 형성하는 데 사용된다. 전체 토큰(예:`07401b.f395accd246ae52d`)을 공유 시크릿으로 사용하여 `HS256` 방식(HMAC-SHA256)을 사용함으로 JWS를 확인할 수 있다. 사용자는 _반드시_ HS256이 사용되고 있는지 확인해야 한다. #### 경고: 부트스트래핑 토큰을 가진 모든 당사자는 해당 토큰에 대한 유효한 서명을 만들 수 있다. 컨피그맵 서명을 사용할 때 많은 클라이언트와 동일한 토큰을 공유하는 것은 권장되지 않는다. 손상된 클라이언트는 잠재적으로 서명에 의존하여 TLS 트러스트를 부트스트랩하는 다른 클라이언트를 대신할 수 있기 때문이다. 자세한 내용은 [kubeadm implementation details](https://kubernetes.io/docs/reference/setup-tools/kubeadm/implementation-details/) 섹션을 참조하면 된다. 2 - 서비스 어카운트 관리하기 ================= _서비스어카운트(ServiceAccount)_ 는 파드에서 실행되는 프로세스에 대한 식별자를 제공한다. 파드 내부의 프로세스는, 자신에게 부여된 서비스 어카운트의 식별자를 사용하여 클러스터의 API 서버에 인증할 수 있다. 서비스 어카운트에 대한 소개는, [서비스 어카운트 구성하기](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 를 참고한다. 이 가이드는 서비스어카운트와 관련된 개념 중 일부를 설명하며, 서비스어카운트를 나타내는 토큰을 얻거나 취소하는 방법에 대해서도 설명한다. 시작하기 전에 ------- 쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, [minikube](https://kubernetes.io/ko/docs/tasks/tools/#minikube) 를 사용해서 생성하거나 다음 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다. * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) 아래 내용들을 따라하기 위해서는 `examplens`라는 네임스페이스가 필요하다. 없을 경우 다음과 같이 네임스페이스를 생성한다. kubectl create namespace examplens 사용자 어카운트와 서비스 어카운트 비교 --------------------- 쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을 구분한다. * 사용자 어카운트는 사람을 위한 것이지만, 서비스 어카운트는 쿠버네티스의 경우 파드의 일부 컨테이너에서 실행되는 애플리케이션 프로세스를 위한 것이다. * 사용자 어카운트는 전역적으로 고려되기 때문에, 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 어떤 네임스페이스를 확인하든지 간에, 특정 사용자명은 해당 유저만을 나타낸다. 쿠버네티스에서 서비스 어카운트는 네임스페이스별로 구분된다. 두 개의 서로 다른 네임스페이스는 동일한 이름의 서비스어카운트를 각자 가질 수 있다. * 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며, 여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다. 반면에 서비스 어카운트를 생성하는 경우는, 클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록 보다 가볍게 만들어졌다. 실 사용자를 온보딩하는 단계와 서비스어카운트를 생성하는 단계를 분리하는 것은, 워크로드가 최소 권한 원칙을 따르기 쉬워지게 한다. * 사람과 서비스 어카운트에 대한 감사 고려 사항은 다를 수 있다. 이 둘을 따로 관리함으로써 더욱 쉽게 감사를 수행할 수 있다. * 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다. 서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에 이러한 설정은 이식성이 좋다. 바인딩된 서비스 어카운트 토큰 볼륨 메커니즘 ------------------------ 기능 상태: `Kubernetes v1.22 [stable]` 기본적으로, 쿠버네티스 컨트롤 플레인(구체적으로 말하자면 [서비스어카운트 어드미션 컨트롤러](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#service-account-admission-controller) )은 [프로젝티드 볼륨](https://kubernetes.io/ko/docs/concepts/storage/projected-volumes/) 을 파드에 추가하며, 이 볼륨은 쿠버네티스 API에 접근할 수 있는 토큰을 포함한다. 다음은 실행된 파드에서 해당 토큰이 어떻게 보이는지에 대한 예시이다. ... - name: kube-api-access- projected: sources: - serviceAccountToken: path: token # 애플리케이션이 알고 있는 경로와 일치해야 한다. - configMap: items: - key: ca.crt path: ca.crt name: kube-root-ca.crt - downwardAPI: items: - fieldRef: apiVersion: v1 fieldPath: metadata.namespace path: namespace 위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다. 이 경우, 각 정보는 해당 볼륨 내의 단일 경로를 나타내기도 한다. 세 가지 정보는 다음과 같다. 1. `서비스어카운트토큰(serviceAccountToken)` 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다. kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다. 이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다). 이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다. 이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다. 해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 토큰과는 달리 만료가 되지 않는 것이었다. 2. `컨피그맵(ConfigMap)` 정보는 인증 및 인가에 관한 번들을 포함한다. 파드들은 이러한 인증서를 사용하여 해당 클러스터의 kube-apiserver(미들박스나 실수로 잘못 구성된 피어가 아닌) 에 대한 연결을 확인할 수 있다. 3. `DownwardAPI` 정보는 파드가 포함된 네임스페이스를 검색하고, 해당 정보를 파드 내부에서 실행 중인 애플리케이션에서 사용할 수 있도록 한다. 이러한 볼륨을 마운트한 컨테이너는 위의 정보들에 접근할 수 있다. #### 참고: TokenRequest를 통해 발급된 토큰을 무효화하는 메커니즘은 없다. 만약 파드에 바인딩된 서비스 어카운트 토큰을 더 이상 신뢰하지 못하게 된다면, 파드를 삭제한다. 파드를 삭제하면 바인딩 되어있던 서비스 어카운트 토큰 역시 만료된다. 서비스어카운트에 대해 수동으로 시크릿 관리하기 ------------------------- 쿠버네티스 v1.22 이전의 버전들은 쿠버네티스 API에 접근하기 위한 자격 증명들을 자동으로 생성했다. 이러한 옛 메커니즘들은, 실행 중인 파드에 마운트 될 수 있는 토큰 시크릿을 만드는 것에 기반을 두었다. 쿠버네티스 v1.35을 포함한 최신 버전에서는, API 자격 증명들은 [TokenRequest](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API를 사용하여 [직접 얻을 수 있으며](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#bound-service-account-token-volume) , 프로젝티드 볼륨을 사용하여 파드에 마운트할 수 있다. 이 방법으로 취득한 토큰은 시간 제한이 있으며, 마운트 되었던 파드가 삭제되는 경우 자동으로 만료된다. 예를 들어 평생 만료되지 않는 토큰이 필요한 경우, 서비스 어카운트 토큰을 유지하기 위한 시크릿을 [수동으로 생성](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount) 할 수 있다. 한 번 시크릿을 수동으로 생성하여 서비스어카운트에 연결했다면, 쿠버네티스 컨트롤 플레인은 자동으로 해당 시크릿에 토큰을 채운다. #### 참고: 장기간 사용할 서비스어카운트 토큰을 수동으로 생성하는 메커니즘이 존재하지만, 단기간 동안에만 사용할 토큰을 취득하는 경우 [TokenRequest](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 를 사용하는 것이 권장된다. 컨트롤 플레인의 세부 사항들 --------------- ### 토큰 컨트롤러 토큰 컨트롤러는 `kube-controller-manager` 의 일부로써 실행되며, 비동기적으로 동작한다. * 서비스어카운트에 대한 삭제를 감시하고, 해당하는 모든 서비스어카운트 토큰 시크릿을 같이 삭제한다. * 서비스어카운트 토큰 시크릿에 대한 추가를 감시하고, 참조된 서비스어카운트가 존재하는지 확인하며, 필요한 경우 시크릿에 토큰을 추가한다. * 시크릿에 대한 삭제를 감시하고, 필요한 경우 해당 서비스어카운트에서 참조 중인 항목들을 제거한다. 서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야 한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다. 마찬가지로 `--service-account-key-file` 플래그를 사용하여 해당 공개키를 `kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다. ### 서비스어카운트 어드미션 컨트롤러 파드 수정은 [어드미션 컨트롤러](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 라는 플러그인을 통해 구현된다. 이것은 API 서버의 일부이며, 파드가 생성될 때 파드를 수정하기 위해 동기적으로 동작한다. 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우, 어드미션 컨트롤러는 파드의 생성 시점에 다음 작업들을 수행한다. 1. 파드에 `.spce.serviceAccountName` 항목이 지정되지 않았다면, 어드미션 컨트롤러는 실행하려는 파드의 서비스어카운트 이름을 `default`로 설정한다. 2. 어드미션 컨트롤러는 실행되는 파드가 참조하는 서비스어카운트가 존재하는지 확인한다. 만약 해당하는 이름의 서비스어카운트가 존재하지 않는 경우, 어드미션 컨트롤러는 파드를 실행시키지 않는다. 이는 `default` 서비스어카운트에 대해서도 동일하게 적용된다. 3. 서비스어카운트의 `automountServiceAccountToken` 또는 파드의 `automountServiceAccountToken` 중 어느 것도 `false` 로 설정되어 있지 않다면, * 어드미션 컨트롤러는 실행하려는 파드에 API에 접근할 수 있는 토큰을 포함하는 [볼륨](https://kubernetes.io/ko/docs/concepts/storage/volumes/ "데이터를 포함하고 있는 디렉터리이며, 파드의 컨테이너에서 접근 가능하다.") 을 추가한다. * 어드미션 컨트롤러는 파드의 각 컨테이너에 `volumeMount`를 추가한다. 이미 `/var/run/secrets/kubernetes.io/serviceaccount` 경로에 볼륨이 마운트 되어있는 컨테이너에 대해서는 추가하지 않는다. 리눅스 컨테이너의 경우, 해당 볼륨은 `/var/run/secrets/kubernetes.io/serviceaccount` 위치에 마운트되며, 윈도우 노드 역시 동일한 경로에 마운트된다. 4. 파드의 spec에 `imagePullSecrets` 이 없는 경우, 어드미션 컨트롤러는 `ServiceAccount`의 `imagePullSecrets`을 복사하여 추가된다. ### TokenRequest API 기능 상태: `Kubernetes v1.22 [stable]` 서비스어카운트의 하위 리소스인 [TokenRequest](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 를 사용하여 일정 시간 동안 해당 서비스어카운트에서 사용할 수 있는 토큰을 가져올 수 있다. 컨테이너 내에서 사용하기 위한 API 토큰을 얻기 위해 이 요청을 직접 호출할 필요는 없는데, kubelet이 _프로젝티드 볼륨_ 을 사용하여 이를 설정하기 때문이다. `kubectl`에서 TokenRequest API를 사용하고 싶다면, [서비스어카운트를 위한 API 토큰을 수동으로 생성하기](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount) 를 확인한다. 쿠버네티스 컨트롤 플레인(구체적으로는 서비스어카운트 어드미션 컨트롤러)은 파드에 프로젝티드 볼륨을 추가하고, kubelet은 컨테이너가 올바른 서비스어카운트로 인증할 수 있도록 해당 볼륨이 토큰을 포함하는고 있는지 확인한다. (이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다. 해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 만료가 되지 않는 것이었다.) 아래는 실행 중인 파드에서 어떻게 보이는지에 대한 예시이다. ... - name: kube-api-access- projected: defaultMode: 420 # 8진수 0644에 대한 10진수 값 sources: - serviceAccountToken: expirationSeconds: 3607 path: token - configMap: items: - key: ca.crt path: ca.crt name: kube-root-ca.crt - downwardAPI: items: - fieldRef: apiVersion: v1 fieldPath: metadata.namespace path: namespace 위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다. 1. `서비스어카운트토큰(serviceAccountToken)` 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다. kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다. 이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다). 이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다. 2. `컨피그맵(ConfigMap)` 정보는 인증 및 인가에 관한 번들을 포함한다. 파드들은 이러한 인증서를 사용하여 해당 클러스터의 kube-apiserver(미들박스나 실수로 잘못 구성된 피어가 아닌) 에 대한 연결을 확인할 수 있다. 3. `DownwardAPI` 정보는 파드가 포함된 네임스페이스를 검색하고, 해당 정보를 파드 내부에서 실행 중인 애플리케이션에서 사용할 수 있도록 한다. 이러한 볼륨을 마운트한 컨테이너는 위의 정보들에 접근할 수 있다. 추가적인 API 토큰 생성하기 ---------------- #### 주의: [토큰 요청](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#tokenrequest-api) 메커니즘이 적합하지 않은 경우에만 수명이 긴 API 토큰을 생성한다. 토큰 요청 메커니즘은 시간 제한이 있는 토큰만을 제공하며, 토큰이 만료되기 때문에 보안에 대한 위험이 적다. 서비스어카운트를 위한 만료되지 않는 API 토큰을 생성하려면, 해당 서비스어카운트를 참조하는 어노테이션을 갖는 `kubernetes.io/service-account-token` 타입의 시크릿을 생성한다. 그러면 컨트롤 플레인은 장기적으로 사용 가능한 토큰을 발급하여 시크릿을 갱신할 것이다. 아래는 시크릿을 위한 예제 매니페스트이다. [`secret/serviceaccount/mysecretname.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/ko/examples/secret/serviceaccount/mysecretname.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy secret/serviceaccount/mysecretname.yaml to clipboard") apiVersion: v1 kind: Secret type: kubernetes.io/service-account-token metadata: name: mysecretname annotations: kubernetes.io/service-account.name: myserviceaccount 이 예제에 기반한 시크릿을 생성하려면, 아래의 명령어를 실행한다. kubectl -n examplens create -f https://k8s.io/examples/secret/serviceaccount/mysecretname.yaml 시크릿에 대한 자세한 사항을 확인하려면, 아래의 명령어를 실행한다. kubectl -n examplens describe secret mysecretname 결과는 다음과 같다. Name: mysecretname Namespace: examplens Labels: Annotations: kubernetes.io/service-account.name=myserviceaccount kubernetes.io/service-account.uid=8a85c4c4-8483-11e9-bc42-526af7764f64 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1362 bytes namespace: 9 bytes token: ... 만약 `examplens` 네임스페이스에 새로운 파드를 실행한다면, 해당 파드는 방금 생성한 `myserviceaccount` 서비스 어카운트 토큰 시크릿을 사용할 수 있다. 서비스어카운트 토큰 시크릿 삭제/무효화 --------------------- 만약 제거하려는 토큰을 포함하는 시크릿의 이름을 알고 있다면, 아래 명령어를 실행한다. kubectl delete secret name-of-secret 그게 아니라면, 먼저 시크릿을 확인한다. # 아래 명령어는 'examplens' 네임스페이스가 존재한다고 가정한다. kubectl -n examplens get serviceaccount/example-automated-thing -o yaml 결과는 다음과 같다. apiVersion: v1 kind: ServiceAccount metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}} creationTimestamp: "2019-07-21T07:07:07Z" name: example-automated-thing namespace: examplens resourceVersion: "777" selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing uid: f23fd170-66f2-4697-b049-e1e266b7f835 secrets: - name: example-automated-thing-token-zyxwv 이제 시크릿의 이름을 알았으니, 삭제한다. kubectl -n examplens delete secret/example-automated-thing-token-zyxwv 컨트롤 플레인은 서비스어카운트에 시크릿이 누락되었음을 감지하고, 새로운 것으로 대체한다. kubectl -n examplens get serviceaccount/example-automated-thing -o yaml apiVersion: v1 kind: ServiceAccount metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}} creationTimestamp: "2019-07-21T07:07:07Z" name: example-automated-thing namespace: examplens resourceVersion: "1026" selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing uid: f23fd170-66f2-4697-b049-e1e266b7f835 secrets: - name: example-automated-thing-token-4rdrh 정리하기 ---- 예제를 위해 `examplens` 네임스페이스를 생성했었다면, 아래의 명령어로 제거할 수 있다. kubectl delete namespace examplens 컨트롤 플레인의 세부 사항들 --------------- ### 서비스어카운트 컨트롤러 서비스어카운트 컨트롤러는 네임스페이스 내의 서비스어카운트들을 관리하며, 활성화된 모든 네임스페이스에 "default"라는 이름의 서비스어카운트가 존재하도록 한다. ### 토큰 컨트롤러 토큰 컨트롤러는 `kube-controller-manager`의 일부로써 실행되며, 비동기적으로 동작한다. * 서비스어카운트에 대한 생성을 감시하고, 해당 서비스어카운트 토큰 시크릿을 생성하여 API에 대한 접근을 허용한다. * 서비스어카운트에 대한 삭제를 감시하고, 해당하는 모든 서비스어카운트 토큰 시크릿을 같이 삭제한다. * 서비스어카운트 토큰 시크릿에 대한 추가를 감시하고, 참조된 서비스어카운트가 존재하는지 확인하며, 필요한 경우 시크릿에 토큰을 추가한다. * 시크릿에 대한 삭제를 감시하고, 필요한 경우 해당 서비스어카운트에서 참조 중인 항목들을 제거한다. 서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야 한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다. 마찬가지로 `--service-account-key-file` 플래그를 사용하여 해당 공개키를 `kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다. 다음 내용 ----- * 자세한 내용은 [프로젝티드 볼륨](https://kubernetes.io/ko/docs/concepts/storage/projected-volumes/) 을 확인한다. 3 - 인가 개요 ========= 지원되는 인가 모듈을 사용하여 정책을 만드는 방법을 포함한 쿠버네티스 인가에 대해 자세히 알아보자. 쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다. 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](https://kubernetes.io/ko/docs/concepts/security/controlling-access/) 를 참고한다. 쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다. 이는 쿠버네티스 인가가 쿠버네티스 API 이외에 다른 API를 처리할 수 있는 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 연동된다는 것을 의미한다. 요청 허용 또는 거부 결정 -------------- 쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다. 모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다. 계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다. 이는 기본적으로 승인이 거부된다는 것을 의미한다. (쿠버네티스는 API 서버를 사용하지만, 특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은 어드미션 컨트롤러에 의해 처리된다.) 여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다. 어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다. 모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다. 요청 거부는 HTTP 상태 코드 403을 반환한다. 요청 속성 검토 -------- 쿠버네티스는 다음 API 요청 속성만 검토한다. * **user** - 인증 중에 제공된 `user` 문자열. * **group** - 인증된 사용자가 속한 그룹 이름 목록. * **extra** - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵. * **API** - 요청이 API 리소스에 대한 것인지 여부. * **Request path** - `/api` 또는 `/healthz`와 같이 다양한 리소스가 아닌 엔드포인트의 경로. * **API request verb** - `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, `deletecollection`과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 [요청 동사 결정](https://kubernetes.io/ko/docs/reference/access-authn-authz/authorization/#%EC%9A%94%EC%B2%AD-%EB%8F%99%EC%82%AC-%EA%B2%B0%EC%A0%95) 을 참고한다. * **HTTP request verb** - `get`, `post`, `put`, `delete`처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다. * **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다. * **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당). * **Namespace** - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당) * **API group** - 접근 중인 [API 그룹](https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/#api-%ea%b7%b8%eb%a3%b9%ea%b3%bc-%eb%b2%84%ec%a0%84-%ea%b7%9c%ec%b9%99 "쿠버네티스 API의 연관된 경로들의 집합.") (리소스 요청에만 해당). 빈 문자열은 _핵심(core)_ [API 그룹](https://kubernetes.io/ko/docs/reference/using-api/#api-%EA%B7%B8%EB%A3%B9) 을 지정한다. 요청 동사 결정 -------- **리소스가 아닌 요청** `/api/v1/...` 또는 `/apis///...` 이외에 다른 엔드포인트에 대한 요청은 "리소스가 아닌 요청"으로 간주되며, 요청의 소문자 HTTP 메서드를 동사로 사용한다. 예를 들어, `/api` 또는 `/healthz`와 같은 엔드포인트에 대한 `GET` 요청은 `get`을 동사로 사용할 것이다. **리소스 요청** 리소스 API 엔드포인트에 대한 요청 동사를 결정하려면 사용된 HTTP 동사와 해당 요청이 개별 리소스 또는 리소스 모음에 적용되는지 여부를 검토한다. | HTTP 동사 | 요청 동사 | | --- | --- | | POST | create | | GET, HEAD | get(개별 리소스), list(전체 오브젝트 내용을 포함한 리소스 모음), watch(개별 리소스 또는 리소스 모음을 주시) | | PUT | update | | PATCH | patch | | DELETE | delete(개별 리소스), deletecollection(리소스 모음) | #### 주의: `get`, `list`, `watch` 요청은 모두 리소스의 전체 세부 내용을 반환할 수 있다. 반환된 데이터의 관점으론 모두 동일하다. 예를 들어 `secrets`에 대해 `list` 요청은 반환된 리소스의 `data` 속성을 여전히 드러낼 것이다. 쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면, * [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) * `rbac.authorization.k8s.io` API 그룹의 `roles` 및 `clusterroles` 리소스에 대한 `bind` 동사. * [인증](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) * 핵심 API 그룹의 `users`, `groups`, `serviceaccounts`와 `authentication.k8s.io` API 그룹의 `userextras` 동사. 인가 모드 ----- 쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다. * **Node** - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 [Node 인가](https://kubernetes.io/docs/reference/access-authn-authz/node/) 를 참조한다. * **ABAC** - 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 [ABAC 모드](https://kubernetes.io/docs/reference/access-authn-authz/abac/) 를 참조한다. * **RBAC** - 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 [RBAC 모드](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 를 참조한다. * 지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 `rbac.authorization.k8s.io` API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다. * RBAC을 활성화하려면 `--authorization-mode=RBAC`로 API 서버를 시작한다. * **Webhook** - WebHook은 HTTP 콜백이다(어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림). WebHook을 구현하는 웹 애플리케이션은 특정한 일이 발생할 때 URL에 메시지를 POST 할 것이다. Webhook 모드 사용에 대한 자세한 내용은 [Webhook 모드](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) 를 참조한다. #### API 접근 확인 `kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 `auth can-i` 하위 명령어를 제공한다. 이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 `SelfSubjectAccessReview` API를 사용하며, 사용되는 인가 모드에 관계없이 작동한다. kubectl auth can-i create deployments --namespace dev 다음과 유사하게 출력된다. yes kubectl auth can-i create deployments --namespace prod 다음과 유사하게 출력된다. no 관리자는 이를 [사용자 가장(impersonation)](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) 과 병행하여 다른 사용자가 수행할 수 있는 작업을 결정할 수 있다. kubectl auth can-i list secrets --namespace dev --as dave 다음과 유사하게 출력된다. no 유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가 `target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다. kubectl auth can-i list pods \ --namespace target \ --as system:serviceaccount:dev:dev-sa 다음과 유사하게 출력된다. yes `SelfSubjectAccessReview`는 `authorization.k8s.io` API 그룹의 일부로서 API 서버 인가를 외부 서비스에 노출시킨다. 이 그룹의 기타 리소스에는 다음이 포함된다. * `SubjectAccessReview` - 현재 사용자뿐만 아니라 모든 사용자에 대한 접근 검토. API 서버에 인가 결정을 위임하는 데 유용하다. 예를 들어, kubelet 및 확장(extension) API 서버는 자신의 API에 대한 사용자 접근을 결정하기 위해 해당 리소스를 사용한다. * `LocalSubjectAccessReview` - `SubjectAccessReview`와 비슷하지만 특정 네임스페이스로 제한된다. * `SelfSubjectRulesReview` - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다. 이러한 API는 반환된 오브젝트의 응답 "status" 필드가 쿼리의 결과인 일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다. kubectl create -f - -o yaml << EOF apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview spec: resourceAttributes: group: apps resource: deployments verb: create namespace: dev EOF 생성된 `SelfSubjectAccessReview` 는 다음과 같다. apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview metadata: creationTimestamp: null spec: resourceAttributes: group: apps resource: deployments namespace: dev verb: create status: allowed: true denied: false 인가 모듈에 플래그 사용 ------------- 정책에 포함된 인가 모듈을 나타내기 위해 정책에 플래그를 포함시켜야 한다. 다음 플래그를 사용할 수 있다. * `--authorization-mode=ABAC` 속성 기반 접근 제어(ABAC) 모드를 사용하면 로컬 파일을 사용하여 정책을 구성할 수 있다. * `--authorization-mode=RBAC` 역할 기반 접근 제어(RBAC) 모드를 사용하면 쿠버네티스 API를 사용하여 정책을 만들고 저장할 수 있다. * `--authorization-mode=Webhook` WebHook은 원격 REST 엔드포인트를 사용하여 인가를 관리할 수 있는 HTTP 콜백 모드다. * `--authorization-mode=Node` 노드 인가는 kubelet이 생성한 API 요청을 특별히 인가시키는 특수 목적 인가 모드다. * `--authorization-mode=AlwaysDeny` 이 플래그는 모든 요청을 차단한다. 이 플래그는 테스트에만 사용한다. * `--authorization-mode=AlwaysAllow` 이 플래그는 모든 요청을 허용한다. API 요청에 대한 인가가 필요하지 않은 경우에만 이 플래그를 사용한다. 하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에 우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다. 워크로드 생성 및 수정을 통한 권한 확대 ---------------------- 네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](https://kubernetes.io/ko/docs/concepts/architecture/controller/) 를 통해 생성/수정할 수 있는 사용자는 해당 네임스페이스 안에서 자신의 권한을 확대할 수 있다. #### 주의: 시스템 관리자는 파드 생성/수정에 대한 접근 권한을 부여할 때 주의한다. [권한 확대 경로](https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/#escalation-paths) 에서 접근 권한이 잘못 사용되었을 때의 상세사항을 확인할 수 있다. ### 권한 확대 경로 * 네임스페이스 내의 임의의 시크릿을 마운트 * 다른 워크로드를 위한 시크릿으로의 접근에 사용될 수 있음 * 더 권한이 많은 서비스 어카운트의 서비스 어카운트 토큰 획득에 사용될 수 있음 * 네임스페이스 내의 임의의 서비스 어카운트를 사용 * 다른 워크로드인것처럼 사칭하여 쿠버네티스 API 액션을 수행할 수 있음 * 서비스 어카운트가 갖고 있는 '권한이 필요한 액션'을 수행할 수 있음 * 네임스페이스 내의 다른 워크로드를 위한 컨피그맵을 마운트 * 다른 워크로드를 위한 정보(예: DB 호스트 이름) 획득에 사용될 수 있음 * 네임스페이스 내의 다른 워크로드를 위한 볼륨을 마운트 * 다른 워크로드를 위한 정보의 획득 및 수정에 사용될 수 있음 #### 주의: 시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다. 이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다. RBAC 제어에 대해 결정할 때 이와 같은 사항을 고려해야 한다. 다음 내용 ----- * 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](https://kubernetes.io/ko/docs/concepts/security/controlling-access/) 에서 **인증** 을 참조한다. * 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 를 참조한다. 4 - Kubelet 인증/인가 ================= 개요 -- kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 제공하는 API를 노출하며, 노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다. 이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다. Kubelet 인증 ---------- 기본적으로, 다른 구성의 인증 방법에 의해 거부되지 않은 kubelet의 HTTPS 엔드포인트에 대한 요청은 익명의 요청으로 처리되며, `system:anonymous`의 사용자 이름과 `system:unauthenticated` 의 그룹이 부여된다. 익명의 접근을 비활성화하고 인증되지 않은 요청에 `401 Unauthorized` 응답을 보내려면 아래를 참고한다. * `--anonymous-auth=false` 플래그로 kubelet을 시작 kubelet의 HTTPS 엔드포인트에 대한 X509 클라이언트 인증서 인증을 활성화하려면 아래를 참고한다. * `--client-ca-file` 플래그로 kubelet을 시작하면 클라이언트 인증서를 확인할 수 있는 CA 번들을 제공 * `--kubelet-client-certificate` 및 `--kubelet-client-key` 플래그로 apiserver를 시작 * 자세한 내용은 [apiserver 인증 문서](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) 를 참고 API bearer 토큰(서비스 계정 토큰 포함)을 kubelet의 HTTPS 엔드포인트 인증에 사용하려면 아래를 참고한다. * API 서버에서 `authentication.k8s.io/v1beta1` API 그룹이 사용 가능한지 확인 * `--authentication-token-webhook` 및 `--kubeconfig` 플래그로 kubelet을 시작 * kubelet은 구성된 API 서버의 `TokenReview` API를 호출하여 bearer 토큰에서 사용자 정보를 결정 Kubelet 승인 ---------- 성공적으로 인증된 모든 요청(익명 요청 포함)이 승인된다. 기본 인가 모드는 모든 요청을 허용하는 `AlwaysAllow` 이다. kubelet API에 대한 접근을 세분화하는 데는 다양한 이유가 있다. * 익명 인증을 사용할 수 있지만, 익명 사용자의 kubelet API 호출 기능은 제한되어야 함 * bearer 토큰 인증을 사용할 수 있지만, 임의의 API 사용자(API 계정)의 kubelet API 호출 기능은 제한되어야 함 * 클라이언트 인증을 사용할 수 있지만, 구성된 CA에서 서명한 일부 클라이언트 인증서만 kubelet API를 사용하도록 허용해야 함 kubelet API에 대한 접근을 세분화하려면 API 서버에 권한을 위임한다. * `authorization.k8s.io/v1beta1` API 그룹이 API 서버에서 사용 가능한지 확인 * `--authorization-mode=Webhook` 및 `--kubeconfig` 플래그로 kubelet을 시작 * kubelet은 구성된 API 서버의 `SubjectAccessReview` API를 호출하여 각각의 요청이 승인되었는지 여부를 확인 kubelet은 API 요청을 apiserver와 동일한 [요청 속성](https://kubernetes.io/ko/docs/reference/access-authn-authz/authorization/#%EC%9A%94%EC%B2%AD-%EC%86%8D%EC%84%B1-%EA%B2%80%ED%86%A0) 접근 방식을 사용하여 승인한다. 동사는 들어오는 요청의 HTTP 동사로부터 결정된다. | HTTP 동사 | 요청 동사 | | --- | --- | | POST | create | | GET, HEAD | get | | PUT | update | | PATCH | patch | | DELETE | delete | 리소스 및 하위 리소스는 들어오는 요청의 경로로부터 결정된다. | Kubelet API | 리소스 | 하위 리소스 | | --- | --- | --- | | /stats/\* | nodes | stats | | /metrics/\* | nodes | metrics | | /logs/\* | nodes | log | | /spec/\* | nodes | spec | | _all others_ | nodes | proxy | 네임스페이스와 API 그룹 속성은 항상 빈 문자열이며, 리소스 이름은 항상 kubelet의 `Node` API 오브젝트 이름이다. 이 모드로 실행할 때, `--kubelet-client-certificate` 및 `--kubelet-client-key` 플래그로 식별된 사용자에게 다음 속성에 대한 권한이 있는지 확인한다. * verb=\*, resource=nodes, subresource=proxy * verb=\*, resource=nodes, subresource=stats * verb=\*, resource=nodes, subresource=log * verb=\*, resource=nodes, subresource=spec * verb=\*, resource=nodes, subresource=metrics --- # SIG Docsへの参加 | Kubernetes これは、このセクションの複数ページの印刷可能なビューです。 [印刷するには、ここをクリックしてください](https://kubernetes.io/ja/docs/contribute/participate/_print/#) . [このページの通常のビューに戻る](https://kubernetes.io/ja/docs/contribute/participate/) . SIG Docsへの参加 ============ * 1: [ロールと責任](https://kubernetes.io/ja/docs/contribute/participate/_print/#pg-76656ea25ba7e6404601838389262482) SIG Docsは、Kubernetesプロジェクト内の [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) の1つであり、 Kubernetes全体のドキュメントの作成、更新、および保守に重点を置いています。 SIGの詳細については、[SIG DocsのGithubリポジトリ](https://github.com/kubernetes/community/blob/master/sig-list.md) を参照してください。 SIG Docsは、すべての寄稿者からのコンテンツとレビューを歓迎します。 誰でもPull Request(PR)を開くことができ、コンテンツに関するissueを提出したり、進行中のPull Requestにコメントしたりできます。 あなたは、[member](https://kubernetes.io/ja/docs/contribute/participate/roles-and-responsibilities/#members) や、 [reviewer](https://kubernetes.io/ja/docs/contribute/participate/roles-and-responsibilities/#reviewers) 、 [approver](https://kubernetes.io/ja/docs/contribute/participate/roles-and-responsibilities/#approvers) になることもできます。 これらの役割にはより多くのアクセスが必要であり、変更を承認およびコミットするための特定の責任が伴います。 Kubernetesコミュニティ内でメンバーシップがどのように機能するかについての詳細は、 [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) をご覧ください。 このドキュメントの残りの部分では、kubernetesの中で最も広く公開されている Kubernetesのウェブサイトとドキュメントの管理を担当しているSIG Docsの中で、これらの役割がどのように機能するのかを概説します。 SIG Docs chairperson -------------------- SIG Docsを含む各SIGは、議長として機能する1人以上のSIGメンバーを選択します。 これらは、SIGDocsとKubernetes organizationの他の部分との連絡先です。 それらには、Kubernetesプロジェクト全体の構造と、SIG Docsがその中でどのように機能するかについての広範な知識が必要です。 現在のchairpersonのリストについては、 [Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) を参照してください。 SIG Docs teamsと自動化 ------------------ SIG Docsの自動化は、GitHub teamsとOWNERSファイルの2つの異なるメカニズムに依存しています。 ### GitHub teams GitHubには、二つのSIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) カテゴリがあります: * `@sig-docs-{language}-owners`は承認者かつリードです。 * `@sig-docs-{language}-reviews` はレビュアーです。 それぞれをGitHubコメントの`@name`で参照して、そのグループの全員とコミュニケーションできます。 ProwチームとGitHub teamsが完全に一致せずに重複する場合があります。 問題の割り当て、Pull Request、およびPR承認のサポートのために、自動化ではOWNERSファイルからの情報を使用します。 ### OWNERSファイルとfront-matter Kubernetesプロジェクトは、GitHubのissueとPull Requestに関連する自動化のためにprowと呼ばれる自動化ツールを使用します。 [Kubernetes Webサイトリポジトリ](https://github.com/kubernetes/website) は、2つの[prowプラグイン](https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins) を使用します： * blunderbuss * approve これらの2つのプラグインは`kubernetes.website`のGithubリポジトリのトップレベルにある [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) ファイルと、 [OWNERS\_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) ファイルを使用して、 リポジトリ内でのprowの動作を制御します。 OWNERSファイルには、SIG Docsのレビュー担当者および承認者であるユーザーのリストが含まれています。 OWNERSファイルはサブディレクトリに存在することもでき、そのサブディレクトリとその子孫のファイルのレビュー担当者または承認者として機能できるユーザーを上書きできます。 一般的なOWNERSファイルの詳細については、 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) を参照してください。 さらに、個々のMarkdownファイルは、個々のGitHubユーザー名またはGitHubグループを一覧表示することにより、そのfront-matterでレビュー担当者と承認者を一覧表示できます。 OWNERSファイルとMarkdownファイルのfront-matterの組み合わせにより、PRの技術的および編集上のレビューを誰に依頼するかについてPRの所有者が自動化システムから得るアドバイスが決まります。 マージの仕組み ------- Pull Requestがコンテンツの公開に使用されるブランチにマージされると、そのコンテンツは [https://kubernetes.io](https://kubernetes.io/) に公開されます。 公開されたコンテンツの品質を高くするために、Pull RequestのマージはSIG Docsの承認者に限定しています。仕組みは次のとおりです。 * Pull Requestに`lgtm`ラベルと`approve`ラベルの両方があり、`hold`ラベルがなく、すべてのテストに合格すると、Pull Requestは自動的にマージされます。 * Kubernetes organizationのメンバーとSIG Docsの承認者はコメントを追加して、特定のPull Requestが自動的にマージされないようにすることができます(`/hold`コメントを追加するか、`/lgtm`コメントを保留します)。 * Kubernetesメンバーは誰でも、`/lgtm`コメントを追加することで`lgtm`ラベルを追加できます。 * `/approve`コメントを追加してPull Requestをマージできるのは、SIG Docsの承認者だけです。一部の承認者は、[PR Wrangler](https://kubernetes.io/docs/contribute/participate/pr-wranglers/) や[SIG Docsのchairperson](https://kubernetes.io/ja/docs/contribute/participate/_print/#sig-docs-chairperson) など、追加の特定の役割も実行します。 次の項目 ---- Kubernetesドキュメントへの貢献の詳細については、以下を参照してください： * [Contributing new content](https://kubernetes.io/docs/contribute/new-content/overview/) * [Reviewing content](https://kubernetes.io/ja/docs/contribute/review/reviewing-prs/) * [ドキュメントスタイルの概要](https://kubernetes.io/ja/docs/contribute/style/) 1 - ロールと責任 ========== 誰もがKubernetesに貢献することができます。 SIG Docs へのコントリビューションが増えると、コミュニティ内で異なるレベルのメンバーシップに申請することができます。 これらの役割により、コミュニティ内でより多くの責任を担うことができます。 各役割にはより多くの時間とコミットメントが必要です。 役割は以下の通りです: * Anyone: Kubernetesドキュメントへの定期的なコントリビューター * Member: Issueの割り当てとトリアージができ、Pull Requestに対する非公式なレビューができる * Reviewer: ドキュメントのPull Requestのレビューをリードし、変更の品質を保証する * Approver: ドキュメントのレビューをリードし、変更をマージできる Anyone ------ GitHubのアカウントを持っている人なら誰もがKubernetesに貢献することができます。 SIG Docs はすべての新たなコントリビューターを歓迎します。 誰もが以下のことをできます: * [`kubernetes/website`](https://github.com/kubernetes/website) を含む、どの[Kubernetes](https://github.com/kubernetes/) リポジトリでもIssueを作成する * Pull Requestに非公式なフィードバックを提供する * ローカライゼーションに貢献する * [Slack](https://slack.k8s.io/) や[SIG Docsのメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) で改善の提案をする [CLA に署名](https://github.com/kubernetes/community/blob/master/CLA.md) した後は、誰もが以下のことをできます: * 既存のコンテンツを改善するためのPull Requestを開く、新しいコンテンツを追加する、ブログ記事やケーススタディを書く * 図表やグラフィックアセット、埋め込み可能なスクリーンキャストやビデオを作成する 詳細については、[新しいコンテンツの貢献](https://kubernetes.io/ja/docs/contribute/new-content/) を参照してください。 Member ------ Memberは、`kubernetes/website`に複数のPull Requestを作成した人です。 Memberは[Kubernetes GitHub organization](https://github.com/kubernetes) の一員です。 Memberは以下のことをできます: * [Anyone](https://kubernetes.io/ja/docs/contribute/participate/_print/#anyone) に列挙されているすべてのことを行う * `/lgtm`コメントを使用して、Pull RequestにLGTM (looks good to me)ラベルを追加する #### 備考: `/lgtm`を使用すると、自動化がトリガーされます。 非公式に承認したい場合は、"LGTM"とコメントするだけでも大丈夫です！ * `/hold`コメントを使用して、Pull Requestのマージをブロックする * `/assign`コメントを使用して、Pull RequestにReviewerを割り当てる * Pull Requestに非公式なレビューを提供する * 自動化を使用してIssueをトリアージし、分類する * 新機能をドキュメント化する ### Memberになる 少なくとも5つの実質的なPull Requestを作成し、その他の[要件](https://github.com/kubernetes/community/blob/master/community-membership.md#member) を満たした後に以下のようにしてMemberになることができます: 1. 2人の[Reviewer](https://kubernetes.io/ja/docs/contribute/participate/_print/#reviewers) または[Approver](https://kubernetes.io/ja/docs/contribute/participate/_print/#approvers) にあなたのメンバーシップを[スポンサー](https://kubernetes.io/docs/contribute/advanced#sponsor-a-new-contributor) してもらいます。 [Slackの#sig-docsチャンネル](https://kubernetes.slack.com/) や[SIG Docsのメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) でスポンサーを依頼してください。 #### 備考: 個別のSIG Docsメンバーに直接メールやSlackのダイレクトメッセージを送らないでください。 また申請する前にスポンサーを依頼する必要があります。 2. [`kubernetes/org`](https://github.com/kubernetes/org/) リポジトリにIssueを作成します。**Organization Membership Request**のissueテンプレートを使用してください。 3. スポンサーにGitHub Issueのことを知らせます。以下の方法があります: * Issue内でGitHubユーザー名に言及する（`@`） * Slackやメールを使ってIssueのリンクを送る スポンサーは`+1`の投票でリクエストを承認します。 スポンサーがリクエストを承認すると、Kubernetes GitHubの管理者があなたをメンバーとして追加します。 おめでとうございます！ メンバーシップリクエストが承認されない場合はフィードバックを受け取ります。 フィードバックに対応した後、再度申請してください。 4. メールアカウントでKubernetes GitHub organizationの招待を受け入れます。 #### 備考: GitHubはアカウントのデフォルトメールアドレスに招待を送信します。 Reviewer -------- ReviewerはオープンなPull Requestのレビューを担当します。 Memberのフィードバックとは異なり、PRを作成した人はReviewerのフィードバックに対応する必要があります。 Reviewerは[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHubチームのメンバーです。 Reviewerは以下のことをできます: * [Anyone](https://kubernetes.io/ja/docs/contribute/participate/_print/#anyone) および[Member](https://kubernetes.io/ja/docs/contribute/participate/_print/#members) に列挙されているすべてのことを行う * Pull Requestをレビューし、拘束力のあるフィードバックを提供する #### 備考: 拘束力のないフィードバックを提供する場合、コメントの前に"Optionally: "などのフレーズを付けてください。 * コード内のユーザー向けの文字列を編集する * コードコメントを改善する SIG DocsのReviewer、あるいは特定の領域に関するドキュメントのReviewerになることができます。 ### Pull RequestへのReviewerの割り当て 自動化により、すべてのPull RequestにReviewerが割り当てられます。 特定の人物にレビューを依頼するには、`/assign [@_github_handle]`とコメントします。 割り当てられたReviewerがPRにコメントしていない場合、他のReviewerが代わりにレビューできます。 また、必要に応じて技術的なReviewerを割り当てることもできます。 ### `/lgtm`の使用 LGTMは"Looks good to me"の略で、Pull Requestが技術的に正確でマージの準備が整っていることを示します。 すべてのPRには、マージするためにReviewerからの`/lgtm`コメントとApproverからの`/approve`コメントが必要です。 Reviewerからの`/lgtm`コメントは拘束力があり、自動化により`lgtm`ラベルが追加されます。 ### Reviewerになる [要件](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer) を満たすと、SIG DocsのReviewerになることができます。他のSIGのReviewerは、SIG DocsでのReviewerステータスを別途申請する必要があります。 申請方法は以下の通りです: 1. `kubernetes/website`リポジトリの[OWNERS\_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) ファイルのセクションに、GitHubユーザー名を追加するPull Requestを開きます。 #### 備考: どこに追加すればよいかわからない場合は、`sig-docs-en-reviews`に追加してください。 訳注: `sig-docs-en-reviews`は英語版のReviewerチームです。日本語ローカライゼーションのReviewerチームに参加する場合は、`sig-docs-ja-reviews`に追加してください。 2. PRを1人以上のSIG Docs Approverに割り当てます(ユーザー名は`sig-docs-{language}-owners`に記載されています)。 承認されると、SIG Docsのリードが適切なGitHubチームに追加します。 追加されると、[k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) が新しいPull RequestのReviewerとしてあなたを割り当て、提案します。 Approver -------- ApproverはPull Requestをレビューし、マージするために承認します。 Approverは[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHubチームのメンバーです。 Approverは以下のことをできます: * [Anyone](https://kubernetes.io/ja/docs/contribute/participate/_print/#anyone) 、[Member](https://kubernetes.io/ja/docs/contribute/participate/_print/#members) 、および[Reviewer](https://kubernetes.io/ja/docs/contribute/participate/_print/#reviewers) に列挙されているすべてのことを行う * `/approve`コメントを使用してPull Requestを承認およびマージすることで、コントリビューターのコンテンツを公開する * スタイルガイドの改善を提案する * ドキュメントテストの改善を提案する * Kubernetesのウェブサイトや他のツールの改善を提案する PRに既に`/lgtm`が付いている場合、またはApprover自身が`/lgtm`コメントを付けた場合、PRは自動的にマージされます。 SIG DocsのApproverは、追加の技術的なレビューが不要な変更にのみ`/lgtm`を付けるべきです。 ### Pull Requestの承認 ApproverとSIG DocsのリードだけがPull Requestをwebsiteリポジトリにマージすることができます。 これには一定の責任が伴います。 * Approverは`/approve`コマンドを使用して、PRをリポジトリにマージできます。 #### 警告: 不注意なマージはサイトを壊す可能性があるため、マージする際には慎重に行ってください。 * 提案された変更が[ドキュメントコンテンツガイド](https://kubernetes.io/ja/docs/contribute/style/content-guide/) に準拠していることを確認してください。 もし疑問がある場合や何か不明な点がある場合は、遠慮なく追加のレビューを依頼してください。 * PRを`/approve`する前に、Netlifyのテストに通っていることを確認してください。 ![Netlifyテストは承認する前に通っている必要があります](https://kubernetes.io/images/docs/contribute/netlify-pass.png) * 承認する前に、PRのNetlifyのページプレビューをクリックして内容が正しいことを確認してください。 * 週ごとのローテーションである[PR Wranglerローテーションスケジュール](https://github.com/kubernetes/website/wiki/PR-Wranglers) に参加してください。SIG DocsはすべてのApproverにこのローテーションへの参加を期待しています。詳細については[PR wranglers](https://kubernetes.io/docs/contribute/participate/pr-wranglers/) を参照してください。 ### Approverになる [要件](https://github.com/kubernetes/community/blob/master/community-membership.md#approver) を満たすと、SIG DocsのApproverになることができます。 他のSIGのApproverは、SIG DocsでのApproverステータスを別途申請する必要があります。 申請方法は以下の通りです: 1. `kubernetes/website`リポジトリの[OWNERS\_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) ファイルのセクションに、自分自身を追加するPull Requestを開きます。 #### 備考: どこに追加すればよいかわからない場合は、`sig-docs-en-owners`に追加してください。 訳注: `sig-docs-en-owners`は英語版のApproverチームです。 日本語ローカライゼーションのApproverチームに参加する場合は、`sig-docs-ja-owners`に追加してください。 2. PRを1人以上の現在のSIG Docs Approversに割り当てます。 承認されると、SIG Docsのリードが適切なGitHubチームに追加します。 追加されると、[k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) が新しいPull RequestのReviewerとしてあなたを割り当て、提案します。 次の項目 ---- * すべてのApproverがローテーションで担当する役割である[PR wrangling](https://kubernetes.io/docs/contribute/participate/pr-wranglers/) について読む。 --- # Contêineres | Kubernetes This is the multi-page printable view of this section. [Click here to print](https://kubernetes.io/pt-br/docs/concepts/containers/_print/#) . [Return to the regular view of this page](https://kubernetes.io/pt-br/docs/concepts/containers/) . Contêineres =========== Tecnologia para empacotar aplicações com suas dependências em tempo de execução * 1: [Imagens](https://kubernetes.io/pt-br/docs/concepts/containers/_print/#pg-16042b4652ad19e565c7263824029a43) * 2: [Ambiente de Contêiner](https://kubernetes.io/pt-br/docs/concepts/containers/_print/#pg-643212488f778acf04bebed65ba34441) * 3: [Classes de execução](https://kubernetes.io/pt-br/docs/concepts/containers/_print/#pg-a858027489648786a3b16264e451272b) * 4: [Hooks de Ciclo de Vida do Contêiner](https://kubernetes.io/pt-br/docs/concepts/containers/_print/#pg-e6941d969d81540208a3e78bc56f43bc) Cada contêiner executado é repetível; a padronização de ter dependências incluídas significa que você obtém o mesmo comportamento onde quer que você execute. Os contêineres separam os aplicativos da infraestrutura de _host_ subjacente. Isso torna a implantação mais fácil em diferentes ambientes de nuvem ou sistema operacional. Imagem de contêiner ------------------- Uma [imagem de contêiner](https://kubernetes.io/pt-br/docs/concepts/containers/images/) é um pacote de software pronto para executar, contendo tudo que é preciso para executar uma aplicação: o código e o agente de execução necessário, aplicação, bibliotecas do sistema e valores padrões para qualquer configuração essencial. Por _design_, um contêiner é imutável: você não pode mudar o código de um contêiner que já está executando. Se você tem uma aplicação conteinerizada e quer fazer mudanças, você precisa construir uma nova imagem que inclui a mudança, e recriar o contêiner para iniciar a partir da imagem atualizada. Agente de execução de contêiner ------------------------------- O agente de execução (_runtime_) de contêiner é o software responsável por executar os contêineres. O Kubernetes suporta diversos agentes de execução de contêineres: [Docker](https://docs.docker.com/engine/ "Docker é uma tecnologia de software que fornece virtualização a nível do sistema operacional, também conhecida como contêineres.") , [containerd](https://containerd.io/docs/ "Um agente de execução de contêiner com enfase em simplicidade, robustez e portabilidade") , [CRI-O](https://cri-o.io/#what-is-cri-o "Um agente de execução leve de contêineres criado especificamente para o Kubernetes") , e qualquer implementação do [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) . Próximos passos --------------- * [Imagens de contêineres](https://kubernetes.io/pt-br/docs/concepts/containers/images/) * [Pods](https://kubernetes.io/pt-br/docs/concepts/workloads/pods/) 1 - Imagens =========== Uma imagem de contêiner representa dados binários que encapsulam uma aplicação e todas as suas dependências de software. As imagens de contêiner são pacotes de software executáveis que podem ser executados de forma autônoma e que fazem suposições muito bem definidas sobre seu agente de execução do ambiente. Normalmente, você cria uma imagem de contêiner da sua aplicação e a envia para um registro antes de fazer referência a ela em um [Pod](https://kubernetes.io/pt-br/docs/concepts/workloads/pods/ "O menor e mais simples objeto Kubernetes. Um Pod representa um conjunto de contêineres em execução no seu cluster.") . Esta página fornece um resumo sobre o conceito de imagem de contêiner. #### Nota: Se você está procurando pelas imagens de contêiner de uma versão do Kubernetes (como a v1.35, a versão menor mais recente), visite [Download Kubernetes](https://kubernetes.io/releases/download/) . Nomes das imagens ----------------- As imagens de contêiner geralmente recebem um nome como `pause`, `exemplo/meuconteiner`, ou `kube-apiserver`. As imagens também podem incluir um hostname de algum registro; por exemplo: `exemplo.registro.ficticio/nomeimagem`, e um possível número de porta; por exemplo: `exemplo.registro.ficticio:10443/nomeimagem`. Se você não especificar um nome de host do registro, o Kubernetes assume que você está se referindo ao [registro público do Docker](https://hub.docker.com/) . Você pode alterar esse comportamento definindo um registro de imagem padrão na configuração do [agente de execução do contêiner](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) . Após a parte do nome da imagem, você pode adicionar uma _tag_ ou _digest_ (da mesma forma que faria ao usar comandos como `docker` ou `podman`). As tags permitem identificar diferentes versões da mesma série de imagens. Digests são identificadores únicos para uma versão específica de uma imagem. Digests são hashes do conteúdo da imagem e são imutáveis. As tags podem ser movidas para apontar para imagens diferentes, mas os digests são fixos. Tags de imagem consistem em letras minúsculas e maiúsculas, dígitos, sublinhados (`_`), pontos (`.`) e hifens (`-`). Elas podem ter até 128 caracteres de comprimento e devem seguir o seguinte padrão de expressão regular: `[a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}`. Você pode ler mais sobre e encontrar a expressão regular de validação na [Especificação de Distribuição OCI](https://github.com/opencontainers/distribution-spec/blob/master/spec.md#workflow-categories) . Se você não especificar uma tag, o Kubernetes assume que você está se referindo à tag `latest`. Digests de imagem consistem em um algoritmo de hash (como `sha256`) e um valor de hash. Por exemplo: `sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07`. Você pode encontrar mais informações sobre o formato de digests na [Especificação de Imagem OCI](https://github.com/opencontainers/image-spec/blob/master/descriptor.md#digests) . Alguns exemplos de nomes de imagem que o Kubernetes pode usar são: * `busybox` - Nome da imagem apenas, sem tag ou digest. O Kubernetes usará o registro público do Docker e a tag `latest`. (Equivalente a `docker.io/library/busybox:latest`) * `busybox:1.32.0` - Nome da imagem com tag. O Kubernetes usará o registro público do Docker. (Equivalente a `docker.io/library/busybox:1.32.0`) * `registry.k8s.io/pause:latest` - Nome da imagem com um registro personalizado e tag `latest`. * `registry.k8s.io/pause:3.5` - Nome da imagem com um registro personalizado e tag diferente de `latest`. * `registry.k8s.io/pause@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07` - Nome da imagem com digest. * `registry.k8s.io/pause:3.5@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07` - Nome da imagem com tag e digest. Apenas o digest será usado para o download. Atualizando imagens ------------------- Quando você cria um [Deployment](https://kubernetes.io/pt-br/docs/concepts/workloads/controllers/deployment/ "Gerencia uma aplicação replicada no seu cluster.") , [StatefulSet](https://kubernetes.io/pt-br/docs/concepts/workloads/controllers/statefulset/ "Gerencia deployment e escalonamento de um conjunto de Pods, com armazenamento durável e identificadores persistentes para cada Pod.") , Pod ou outro objeto que inclua um template de Pod, por padrão a política utilizada para baixar as imagens dos contêineres nesse Pod será definida como `IfNotPresent` quando não especificada explicitamente. Essa política faz com que o [kubelet](https://kubernetes.io/pt-br/docs/reference/command-line-tools-reference/kubelet "Um agente que é executado em cada nó no cluster. Ele garante que os contêineres estejam sendo executados em um Pod.") ignore o download da imagem se ela já existir. ### Política de download de imagem A `imagePullPolicy` de um contêiner e a tag da imagem afetam quando o [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) tenta puxar (download) a imagem especificada. Aqui está uma lista dos valores que você pode definir para `imagePullPolicy` e os efeitos que esses valores têm: `IfNotPresent` a imagem será baixada apenas se não estiver presente localmente. `Always` toda vez que o kubelet iniciar um contêiner, ele consultará o registro de imagens de contêiner para resolver o nome para um [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier) . Se o kubelet tiver uma imagem de contêiner com exatamente esse digest em cache local, ele usará a imagem em cache; caso contrário, o kubelet fará o download da imagem com o digest resolvido e usará essa imagem para iniciar o contêiner. `Never` o kubelet não tenta buscar a imagem. Se a imagem já estiver presente localmente de alguma forma, o kubelet tentará iniciar o contêiner; caso contrário, a inicialização falhará. Veja [imagens pré-baixadas](https://kubernetes.io/pt-br/docs/concepts/containers/_print/#pre-pulled-images) para mais detalhes. A semântica de cache do provedor de imagens subjacente torna mesmo `imagePullPolicy: Always` eficiente, desde que o registro esteja acessível de forma confiável. Seu agente de execução de contêiner pode perceber que as camadas da imagem já existem no nó, evitando que precisem ser baixadas novamente. #### Nota: Você deve evitar o uso da tag `:latest` ao implantar contêineres em produção, pois isso torna mais difícil rastrear qual versão da imagem está em execução e também dificulta realizar um rollback corretamente. Em vez disso, especifique uma tag significativa como `v1.42.0` e/ou um digest. Para garantir que o Pod sempre use a mesma versão de uma imagem de contêiner, você pode especificar o digest da imagem; substitua `:` por `@` (por exemplo, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). Ao usar tags de imagem, se o registro de imagens alterar o código que a tag representa, você pode acabar com uma mistura de Pods executando o código antigo e o novo. Um digest de imagem identifica de forma única uma versão específica da imagem, então o Kubernetes executa o mesmo código sempre que inicia um contêiner com aquele nome de imagem e digest especificado. Especificar uma imagem por digest fixa o código que será executado, de modo que uma alteração no registro não leve a essa mistura de versões. Existem [controladores de admissão](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) de terceiros que mutam Pods (e templates de Pods) quando eles são criados, de forma que a carga de trabalho em execução seja definida com base em um digest de imagem em vez de uma tag. Isso pode ser útil se você quiser garantir que toda sua carga de trabalho esteja executando o mesmo código, independentemente das mudanças de tags no registro. #### Política padrão de download de imagem Quando você (ou um controlador) envia um novo Pod para o servidor de API, seu cluster define o campo `imagePullPolicy` quando certas condições são atendidas: * se você omitir o campo `imagePullPolicy` e especificar o digest da imagem do contêiner, o `imagePullPolicy` será automaticamente definido como `IfNotPresent`; * se você omitir o campo `imagePullPolicy` e a tag da imagem do contêiner for `:latest`, o `imagePullPolicy` será automaticamente definido como `Always`; * se você omitir o campo `imagePullPolicy` e não especificar uma tag para a imagem do contêiner, o `imagePullPolicy` será automaticamente definido como `Always`; * se você omitir o campo `imagePullPolicy` e especificar uma tag para a imagem do contêiner que não seja `:latest`, o `imagePullPolicy` será automaticamente definido como `IfNotPresent`. #### Nota: O valor de `imagePullPolicy` do contêiner é sempre definido quando o objeto é _criado_ pela primeira vez, e não é atualizado se a tag ou o digest da imagem for alterado posteriormente. Por exemplo, se você criar um Deployment com uma imagem cuja tag _não_ é `:latest`, e mais tarde atualizar a imagem desse Deployment para a tag `:latest`, o campo `imagePullPolicy` _NÃO_ será alterado para `Always`. Você deve alterar manualmente a política de puxar imagem de qualquer objeto após sua criação inicial. #### Download obrigatório da imagem Se você deseja forçar sempre o download da imagem, pode fazer uma das seguintes opções: * Defina o `imagePullPolicy` do contêiner como `Always`. * Omita o `imagePullPolicy` e use `:latest` como a tag da imagem a ser usada; o Kubernetes definirá a política como `Always` ao enviar o Pod. * Omita o `imagePullPolicy` e a tag da imagem a ser usada; o Kubernetes definirá a política como `Always` ao enviar o Pod. * Ative o controlador de admissão [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) . ### ImagePullBackOff Quando o kubelet começa a criar contêineres para um Pod usando um agente de execução de contêiner, é possível que o contêiner esteja no estado [Waiting](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) devido a `ImagePullBackOff`. O status `ImagePullBackOff` significa que um contêiner não pôde ser iniciado porque o Kubernetes não conseguiu fazer o download da imagem do contêiner (por motivos como nome de imagem inválido ou tentativa de download de um registro privado sem `imagePullSecret`). A parte `BackOff` indica que o Kubernetes continuará tentando fazer o download da imagem, com um atraso incremental entre as tentativas. O Kubernetes aumenta o intervalo entre cada tentativa até atingir um limite definido no código, que é de 300 segundos (5 minutos). ### Download de imagem por classe de agente de execução ESTADO DA FUNCIONALIDADE: `Kubernetes v1.29 [alpha]`(desabilitado por padrão) O Kubernetes inclui suporte em estado alpha para realizar o download de imagens com base na RuntimeClass de um Pod. Se você habilitar o [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) `RuntimeClassInImageCriApi`, o kubelet passará a referenciar imagens de contêiner por uma tupla (nome da imagem, manipulador de agente de execução) em vez de apenas pelo nome da imagem ou digest. Seu [agente de execução do contêiner](https://kubernetes.io/pt-br/docs/setup/production-environment/container-runtimes "O agente de execução de contêiner é o software responsável por executar os contêineres.") pode adaptar seu comportamento com base no manipulador de agente de execução selecionado. Fazer download de imagens com base na classe de agente de execução será útil para contêineres baseados em máquina virtual, como contêineres do tipo Windows Hyper-V. Downloads de imagem em série e em paralelo ------------------------------------------ Por padrão, o kubelet realiza downloads de imagens de forma sequencial. Em outras palavras, o kubelet envia apenas uma solicitação de download de imagem por vez para o serviço de imagens. Outras solicitações de download precisam aguardar até que a solicitação em andamento seja concluída. Os Nós tomam decisões de download de imagem de forma isolada. Mesmo quando você usa downloads de imagem em série, dois Nós diferentes podem puxar a mesma imagem em paralelo. Se você quiser habilitar downloads de imagem em paralelo, pode definir o campo `serializeImagePulls` como `false` na [configuração do kubelet](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/) . Com `serializeImagePulls` definido como `false`, as solicitações de download de imagem serão enviadas imediatamente para o serviço de imagens, permitindo que várias imagens sejam puxadas ao mesmo tempo. Ao habilitar downloads de imagem em paralelo, certifique-se de que o serviço de imagens do seu agente de execução do contêiner pode lidar com esse tipo de operação. O kubelet nunca realiza download de múltiplas imagens em paralelo para um único Pod. Por exemplo, se você tiver um Pod com um Init Container e um contêiner de aplicação, os downloads de imagem desses dois contêineres não serão paralelizados. No entanto, se você tiver dois Pods que usam imagens diferentes, o kubelet puxará as imagens em paralelo para os dois Pods diferentes, quando o download paralelo estiver habilitado. ### Máximo de downloads de imagem em paralelo ESTADO DA FUNCIONALIDADE: `Kubernetes v1.32 [beta]` Quando `serializeImagePulls` está definido como `false`, o kubelet, por padrão, não impõe limite ao número máximo de imagens sendo puxadas ao mesmo tempo. Se você quiser limitar a quantidade de downloads de imagem paralelos, pode definir o campo `maxParallelImagePulls` na configuração do kubelet. Com `maxParallelImagePulls` definido como _n_, apenas _n_ imagens podem ser puxadas simultaneamente, e qualquer download de imagem além de _n_ terá que aguardar até que pelo menos um download em andamento seja concluído. Limitar o número de downloads de imagem paralelos ajuda a evitar que o processo de download consuma muita largura de banda de rede ou I/O de disco quando esta funcionalidade estiver habilitada. Você pode definir `maxParallelImagePulls` para um número positivo maior ou igual a 1. Se você definir `maxParallelImagePulls` como maior ou igual a 2, também deverá definir `serializeImagePulls` como `false`. O kubelet não iniciará se as configurações de `maxParallelImagePulls` forem inválidas. Multiarquitetura de imagens com índice de imagens ------------------------------------------------- Além de fornecer o binário das imagens, um registro de contêiner também pode servir um [índice de imagem do contêiner](https://github.com/opencontainers/image-spec/blob/master/image-index.md) . Um índice de imagem pode apontar para múltiplos [manifestos da imagem](https://github.com/opencontainers/image-spec/blob/master/manifest.md) para versões específicas de arquitetura de um contêiner. A ideia é que você possa ter um nome para uma imagem (por exemplo: `pause`, `exemple/meuconteiner`, `kube-apiserver`) e permitir que diferentes sistemas busquem o binário da imagem correta para a arquitetura de máquina que estão usando. O próprio Kubernetes normalmente nomeia as imagens de contêiner com o sufixo `-$(ARCH)`. Para retrocompatibilidade, gere as imagens mais antigas com sufixos. A ideia é gerar a imagem `pause` que tem o manifesto para todas as arquiteturas e `pause-amd64` que é retrocompatível com as configurações anteriores ou arquivos YAML que podem ter codificado as imagens com sufixos. Usando um registro privado -------------------------- Os registros privados podem exigir chaves para acessar as imagens deles. As credenciais podem ser fornecidas de várias maneiras: * Configurando nós para autenticação em um registro privado * todos os pods podem ler qualquer registro privado configurado * requer configuração de nó pelo administrador do cluster * Imagens pré-obtidas * todos os pods podem usar qualquer imagem armazenada em cache em um nó * requer acesso root a todos os nós para configurar * Especificando ImagePullSecrets em um Pod * apenas pods que fornecem chaves próprias podem acessar o registro privado * Extensões locais ou específicas do fornecedor * se estiver usando uma configuração de nó personalizado, você (ou seu provedor de nuvem) pode implementar seu mecanismo para autenticar o nó ao registro do contêiner. Essas opções são explicadas com mais detalhes abaixo. ### Configurando nós para autenticação em um registro privado As instruções específicas para configurar as credenciais dependem do agente de execução de contêiner e do registro que você escolheu utilizar. Você deve consultar a documentação da sua solução para obter as informações mais precisas. Para um exemplo de configuração de um registro de imagens de contêiner privado, veja a tarefa [Realizar download de uma Imagem a partir de um Registro Privado](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry) . Esse exemplo utiliza um registro privado no Docker Hub. ### Provedor de credenciais do kubelet para downloads de imagem autenticados #### Nota: Essa abordagem é especialmente adequada quando o kubelet precisa buscar credenciais de registro de forma dinâmica. É mais comumente usada com registros fornecidos por provedores de nuvem, onde os tokens de autenticação têm vida curta. Você pode configurar o kubelet para invocar um binário de plugin a fim de buscar dinamicamente as credenciais de registro para uma imagem de contêiner. Essa é a maneira mais robusta e versátil de obter credenciais para registros privados, mas também exige uma configuração no nível do kubelet para ser habilitada. Veja [Configurar um provedor de credenciais de imagem no kubelet](https://kubernetes.io/pt-br/docs/tasks/administer-cluster/kubelet-credential-provider/) para mais detalhes. ### Interpretação do config.json A interpretação do `config.json` varia entre a implementação original do Docker e a interpretação feita pelo Kubernetes. No Docker, as chaves em `auths` podem especificar apenas URLs raiz, enquanto o Kubernetes permite URLs com _glob_ e também caminhos com correspondência por prefixo. A única limitação é que os padrões _glob_ (`*`) devem incluir o ponto (`.`) para cada subdomínio. A quantidade de subdomínios correspondentes deve ser igual à quantidade de padrões glob (`*.`), por exemplo: * `*.kubernetes.io` _não_ corresponderá a `kubernetes.io`, mas corresponderá a `abc.kubernetes.io` * `*.*.kubernetes.io` _não_ corresponderá a `abc.kubernetes.io`, mas corresponderá a `abc.def.kubernetes.io` * `prefix.*.io` corresponderá a `prefix.kubernetes.io` * `*-good.kubernetes.io` corresponderá a `prefix-good.kubernetes.io` Isso significa que um `config.json` como este é válido: { "auths": { "my-registry.io/images": { "auth": "…" }, "*.my-registry.io/images": { "auth": "…" } } } As operações de pull de imagem agora passarão as credenciais para o agente de execução de contêiner via CRI para cada padrão válido. Por exemplo, os seguintes nomes de imagem de contêiner corresponderiam com sucesso: * `my-registry.io/images` * `my-registry.io/images/my-image` * `my-registry.io/images/another-image` * `sub.my-registry.io/images/my-image` Mas não: * `a.sub.my-registry.io/images/my-image` * `a.b.sub.my-registry.io/images/my-image` O kubelet realiza downloads de imagem de forma sequencial para cada credencial encontrada. Isso significa que múltiplas entradas no `config.json` para caminhos diferentes também são possíveis: { "auths": { "my-registry.io/images": { "auth": "…" }, "my-registry.io/images/subpath": { "auth": "…" } } } Se agora um contêiner especificar uma imagem `my-registry.io/images/subpath/my-image` para ser baixada, o kubelet tentará fazer o download utilizando ambas as fontes de autenticação, caso uma delas falhe. ### Imagens pré-obtidas #### Nota: Essa abordagem é adequada se você puder controlar a configuração do nó. Isto não funcionará de forma confiável se o seu provedor de nuvem for responsável pelo gerenciamento de nós e os substituir automaticamente. Por padrão, o kubelet tenta realizar um "pull" para cada imagem do registro especificado. No entanto, se a propriedade `imagePullPolicy` do contêiner for definida como `IfNotPresent` ou `Never`, em seguida, uma imagem local é usada (preferencial ou exclusivamente, respectivamente). Se você quiser usar imagens pré-obtidas como um substituto para a autenticação do registro, você deve garantir que todos os nós no cluster tenham as mesmas imagens pré-obtidas. Isso pode ser usado para pré-carregar certas imagens com o intuíto de aumentar a velocidade ou como uma alternativa para autenticação em um registro privado. Todos os pods terão permissão de leitura a quaisquer imagens pré-obtidas. ### Especificando imagePullSecrets em um pod #### Nota: Esta é a abordagem recomendada para executar contêineres com base em imagens de registros privados. O Kubernetes oferece suporte à especificação de chaves de registro de imagem de contêiner em um Pod. Todos os `imagePullSecrets` devem estar no mesmo namespace que o Pod. Os Secrets referenciados devem ser do tipo `kubernetes.io/dockercfg` ou `kubernetes.io/dockerconfigjson`. #### Criando um segredo com Docker config Você precisa saber o nome de usuário, a senha do registro, o endereço de e-mail do cliente para autenticação no registro, além do nome do host. Execute o seguinte comando, substituindo os valores em letras maiúsculas pelos apropriados: kubectl create secret docker-registry \ --docker-server=DOCKER_REGISTRY_SERVER \ --docker-username=DOCKER_USER \ --docker-password=DOCKER_PASSWORD \ --docker-email=DOCKER_EMAIL Se você já tem um arquivo de credenciais do Docker, em vez de usar o comando acima, você pode importar o arquivo de credenciais como um Kubernetes [Secrets](https://kubernetes.io/pt-br/docs/concepts/configuration/secret/ "Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH.") . [Criar um segredo com base nas credenciais Docker existentes](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explica como configurar isso. Isso é particularmente útil se você estiver usando vários registros privados de contêineres, como `kubectl create secret docker-registry` cria um Segredo que só funciona com um único registro privado. #### Nota: Os pods só podem fazer referência a _pull secrets_ de imagem em seu próprio namespace, portanto, esse processo precisa ser feito uma vez por namespace. #### Referenciando um imagePullSecrets em um pod Agora, você pode criar Pods que referenciam esse Secret adicionando uma seção `imagePullSecrets` na definição do Pod. Cada item no array `imagePullSecrets` pode referenciar apenas um Secret no mesmo namespace. Por exemplo: cat < pod.yaml apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey EOF cat <> ./kustomization.yaml resources: - pod.yaml EOF Isso precisa ser feito para cada pod que está usando um registro privado. No entanto, a configuração deste campo pode ser automatizada definindo o imagePullSecrets em um recurso de [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) . Verifique [Adicionar ImagePullSecrets a uma conta de serviço](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) para obter instruções detalhadas. Você pode usar isso em conjunto com um `.docker / config.json` por nó. As credenciais serão mescladas. Casos de uso ------------ Existem várias soluções para configurar registros privados. Aqui estão alguns casos de uso comuns e soluções sugeridas. 1. Cluster executando apenas imagens não proprietárias (por exemplo, código aberto). Não há necessidade de ocultar imagens. * Use imagens públicas no Docker hub. * Nenhuma configuração necessária. * Alguns provedores de nuvem armazenam em cache ou espelham automaticamente imagens públicas, o que melhora a disponibilidade e reduz o tempo para extrair imagens. 2. Cluster executando algumas imagens proprietárias que devem ser ocultadas para quem está fora da empresa, mas visível para todos os usuários do cluster. * Use um [registro Docker](https://docs.docker.com/registry/) privado hospedado. * Pode ser hospedado no [Docker Hub](https://hub.docker.com/signup) ou em outro lugar. * Configure manualmente .docker/config.json em cada nó conforme descrito acima. * Ou execute um registro privado interno atrás de seu firewall com permissão de leitura. * Nenhuma configuração do Kubernetes é necessária. * Use um serviço de registro de imagem de contêiner que controla o acesso à imagem * Funcionará melhor com o escalonamento automático do cluster do que com a configuração manual de nós. * Ou, em um cluster onde alterar a configuração do nó é inconveniente, use `imagePullSecrets`. 3. Cluster com imagens proprietárias, algumas das quais requerem controle de acesso mais rígido. * Certifique-se de que o [controlador de admissão AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) está ativo. Caso contrário, todos os pods têm potencialmente acesso a todas as imagens. * Mova dados confidenciais para um recurso "secreto", em vez de empacotá-los em uma imagem. 4. Um cluster multilocatário em que cada locatário precisa de seu próprio registro privado. * Certifique-se de que o [controlador de admissão AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) está ativo. Caso contrário, todos os Pods de todos os locatários terão potencialmente acesso a todas as imagens. * Execute um registro privado com autorização necessária. * Gere credenciais de registro para cada locatário, coloque em segredo e preencha o segredo para cada namespace de locatário. * O locatário adiciona esse segredo a imagePullSecrets de cada namespace. Se precisar de acesso a vários registros, você pode criar um segredo para cada registro. Provedor de credenciais legado embutido no kubelet -------------------------------------------------- Em versões mais antigas do Kubernetes, o kubelet tinha uma integração direta com as credenciais de provedores de nuvem. Isso permitia buscar dinamicamente as credenciais para registros de imagens. Havia três implementações embutidas do provedor de credenciais do kubelet: ACR (Azure Container Registry), ECR (Elastic Container Registry) e GCR (Google Container Registry). Para mais informações sobre o mecanismo legado, consulte a documentação da versão do Kubernetes que você está utilizando. As versões do Kubernetes da v1.26 até a v1.35 não incluem mais esse mecanismo legado, portanto, você precisará: * configurar um provedor de credenciais de imagem no kubelet em cada nó * ou especificar credenciais de download de imagem usando `imagePullSecrets` e pelo menos um Secret Próximos passos --------------- * Leia a [Especificação do Manifesto de Imagem OCI](https://github.com/opencontainers/image-spec/blob/master/manifest.md) * Saiba mais sobre [coleta de lixo de imagens de contêiner](https://kubernetes.io/pt-br/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection) . * Saiba mais sobre [realizar download de uma imagem a partir de um registro privado](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry) . 2 - Ambiente de Contêiner ========================= Essa página descreve os recursos disponíveis para contêineres no ambiente de contêiner. Ambiente de contêiner --------------------- O ambiente de contêiner do Kubernetes fornece recursos importantes para contêineres: * Um sistema de arquivos, que é a combinação de uma [imagem](https://kubernetes.io/pt-br/docs/concepts/containers/images/) e um ou mais [volumes](https://kubernetes.io/pt-br/docs/concepts/storage/volumes/) . * Informação sobre o contêiner propriamente. * Informação sobre outros objetos no cluster. ### Informação de contêiner O _hostname_ de um contêiner é o nome do Pod em que o contêiner está executando. Isso é disponibilizado através do comando `hostname` ou da função [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) chamada na libc. O nome do Pod e o Namespace são expostos como variáveis de ambiente através de um mecanismo chamado [downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) . Variáveis de ambiente definidas pelo usuário a partir da definição do Pod também são disponíveis para o contêiner, assim como qualquer variável de ambiente especificada estáticamente na imagem Docker. ### Informação do cluster Uma lista de todos os serviços que estão executando quando um contêiner foi criado é disponibilizada para o contêiner como variáveis de ambiente. Essas variáveis de ambiente são compatíveis com a funcionalidade _docker link_ do Docker. Para um serviço nomeado _foo_ que mapeia para um contêiner nomeado _bar_, as seguintes variáveis são definidas: FOO_SERVICE_HOST= FOO_SERVICE_PORT= Serviços possuem endereço IP dedicado e são disponibilizados para o contêiner via DNS, se possuírem [DNS addon](https://releases.k8s.io/v1.35.0/cluster/addons/dns/) habilitado. Próximos passos --------------- * Aprenda mais sobre [hooks de ciclo de vida do contêiner](https://kubernetes.io/pt-br/docs/concepts/containers/container-lifecycle-hooks/) . * Obtenha experiência prática [anexando manipuladores a eventos de ciclo de vida do contêiner](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . 3 - Classes de execução ======================= ESTADO DA FUNCIONALIDADE: `Kubernetes v1.20 [stable]` Essa página descreve o recurso _RuntimeClass_ e a seleção do mecanismo do agente de execução. RuntimeClass é uma funcionalidade para selecionar as configurações do agente de execução do contêiner. A configuração do agente de execução de contêineres é usada para executar os contêineres de um Pod. Motivação --------- Você pode configurar um _RuntimeClass_ diferente entre os diferentes Pods para prover um equilíbrio entre performance versus segurança. Por exemplo, se parte de sua carga de trabalho necessita de um alto nível de garantia de segurança da informação, você pode optar em executar esses Pods em um agente de execução que usa virtualização de hardware. Você então terá o benefício do isolamento extra de um agente de execução alternativo, ao custo de uma latência adicional. Você pode ainda usar um _RuntimeClass_ para executar diferentes Pods com o mesmo agente de execução de contêineres mas com diferentes configurações. Configuração ------------ 1. Configure a implementação do CRI nos nós (depende do agente de execução) 2. Crie o recurso RuntimeClass correspondente. ### 1\. Configure a implementação do CRI nos nós As configurações disponíveis através do RuntimeClass sáo dependentes da implementação do _Container Runtime Interface_ ([Container runtime interface (CRI)](https://kubernetes.io/pt-br/docs/concepts/overview/components/#container-runtime "Uma API para agentes de execução de contêineres se integrarem com o kubelet") ). Veja a documentação correspondente [abaixo](https://kubernetes.io/pt-br/docs/concepts/containers/_print/#configura%C3%A7%C3%A3o-do-cri) para a sua implementação CRI para verificar como configurar. #### Nota: RuntimeClass assume uma configuração homogênea de nós entre todo o cluster por padrão (o que significa que todos os nós estão configurados do mesmo jeito referente aos agentes de execução). Para suportar configurações heterogêneas, veja [Associação](https://kubernetes.io/pt-br/docs/concepts/containers/_print/#associa%C3%A7%C3%A3o) abaixo. As configurações possuem um nome `handler` correspondente, referenciado pelo RuntimeClass. Esse nome deve ser um valor DNS 1123 válido (letras, números e o carácter `-`). ### 2\. Crie o recurso RuntimeClass correspondente As etapas de configuração no passo 1 devem todas estar associadas a um nome para o campo `handler` que identifica a configuração. Para cada um, crie o objeto RuntimeClass correspondente. O recurso RuntimeClass atualmente possui apenas 2 campos significativos: o nome do RuntimeClass (`metadata.name`) e o agente (`handler`). A definição do objeto se parece conforme a seguir: apiVersion: node.k8s.io/v1 # RuntimeClass é definido no grupo de API node.k8s.io kind: RuntimeClass metadata: name: myclass # O nome que o RuntimeClass será chamado como # RuntimeClass é um recurso global, e não possui namespace. handler: myconfiguration # Nome da configuração CRI correspondente O nome de um objeto RuntimeClass deve ser um [nome de subdomínio DNS](https://kubernetes.io/pt-br/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. #### Nota: É recomendado que operações de escrita no objeto RuntimeClass (criar/atualizar/patch/apagar) sejam restritas a administradores do cluster. Isso geralmente é o padrão. Veja [Visão Geral de autorizações](https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authorization/) para maiores detalhes. Uso --- Uma vez que as classes de execução estão configuradas no cluster, usar elas é relativamente simples. Especifique um `runtimeClassName` na especificação do Pod. Por exemplo: apiVersion: v1 kind: Pod metadata: name: mypod spec: runtimeClassName: myclass # ... Isso irá instruir o kubelet a usar o RuntimeClass nomeado acima (myclass) para esse Pod. Se o nome do RuntimeClass não existir, ou o CRI não puder executar a solicitação, o Pod entrará na [fase final](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. Procure por um [evento](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application-introspection/) correspondente para uma mensagem de erro. Se nenhum `runtimeClassName` for especificado, o RuntimeHandler padrão será utilizado, que é equivalente ao comportamento quando a funcionalidade de RuntimeClass está desativada. ### Configuração do CRI Para maiores detalhes de configuração dos agentes de execução CRI, veja [instalação do CRI](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) . #### dockershim O CRI dockershim embutido no Kubernetes não suporta outros agentes de execução. #### [containerd](https://containerd.io/docs/ "Um agente de execução de contêiner com enfase em simplicidade, robustez e portabilidade") Agentes de execução são configurados através da configuração do containerd em `/etc/containerd/config.toml`. Agentes válidos são configurados sob a seção de `runtimes`: [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] Veja a documentação de configuração do containerd para maiores detalhes: [https://github.com/containerd/containerd/blob/main/docs/cri/config.md](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) #### [CRI-O](https://cri-o.io/#what-is-cri-o "Um agente de execução leve de contêineres criado especificamente para o Kubernetes") Agentes de execução são configurados através da configuração do CRI-O em `/etc/crio/crio.conf`. Agentes válidos são configurados na seção [crio.runtime table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) : [crio.runtime.runtimes.${HANDLER_NAME}] runtime_path = "${PATH_TO_BINARY}" Veja a [documentação de configuração](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) do CRI-O para maiores detalhes. Associação ---------- ESTADO DA FUNCIONALIDADE: `Kubernetes v1.16 [beta]` Ao especificar o campo `scheduling` para um RuntimeClass, você pode colocar limites e garantir que os Pods executando dentro de uma RuntimeClass sejam associados a nós que suportem eles. Se o `scheduling` não estiver configurado, assume-se que esse RuntimeClass é suportado por todos os nós. Para garantir que os Pods sejam executados em um nó que suporte um RuntimeClass específico, aquele conjunto de nós deve possuir uma marca/label padrão que é selecionado pelo campo `runtimeclass.scheduling.nodeSelector`. O nodeSelector do RuntimeClass é combinado com o nodeSelector do Pod em tempo de admissão, obtendo a intersecção do conjunto de nós selecionado por cada. Se existir um conflito, o pod será rejeitado. Se os nós suportados possuírem marcação de restrição para prevenir outros Pods com uma classe de execução diferente de executar no nó, você pode adicionar o campo `tolerations` ao objeto RuntimeClass. Assim como com o `nodeSelector`, o `tolerations` é combinado com o campo `tolerations` do Pod em tempo de admissão, efetivamente pegando a intersecção do conjunto de nós aplicáveis para cada. Para saber mais sobre a configuração de seleção de nós e tolerâncias, veja [Associando Pods a Nós](https://kubernetes.io/pt-br/docs/concepts/scheduling-eviction/assign-pod-node/) . ### Sobrecarga de Pods ESTADO DA FUNCIONALIDADE: `Kubernetes v1.18 [beta]` Você pode especificar os recursos extra que estão associados à execução de um Pod. Declarar esses recursos extra permite ao cluster (incluindo o agendador/scheduler de pods) contabilizar por esses recursos quando estiver decidindo sobre Pods e recursos. Para usar a contabilização desses recursos extras, você deve estar com o [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) PodOverhead habilitado (ele já está habilitado por padrão). Os recursos extras utilizados são especificados no objeto RuntimeClass através do campo `overhead`. Ao usar esses campos, você especifica o uso extra de recursos necessários para executar Pods utilizando-se desse Runtimeclass e assim contabilizar esses recursos para o Kubernetes. Próximos passos --------------- * [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) * [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) * Leia mais sobre [Sobrecarga de Pods](https://kubernetes.io/pt-br/docs/concepts/scheduling-eviction/pod-overhead/) * [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) 4 - Hooks de Ciclo de Vida do Contêiner ======================================= Essa página descreve como os contêineres gerenciados pelo _kubelet_ podem usar a estrutura de _hook_ de ciclo de vida do contêiner para executar código acionado por eventos durante seu ciclo de vida de gerenciamento. Visão Geral ----------- Análogo a muitas estruturas de linguagem de programação que tem _hooks_ de ciclo de vida de componentes, como angular, o Kubernetes fornece aos contêineres _hooks_ de ciclo de vida. Os _hooks_ permitem que os contêineres estejam cientes dos eventos em seu ciclo de vida de gerenciamento e executem código implementado em um manipulador quando o _hook_ de ciclo de vida correspondente é executado. Hooks do contêiner ------------------ Existem dois _hooks_ que são expostos para os contêiners: `PostStart` Este _hook_ é executado imediatamente após um contêiner ser criado. Entretanto, não há garantia que o _hook_ será executado antes do ENTRYPOINT do contêiner. Nenhum parâmetro é passado para o manipulador. `PreStop` Esse _hook_ é chamado imediatamente antes de um contêiner ser encerrado devido a uma solicitação de API ou um gerenciamento de evento como liveness/startup probe failure, preemption, resource contention e outros. Uma chamada ao _hook_ `PreStop` falha se o contêiner já está em um estado finalizado ou concluído e o _hook_ deve ser concluído antes que o sinal TERM seja enviado para parar o contêiner. A contagem regressiva do período de tolerância de término do Pod começa antes que o _hook_ `PreStop` seja executado, portanto, independentemente do resultado do manipulador, o contêiner será encerrado dentro do período de tolerância de encerramento do Pod. Nenhum parâmetro é passado para o manipulador. Uma descrição mais detalhada do comportamento de término pode ser encontrada em [Término de Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) . ### Implementações de manipulador de hook Os contêineres podem acessar um _hook_ implementando e registrando um manipulador para esse _hook_. Existem dois tipos de manipuladores de _hooks_ que podem ser implementados para contêineres: * Exec - Executa um comando específico, como `pre-stop.sh`, dentro dos cgroups e Namespaces do contêiner. * HTTP - Executa uma requisição HTTP em um endpoint específico do contêiner. ### Execução do manipulador de hook Quando um _hook_ de gerenciamento de ciclo de vida do contêiner é chamado, o sistema de gerenciamento do Kubernetes executa o manipulador de acordo com a ação do _hook_, `httpGet` e `tcpSocket` são executados pelo processo kubelet e `exec` é executado pelo contêiner. As chamadas do manipulador do _hook_ são síncronas no contexto do Pod que contém o contêiner. Isso significa que para um _hook_ `PostStart`, o ENTRYPOINT do contêiner e o _hook_ disparam de forma assíncrona. No entanto, se o _hook_ demorar muito para ser executado ou travar, o contêiner não consegue atingir o estado `running`. Os _hooks_ `PreStop` não são executados de forma assíncrona a partir do sinal para parar o contêiner, o _hook_ precisa finalizar a sua execução antes que o sinal TERM possa ser enviado. Se um _hook_ `PreStop` travar durante a execução, a fase do Pod será `Terminating` e permanecerá até que o Pod seja morto após seu `terminationGracePeriodSeconds` expirar. Esse período de tolerância se aplica ao tempo total necessário para o _hook_ `PreStop`executar e para o contêiner parar normalmente. Se por exemplo, o `terminationGracePeriodSeconds` é 60, e o _hook_ leva 55 segundos para ser concluído, e o contêiner leva 10 segundos para parar normalmente após receber o sinal, então o contêiner será morto antes que possa parar normalmente, uma vez que o `terminationGracePeriodSeconds` é menor que o tempo total (55 + 10) que é necessário para que essas duas coisas aconteçam. Se um _hook_ `PostStart` ou `PreStop` falhar, ele mata o contêiner. Os usuários devem tornar seus _hooks_ o mais leve possíveis. Há casos, no entanto, em que comandos de longa duração fazem sentido, como ao salvar o estado antes de parar um contêiner. ### Garantias de entrega de _hooks_ A entrega do _hook_ é destinada a acontecer _pelo menos uma vez_, o que quer dizer que um _hook_ pode ser chamado várias vezes para qualquer evento, como para `PostStart` ou `PreStop`. Depende da implementação do _hook_ lidar com isso corretamente. Geralmente, apenas entregas únicas são feitas. Se, por exemplo, um receptor de _hook_ HTTP estiver inativo e não puder receber tráfego, não há tentativa de reenviar. Em alguns casos raros, no entanto, pode ocorrer uma entrega dupla. Por exemplo, se um kubelet reiniciar no meio do envio de um _hook_, o _hook_ pode ser reenviado depois que o kubelet voltar a funcionar. ### Depurando manipuladores de _hooks_ Os logs para um manipulador de _hook_ não são expostos em eventos de Pod. Se um manipulador falhar por algum motivo, ele transmitirá um evento. Para `PostStart` é o evento `FailedPostStartHook` e para `PreStop` é o evento `FailedPreStopHook`. Você pode ver esses eventos executando `kubectl describe pod `. Aqui está um exemplo de saída de eventos da execução deste comando: Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook Próximos passos --------------- * Saiba mais sobre o [Ambiente de contêiner](https://kubernetes.io/pt-br/docs/concepts/containers/container-environment/) . * Obtenha experiência prática [anexando manipuladores a eventos de ciclo de vida do contêiner](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) . --- # Arquitectura de Kubernetes | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/concepts/architecture/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/concepts/architecture/) . Arquitectura de Kubernetes ========================== * 1: [Nodos](https://kubernetes.io/es/docs/concepts/architecture/_print/#pg-9ef2890698e773b6c0d24fd2c20146f5) * 2: [Comunicación entre Nodos y el Plano de Control](https://kubernetes.io/es/docs/concepts/architecture/_print/#pg-c0251def6da29b30afebfb04549f1703) * 3: [Conceptos subyacentes del Cloud Controller Manager](https://kubernetes.io/es/docs/concepts/architecture/_print/#pg-bc804b02614d67025b4c788f1ca87fbc) * 4: [Leases](https://kubernetes.io/es/docs/concepts/architecture/_print/#pg-d5e64235fa89f107957072cd8a39e4c5) * 5: [Container Runtime Interface (CRI)](https://kubernetes.io/es/docs/concepts/architecture/_print/#pg-c0ea5310f52e22c5de34dc84d9ab5e0d) 1 - Nodos ========= Un nodo es una máquina de trabajo en Kubernetes, previamente conocida como `minion`. Un nodo puede ser una máquina virtual o física, dependiendo del tipo de clúster. Cada nodo está gestionado por el componente máster y contiene los servicios necesarios para ejecutar [pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod/) . Los servicios en un nodo incluyen el [container runtime](https://kubernetes.io/es/docs/concepts/overview/components/#node-components) , kubelet y el kube-proxy. Accede a la sección [The Kubernetes Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) en el documento de diseño de arquitectura para más detalle. Estado del Nodo --------------- El estado de un nodo comprende la siguiente información: * [Direcciones](https://kubernetes.io/es/docs/concepts/architecture/_print/#direcciones) * [Estados](https://kubernetes.io/es/docs/concepts/architecture/_print/#estados) * [Capacidad](https://kubernetes.io/es/docs/concepts/architecture/_print/#capacidad) * [Información](https://kubernetes.io/es/docs/concepts/architecture/_print/#informaci%C3%B3n) ### Direcciones El uso de estos campos varía dependiendo del proveedor de servicios en la nube y/o de la configuración en máquinas locales. * `HostName`: El nombre de la máquina huésped como aparece en el kernel del nodo. Puede ser reconfigurado a través del kubelet usando el parámetro `--hostname-override`. * `ExternalIP`: La dirección IP del nodo que es accesible externamente (que está disponible desde fuera del clúster). * `InternalIP`: La dirección IP del nodo que es accesible únicamente desde dentro del clúster. ### Estados El campo `conditions` describe el estado de todos los nodos en modo `Running`. | Estado | Descripción | | --- | --- | | `OutOfDisk` | `True` si no hay espacio suficiente en el nodo para añadir nuevos pods; sino `False` | | `Ready` | `True` si el nodo está en buen estado y preparado para aceptar nuevos pods, `Falso` si no puede aceptar nuevos pods, y `Unknown` si el controlador aún no tiene constancia del nodo después del último `node-monitor-grace-period` (por defecto cada 40 segundos) | | `MemoryPressure` | `True` si hay presión en la memoria del nodo -- es decir, si el consumo de memoria en el nodo es elevado; sino `False` | | `PIDPressure` | `True` si el número de PIDs consumidos en el nodo es alto -- es decir, si hay demasiados procesos en el nodo; sino `False` | | `DiskPressure` | `True` si hay presión en el tamaño del disco -- esto es, si la capacidad del disco es baja; sino `False` | | `NetworkUnavailable` | `True` si la configuración de red del nodo no es correcta; sino `False` | El estado del nodo se representa como un objeto JSON. Por ejemplo, la siguiente respuesta describe un nodo en buen estado: "conditions": [\ {\ "type": "Ready",\ "status": "True"\ }\ ] Si el `status` de la condición `Ready` se mantiene como `Unknown` o `False` por más tiempo de lo que dura un `pod-eviction-timeout`, se pasa un argumento al [kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager/) y todos los pods en el nodo se marcan para borrado por el controlador de nodos. El tiempo de desalojo por defecto es de **cinco minutos**. En algunos casos, cuando el nodo se encuentra inaccesible, el API Server no puede comunicar con el kubelet del nodo. La decisión de borrar pods no se le puede hacer llegar al kubelet hasta que la comunicación con el API Server se ha restablecido. Mientras tanto, los pods marcados para borrado pueden continuar ejecutándose en el nodo aislado. En versiones de Kubernetes anteriores a 1.5, el controlador de nodos [forzaba el borrado](https://kubernetes.io/es/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) de dichos pods inaccesibles desde el API Server. Sin embargo, desde la versión 1.5, el nodo controlador no fuerza el borrado de pods hasta que se confirma que dichos pods han dejado de ejecutarse en el clúster. Pods que podrían estar ejecutándose en un nodo inalcanzable se muestran como `Terminating` o `Unknown`. En aquellos casos en los que Kubernetes no puede deducir si un nodo ha abandonado el clúster de forma permanente, puede que sea el administrador el que tenga que borrar el nodo de forma manual. Borrar un objeto `Node` en un clúster de Kubernetes provoca que los objetos Pod que se ejecutaban en el nodo sean eliminados en el API Server y libera sus nombres. En la versión 1.12, la funcionalidad `TaintNodesByCondition` se eleva a beta, de forma que el controlador del ciclo de vida de nodos crea [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) de forma automática, que representan estados de nodos. De forma similar, el planificador de tareas ignora estados cuando evalúa un nodo; en su lugar mira los taints del nodo y las tolerancias de los pods. En la actualidad, los usuarios pueden elegir entre la versión de planificación antigua y el nuevo, más flexible, modelo de planificación. Un pod que no tiene definida ninguna tolerancia es planificado utilizando el modelo antiguo, pero si un nodo tiene definidas ciertas tolerancias, sólo puede ser asignado a un nodo que lo permita. #### Precaución: Habilitar esta funcionalidad crea una pequeña demora entre que una condición es evaluada y un taint creado. Esta demora suele ser inferior a un segundo, pero puede incrementar el número de pods que se planifican con éxito pero que luego son rechazados por el kubelet. ### Capacidad Describe los recursos disponibles en el nodo: CPU, memoria, y el número máximo de pods que pueden ser planificados dentro del nodo. ### Información Información general sobre el nodo: versión del kernel, versión de Kubernetes (versiones del kubelet y del kube-proxy), versión de Docker (si se utiliza), nombre del sistema operativo. Toda esta información es recogida por el kubelet en el nodo. Gestión ------- A diferencia de [pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod/) y [services](https://kubernetes.io/es/docs/concepts/services-networking/service/) , los nodos no son creados por Kubernetes de forma inherente; o son creados de manera externa por los proveedores de servicios en la nube como Google Compute Engine, o existen en la colección de máquinas virtuales o físicas. De manera que cuando Kubernetes crea un nodo, crea un objeto que representa el nodo. Después de ser creado, Kubernetes comprueba si el nodo es válido o no. Por ejemplo, si intentas crear un nodo con el siguiente detalle: { "kind": "Node", "apiVersion": "v1", "metadata": { "name": "10.240.79.157", "labels": { "name": "my-first-k8s-node" } } } Kubernetes crea un objeto `Node` internamente (la representación), y valida el nodo comprobando su salud en el campo `metadata.name`. Si el nodo es válido -- es decir, si todos los servicios necesarios están ejecutándose -- el nodo es elegible para correr un pod. Sino, es ignorado para cualquier actividad del clúster hasta que se convierte en un nodo válido. #### Nota: Kubernetes conserva el objeto de un nodo inválido y continúa probando por si el nodo, en algún momento, entrase en servicio. Para romper este ciclo deberás borrar el objeto `Node` explícitamente. Actualmente, hay tres componentes que interactúan con la interfaz de nodos de Kubernetes: controlador de nodos, kubelet y kubectl. ### Controlador de Nodos El controlador de nodos es un componente maestro en Kubernetes que gestiona diferentes aspectos de los nodos. El controlador juega múltiples papeles en la vida de un nodo. El primero es asignar un bloque CIDR (Class Inter-Domain Routing) al nodo cuando este se registra (si la asignación CIDR está activada) que contendrá las IPs disponibles para asignar a los objetos que se ejecutarán en ese nodo. El segundo es mantener actualizada la lista interna del controlador con la lista de máquinas disponibles a través del proveedor de servicios en la nube. Cuando Kubernetes se ejecuta en la nube, si un nodo deja de responder, el controlador del nodo preguntará al proveedor si la máquina virtual de dicho nodo continúa estando disponible. Si no lo está, el controlador borrará dicho nodo de su lista interna. El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue reintentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos. En versiones de Kubernetes previas a 1.13, `NodeStatus` es el `heartbeat` del nodo. Empezando con 1.13 la funcionalidad de `node lease` se introduce como alfa (`NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md) ). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto `Lease` asociado en el namespace `kube-node-lease` que se renueva periódicamente y ambos, el `NodeStatus` y el `Lease` son considerados como `hearbeats` del nodo. `Node leases` se renuevan con frecuencia, mientras que `NodeStatus` se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los `node lease` más ligeros que `NodeStatus`, los `hearbeats` resultan más económicos desde las perspectivas de escalabilidad y de rendimiento. En Kubernetes 1.4, se actualizó la lógica del controlador de nodos para gestionar mejor los casos en los que un gran número de nodos tiene problemas alcanzando el nodo máster (Por ejemplo, cuando el nodo máster es el que tiene un problema de red). Desde 1.4, el controlador de nodos observa el estado de todos los nodos en el clúster cuando toma decisiones sobre desalojo de pods. En la mayoría de los casos, el controlador de nodos limita el ritmo de desalojo `--node-eviction-rate` (0.1 por defecto) por segundo, lo que significa que no desalojará pods de más de un nodo cada diez segundos. El comportamiento de desalojo de nodos cambia cuando un nodo en una zona de disponibilidad tiene problemas. El controlador de nodos comprobará qué porcentaje de nodos en la zona no se encuentran en buen estado (es decir, que su condición `NodeReady` tiene un valor `ConditionUnknown` o `ConditionFalse`) al mismo tiempo. Si la fracción de nodos con problemas es de al menos `--unhealthy-zone-threshold` (0.55 por defecto) entonces se reduce el ratio de desalojos: si el clúster es pequeño (por ejemplo, tiene menos o los mismos nodos que `--large-cluster-size-threshold` - 50 por defecto) entonces los desalojos se paran. Sino, el ratio se reduce a `--secondary-node-eviction-rate` (0.01 por defecto) por segundo. La razón por la que estas políticas se implementan por zonas de disponibilidad es debido a que una zona puede quedarse aislada del nodo máster mientras que las demás continúan conectadas. Si un clúster no comprende más de una zona, todo el clúster se considera una única zona. La razón principal por la que se distribuyen nodos entre varias zonas de disponibilidad es para que el volumen de trabajo se transfiera a aquellas zonas que se encuentren en buen estado cuando una de las zonas se caiga. Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se restablezca la conectividad. Desde la versión 1.6 de Kubernetes el controlador de nodos también es el responsable de desalojar pods que están ejecutándose en nodos con `NoExecute` taints, cuando los pods no permiten dichos taints. De forma adicional, como una funcionalidad alfa que permanece deshabilitada por defecto, el `NodeController` es responsable de añadir taints que se corresponden con problemas en los nodos del tipo nodo inalcanzable o nodo no preparado. En [esta sección de la documentación](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) hay más detalles acerca de los taints `NoExecute` y de la funcionalidad alfa. Desde la versión 1.8, el controlador de nodos puede ser responsable de la creación de taints que representan condiciones de nodos. Esta es una funcionalidad alfa en 1.8. ### Auto-Registro de Nodos Cuando el atributo del kubelet `--register-node` está habilitado (el valor por defecto), el kubelet intentará auto-registrarse con el API Server. Este es el patrón de diseño preferido, y utilizado por la mayoría de distribuciones. Para auto-registro, el kubelet se inicia con las siguientes opciones: * `--kubeconfig` - La ruta a las credenciales para autentificarse con el API Server. * `--cloud-provider` - Cómo comunicarse con un proveedor de servicios para leer meta-datos sobre si mismo. * `--register-node` - Registro automático con el API Server. * `--register-with-taints` - Registro del nodo con la lista de taints proporcionada (separada por comas `=:`). Esta opción se ignora si el atributo`--register-node` no está habilitado. * `--node-ip` - La dirección IP del nodo. * `--node-labels` - Etiquetas para añadir al nodo durante el registro en el clúster (ver las restricciones que impone el [NodeRestriction admission plugin](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) en 1.13+). * `--node-status-update-frequency` - Especifica la frecuencia con la que el nodo envía información de estado al máster. Cuando el [Node authorization mode](https://kubernetes.io/docs/reference/access-authn-authz/node/) y el [NodeRestriction admission plugin](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) están habilitados, los kubelets sólo tienen permisos para crear/modificar su propio objeto `Node`. ### Administración Manual de Nodos Los administradores del clúster pueden crear y modificar objetos `Node`. Si un administrador desea crear objetos `Node` de forma manual, debe levantar kubelet con el atributo `--register-node=false`. Los administradores del clúster pueden modificar recursos `Node` (independientemente del valor de `--register-node`). Dichas modificaciones incluyen crear etiquetas en el nodo y/o marcarlo como no-planificable (de forma que pods no pueden ser planificados para instalación en el nodo). Etiquetas y selectores de nodos pueden utilizarse de forma conjunta para controlar las tareas de planificación, por ejemplo, para determinar un subconjunto de nodos elegibles para ejecutar un pod. Marcar un nodo como no-planificable impide que nuevos pods sean planificados en dicho nodo, pero no afecta a ninguno de los pods que existían previamente en el nodo. Esto resulta de utilidad como paso preparatorio antes de reiniciar un nodo, etc. Por ejemplo, para marcar un nodo como no-planificable, se ejecuta el siguiente comando: kubectl cordon $NODENAME #### Nota: Los pods creados por un controlador DaemonSet ignoran el planificador de Kubernetes y no respetan el atributo no-planificable de un nodo. Se asume que los daemons pertenecen a la máquina huésped y que se ejecutan incluso cuando esta está siendo drenada de aplicaciones en preparación de un reinicio. ### Capacidad del Nodo La capacidad del nodo (número de CPUs y cantidad de memoria) es parte del objeto `Node`. Normalmente, nodos se registran a sí mismos y declaran sus capacidades cuando el objeto `Node` es creado. Si se está haciendo [administración manual](https://kubernetes.io/es/docs/concepts/architecture/_print/#administraci%C3%B3n-manual-de-nodos) , las capacidades deben configurarse en el momento de añadir el nodo. El planificador de Kubernetes asegura la existencia de recursos suficientes para todos los pods que se ejecutan en un nodo. Comprueba que la suma recursos solicitados por los pods no exceda la capacidad del nodo. Incluye todos los pods iniciados por el kubelet, pero no tiene control sobre contenedores iniciados directamente por el [runtime de contenedores](https://kubernetes.io/es/docs/concepts/overview/components/#node-components) ni sobre otros procesos que corren fuera de contenedores. Para reservar explícitamente recursos en la máquina huésped para procesos no relacionados con pods, sigue este tutorial [reserva de recursos para daemons de sistema](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) . Objeto API ---------- Un nodo es un recurso principal dentro de la REST API de Kubernetes. Más detalles sobre el objeto en la API se puede encontrar en: [Object Node API](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#node-v1-core) . 2 - Comunicación entre Nodos y el Plano de Control ================================================== Este documento cataloga las diferentes vías de comunicación entre el [kube-apiserver](https://kubernetes.io/es/docs/reference/generated/kube-apiserver/ "Componente del plano de control que expone la API de Kubernetes.") y el [clúster](https://kubernetes.io/es/docs/reference/glossary/?all=true#term-cluster "Un conjunto de máquinas, llamadas nodos, que ejecutan aplicaciones en contenedores administradas por Kubernetes.") de Kubernetes. La intención es permitir a los usuarios personalizar sus instalaciones para proteger sus configuraciones de red de forma que el clúster pueda ejecutarse en una red insegura (o en un proveedor de servicios en la nube con direcciones IP públicas) Nodo al Plano de Control ------------------------ La API de Kubernetes usa el patrón de "hub-and-spoke". Todo uso de la API desde los nodos (o los pods que ejecutan) termina en el servidor API. Ninguno de los otros componentes del plano de control está diseñado para exponer servicios remotos. El servidor API está configurado para escuchar conexiones remotas en un puerto seguro HTTPS (normalmente 443) con una o más formas de [autenticación](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) de cliente habilitada. Una o más formas de [autorización](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) deben ser habilitadas, especialmente si las [peticiones anónimas](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests) o los [tokens de cuenta de servicio](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) están permitidos. Los nodos deben ser aprovisionados con el [certificado](https://kubernetes.io/es/docs/tasks/tls/managing-tls-in-a-cluster/ "Un fichero criptográficamente seguro usado para validar el acceso al clúster de Kubernetes.") raíz público del clúster, de modo que puedan conectarse de forma segura al servidor API en conjunto con credenciales de cliente válidas. Un buen enfoque es que las credenciales de cliente proporcionadas al kubelet estén en forma de certificado de cliente. Véase el [TLS bootstrapping de kubelet](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) para ver cómo aprovisionar certificados de cliente kubelet de forma automática. Los [Pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/ "El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.") que deseen conectar con el apiserver pueden hacerlo de forma segura a través de una cuenta de servicio, de esta forma Kubernetes inserta de forma automática el certificado raíz público y un bearer token válido en el pod cuando es instanciado. El servicio `kubernetes` (en todos los namespaces) se configura con una dirección IP virtual que es redireccionada (via `[kube-proxy](https://kubernetes.io/es/docs/reference/command-line-tools-reference/kube-proxy/ "kube-proxy es un componente de red que se ejecuta en cada nodo del clúster.") `) al punto de acceso HTTPS en el apiserver. Los componentes del plano de control también se comunican con el apiserver del clúster a través de un puerto seguro. Como resultado, el modo de operación para las conexiones desde los nodos y pods que se ejecutan en los nodos al plano de control es seguro por defecto y puede ejecutarse en redes públicas y/o inseguras. Plano de control al nodo ------------------------ Hay dos vías de comunicación primaria desde el plano de control (apiserver) y los nodos. La primera es desde el apiserver al proceso [kubelet](https://kubernetes.io/es/docs/reference/generated/kubelet "Agente que se ejecuta en cada nodo de un clúster. Se asegura de que los contenedores estén corriendo en un pod.") que se ejecuta en cada nodo del clúster. La segunda es desde el apiserver a cualquier nodo, pod o servicio a través de la funcionalidad _proxy_ del apiserver. ### Apiserver al kubelet Las conexiones del apiserver al kubelet se utilizan para: * Recoger entradas de registro de pods. * Conectar (a través de `kubectl`) con pods en ejecución. * Facilitar la funcionalidad `port-forwarding` del kubelet. Estas conexiones terminan en el endpoint HTTPS del kubelet. Por defecto, el apiserver no verifica el certificado del kubelet, por lo que la conexión es vulnerable a ataques del tipo "ataque de intermediario" ("man-in-the-middle"), e **insegura** para conectar a través de redes públicas y/o no fiables. Para verificar esta conexión, se utiliza el atributo `--kubelet-certificate-authority` que provee el apiserver con un certificado raíz con el que verificar el certificado del kubelet. Si esto no es posible, se utiliza un [túnel SSH](https://kubernetes.io/es/docs/concepts/architecture/_print/#ssh-tunnels) entre el apiserver y el kubelet para conectar a través de redes públicas o de no confianza. Finalmente, la [autenticación y/o autorización al kubelet](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) debe ser habilitada para proteger la API de kubelet. ### Apiserver para nodos, pods y servicios Las conexiones desde el apiserver a un nodo, pod o servicio se realizan por defecto con conexiones HTTP simples y, por consiguiente, no son autenticadas o encriptadas. Pueden ser ejecutadas en una conexión segura HTTPS con el prefijo `https:` al nodo, pod o nombre de servicio en la URL de la API, pero no validarán el certificado proporcionado por el punto final HTTPS ni proporcionarán las credenciales del cliente. Por tanto, aunque la conexión estará cifrada, no proporcionará ninguna garantía de integridad. Estas conexiones **no son actualmente seguras** para ejecutarse en redes públicas o no fiables. ### Túneles SSH Kubernetes ofrece soporte para [túneles SSH](https://www.ssh.com/academy/ssh/tunneling) que protegen la comunicación entre el plano de control y los nodos. En este modo de configuración, el apiserver inicia un túnel SSH a cada nodo en el clúster (conectando al servidor SSH en el puerto 22) y transfiere todo el tráfico destinado a un kubelet, nodo, pod o servicio a través del túnel. El túnel garantiza que dicho tráfico no es expuesto fuera de la red en la que se ejecutan los nodos. #### Nota: Los túneles SSH están actualmente obsoletos, por lo que no deberías optar por utilizarlos a menos que sepas lo que estás haciendo. El [Konnectivity service](https://kubernetes.io/es/docs/concepts/architecture/_print/#konnectivity-service) es un sustituto de este canal de comunicación. ### Servicio Konnectivity FEATURE STATE: `Kubernetes v1.18 [beta]` En sustitución de los túneles SSH, el servicio Konnectivity proporciona un proxy de nivel TCP para la comunicación entre el plano de control y el clúster. El servicio Konnectivity consta de dos partes: el servidor Konnectivity en la red del plano de control y los agentes Konnectivity en la red de nodos. Los agentes Konnectivity inician conexiones con el servidor Konnectivity y mantienen las conexiones de red. Tras habilitar el servicio Konnectivity, todo el tráfico del plano de control a los nodos pasa por estas conexiones. Sigue la [Tarea del servicio Konnectivity](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) para configurar el servicio Konnectivity en tu clúster. Siguientes pasos ---------------- * [Componentes del plano de control de Kubernetes](https://kubernetes.io/es/docs/concepts/overview/components/#control-plane-components) * Más información sobre el [modelo Hubs y Spoke](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors) * [Cómo proteger un clúster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) * Más información sobre la [API de Kubernetes](https://kubernetes.io/es/docs/concepts/overview/kubernetes-api/) * [Configurar el Servicio Konnectivity](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/) * Utilizar el [Port Forwarding para acceder a aplicaciones en un clúster](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) * Aprenda [Fetch logs para Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs) , [use kubectl port-forward](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod) 3 - Conceptos subyacentes del Cloud Controller Manager ====================================================== El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes. El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en implementar nuevos proveedores de servicios y para migrar los existentes del antiguo modelo al nuevo CCM. Este documento describe los conceptos tras el Cloud Controller Manager y detalla sus funciones asociadas. En la siguiente imagen, se puede visualizar la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: ![Arquitectura previa a CCM](https://kubernetes.io/images/docs/pre-ccm-arch.png) Diseño ------ En el diagrama anterior, Kubernetes y el proveedor de servicios en la nube están integrados a través de diferentes componentes: * Kubelet * Kubernetes controller manager * Kubernetes API server El CCM consolida toda la lógica dependiente de la nube de estos tres componentes para crear un punto de integración único. La nueva arquitectura con CCM se muestra a continuación: ![Arquitectura CCM](https://kubernetes.io/images/docs/post-ccm-arch.png) Componentes del CCM ------------------- El CCM secciona parte de la funcionalidad del Kubernetes Controller Manager (KCM) y la ejecuta como procesos independientes. Específicamente, aquellos controladores en el KCM que son dependientes de la nube: * Controlador de Nodos * Controlador de Volúmenes * Controlador de Rutas * Controlador de Servicios En la versión 1.9, el CCM se encarga de la ejecución de los siguientes controladores: * Controlador de Nodos * Controlador de Rutas * Controlador de Servicios #### Nota: El controlador de volúmenes se dejó fuera del CCM de forma explícita. Debido a la complejidad que ello requería y a los esfuerzos existentes para abstraer lógica de volúmenes específica a proveedores de servicios, se decidió que el controlador de volúmenes no fuese movido al CCM. El plan original para habilitar volúmenes en CCM era utilizar volúmenes Flex con soporte para volúmenes intercambiables. Sin embargo, otro programa conocido como CSI (Container Storage Interface) se está planeando para reemplazar Flex. Considerando todo lo anterior, se ha decidido esperar hasta que CSI esté listo. Funciones del CCM ----------------- El CCM hereda sus funciones de componentes que son dependientes de un proveedor de servicios en la nube. Esta sección se ha estructurado basado en dichos componentes: ### 1\. Kubernetes Controller Manager La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en la sección anterior, el CCM es responsable de los siguientes circuitos de control: * Controlador de Nodos * Controlador de Rutas * Controlador de Servicios #### Controlador de Nodos El controlador de nodos es responsable de inicializar un nodo obteniendo información del proveedor de servicios sobre los nodos ejecutándose en el clúster. El controlador de nodos lleva a cabo las siguientes funciones: 1. Inicializa un nodo con etiquetas de región y zona específicas del proveedor. 2. Inicializa un nodo con detalles de la instancia específicos del proveedor, como por ejemplo, el tipo o el tamaño. 3. Obtiene las direcciones de red del nodo y su hostname. 4. En caso de que el nodo deje de responder, comprueba la nube para ver si el nodo ha sido borrado. Si lo ha sido, borra el objeto nodo en Kubernetes. #### Controlador de Rutas El controlador de Rutas es responsable de configurar rutas en la nube para que contenedores en diferentes nodos dentro de un clúster kubernetes se puedan comunicar entre sí. #### Controlador de Servicios El controlador de servicios es responsable de monitorizar eventos de creación, actualización y borrado de servicios. Basándose en el estado actual de los servicios en el clúster Kubernetes, configura balanceadores de carga del proveedor (como Amazon ELB, Google LB, or Oracle Cloud Infrastructure Lb) de forma que estos reflejen los servicios definidos en Kubernetes. Adicionalmente, se asegura de que los sistemas de apoyo de servicios para balanceadores de carga en la nube se encuentren actualizados. ### 2\. Kubelet El controlador de nodos incluye la funcionalidad del kubelet que es dependiente de la nube. Previa a la introducción de CCM, el kubelet era responsable de inicializar un nodo con detalles específicos al proveedor como direcciones IP, etiquetas de región/zona y tipo de instancia. La introducción de CCM transfiere esta inicialización del kubelet al CCM. En este nuevo modelo, el kubelet inicializa un nodo sin información específica del proveedor de servicios. Sin embargo, añade un `taint` al nodo recién creado de forma que este no esté disponible para el planificador hasta que el CCM completa el nodo con la información específica del proveedor. Sólo entonces elimina el `taint` y el nodo se vuelve accesible. Mecanismo de Plugins (extensiones) ---------------------------------- El Cloud Controller Manager utiliza interfaces Go(lang), lo que permite que implementaciones de cualquier proveedor de servicios sean conectadas. Específicamente, utiliza el CloudProvider Interface definido [aquí](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62) . La implementación de los cuatro controladores referenciados en este documento, algunas estructuras de inicialización junto con el interface CloudProvider, permanecerán como parte del núcleo de Kubernetes. Para más información sobre el desarrollo de extensiones/plugins, consultar [Desarrollo del CCM](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/) . Autorización ------------ Esta sección divide el nivel de acceso requerido por varios objetos API para que el CCM pueda llevar acabo sus operaciones. ### Controlador de Nodos El controlador de nodos sólo opera con objetos Nodo. Necesita de acceso total para obtener, listar, crear, actualizar, parchear, monitorizar y borrar objetos Nodo. v1/Node: * Get * List * Create * Update * Patch * Watch * Delete ### Controlador de Rutas El controlador de rutas permanece a la escucha de eventos de creación de nodos y configura sus rutas. Necesita acceso a los objetos Nodo. v1/Node: * Get ### Controlador de Servicios El controlador de servicios permanece a la escucha de eventos de creación, actualización y borrado de objetos Servicio, y se encarga de configurar los endpoints para dichos servicios. Para acceder a los objetos Servicio, necesita permisos para listar y monitorizar. Para el mantenimiento de servicios necesita permisos para parchear y actualizar. Para configurar endpoints para los servicios necesita permisos para crear, listar, obtener, monitorizar y actualizar. v1/Service: * List * Get * Watch * Patch * Update ### Otros La implementación del núcleo de CCM requiere acceso para crear eventos, y para asegurar la seguridad de operaciones; necesita acceso para crear ServiceAccounts. v1/Event: * Create * Patch * Update v1/ServiceAccount: * Create El RBAC ClusterRole para CCM se muestra a continuación: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cloud-controller-manager rules: - apiGroups: - "" resources: - events verbs: - create - patch - update - apiGroups: - "" resources: - nodes verbs: - '*' - apiGroups: - "" resources: - nodes/status verbs: - patch - apiGroups: - "" resources: - services verbs: - list - patch - update - watch - apiGroups: - "" resources: - serviceaccounts verbs: - create - apiGroups: - "" resources: - persistentvolumes verbs: - get - list - update - watch - apiGroups: - "" resources: - endpoints verbs: - create - get - list - watch - update Implementaciones de Proveedores ------------------------------- Los siguientes proveedores de servicios en la nube han implementado CCMs: * [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) * [Oracle](https://github.com/oracle/oci-cloud-controller-manager) * [Azure](https://github.com/kubernetes/cloud-provider-azure) * [GCP](https://github.com/kubernetes/cloud-provider-gcp) * [AWS](https://github.com/kubernetes/cloud-provider-aws) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) * [Linode](https://github.com/linode/linode-cloud-controller-manager) Administración del Clúster -------------------------- Instrucciones para configurar y ejecutar el CCM pueden encontrarse [aquí](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) . 4 - Leases ========== Los sistemas distribuidos suelen necesitar _leases_, que proporcionan un mecanismo para bloquear recursos compartidos y coordinar la actividad entre los miembros de un conjunto. En Kubernetes, el concepto de lease (arrendamiento) está representado por objetos [Lease](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/lease-v1/) en el [grupo API](https://kubernetes.io/es/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning "A set of related paths in the Kubernetes API.") de `coordination.k8s.io`, que se utilizan para capacidades críticas del sistema, como los heartbeats del nodo y la elección del líder a nivel de componente. Heartbeats del nodo ------------------- Kubernetes utiliza la API Lease para comunicar los heartbeats de los nodos kubelet al servidor API de Kubernetes. Para cada `Nodo` , existe un objeto `Lease` con un nombre que coincide en el espacio de nombres `kube-node-lease`. Analizando a detalle, cada hearbeat es una solicitud **update** a este objeto `Lease`, actualizando el campo `spec.renewTime` del objeto Lease. El plano de control de Kubernetes utiliza la marca de tiempo de este campo para determinar la disponibilidad de este «Nodo». Ve [Objetos Lease de nodos](https://kubernetes.io/es/docs/concepts/architecture/nodes/#node-heartbeats) para más detalles. Elección del líder ------------------ Kubernetes también utiliza Leases para asegurar que sólo una instancia de un componente se está ejecutando en un momento dado. Esto lo utilizan componentes del plano de control como `kube-controller-manager` y `kube-scheduler` en configuraciones de HA, donde sólo una instancia del componente debe estar ejecutándose activamente mientras las otras instancias están en espera. Identidad del servidor API -------------------------- FEATURE STATE: `Kubernetes v1.26 [beta]`(enabled by default) A partir de Kubernetes v1.26, cada `kube-apiserver` utiliza la API Lease para publicar su identidad al resto del sistema. Aunque no es particularmente útil por sí mismo, esto proporciona un mecanismo para que los clientes puedan descubrir cuántas instancias de `kube-apiserver` están operando el plano de control de Kubernetes. La existencia de los objetos leases de kube-apiserver permite futuras capacidades que pueden requerir la coordinación entre cada kube-apiserver. Puedes inspeccionar los leases de cada kube-apiserver buscando objetos leases en el namespace `kube-system` con el nombre `apiserver-`. También puedes utilizar el selector de etiquetas `apiserver.kubernetes.io/identity=kube-apiserver`: kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver NAME HOLDER AGE apiserver-07a5ea9b9b072c4a5f3d1c3702 apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05 5m33s apiserver-7be9e061c59d368b3ddaf1376e apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f 4m23s apiserver-1dfef752bcb36637d2763d1868 apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e 4m43s El hash SHA256 utilizado en el nombre del lease se basa en el nombre de host del sistema operativo visto por ese servidor API. Cada kube-apiserver debe ser configurado para utilizar un nombre de host que es único dentro del clúster. Las nuevas instancias de kube-apiserver que utilizan el mismo nombre de host asumirán los leases existentes utilizando una nueva identidad de titular, en lugar de instanciar nuevos objetos leases. Puedes comprobar el nombre de host utilizado por kube-apiserver comprobando el valor de la etiqueta `kubernetes.io/hostname`: kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml apiVersion: coordination.k8s.io/v1 kind: Lease metadata: creationTimestamp: "2023-07-02T13:16:48Z" labels: apiserver.kubernetes.io/identity: kube-apiserver kubernetes.io/hostname: master-1 name: apiserver-07a5ea9b9b072c4a5f3d1c3702 namespace: kube-system resourceVersion: "334899" uid: 90870ab5-1ba9-4523-b215-e4d4e662acb1 spec: holderIdentity: apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05 leaseDurationSeconds: 3600 renewTime: "2023-07-04T21:58:48.065888Z" Los leases caducados de los kube-apiservers que ya no existen son recogidos por los nuevos kube-apiservers después de 1 hora. Puedes desactivar el lease de identidades del servidor API desactivando la opción `APIServerIdentity` de los [interruptores de funcionalidades](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) . Cargas de trabajo ----------------- Tu propia carga de trabajo puede definir su propio uso de los leases. Por ejemplo, puede ejecutar un [controlador](https://kubernetes.io/es/docs/concepts/architecture/controller/ "Los controladores son bucles de control que observan el estado del clúster, y ejecutan o solicitan los cambios que sean necesarios para alcanzar el estado deseado.") en la que un miembro principal o líder realiza operaciones que sus compañeros no realizan. Tú defines un Lease para que las réplicas del controlador puedan seleccionar o elegir un líder, utilizando la API de Kubernetes para la coordinación. Si utilizas un lease, es una buena práctica definir un nombre para el lease que esté obviamente vinculado a el producto o componente. Por ejemplo, si tienes un componente denominado Ejemplo Foo, utilice un lease denominado `ejemplo-foo`. Si un operador de clúster u otro usuario final puede desplegar varias instancias de un componente, selecciona un nombre prefijo y elije un mecanismo (como el hash del nombre del despliegue) para evitar colisiones de nombres para los leases. Puedes utilizar otro enfoque siempre que consigas el mismo resultado: los distintos productos de software no entren en conflicto entre sí. 5 - Container Runtime Interface (CRI) ===================================== _CRI_ es una interfaz de plugin que permite que kubelet use una amplia variedad de container runtimes, sin necesidad de volver a compilar los componentes del clúster. Necesitas un _[container runtime](https://kubernetes.io/es/docs/setup/production-environment/container-runtimes "El Container Runtime, entorno de ejecución de un contenedor, es el software responsable de ejecutar contenedores.") _ ejecutándose en cada Nodo en tu clúster, de manera que [kubelet](https://kubernetes.io/es/docs/reference/generated/kubelet "Agente que se ejecuta en cada nodo de un clúster. Se asegura de que los contenedores estén corriendo en un pod.") pueda iniciar los [Pods](https://kubernetes.io/es/docs/concepts/workloads/pods/pod-overview/ "El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.") y sus contenedores. Container Runtime Interface (CRI) es el protocolo principal para la comunicación entre el _kubelet_ y el _Container Runtime_. La _Kubernetes Container Runtime Interface_ (CRI) define el principal protocolo de [gRPC](https://grpc.io/) para la comunicación entre los [componentes de clúster](https://kubernetes.io/es/docs/concepts/overview/components/#componentes-de-nodo) _[kubelet](https://kubernetes.io/es/docs/reference/generated/kubelet "Agente que se ejecuta en cada nodo de un clúster. Se asegura de que los contenedores estén corriendo en un pod.") _ y _[container runtime](https://kubernetes.io/es/docs/setup/production-environment/container-runtimes "El Container Runtime, entorno de ejecución de un contenedor, es el software responsable de ejecutar contenedores.") _. API --- FEATURE STATE: `Kubernetes v1.23 [stable]` Kubelet actúa como un cliente cuando se conecta al _runtime_ del contenedor a través de gRPC. El _runtime_ y los _endpoints_ del servicio de imágenes deben estar disponibles en el _runtime_ del contenedor, que se puede configurar por separado dentro de kubelet usando `--image-service-endpoint` [banderas de línea de comando](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet) . Para Kubernetes v1.35, kubelet prefiere usar CRI `v1`. Si el _runtime_ del contenedor no es compatible con `v1` del CRI, kubelet intenta negociar cualquier versión compatible anterior. Kubelet v1.35 también puede negociar CRI `v1alpha2`, pero esta versión se considera obsoleta. Si kubelet no puede negociar una versión CRI soportada, kubelet se da por vencido y no se registra como nodo. Actualizando ------------ Al actualizar Kubernetes, kubelet intenta seleccionar automáticamente la última versión de CRI al reiniciar el componente. Si eso falla, entonces la alternativa se llevará a cabo como se mencionó anteriormente. Si se requirió una rellamada de gRPC porque el _runtime_ del contenedor se ha actualizado, entonces el _runtime_ del contenedor también debe soportar la versión seleccionada inicialmente o se espera que la rellamada falle. Esto requiere un reinicio de kubelet. Siguientes pasos ---------------- * Más información sobre CRI [definición de protocolo](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto) --- # 쿠버네티스 이슈와 보안 | Kubernetes 이 섹션의 다중 페이지 출력 화면임. [여기를 클릭하여 프린트](https://kubernetes.io/ko/docs/reference/issues-security/_print/#) . [이 페이지의 일반 화면으로 돌아가기](https://kubernetes.io/ko/docs/reference/issues-security/) . 쿠버네티스 이슈와 보안 ============ * 1: [쿠버네티스 이슈 트래커](https://kubernetes.io/ko/docs/reference/issues-security/_print/#pg-980c0542a3b195a20cfd4358792e2a38) * 2: [쿠버네티스 보안과 공개 정보](https://kubernetes.io/ko/docs/reference/issues-security/_print/#pg-1f7dc06f1cc1ea2cdde4480e54d5fb34) 1 - 쿠버네티스 이슈 트래커 ================ 보안 문제를 보고하려면 [쿠버네티스 보안 공개 프로세스](https://kubernetes.io/ko/docs/reference/issues-security/security/#%EC%B7%A8%EC%95%BD%EC%A0%90-%EB%B3%B4%EA%B3%A0) 를 따른다. 쿠버네티스 코드 작업 및 공개 이슈는 [깃허브 이슈](https://github.com/kubernetes/kubernetes/issues/) 를 사용하여 추적된다. * \[잘 알려진 CVE에 대한\] 공식 리스트(/docs/reference/issues-security/official-cve-feed/) [보안 대응 위원회(Security Response Committee)](https://github.com/kubernetes/committee-security-response) 가 발표한 (보안 취약점) * [CVE-연관된 깃허브 이슈들](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) 보안에 관련된 공지사항은 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 메일 리스트로 전송된다. 2 - 쿠버네티스 보안과 공개 정보 =================== 이 페이지는 쿠버네티스 보안 및 공개 정보를 설명한다. 보안 공지 ----- 보안 및 주요 API 공지에 대한 이메일을 위해서는 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) ) 그룹에 가입한다. 취약점 보고 ------ 우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다. 보고서를 작성하려면, [쿠버네티스 버그 현상금 프로그램](https://hackerone.com/kubernetes) 에 취약점을 제출한다. 이를 통해 표준화된 응답시간으로 취약점을 분류하고 처리할 수 있다. 또한, 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml) 로 부터 예상되는 세부사항을 [security@kubernetes.io](mailto:security@kubernetes.io) 로 이메일을 보낸다. [보안 대응 위원회(Security Response Committee) 구성원](https://git.k8s.io/security/README.md#product-security-committee-psc) 의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다. ### 언제 취약점을 보고해야 하는가? * 쿠버네티스에서 잠재적인 보안 취약점을 발견했다고 생각하는 경우 * 취약성이 쿠버네티스에 어떤 영향을 미치는지 확신할 수 없는 경우 * 쿠버네티스가 의존하는 다른 프로젝트에서 취약점을 발견한 경우 * 자체 취약성 보고 및 공개 프로세스가 있는 프로젝트의 경우 직접 보고한다. ### 언제 취약점을 보고하지 말아야 하는가? * 보안을 위해 쿠버네티스 구성요소를 조정하는데 도움이 필요한 경우 * 보안 관련 업데이트를 적용하는 데 도움이 필요한 경우 * 보안 관련 문제가 아닌 경우 보안 취약점 대응 --------- 각 보고서는 보안 대응 위원회 위원들에 의해 작업일 3일 이내에 인정되고 분석된다. 이렇게 하면 [보안 릴리스 프로세스](https://git.k8s.io/security/security-release-process.md#disclosures) 가 시작된다. 보안 대응 위원회와 공유하는 모든 취약성 정보는 쿠버네티스 프로젝트 내에 있으며, 문제를 해결할 필요가 없는 한 다른 프로젝트에 전파되지 않는다. 보안 문제가 심사에서 확인된 수정, 릴리스 계획으로 이동함에 따라 리포터를 계속 업데이트할 것이다. 공개 시기 ----- 공개 날짜는 쿠버네티스 보안 대응 위원회와 버그 제출자가 협상한다. 사용자 완화가 가능해지면 가능한 빨리 버그를 완전히 공개하는 것이 좋다. 버그 또는 픽스가 아직 완전히 이해되지 않았거나 솔루션이 제대로 테스트되지 않았거나 벤더 협력을 위해 공개를 지연시키는 것이 합리적이다. 공개 기간은 즉시(특히 이미 공개적으로 알려진 경우)부터 몇 주까지다. 간단한 완화 기능이 있는 취약점의 경우 보고 날짜부터 공개 날짜까지는 7일 정도 소요될 것으로 예상된다. 쿠버네티스 보안 대응 위원회는 공개 날짜를 설정할 때 최종 결정권을 갖는다. --- # ベストプラクティス | Kubernetes これは、このセクションの複数ページの印刷可能なビューです。 [印刷するには、ここをクリックしてください](https://kubernetes.io/ja/docs/setup/best-practices/_print/#) . [このページの通常のビューに戻る](https://kubernetes.io/ja/docs/setup/best-practices/) . ベストプラクティス ========= * 1: [大規模クラスターの構築](https://kubernetes.io/ja/docs/setup/best-practices/_print/#pg-c797ee17120176c685455db89ae091a9) * 2: [複数のゾーンで動かす](https://kubernetes.io/ja/docs/setup/best-practices/_print/#pg-970615c97499e3651fd3a98e0387cefc) * 3: [ノードのセットアップの検証](https://kubernetes.io/ja/docs/setup/best-practices/_print/#pg-f89867de1d34943f1524f67a241f5cc9) * 4: [Podセキュリティ標準の強制](https://kubernetes.io/ja/docs/setup/best-practices/_print/#pg-92a61cf5b0575aa3500f7665b68127d1) * 5: [PKI証明書とその要件](https://kubernetes.io/ja/docs/setup/best-practices/_print/#pg-0394f813094b7a35058dffe5b8bacd20) 1 - 大規模クラスターの構築 =============== クラスターはKubernetesのエージェントが動作する(物理もしくは仮想の)[ノード](https://kubernetes.io/ja/docs/concepts/architecture/nodes/ "ノードはKubernetesのワーカーマシンです。") の集合で、[コントロールプレーン](https://kubernetes.io/ja/docs/reference/glossary/?all=true#term-control-plane "コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェースを公開するコンテナオーケストレーションレイヤーです。") によって管理されます。 Kubernetes v1.35 では、最大5000ノードから構成されるクラスターをサポートします。 具体的には、Kubernetesは次の基準を _全て_ 満たす構成に対して適用できるように設計されています。 * 1ノードにつきPodが110個以上存在しない * 5000ノード以上存在しない * Podの総数が150000個以上存在しない * コンテナの総数が300000個以上存在しない ノードを追加したり削除したりすることによって、クラスターをスケールできます。 これを行う方法は、クラスターがどのようにデプロイされたかに依存します。 クラウドプロバイダーのリソースクォータ ------------------- クラウドプロバイダーのクォータの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 * 次のようなクラウドリソースの増加をリクエストする * コンピューターインスタンス * CPU * ストレージボリューム * 使用中のIPアドレス * パケットフィルタリングのルールセット * ロードバランサーの数 * ネットワークサブネット * ログストリーム * クラウドプロバイダーによる新しいインスタンスの作成に対するレート制限のため、バッチで新しいノードを立ち上げるようなクラスターのスケーリング操作を通すためには、バッチ間ですこし休止を入れます。 コントロールプレーンのコンポーネント ------------------ 大きなクラスターでは、十分な計算とその他のリソースを持ったコントロールプレーンが必要になります。 特に故障ゾーンあたり1つまたは2つのコントロールプレーンインスタンスを動かす場合、最初に垂直方向にインスタンスをスケールし、垂直方向のスケーリングの効果が低下するポイントに達したら水平方向にスケールします。 フォールトトレランスを備えるために、1つの故障ゾーンに対して最低1インスタンスを動かすべきです。 Kubernetesノードは、同一故障ゾーン内のコントロールプレーンエンドポイントに対して自動的にトラフィックが向かないようにします。 しかし、クラウドプロバイダーはこれを実現するための独自の機構を持っているかもしれません。 例えばマネージドなロードバランサーを使うと、故障ゾーン _A_ にあるkubeletやPodから発生したトラフィックを、同じく故障ゾーン _A_ にあるコントロールプレーンホストに対してのみ送るように設定します。もし1つのコントロールプレーンホストまたは故障ゾーン _A_ のエンドポイントがオフラインになった場合、ゾーン _A_ にあるノードについてすべてのコントロールプレーンのトラフィックはゾーンを跨いで送信されます。それぞれのゾーンで複数のコントロールプレーンホストを動作させることは、結果としてほとんどありません。 etcdストレージ --------- 大きなクラスターの性能を向上させるために、他の専用のetcdインスタンスにイベントオブジェクトを保存できます。 クラスターを作るときに、(カスタムツールを使って)以下のようなことができます。 * 追加のetcdインスタンスを起動または設定する * イベントを保存するために[APIサーバ](https://kubernetes.io/ja/docs/concepts/overview/components/#kube-apiserver "Kubernetes APIを提供するコントロールプレーンのコンポーネントです。") を設定する 大きなクラスターのためにetcdを設定・管理する詳細については、[Operating etcd clusters for Kubernetes](https://kubernetes.io/ja/docs/tasks/administer-cluster/configure-upgrade-etcd/) または[kubeadmを使用した高可用性etcdクラスターの作成](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) を見てください。 アドオンのリソース --------- Kubernetesの[リソース制限](https://kubernetes.io/ja/docs/concepts/configuration/manage-resources-containers/) は、メモリリークの影響やPodやコンテナが他のコンポーネントに与える他の影響を最小化することに役立ちます。 これらのリソース制限は、アプリケーションのワークロードに適用するのと同様に、[アドオン](https://kubernetes.io/ja/docs/concepts/cluster-administration/addons/ "Kubernetesの機能を拡張するリソース。") のリソースにも適用されます。 例えば、ロギングコンポーネントに対してCPUやメモリ制限を設定できます。 ... containers: - name: fluentd-cloud-logging image: fluent/fluentd-kubernetes-daemonset:v1 resources: limits: cpu: 100m memory: 200Mi アドオンのデフォルト制限は、アドオンを小～中規模のKubernetesクラスターで動作させたときの経験から得られたデータに基づきます。 大規模のクラスターで動作させる場合は、アドオンはデフォルト制限よりも多くのリソースを消費することが多いです。 これらの値を調整せずに大規模のクラスターをデプロイした場合、メモリー制限に達し続けるため、アドオンが継続的に停止されるかもしれません。 あるいは、CPUのタイムスライス制限により性能がでない状態で動作するかもしれません。 クラスターのアドオンのリソース制限に遭遇しないために、多くのノードで構成されるクラスターを構築する場合は次のことを考慮します。 * いくつかのアドオンは垂直方向にスケールします - クラスターに1つのレプリカ、もしくは故障ゾーン全体にサービングされるものがあります。このようなアドオンでは、クラスターをスケールアウトしたときにリクエストと制限を増やす必要があります。 * 数多くのアドオンは、水平方向にスケールします - より多くのPod数を動作させることで性能を向上できます - ただし、とても大きなクラスターではCPUやメモリの制限も少し引き上げる必要があるかもしれません。VerticalPodAutoscalerは、提案されたリクエストや制限の数値を提供する `_recommender_` モードで動作可能です。 * いくつかのアドオンは[DaemonSet](https://kubernetes.io/ja/docs/concepts/workloads/controllers/daemonset "Podのコピーがクラスター内の一連のNodeに渡って実行されることを保証します。") によって制御され、1ノードに1つ複製される形で動作します: 例えばノードレベルのログアグリゲーターです。水平方向にスケールするアドオンの場合と同様に、CPUやメモリ制限を少し引き上げる必要があるかもしれません。 次の項目 ---- `VerticalPodAutoscaler` は、リソースのリクエストやPodの制限についての管理を手助けするためにクラスターへデプロイ可能なカスタムリソースです。 `VerticalPodAutoscaler` やクラスターで致命的なアドオンを含むクラスターコンポーネントをスケールする方法についてさらに知りたい場合は[Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) をご覧ください。 [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) は、クラスターで要求されるリソース水準を満たす正確なノード数で動作できるよう、いくつかのクラウドプロバイダーと統合されています。 [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) は、クラスターのスケールが変化したときにアドオンの自動的なリサイズをお手伝いします。 2 - 複数のゾーンで動かす ============== このページでは、複数のゾーンにまたがるKubernetesクラスターの実行について説明します。 背景 -- Kubernetesは、1つのKubernetesクラスターが複数のゾーンにまたがって実行できるように設計されており、通常これらのゾーンは _リージョン_ と呼ばれる論理的なグループ内に収まります。主要なクラウドプロバイダーは、一貫した機能を提供するゾーン( _アベイラビリティゾーン_ とも呼ばれる)の集合をリージョンと定義しており、リージョン内では各ゾーンが同じAPIとサービスを提供しています。 一般的なクラウドアーキテクチャは、あるゾーンでの障害が別のゾーンのサービスにも影響を与える可能性を最小限に抑えることを目的としています。 コントロールプレーンの動作 ------------- すべての[コントロールプレーンコンポーネント](https://kubernetes.io/ja/docs/concepts/overview/components/#control-plane-components) は、交換可能なリソースのプールとして実行され、コンポーネントごとに複製されることをサポートします。 クラスターコントロールプレーンをデプロイする場合は、複数のゾーンに渡ってコントロールプレーンコンポーネントのレプリカを配置します。可用性を重視する場合は、少なくとも3つのゾーンを選択し、個々のコントロールプレーンコンポーネント(APIサーバー、スケジューラー、etcd、クラスターコントローラーマネージャー)を少なくとも3つのゾーンに渡って複製します。クラウドコントローラーマネージャーを実行している場合は、選択したすべてのゾーンにまたがって複製する必要があります。 #### 備考: KubernetesはAPIサーバーのエンドポイントに対してゾーンを跨いだ回復力を提供しません。クラスター内のAPIサーバーの可用性を向上させるためにDNSラウンドロビン、SRVレコード、またはヘルスチェックを備えたサードパーティの負荷分散ソリューションなど、さまざまな技術を使用できます。 ノードの動作 ------ Kubernetesは、([Deployment](https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/ "クラスター上の複製されたアプリケーションを管理します。") や[StatefulSet](https://kubernetes.io/ja/docs/concepts/workloads/controllers/statefulset/ "StatefulSetはPodのデプロイとスケーリングを管理し、永続化ストレージと各Podの永続的な識別子を備えています。") のような)ワークロードリソース用のPodをクラスター内の異なるノードに自動的に分散します。この分散は、障害の影響を軽減するのに役立ちます。 ノードが起動すると、各ノードのkubeletは、Kubernetes APIで特定のkubeletを表すNodeオブジェクトに[ラベル](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/labels "ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。") を自動的に追加します。これらのラベルには[ゾーン情報](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone) を含めることができます。 クラスターが複数のゾーンまたはリージョンにまたがっている場合、ノードラベルと[Pod Topology Spread Constraints](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/topology-spread-constraints/) を組み合わせて使用することで、リージョン、ゾーン、さらには特定のノードといった障害ドメイン間でクラスター全体にPodをどのように分散させるかを制御できます。これらのヒントにより、[スケジューラー](https://kubernetes.io/ja/docs/reference/generated/kube-scheduler/ "コントロールプレーン上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。") は期待される可用性を高めてPodを配置し、関連する障害がワークロード全体に影響するリスクを低減できます 例えば、StatefulSetの3つのレプリカがすべて互いに異なるゾーンで実行されるように制約を設定できます。ワークロードごとにどのアベイラビリティゾーンを使用するかを明示的に定義しなくても、宣言的に定義できます。 ### ノードをゾーンに分散させる Kubernetesのコアがノードを作成してくれるわけではないため、自分で行うか、[Cluster API](https://cluster-api.sigs.k8s.io/) などのツールを使ってノードの管理を代行する必要があります。 Cluster APIなどのツールを使用すると、複数の障害ドメインにわたってクラスターのワーカーノードとして実行するマシンのセットを定義したり、ゾーン全体のサービスが中断した場合にクラスターを自動的に復旧するルールを定義できます。 Podの手動ゾーン割り当て ------------- [nodeSelectorの制約](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) は、作成したPodだけでなく、Deployment、StatefulSet、Jobなどのワークロードリソース内のPodテンプレートにも適用できます。 ゾーンのストレージアクセス ------------- Persistent Volumeが作成されると、Kubernetesは特定のゾーンにリンクされているすべてのPersistent Volumeにゾーンラベルを自動的に追加します。その後、[スケジューラー](https://kubernetes.io/ja/docs/reference/generated/kube-scheduler/ "コントロールプレーン上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。") は、`NoVolumeZoneConflict`条件を通じて、指定されたPersistent Volumeを要求するPodがそのボリュームと同じゾーンにのみ配置されるようにします。 ゾーンラベルの追加方法は、クラウドプロバイダーと使用しているストレージプロビジョナーによって異なる可能性があることに注意してください。正しい設定を行うために、常に利用している環境のドキュメントを参照してください。 Persistent Volume Claimには、そのクラス内のストレージが使用する障害ドメイン(ゾーン)を指定する[StorageClass](https://kubernetes.io/ja/docs/concepts/storage/storage-classes "StorageClassは管理者が利用可能なさまざまなストレージタイプを記述する方法を提供します。") を指定できます。障害ドメインまたはゾーンを認識するStorageClassの構成については、[許可されたトポロジー](https://kubernetes.io/ja/docs/concepts/storage/storage-classes/#allowed-topologies) を参照してください。 ネットワーキング -------- Kubernetes自体にはゾーンを意識したネットワーキングは含まれていません。ネットワークプラグインを使用してクラスターネットワーキングを設定できますが、そのネットワークソリューションにはゾーン固有の要素があるかもしれません。例えば、クラウドプロバイダーが`type=LoadBalancer`のServiceをサポートしている場合、ロードバランサーは与えられた接続を処理するロードバランサーのコンポーネントと同じゾーンで動作しているPodにのみトラフィックを送信する可能性があります。詳しくはクラウドプロバイダーのドキュメントを確認してください。 カスタムまたはオンプレミスのデプロイメントの場合、同様の考慮事項が適用されます。[Service](https://kubernetes.io/ja/docs/concepts/services-networking/service/ "Podの集合で実行されているアプリケーションをネットワークサービスとして公開する方法。") および[Ingress](https://kubernetes.io/ja/docs/concepts/services-networking/ingress/ "クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するAPIオブジェクトです。") の動作は、異なるゾーンの処理を含め、クラスターのセットアップ方法によって異なります。 障害回復 ---- クラスターをセットアップする際には、リージョン内のすべてのゾーンが同時にオフラインになった場合にセットアップがサービスを復旧できるかどうか、またどのように復旧させるかを考慮しておく必要があるかもしれません。例えば、ゾーン内にPodを実行できるノードが少なくとも1つあることに依存していますか？クラスタークリティカルな修復作業が、クラスター内に少なくとも1つの健全なノードがあることに依存していないことを確認してください。例えば、全てのノードが不健全な場合、少なくとも1つのノードを使用できるよう修復が完了するように、特別な[toleration](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/taint-and-toleration/ "key、value、effectの3つの必須属性からなるコアオブジェクトです。 Tolerationは、対応するTaintを持つノードやノードグループにPodをスケジューリングできるようにします。") で修復Jobを実行する必要があるかもしれません。 Kubernetesにはこの課題に対する答えはありませんが、検討すべきことです。 次の項目 ---- 設定された制約を守りつつ、スケジューラーがクラスターにPodを配置する方法については、[スケジューリング、プリエンプションと退避](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/) を参照してください。 3 - ノードのセットアップの検証 ================= ノード適合テスト -------- _ノード適合テスト_ は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスターに参加する資格があることになります。 ノードの前提条件 -------- 適合テストを実行するにはノードは通常のKubernetesノードと同じ前提条件を満たしている必要があります。 最低でもノードに以下のデーモンがインストールされている必要があります: * コンテナランタイム (Docker) * Kubelet ノード適合テストの実行 ----------- ノード適合テストを実行するには、以下の手順に従います: 1. kubeletの`--kubeconfig`オプションの値を調べます。例:`--kubeconfig=/var/lib/kubelet/config.yaml`。 このテストフレームワークはKubeletのテスト用にローカルコントロールプレーンを起動するため、APIサーバーのURLとして`http://localhost:8080`を使用します。 他にも使用できるkubeletコマンドラインパラメーターがいくつかあります: * `--cloud-provider`: `--cloud-provider=gce`を指定している場合は、テストを実行する前にこのフラグを取り除いてください。 2. 以下のコマンドでノード適合テストを実行します: # $CONFIG_DIRはKubeletのPodのマニフェストパスです。 # $LOG_DIRはテスト出力のパスです。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ registry.k8s.io/node-test:0.2 他アーキテクチャ向けのノード適合テストの実行 ---------------------- Kubernetesは他のアーキテクチャ用のノード適合テストのdockerイメージを提供しています: | Arch | Image | | --- | --- | | amd64 | node-test-amd64 | | arm | node-test-arm | | arm64 | node-test-arm64 | 選択したテストの実行 ---------- 特定のテストを実行するには、環境変数`FOCUS`を実行したいテストの正規表現で上書きします。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e FOCUS=MirrorPod \ # MirrorPodテストのみを実行します registry.k8s.io/node-test:0.2 特定のテストをスキップするには、環境変数`SKIP`をスキップしたいテストの正規表現で上書きします。 sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e SKIP=MirrorPod \ # MirrorPodテスト以外のすべてのノード適合テストを実行します registry.k8s.io/node-test:0.2 ノード適合テストは、[node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md) のコンテナ化されたバージョンです。 デフォルトでは、すべての適合テストが実行されます。 理論的には、コンテナを構成し必要なボリュームを適切にマウントすれば、どのノードのe2eテストも実行できます。しかし、不適合テストを実行するためにはより複雑な設定が必要となるため、**適合テストのみを実行することを強く推奨します**。 注意事項 ---- * このテストでは、ノード適合テストイメージや機能テストで使用されるコンテナのイメージなど、いくつかのdockerイメージがノード上に残ります。 * このテストでは、ノード上にデッドコンテナが残ります。これらのコンテナは機能テスト中に作成されます。 4 - Podセキュリティ標準の強制 ================== このページでは、[Podセキュリティの標準](https://kubernetes.io/ja/docs/concepts/security/pod-security-standards) を強制する際のベストプラクティスの概要を説明します。 ビルトインPodセキュリティアドミッションコントローラーの使用 ------------------------------- FEATURE STATE: `Kubernetes v1.25 [stable]` [Podセキュリティアドミッションコントローラー](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podsecurity) は、非推奨のPodSecurityPolicyを置き換えます。 ### すべてのNamespaceに設定する 設定が全く無いNamespaceは、クラスターのセキュリティモデルにおいて重大な弱点とみなすべきです。 各Namespaceで発生するワークロードのタイプを時間をかけて分析し、Podセキュリティ標準を参照しながら、それぞれに適切なレベルを決定することを推奨します。 また、ラベルのないNamespaceは、まだ評価されていないことだけを示すべきです。 すべてのNamespaceのワークロードが同じセキュリティ要件を持つというシナリオでは、PodSecurityラベルを一括適用する方法を[例](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) で説明しています。 ### 最小特権の原則を採用する 理想的な世界では、すべてのNamespaceのPodが`restricted`ポリシーの要件を満たすでしょう。 しかし、ワークロードの中には正当な理由で昇格した特権を必要とするものもあるため、それは不可能であり、現実的でもありません。 * `privileged`ワークロードを許可するNamespaceは、適切なアクセス制御を確立し、実施すべきである。 * 最小権限のNamespaceで実行されるワークロードについては、そのワークロードのセキュリティ要件に関するドキュメントを整備する。可能であれば、それらの要件がどのように制約される可能性があるのかを考慮する。 ### マルチモード戦略の採用 Podセキュリティアドミッションコントローラーの`audit`と`warn`モードを使用すると、既存のワークロードを破壊することなく、Podに関する重要なセキュリティインサイトを簡単に収集できます。 すべてのNamespaceでこれらのモードを有効にし、最終的に`enforce`したいレベルやバージョンに設定するのがよい方法です。 このフェーズで生成される警告と監査注釈は、その状態への指針となります。 ワークロード作成者が希望のレベルに収まるように変更することを期待している場合は、`warn`モードを有効にしてください。 監査ログを使用して、希望のレベルに収まるように変更を監視/推進することを期待している場合は、`audit`モードを有効にしてください。 `enforce`モードが希望通りの値に設定されている場合でも、これらのモードはいくつかの異なる方法で役立ちます。 * `warn`を`enforce`と同じレベルに設定すると、バリデーションを通過しないPod(またはPodテンプレートを持つリソース)を作成しようとしたときに、クライアントが警告を受け取るようになります。これにより、対象のリソースを更新して準拠させることができます。 * `enforce`を特定の最新バージョンではないに固定するNamespaceでは、`audit`と`warn`モードを`enforce`と同じレベルに設定するが、最新バージョンに対して設定することで、以前のバージョンでは許可されていたが、現在のベストプラクティスでは許可されていない設定を可視化することができます。 サードパーティによる代替案 ------------- **備考:** このセクションでは、Kubernetesが必要とする機能を提供するサードパーティープロジェクトにリンクしています。これらのプロジェクトはアルファベット順に記載されていて、Kubernetesプロジェクトの作者は責任を持ちません。このリストにプロジェクトを追加するには、変更を提出する前に[content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) をお読みください。[詳細はこちら。](https://kubernetes.io/ja/docs/setup/best-practices/_print/#third-party-content-disclaimer) Kubernetesエコシステムでは、セキュリティプロファイルを強制するための他の選択肢も開発されています。 * [Kubewarden](https://github.com/kubewarden) * [Kyverno](https://kyverno.io/policies/) * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) ビルトインソリューション(PodSecurityアドミッションコントローラーなど)とサードパーティツールのどちらを選ぶかは、あなたの状況次第です。 どのようなソリューションを評価する場合でも、サプライチェーンの信頼が非常に重要です。最終的には、前述のアプローチのどれを使っても、何もしないよりはましでしょう。 5 - PKI証明書とその要件 =============== Kubernetesでは、TLS認証のためにPKI証明書が必要です。 [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) でKubernetesをインストールする場合、必要な証明書は自動で生成されます。 自身で証明書を作成することも可能です。例えば、秘密鍵をAPIサーバーに保持しないことで、管理をよりセキュアにする場合が挙げられます。 本ページでは、クラスターに必要な証明書について説明します。 クラスターではどのように証明書が使われているのか ------------------------ Kubernetesは下記の用途でPKIを必要とします: * kubeletがAPIサーバーの認証をするためのクライアント証明書 * APIサーバーがkubeletと通信するためのkubeletの[サーバー証明書](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates) * APIサーバーのエンドポイント用サーバー証明書 * クラスターの管理者がAPIサーバーの認証を行うためのクライアント証明書 * APIサーバーがkubeletと通信するためのクライアント証明書 * APIサーバーがetcdと通信するためのクライアント証明書 * controller managerがAPIサーバーと通信するためのクライアント証明書およびkubeconfig * スケジューラーがAPIサーバーと通信するためのクライアント証明書およびkubeconfig * [front-proxy](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 用のクライアント証明書およびサーバー証明書 #### 備考: `front-proxy`証明書は、[Kubernetes APIの拡張](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-extension-api-server/) をサポートするためにkube-proxyを実行する場合のみ必要です。 さらに、etcdはクライアントおよびピア間の認証に相互TLS通信を実装しています。 証明書の保存場所 -------- kubeadmを使用してKubernetesをインストールする場合、ほとんどの証明書は`/etc/kubernetes/pki`に保存されます。このドキュメントの全てのパスは、そのディレクトリの相対パスを表します。 ただしユーザーアカウントの証明書に関しては、kubeadmは`/etc/kubernetes`に配置します。 手動で証明書を設定する ----------- もしkubeadmに必要な証明書の生成を望まない場合、それらを単一ルート認証局を使って作成するか、全ての証明書を提供することで作成できます。 自身の認証局を作成する詳細については、[証明書を手動で生成する](https://kubernetes.io/ja/docs/tasks/administer-cluster/certificates/) を参照してください。 証明書の管理についての詳細は、[kubeadmによる証明書管理](https://kubernetes.io/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) を参照してください。 ### 単一ルート認証局 管理者によりコントロールされた、単一ルート認証局の作成が可能です。このルート認証局は複数の中間認証局を作る事が可能で、作成はKubernetes自身に委ねます。 必要な認証局: | パス | デフォルトCN | 説明 | | --- | --- | --- | | ca.crt,key | kubernetes-ca | Kubernetes全体の認証局 | | etcd/ca.crt,key | etcd-ca | etcd用 | | front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
用 | 上記の認証局に加えて、サービスアカウント管理用に公開鍵/秘密鍵のペア(`sa.key`と`sa.pub`)を取得する事が必要です。 次の例は、前の表で示されたCAのキーと証明書を示しています: /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/ca.key /etc/kubernetes/pki/etcd/ca.crt /etc/kubernetes/pki/etcd/ca.key /etc/kubernetes/pki/front-proxy-ca.crt /etc/kubernetes/pki/front-proxy-ca.key ### 全ての証明書 CAの秘密鍵をクラスターにコピーしたくない場合、自身で全ての証明書を作成できます。 必要な証明書: | デフォルトCN | 親認証局 | 組織 | 種類 | ホスト名 (SAN) | | --- | --- | --- | --- | --- | | kube-etcd | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | | kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | | kube-etcd-healthcheck-client | etcd-ca | | client | | | kube-apiserver-etcd-client | etcd-ca | | client | | | kube-apiserver | kubernetes-ca | | server | ``, ``, ``, `[1]` | | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | #### 備考: `kube-apiserver-kubelet-client`にスーパーユーザーグループ`system:masters`を使用する代わりに、より権限の低いグループを使用することができます。 そのために、kubeadmは`kubeadm:cluster-admins`グループを使用します。 \[1\]: クラスターに接続するIPおよびDNS名( [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`) ここで`種類`は、一つまたは複数のx509の鍵用途にマッピングされており、これは[CertificateSigningRequest](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1#CertificateSigningRequest) の`.spec.usages`にも記載されています: | 種類 | 鍵の用途 | | --- | --- | | server | digital signature, key encipherment, server auth | | client | digital signature, key encipherment, client auth | #### 備考: 上記に挙げられたホスト名(SAN)は、クラスターを動作させるために推奨されるものです。 特別なセットアップが求められる場合、全てのサーバー証明書にSANを追加する事ができます。 #### 備考: kubeadm利用者のみ: * 秘密鍵なしでCA証明書をクラスターにコピーするシナリオは、kubeadmドキュメントの外部認証局の項目で言及されています。 * kubeadmでPKIを生成すると、`kube-etcd`、`kube-etcd-peer`および `kube-etcd-healthcheck-client`証明書は外部etcdを利用するケースでは生成されない事に留意してください。 ### 証明書のパス 証明書は推奨パスに配置するべきです([kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) を使用する場合と同様)。 パスは場所に関係なく与えられた引数で特定されます。 | デフォルトCN | 鍵の推奨パス | 証明書の推奨パス | コマンド | 鍵を指定する引数 | 証明書を指定する引数 | | --- | --- | --- | --- | --- | --- | | etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | \--etcd-cafile | | kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | \--etcd-keyfile | \--etcd-certfile | | kubernetes-ca | ca.key | ca.crt | kube-apiserver | | \--client-ca-file | | kubernetes-ca | ca.key | ca.crt | kube-controller-manager | \--cluster-signing-key-file | \--client-ca-file, --root-ca-file, --cluster-signing-cert-file | | kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | \--tls-private-key-file | \--tls-cert-file | | kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | \--kubelet-client-key | \--kubelet-client-certificate | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | \--requestheader-client-ca-file | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | \--requestheader-client-ca-file | | front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | \--proxy-client-key-file | \--proxy-client-cert-file | | etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | \--trusted-ca-file, --peer-trusted-ca-file | | kube-etcd | etcd/server.key | etcd/server.crt | etcd | \--key-file | \--cert-file | | kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | \--peer-key-file | \--peer-cert-file | | etcd-ca | | etcd/ca.crt | etcdctl | | \--cacert | | kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | \--key | \--cert | サービスアカウント用の鍵ペアについても同様です。 | 秘密鍵のパス | 公開鍵のパス | コマンド | 引数 | | --- | --- | --- | --- | | sa.key | | kube-controller-manager | service-account-private | | | sa.pub | kube-apiserver | service-account-key | 次の例は、自分自身で全てのキーと証明書を生成している場合に提供する必要があるファイルパスを[前の表](https://kubernetes.io/ja/docs/setup/best-practices/_print/#certificate-paths) から示しています: /etc/kubernetes/pki/etcd/ca.key /etc/kubernetes/pki/etcd/ca.crt /etc/kubernetes/pki/apiserver-etcd-client.key /etc/kubernetes/pki/apiserver-etcd-client.crt /etc/kubernetes/pki/ca.key /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/front-proxy-ca.key /etc/kubernetes/pki/front-proxy-ca.crt /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/etcd/server.key /etc/kubernetes/pki/etcd/server.crt /etc/kubernetes/pki/etcd/peer.key /etc/kubernetes/pki/etcd/peer.crt /etc/kubernetes/pki/etcd/healthcheck-client.key /etc/kubernetes/pki/etcd/healthcheck-client.crt /etc/kubernetes/pki/sa.key /etc/kubernetes/pki/sa.pub ユーザーアカウント用に証明書を設定する ------------------- 管理者アカウントおよびサービスアカウントは手動で設定しなければなりません。 | ファイル名 | クレデンシャル名 | デフォルトCN | O (in Subject) | | --- | --- | --- | --- | | admin.conf | default-admin | kubernetes-admin | `` | | super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters | | kubelet.conf | default-auth | system:node:`` (備考を参照) | system:nodes | | controller-manager.conf | default-controller-manager | system:kube-controller-manager | | | scheduler.conf | default-scheduler | system:kube-scheduler | | #### 備考: `kubelet.conf`における``の値は**必ず**APIサーバーに登録されたkubeletのノード名と一致しなければなりません。詳細は、[Node Authorization](https://kubernetes.io/docs/reference/access-authn-authz/node/) を参照してください。 #### 備考: 上記の例での``は実装に依存します。 一部のツールはデフォルトの`admin.conf`内の証明書に`system:masters`グループの一部として署名します。 `system:masters`は緊急用のスーパーユーザーグループであり、RBACのようなKubernetesの認証レイヤーをバイパスすることができます。 また、一部のツールはこのスーパーユーザーグループに紐づけられた証明書を含む`super-admin.conf`を生成しません。 kubeadmはkubeconfigファイル内に2つの別々の管理者証明書を生成します。 一つは`admin.conf`内にあり、`Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin`となっています。 `kubeadm:cluster-admins`は`cluster-admin` ClusterRoleに紐づけられたカスタムグループです。 このファイルは、kubeadmが管理する全てのコントロールプレーンマシン上で生成されます。 もう一つは`super-admin.conf`内にあり、`Subject: O = system:masters, CN = kubernetes-super-admin`となっています。 このファイルは`kubeadm init`が呼び出されたノード上でのみ生成されます。 1. 各コンフィグ毎に、CN名と組織を指定してx509証明書と鍵ペアを生成してください。 2. 以下のように、各コンフィグで`kubectl`を実行してください。 KUBECONFIG= kubectl config set-cluster default-cluster --server=https://:6443 --certificate-authority --embed-certs KUBECONFIG= kubectl config set-credentials --client-key .pem --client-certificate .pem --embed-certs KUBECONFIG= kubectl config set-context default-system --cluster default-cluster --user KUBECONFIG= kubectl config use-context default-system これらのファイルは以下のように利用されます: | ファイル名 | コマンド | コメント | | --- | --- | --- | | admin.conf | kubectl | クラスターの管理者設定用 | | kubelet.conf | kubelet | クラスターの各ノードに1つ必要です。 | | controller-manager.conf | kube-controller-manager | `manifests/kube-controller-manager.yaml`のマニフェストファイルに追記する必要があります。 | | scheduler.conf | kube-scheduler | `manifests/kube-scheduler.yaml`のマニフェストファイルに追記する必要があります。 | 以下のファイルは、前の表に挙げたファイルへの絶対パスを示しています: /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf --- # Seguridad | Kubernetes Versión imprimible multipagina. [Haga click aquí para imprimir](https://kubernetes.io/es/docs/concepts/security/_print/#) . [Volver a la vista normal de esta página](https://kubernetes.io/es/docs/concepts/security/) . Seguridad ========= * 1: [Vista General de Seguridad Cloud Native](https://kubernetes.io/es/docs/concepts/security/_print/#pg-04eeb110d75afc8acb2cf7a3db743985) * 2: [Políticas de Seguridad del Pod](https://kubernetes.io/es/docs/concepts/security/_print/#pg-ac71855bb20cbf21edc666e810f4103a) * 3: [Controlando el Acceso a la API de Kubernetes](https://kubernetes.io/es/docs/concepts/security/_print/#pg-4d77d1ae4c06aa14f54b385191627881) 1 - Vista General de Seguridad Cloud Native =========================================== Esta descripción general define un modelo para la seguridad de Kubernetes en el contexto de Seguridad en Cloud Native. #### Advertencia: Este modelo de seguridad en el contenedor brinda sugerencias, no es una prueba de políticas de seguridad de la información. Las 4C de Seguridad en Cloud Native ----------------------------------- Puede pensar en seguridad por capas. Las 4C de la seguridad en Cloud Native son la nube (Cloud), [Clústeres](https://kubernetes.io/es/docs/reference/glossary/?all=true#term-cluster "Un conjunto de máquinas, llamadas nodos, que ejecutan aplicaciones en contenedores administradas por Kubernetes.") , [Contenedores](https://kubernetes.io/es/docs/concepts/overview/what-is-kubernetes/#why-containers "Una imagen ligera y portátil que contiene un software y todas sus dependencias.") y Código. #### Nota: Este enfoque en capas aumenta la [defensa en profundidad](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) de la seguridad, es considerada una buena práctica en seguridad para el software de sistemas. ![](https://kubernetes.io/images/docs/4c.png) #### Las 4C de Seguridad en Cloud Native Cada capa del modelo de seguridad Cloud Native es basada en la siguiente capa más externa. La capa de código se beneficia de una base sólida (nube, clúster, contenedor) de capas seguras. No podemos garantizar la seguridad aplicando solo seguridad a nivel del código, y usar estándares de seguridad deficientes en las otras capas. Nube (Cloud) ------------ En muchos sentidos, la nube (o los servidores o el centro de datos corporativo) es la [base de computador confiable](https://es.wikipedia.org/wiki/Base_de_computador_confiable) de un clúster de Kubernetes. Si la capa de la nube es vulnerable (o configurado de alguna manera vulnerable), por consecuencia no hay garantía de que los componentes construidos encima de la base sean seguros. Cada proveedor de la nube tiene recomendaciones de seguridad para ejecutar las cargas de trabajo de forma segura en sus entornos. ### Seguridad del proveedor de la nube Si está ejecutando un clúster de Kubernetes en su propio hardware o en un proveedor de nube diferente, consulte la documentación para conocer las mejores prácticas de seguridad. A continuación, algunos enlaces a la documentación de seguridad de los proveedores de nube más populares: | | | | --- | --- |Cloud provider security | Proveedor IaaS | Link | | --- | --- | | Alibaba Cloud | [https://www.alibabacloud.com/trust-center](https://www.alibabacloud.com/trust-center) | | Amazon Web Services | [https://aws.amazon.com/security/](https://aws.amazon.com/security/) | | Google Cloud Platform | [https://cloud.google.com/security/](https://cloud.google.com/security/) | | Huawei Cloud | [https://www.huaweicloud.com/intl/es-us/securecenter/overallsafety](https://www.huaweicloud.com/intl/es-us/securecenter/overallsafety) | | IBM Cloud | [https://www.ibm.com/cloud/security](https://www.ibm.com/cloud/security) | | Microsoft Azure | [https://docs.microsoft.com/en-us/azure/security/azure-security](https://docs.microsoft.com/en-us/azure/security/azure-security) | | Oracle Cloud Infrastructure | [https://www.oracle.com/security/](https://www.oracle.com/security/) | | VMWare VSphere | [https://www.vmware.com/solutions/security/hardening-guides](https://www.vmware.com/solutions/security/hardening-guides) | ### Seguridad de la Infraestructura Sugerencias para proteger su infraestructura en un clúster de Kubernetes: | | | | --- | --- |Infrastructure security | Área de Interés para la Infraestructura de Kubernetes | Recomendación | | --- | --- | | Acceso de red al Plano de Control | Todo acceso público al [plano de control](https://kubernetes.io/es/docs/reference/glossary/?all=true#term-control-plane "The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.")
del Kubernetes en Internet no está permitido y es controlado por listas de control de acceso a la red estrictas a un conjunto de direcciones IP necesarias para administrar el clúster. | | Acceso a la red de los Nodos | Los [nodos](https://kubernetes.io/es/docs/concepts/architecture/nodes/ "Un Node, nodo en castellano, es una de las máquinas del clúster de Kubernetes.")
deben ser configurados para _solo_ aceptar conexiones (por medio de listas de control de acceso a la red) desde el plano de control en los puertos especificados y aceptar conexiones para servicios en Kubernetes del tipo NodePort y LoadBalancer. Si es posible, estos nodos no deben exponerse públicamente en Internet. | | Acceso a la API de Kubernetes del proveedor de la nube | Cada proveedor de la nube debe dar un conjunto de permisos al plano de control y nodos del Kubernetes. Es mejor otorgar al clúster el permiso de acceso al proveedor de nube siguiendo el [principio de mínimo privilegio](https://es.wikipedia.org/wiki/Principio_de_m%C3%ADnimo_privilegio)
para los recursos que necesite administrar. La [documentación del Kops](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)
ofrece información sobre las políticas y roles de IAM. | | Acceso a etcd | El acceso a [etcd](https://kubernetes.io/es/docs/tasks/administer-cluster/configure-upgrade-etcd/ "Almacén de datos persistente, consistente y distribuido de clave-valor utilizado para almacenar toda a la información del clúster de Kubernetes.")
(banco de datos de Kubernetes) debe ser limitado apenas al plano de control. Dependiendo de su configuración, debería intentar usar etcd sobre TLS. Puede encontrar mas información en la [documentación de etcd](https://github.com/etcd-io/etcd/tree/master/Documentation)
. | | Encriptación etcd | Siempre que sea posible, es una buena práctica encriptar todas las unidades de almacenamiento. Etcd mantiene el estado de todo el clúster (incluidos los Secretos), por lo que su disco debe estar encriptado. | Clúster ------- Existen dos áreas de preocupación para proteger Kubernetes: * Protección de las configuraciones de los componentes del clúster. * Protección de las aplicaciones que se ejecutan en el clúster. ### Componentes del Clúster Si desea proteger su clúster de accesos accidentales o maliciosos y adoptar buenas prácticas de seguridad, a continuación sigue estos consejos sobre [como proteger el clúster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) . ### Componentes del clúster (su aplicación) Dependiendo de la superficie de ataque de su aplicación, es posible que desee concentrarse en temas de seguridad específicos. Por ejemplo: si está ejecutando un servicio (Servicio A) que es crítico en una cadena de otros recursos y otra carga de trabajo separada (Servicio B) que es vulnerable a un ataque de sobrecarga de recursos, el riesgo de comprometer el Servicio A es alto si no limita las funciones del Servicio B. La siguiente tabla enumera áreas de atención de seguridad y recomendaciones para proteger las cargas de trabajo que se ejecutan en Kubernetes: | Áreas para la seguridad de la carga del trabajo | Recomendación | | --- | --- | | Autorización RBAC (acceso a la API Kubernetes) | [https://kubernetes.io/docs/reference/access-authn-authz/rbac/](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) | | Autenticación | [https://kubernetes.io/docs/concepts/security/controlling-access/](https://kubernetes.io/docs/concepts/security/controlling-access/) | | Administrar secretos en la aplicación (encriptar el etcd - dato en reposo) | [https://kubernetes.io/docs/concepts/configuration/secret/](https://kubernetes.io/docs/concepts/configuration/secret/)

[https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) | | Políticas de seguridad de Pod | [https://kubernetes.io/docs/concepts/policy/pod-security-policy/](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) | | Calidad de servicio (y gestión de recursos del clúster) | [https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) | | Políticas de Red | [https://kubernetes.io/docs/concepts/services-networking/network-policies/](https://kubernetes.io/docs/concepts/services-networking/network-policies/) | | TLS para Kubernetes Ingress | [https://kubernetes.io/docs/concepts/services-networking/ingress/#tls](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls) | Contenedor ---------- La seguridad de los contenedores está fuera del alcance de la guía. Aquí hay recomendaciones generales y enlaces para explorar este tema: | Área de Interés para Contenedores | Recomendación | | --- | --- | | Escáneres de vulnerabilidad de contenedores y seguridad de dependencia del sistema operativo | Como parte del paso de la creación de la imagen, se debe utilizar un escáner de contenedores para detectar vulnerabilidades. | | Firma de Imágenes y Aplicación | Firma de imágenes de contenedores para mantener un sistema confiable para el contenido de sus contenedores. | | Prohibir Usuarios Privilegiados | Al crear contenedores, consulte la documentación para crear usuarios dentro de los contenedores con el menor privilegio necesario para cumplir con el propósito del contenedor en el sistema operativo. | | Utilice el contenedor de tiempo de ejecución con el aislamiento más fuerte | Seleccione [clases del contenedor runtime](https://kubernetes.io/es/docs/concepts/containers/runtime-class/)
con el proveedor de aislamiento más fuerte. | Código ------ El código de la aplicación es una de las principales superficies de ataque sobre las que tenemos más control. Aunque la protección del código de la aplicación está fuera del tema de seguridad de Kubernetes, aquí algunas recomendaciones para proteger el código de su aplicación: ### Seguridad del código | | | | --- | --- |Code security | Áreas de Atención para el Código | Recomendación | | --- | --- | | Acceso solo a través de TLS | Si su código necesita comunicarse a través de TCP, ejecute un handshake TLS con el cliente anticipadamente. Con la excepción de algunos casos, encripte todo lo que está en tránsito. Yendo un paso más allá, es una buena idea cifrar el tráfico de red entre los servicios. Esto se puede hacer a través del proceso de autenticación mutua o [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)
, que realiza una verificación bilateral de la comunicación a través de los certificados en los servicios. | | Limitación de rangos de puertos de comunicación | Esta recomendación puede ser un poco evidente, pero siempre que sea posible, solo debe exponer los puertos de su servicio que son absolutamente esenciales para la comunicación o la recopilación de métricas. | | Seguridad en dependencia de terceros | Es una buena práctica comprobar periódicamente las bibliotecas de terceros de su aplicación en busca de vulnerabilidades de seguridad. Cada lenguaje de programación tiene una herramienta para realizar esta verificación de forma automática. | | Análisis de código estático | La mayoría de los lenguajes proporcionan una forma de analizar el código en busca de prácticas de codificación potencialmente inseguras. Siempre que sea posible, debe automatizar los escaneos utilizando herramientas que puedan escanear las bases del código en busca de errores de seguridad comunes. Algunas de las herramientas se pueden encontrar en [OWASP Source Code Analysis Tools](https://owasp.org/www-community/Source_Code_Analysis_Tools)
. | | Ataques de sondeo dinámico | Existen algunas herramientas automatizadas que puede ejecutar en su servicio para explorar algunos de los ataques más conocidos. Esto incluye la inyección de SQL, CSRF y XSS. Una de las herramientas de análisis dinámico más populares es la [OWASP Zed Attack proxy](https://www.zaproxy.org/)
. | Siguientes pasos ---------------- Obtenga más información sobre los temas de seguridad de Kubernetes: * [Estándares de seguridad del pod](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [Políticas de red para pods](https://kubernetes.io/es/docs/concepts/services-networking/network-policies/) * [Control de acceso a la API de Kubernetes](https://kubernetes.io/es/docs/concepts/security/controlling-access/) * [Protegiendo su clúster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) * [Criptografía de datos en tránsito](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) * [Criptografía de datos en reposo](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) * [Secretos en Kubernetes](https://kubernetes.io/es/docs/concepts/configuration/secret/) * [Runtime class](https://kubernetes.io/es/docs/concepts/containers/runtime-class/) 2 - Políticas de Seguridad del Pod ================================== #### Funcionalidad eliminada PodSecurityPolicy está en [obsoleto](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/#podsecuritypolicy-deprecation) en Kubernetes v1.21, y removida desde Kubernetes v1.25. En vez de usar PodSecurityPolicy, puedes aplicar restricciones similares en Pods usando cualquiera o los dos: * [Admisión de seguridad de pod](https://kubernetes.io/docs/concepts/security/pod-security-admission/) * Un plugin de admisión de terceros, que implementa y configura usted mismo Para obtener una guía de migración, consulte [Migrar de PodSecurityPolicy al Controlador de Admisión de Seguridad de Pod Integrado](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) . Para obtener más información sobre la eliminación de esta API, consulte [Obsoleto de PodSecurityPolicy: Pasado, Presente y Futuro](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) . Si no está ejecutando Kubernetes v1.35, consulte la documentación para su versión de Kubernetes. 3 - Controlando el Acceso a la API de Kubernetes ================================================ Esta página proporciona información sobre cómo controlar el acceso a la API de Kubernetes. Los usuarios acceden a la [API de Kubernetes](https://kubernetes.io/es/docs/concepts/overview/kubernetes-api/) usando `kubectl`, bibliotecas de cliente, o haciendo peticiones REST. Usuarios y [Kubernetes service accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) pueden ser autorizados para acceder a la API. Cuando una petición llega a la API, pasa por varias etapas, están ilustradas en el siguiente diagrama: ![Diagrama de pasos para una petición a la API de Kubernetes](https://kubernetes.io/images/docs/admin/access-control-overview.svg) Seguridad en la capa de transporte ---------------------------------- En un [cluster](https://kubernetes.io/es/docs/reference/glossary/?all=true#term-cluster "Un conjunto de máquinas, llamadas nodos, que ejecutan aplicaciones en contenedores administradas por Kubernetes.") típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. El [API Server](https://kubernetes.io/es/docs/reference/generated/kube-apiserver/ "Componente del plano de control que expone la API de Kubernetes.") presenta un certificado. Este certificado puede ser firmando usando un certificado de autoridad privada (CA) o basado en una llave pública relacionada generalmente a un CA reconocido. Si el cluster usa un certificado de autoridad privado, se necesita copiar este certificado CA configurado dentro de su `~/.kube/config` en el cliente, entonces se podrá confiar en la conexión y estar seguro que no será comprometida. El cliente puede presentar un certificado TLS de cliente en esta etapa. Autenticación ------------- Una vez que se estableció la conexión TLS, las peticiones HTTP avanzan a la etapa de autenticación. Esto se muestra en el paso 1 del diagrama. El script de creación del cluster o el administrador del cluster puede configurar el [API Server](https://kubernetes.io/es/docs/reference/generated/kube-apiserver/ "Componente del plano de control que expone la API de Kubernetes.") para ejecutar uno o mas módulos de autenticación. Los Autenticadores están descritos con más detalle en [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) . La entrada al paso de autenticación es la petición HTTP completa, aun así, esta tipicamente examina las cabeceras y/o el certificado del cliente. Los modulos de autenticación incluyen certificado de cliente, contraseña, tokens planos, tokens de inicio y JSON Web Tokens (usados para los service accounts). Múltiples módulos de autenticación puede ser especificados, en este caso cada uno es probado secuencialmente, hasta que uno de ellos tiene éxito. Si la petición no puede ser autenticada, la misma es rechazada con un código HTTP 401. Si la autenticación tiene éxito, el usuario es validado con el `username` específico, y el nombre de usuario esta disponible para los pasos siguientes. Algunos autenticadores también proporcionan membresías de grupo al usuario, mientras que otros no lo hacen. Aunque Kubernetes utiliza los nombres de usuario para tomar decisiones durante el control de acceso y para registrar las peticiones de entrada, no tiene un objeto `User` ni tampoco almacena información sobre los usuarios en la API. Autorización ------------ Después de autenticar la petición como proveniente de un usuario específico, la petición debe ser autorizada. Esto se muestra en el paso 2 del diagrama. Una petición debe incluir el nombre de usuario solicitante, la acción solicitada y el objeto afectado por la acción. La petición es autorizada si hay una política existente que declare que el usuario tiene permisos para la realizar la acción. Por ejemplo, si el usuario Bob tiene la siguiente política, entonces puede leer pods solamente en el namespace `projectCaribou`: { "apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": { "user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true } } Si Bob hace la siguiente petición, será autorizada dado que tiene permitido leer los objetos en el namespace `projectCaribou` : { "apiVersion": "authorization.k8s.io/v1beta1", "kind": "SubjectAccessReview", "spec": { "resourceAttributes": { "namespace": "projectCaribou", "verb": "get", "group": "unicorn.example.org", "resource": "pods" } } } En cambio, si Bob en su petición intenta escribir (`create` o `update`) en los objetos del namespace `projectCaribou`, la petición será denegada. Del mismo modo, si Bob hace una petición para leer (`get`) objetos en otro namespace como `projectFish`, la autorización también será denegada. Las autorizaciones en Kubernetes requieren que se usen atributos REST comunes para interactuar con el existente sistema de control de toda la organización o del proveedor cloud. Es importante usar formatos REST porque esos sistemas de control pueden interactuar con otras APIs además de la API de Kubernetes. Kubernetes soporta múltiples módulos de autorización, como el modo ABAC, el modo RBAC y el modo Webhook. Cuando un administrador crea un cluster, se realiza la configuración de los módulos de autorización que deben ser usados con la API del server. Si más de uno módulo de autorización es configurado, Kubernetes verificada cada uno y si alguno de ellos autoriza la petición entonces la misma se ejecuta. Si todos los modules deniegan la petición, entonces la misma es denegada (Con un error HTTP con código 403). Para leer más acerca de las autorizaciones en Kubernetes, incluyendo detalles sobre cómo crear politicas usando los módulos de autorización soportados, vea [Authorization](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) . Control de Admisión ------------------- Los módulos de Control de Admisión son módulos de software que solo pueden modificar o rechazar peticiones. Adicionalmente a los atributos disponibles en los módulos de Autorización, los de Control de Admisión pueden acceder al contenido del objeto que esta siendo creado o modificado. Los Controles de Admisión actúan en las peticiones que crean, modifican, borran o se conectan (proxy) a un objeto. Cuando múltiples módulos de control de admisión son configurados, son llamados en orden. Esto se muestra en el paso 3 del diagrama. A diferencia de los módulos de Autorización y Autenticación, si uno de los módulos de control de admisión rechaza la petición, entonces es inmediatamente rechazada. Adicionalmente a rechazar objetos, los controles de admisión también permiten establecer valores predeterminados complejos. Los módulos de Control de Admisión disponibles están descritos en [Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) . Cuando una petición pasa todos los controles de admisión, esta es validada usando la rutinas de validación para el objeto API correspondiente y luego es escrita en el objeto. Puertos e IPs del API server ---------------------------- La discusión previa aplica a peticiones enviadas a un puerto seguro del servidor API (el caso típico). El servidor API puede en realidad servir en 2 puertos: Por defecto, la API de Kubernetes entrega HTTP en 2 puertos: 1. puerto `localhost`: * debe usarse para testeo e iniciar el sistema y para otros componentes del nodo maestro (scheduler, controller-manager) para hablar con la API * no se usa TLS * el puerto predeterminado es el `8080` * la IP por defecto es localhost, la puede cambiar con el flag `--insecure-bind-address`. * la petición no pasa por los mecanismos de autenticación ni autorización * peticiones controladas por los modulos de control de admisión. * protegidas por necesidad para tener acceso al host 2. “Puerto seguro”: * usar siempre que sea posible * usa TLS. Se configura el certificado con el flag `--tls-cert-file` y la clave con `--tls-private-key-file`. * el puerto predeterminado es `6443`, se cambia con el flag `--secure-port`. * la IP por defecto es la primer interface que no es la localhost. se cambia con el flag `--bind-address`. * peticiones controladas por los módulos de autenticación y autorización. * peticiones controladas por los módulos de control de admisión. Siguientes pasos ---------------- En los siguientes enlaces, encontrará mucha más documentación sobre autenticación, autorización y el control de acceso a la API: * [Authenticating](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) * [Authenticating with Bootstrap Tokens](https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/) * [Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) * [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) * [Authorization](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) * [Role Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) * [Attribute Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/abac/) * [Node Authorization](https://kubernetes.io/docs/reference/access-authn-authz/node/) * [Webhook Authorization](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) * [Certificate Signing Requests](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/) * including [CSR approval](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) and [certificate signing](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#signing) * Service accounts * [Developer guide](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) * [Administration](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/) * Como los pods pueden usar [Secrets](https://kubernetes.io/es/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) para obtener credenciales para la API. --- # শিডিউলিং, প্রিএম্পশন এবং ইভিকশন (Scheduling, Preemption and Eviction) | Kubernetes এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। [মুদ্রণ করতে এখানে ক্লিক করুন](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/_print/#) . [এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/) . শিডিউলিং, প্রিএম্পশন এবং ইভিকশন (Scheduling, Preemption and Eviction) ===================================================================== কুবারনেটিসে, শিডিউলিং মানে হল নিশ্চিত করা যে [পডগুলি](https://kubernetes.io/bn/docs/concepts/workloads/pods/ "একটি পড আপনার ক্লাস্টারে চলমান কন্টেইনারগুলোর একটি সেট উপস্থাপন করে।") [নোডগুলির](https://kubernetes.io/bn/docs/concepts/architecture/nodes/ "নোড হলো কুবারনেটিসে একটি ওয়ার্কার মেশিন।") সাথে মিলিত হয়েছে কিনা যাতে [kubelet](https://kubernetes.io/bn/docs/reference/command-line-tools-reference/kubelet "An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.") তাদের রান করতে পারে। প্রিএম্পশন হল স্বল্প [অগ্রাধিকার](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority "Pod Priority indicates the importance of a Pod relative to other Pods.") পডগুলি বাতিল করার প্রক্রিয়া যাতে উচ্চ অগ্রাধিকার পডগুলি নোডগুলিতে শিডিউল করতে পারে। ইভিকশন হল রিসোর্স-ক্ষুধার্ত নোডগুলিতে এক বা একাধিক পডগুলি প্রত্যাহার করার প্রক্রিয়া। শিডিউলিং -------- * [কুবারনেটস এর শিডিউলিং](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/kube-scheduler/) * [নোডগুলিতে পডস বরাদ্দ করা](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/assign-pod-node/) * [পডসের অতিরিক্ত ব্যয়](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/pod-overhead/) * [পডস এর টপোলজি ছড়িয়ে যাওয়ার সীমাবদ্ধতা](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/topology-spread-constraints/) * [টেইন্টস এবং টলারেশনস](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/taint-and-toleration/) * [শিডিউলিং ফ্রেমওয়ার্ক](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/scheduling-framework) * [ডাইনামিক রিসোর্স বরাদ্দ করা](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/dynamic-resource-allocation) * [শিডিউলার পারফরমেন্স টিউনিং](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * [সম্প্রসারিত রিসোর্স এর জন্য রিসোর্স বিন প্যাকিং](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/resource-bin-packing/) * [পড শিডিউলিং এর সাধনযোগ্যতা](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/pod-scheduling-readiness/) * [ডিশেডিউলার](https://github.com/kubernetes-sigs/descheduler#descheduler-for-kubernetes) পডস এর ভাঙ্গন ------------- [পড-ব্যঘাত](https://kubernetes.io/bn/docs/concepts/workloads/pods/disruptions/) হলো সেই প্রক্রিয়া যার মাধ্যমে নোডের পডগুলো স্বেচ্ছায় বা অনিচ্ছাকৃতভাবে বন্ধ করা হয়। অ্যাপ্লিকেশন মালিক বা ক্লাস্টার অ্যাডমিনিস্ট্রেটররা ইচ্ছাকৃতভাবে স্বেচ্ছায় ব্যাঘাত শুরু করে। অনিচ্ছাকৃত ব্যাঘাতগুলি অনিচ্ছাকৃত এবং নোডের রিসোর্স ফুরিয়ে যাওয়ার মতো অনিবার্য সমস্যার কারণে বা দুর্ঘটনাবশত মুছে ফেলার কারণে ট্রিগার হতে পারে। * [পড অগ্রাধিকার এবং প্রিম্পশন](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/pod-priority-preemption/) * [নোড-প্রেসার ইভিকশন](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/node-pressure-eviction/) * [API-প্রবর্তিত ইভিকশন](https://kubernetes.io/bn/docs/concepts/scheduling-eviction/api-eviction/) --- # TLS | Kubernetes これは、このセクションの複数ページの印刷可能なビューです。 [印刷するには、ここをクリックしてください](https://kubernetes.io/ja/docs/tasks/tls/_print/#) . [このページの通常のビューに戻る](https://kubernetes.io/ja/docs/tasks/tls/) . TLS === Transport Layer Security(TLS)を使用して、クラスター内のトラフィックを保護する方法について理解します。 * 1: [Kubeletの証明書のローテーションを設定する](https://kubernetes.io/ja/docs/tasks/tls/_print/#pg-1272b18ac0c008f6ffc2c62a29fa929f) 1 - Kubeletの証明書のローテーションを設定する ============================ このページでは、kubeletの証明書のローテーションを設定する方法を説明します。 FEATURE STATE: `Kubernetes v1.8 [beta]` 始める前に ----- * Kubernetesはバージョン1.8.0以降である必要があります。 概要 -- kubeletは、Kubernetes APIへの認証のために証明書を使用します。デフォルトでは、証明書は1年間の有効期限付きで発行されるため、頻繁に更新する必要はありません。 Kubernetes 1.8にはベータ機能の[kubelet certificate rotation](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) が含まれているため、現在の証明書の有効期限が近づいたときに自動的に新しい鍵を生成して、Kubernetes APIに新しい証明書をリクエストできます。新しい証明書が利用できるようになると、Kubernetes APIへの接続の認証に利用されます。 クライアント証明書のローテーションを有効にする ----------------------- `kubelet`プロセスは`--rotate-certificates`という引数を受け付けます。この引数によって、現在使用している証明書の有効期限が近づいたときに、kubeletが自動的に新しい証明書をリクエストするかどうかを制御できます。証明書のローテーションはベータ機能であるため、`--feature-gates=RotateKubeletClientCertificate=true`を使用してフィーチャーフラグを有効にする必要もあります。 `kube-controller-manager`プロセスは、`--experimental-cluster-signing-duration`という引数を受け付け、この引数で証明書が発行される期間を制御できます。 証明書のローテーションの設定を理解する ------------------- kubeletが起動すると、ブートストラップが設定されている場合(`--bootstrap-kubeconfig`フラグを使用した場合)、初期証明書を使用してKubernetes APIに接続して、証明書署名リクエスト(certificate signing request、CSR)を発行します。証明書署名リクエストのステータスは、次のコマンドで表示できます。 kubectl get csr ノード上のkubeletから発行された証明書署名リクエストは、初めは`Pending`状態です。証明書署名リクエストが特定の条件を満たすと、コントローラーマネージャーに自動的に承認され、`Approved`状態になります。次に、コントローラーマネージャーは`--experimental-cluster-signing-duration`パラメーターで指定された有効期限で発行された証明書に署名を行い、署名された証明書が証明書署名リクエストに添付されます。 kubeletは署名された証明書をKubernetes APIから取得し、ディスク上の`--cert-dir`で指定された場所に書き込みます。その後、kubeletは新しい証明書を使用してKubernetes APIに接続するようになります。 署名された証明書の有効期限が近づくと、kubeletはKubernetes APIを使用して新しい証明書署名リクエストを自動的に発行します。再び、コントローラーマネージャーは証明書のリクエストを自動的に承認し、署名された証明書を証明書署名リクエストに添付します。kubeletは新しい署名された証明書をKubernetes APIから取得してディスクに書き込みます。その後、kubeletは既存のコネクションを更新して、新しい証明書でKubernetes APIに再接続します。 --- # নীতিমালা | Kubernetes এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। [মুদ্রণ করতে এখানে ক্লিক করুন](https://kubernetes.io/bn/docs/concepts/policy/_print/#) . [এই পৃষ্ঠার নিয়মিত দৃশ্যে ফিরে আসুন](https://kubernetes.io/bn/docs/concepts/policy/) . নীতিমালা ======== নীতিগুলির সাথে সুরক্ষা এবং সর্বোত্তম-অনুশীলনগুলি পরিচালনা করুন কুবারনেটিস নীতিগুলি এমন কনফিগারেশন যা অন্যান্য কনফিগারেশন বা রানটাইম আচরণগুলি পরিচালনা করে। কুবারনেটিস বিভিন্ন ধরণের নীতি সরবরাহ করে নীচে তা বর্ণিত হলো: এপিআই (API) অবজেক্ট ব্যবহার করে পলিসি প্রয়োগ করুন -------------------------------------------------- কিছু API অবজেক্ট নীতি হিসাবে কাজ করে। এখানে কিছু উদাহরণ দেওয়া হল: * [নেটওয়ার্ক নীতি](https://kubernetes.io/bn/docs/concepts/services-networking/network-policies/) একটি কাজের চাপের জন্য প্রবেশ এবং প্রস্থানে ট্র্যাফিক সীমাবদ্ধ করতে ব্যবহার করা যেতে পারে। * [লিমিট রেঞ্জ](https://kubernetes.io/bn/docs/concepts/policy/limit-range/) বিভিন্ন বস্তুর ধরণের জুড়ে রিসোর্স বরাদ্দের সীমাবদ্ধতা পরিচালনা করে। * [রিসোর্স কোটা](https://kubernetes.io/bn/docs/concepts/policy/resource-quotas/) একটি জন্য সম্পদ খরচ সীমাবদ্ধ করুন [নেমস্পেস](https://kubernetes.io/bn/docs/concepts/overview/working-with-objects/namespaces "একটি অ্যাবস্ট্রাকশন যা কুবার্নেটিস ব্যবহার করে রিসোর্স গ্রুপের আইসোলেশন সাপোর্ট করার জন্য, একটি একক ক্লাস্টার এর মধ্যে।") ভর্তি নিয়ন্ত্রক ব্যবহার করে নীতিমালা প্রয়োগ করুন -------------------------------------------------- একটি [ভর্তি নিয়ন্ত্রক](https://kubernetes.io/bn/docs/reference/access-authn-authz/admission-controllers/ "কোডের একটি অংশ যা অবজেক্টের পার্সিস্টেন্সের(persistence) পূর্বে কুবারনেটিস API সার্ভারের অনুরোধগুলিকে বাধা দেয়।") API সার্ভারে চলে এবং API অনুরোধগুলিকে যাচাই বা পরিবর্তন করতে পারে। কিছু ভর্তি নিয়ন্ত্রক নীতি প্রয়োগ করার জন্য কাজ করে। উদাহরণস্বরূপ, [অলওয়েজইমেজপুল](https://kubernetes.io/bn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) অ্যাডমিশন কন্ট্রোলার ইমেজ পুল পলিসি `অলওয়েজ` এ সেট করতে একটি নতুন পড সংশোধন করে। কুবারনেটিস বেশ কয়েকটি অন্তর্নির্মিত ভর্তি নিয়ামক রয়েছে যা API সার্ভারের মাধ্যমে কনফিগারযোগ্য `--enable-admission-plugin` ফ্লাগ। ভর্তি নিয়ন্ত্রকদের বিবরণ, উপলব্ধ ভর্তি নিয়ন্ত্রকদের সম্পূর্ণ তালিকা সহ, একটি ডেডিকেটেড অংশে নথিভুক্ত ( ডকুমেন্ট) করা হয়েছে। * [ভর্তি নিয়ন্ত্রকরা](https://kubernetes.io/bn/docs/reference/access-authn-authz/admission-controllers/) ভ্যালিডেটিংএডমিশনপলিসি ব্যবহার করে নীতিগুলি প্রয়োগ করুন -------------------------------------------------------- ভর্তি নীতিগুলি যাচাই করা কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (সিইএল) ব্যবহার করে API সার্ভারে কনফিগারযোগ্য বৈধতা চেকগুলি কার্যকর করার অনুমতি দেয়। উদাহরণস্বরূপ, `সর্বশেষ` চিত্র ট্যাগের ব্যবহার নিষিদ্ধ করতে একটি `ভ্যালিডেটিংঅ্যাডমিশনপলিসি` ব্যবহার করা যেতে পারে। একটি `ভ্যালিডেটিঅ্যাডমিশনপলিসি` একটি API অনুরোধের ভিত্তিতে কাজ করে এবং ব্যবহারকারীদের অ-সম্মতিযুক্ত কনফিগারেশন সম্পর্কে ব্লক, নিরীক্ষণ (হিসাবনিকাশ) এবং সতর্ক করতে ব্যবহার করা যেতে পারে। উদাহরণ সহ `ভ্যালিডেটিংএডমিশনপলিসি` API সম্পর্কে বিশদ বিবরণ একটি ডেডিকেটেড অংশে নথিভুক্ত (ডকুমেন্ট) করা হয়েছে: * [ভ্যালিডেটিং এডমিশন পলিসি](https://kubernetes.io/bn/docs/reference/access-authn-authz/validating-admission-policy/) ডাইনামিক ভর্তি নিয়ন্ত্রণ ব্যবহার করে নীতিমালা প্রয়োগ করুন ----------------------------------------------------------- ডায়নামিক অ্যাডমিশন কন্ট্রোলার (বা অ্যাডমিশন ওয়েবহুক) এপিআই সার্ভারের বাইরে পৃথক অ্যাপ্লিকেশন হিসাবে চালিত হয় যা এপিআই অনুরোধগুলির বৈধতা বা মিউটেশন সম্পাদনের জন্য ওয়েবহুক অনুরোধগুলি গ্রহণ করতে নিবন্ধন করে। ডায়নামিক অ্যাডমিশন কন্ট্রোলারগুলি এপিআই অনুরোধগুলিতে নীতি প্রয়োগ করতে এবং অন্যান্য নীতি-ভিত্তিক কর্মপ্রবাহকে ট্রিগার করতে ব্যবহার করা যেতে পারে। একটি ডায়নামিক ভর্তি কন্ট্রোলার অন্যান্য ক্লাস্টার সংস্থান এবং বহিরাগত ডেটা পুনরুদ্ধারের প্রয়োজন সহ জটিল চেকগুলি সম্পাদন করতে পারে। উদাহরণস্বরূপ, একটি ইমেজ যাচাইকরণ কন্টেইনার চিত্রের স্বাক্ষর এবং প্রত্যয়নগুলি যাচাই করতে ওসিআই (OCI) রেজিস্ট্রি থেকে ডেটা খুঁজতে পারে। ডায়নামিক ভর্তি নিয়ন্ত্রণের বিশদ বিবরণ একটি নিয়োজিত (ডেডিকেটেড) অংশে নথিভুক্ত ( ডকুমেন্ট) করা হয়েছে: * [ডাইনামিক ভর্তি নিয়ন্ত্রণ](https://kubernetes.io/bn/docs/reference/access-authn-authz/extensible-admission-controllers/) ### বাস্তবায়ন **বিঃদ্রঃ:** এই বিভাগটি তৃতীয় পক্ষের (third party) প্রকল্পগুলির সাথে লিঙ্ক করে যা কুবারনেটিস দ্বারা প্রয়োজনীয় কার্যকারিতা প্রদান করে। কুবারনেটিস প্রকল্প লেখক এই প্রকল্পগুলির জন্য দায়ী নয়, যা বর্ণানুক্রমিকভাবে তালিকাভুক্ত করা হয়েছে। এই তালিকায় একটি প্রকল্প যোগ করতে, একটি পরিবর্তন জমা দেওয়ার আগে [content guide](https://kubernetes.io/docs/contribute/style/content-guide/#third-party-content) পড়ুন। [অধিক তথ্য](https://kubernetes.io/bn/docs/concepts/policy/_print/#third-party-content-disclaimer) নমনীয় নীতি ইঞ্জিন হিসাবে কাজ করে এমন ডায়নামিক অ্যাডমিশন কন্ট্রোলারগুলি কুবারনেটিস ইকোসিস্টেমে উন্নত(ডেভলাপ) করা হচ্ছে, যেমন: * [Kubewarden](https://github.com/kubewarden) * [Kyverno](https://kyverno.io/) * [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) * [Polaris](https://polaris.docs.fairwinds.com/admission-controller/) Kubelet কনফিগারেশন ব্যবহার করে নীতি প্রয়োগ করুন ------------------------------------------------ কুবারনেটিস প্রতিটি ওর্য়াকার নোডে Kubelet কনফিগার করার অনুমতি দেয়। কিছু Kubelet কনফিগারেশন নীতি হিসাবে কাজ করে: * [প্রক্রিয়া আইডি সীমা এবং সংরক্ষণ](https://kubernetes.io/bn/docs/concepts/policy/pid-limiting/) বরাদ্দযোগ্য পিআইডি সীমাবদ্ধ এবং সংরক্ষণ করতে ব্যবহৃত হয়। * [নোড রিসোর্স ম্যানেজার](https://kubernetes.io/bn/docs/concepts/policy/node-resource-managers/) বিলম্ব-সমালোচনামূলক এবং উচ্চ-থ্রুপুট ওয়ার্কলোডের জন্য গণনা, মেমরি এবং ডিভাইস সংস্থানগুলি পরিচালনা করতে পারে। --- # 쿠버네티스 기초 학습 | Kubernetes 이 섹션의 다중 페이지 출력 화면임. [여기를 클릭하여 프린트](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#) . [이 페이지의 일반 화면으로 돌아가기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/) . 쿠버네티스 기초 학습 =========== * 1: [클러스터 생성하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-7df66040311338d6098ebeab43ba9afb) * 1.1: [Minikube를 사용해서 클러스터 생성하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-de49316920e97a82e36763cb66781ada) * 1.2: [대화형 튜토리얼 - 클러스터 생성하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-323b75976001e8dfe35d67d61bc74f1a) * 2: [앱 배포하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-76d78b3fba507f7ed33cef14a35b631d) * 2.1: [kubectl을 사용해서 디플로이먼트 생성하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-2b1bba431989008c7493109a0f049ece) * 2.2: [대화형 튜토리얼 - 앱 배포하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-f8997ec143b382fa6c9621941ea62ca3) * 3: [앱 조사하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-250d620a73ec8be7e1f7d835574c4596) * 3.1: [파드와 노드 보기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-2771f4e8c45321b17cb0114a2d266453) * 3.2: [대화형 튜토리얼 - 앱 조사하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-4b01eab98a9844ad91131079654199dd) * 4: [앱 외부로 노출하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-4b0e31c9e0eae68bbb0a358b4042ada9) * 4.1: [앱 노출을 위해 서비스 이용하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-8ef4dad8f743b191a9e8c6f891cb191a) * 4.2: [대화형 튜토리얼 - 앱 노출하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-352241d22effe0714772d21c7d1b512d) * 5: [앱 스케일링하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-be4996c93fb39c459a30b6669569d423) * 5.1: [복수의 앱 인스턴스를 구동하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-d1c15c9bd4f625adbc13149b1475287c) * 5.2: [대화형 튜토리얼 - 앱 스케일링하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-7bdb3fbaa1177ff5dfa3fe86bd35ef59) * 6: [앱 업데이트하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-62b8b17dadfb55f1801cf8439e944e58) * 6.1: [롤링 업데이트 수행하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-12e04355145afad615ca3c38335ba019) * 6.2: [대화형 튜토리얼 - 앱 업데이트 하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#pg-dddc0cb356c280e0339bcf42776987dc) 쿠버네티스 기초 -------- 이 튜토리얼에서는 쿠버네티스 클러스터 오케스트레이션 시스템의 기초를 익힐 수 있는 가이드를 제공한다. 각각의 모듈에는 쿠버네티스의 주요 기능과 개념에 대한 배경 지식이 담겨 있으며 대화형 온라인 튜토리얼도 포함되어 있다. 대화형 튜토리얼에서 간단한 클러스터와 그 클러스터 상의 컨테이너화 된 애플리케이션을 직접 관리해볼 수 있다. 대화형 튜토리얼을 사용해서 다음의 내용을 배울 수 있다. * 컨테이너화된 애플리케이션을 클러스터에 배포하기. * 디플로이먼트를 스케일링하기. * 컨테이너화된 애플리케이션을 새로운 소프트웨어 버전으로 업데이트하기. * 컨테이너화된 애플리케이션을 디버그하기. 이 튜토리얼에서는 Katacoda를 사용해서 독자의 웹브라우저에서 Minikube가 동작하는 가상 터미널을 구동시킨다. Minikube는 로컬에 설치할 수 있는 작은 규모의 쿠버네티스로써 어디에서든 작동된다. 어떤 소프트웨어도 설치할 필요가 없고, 아무 것도 설정할 필요가 없다. 왜냐하면 대화형 튜토리얼이 웹브라우저 자체에서 바로 동작하기 때문이다. 쿠버네티스가 어떤 도움이 될까? ----------------- 오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다. 쿠버네티스 기초 모듈 ----------- [![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_01.svg?v=1469803628347)](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/) [##### 1\. 쿠버네티스 클러스터 생성하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/) [![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_02.svg?v=1469803628347)](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/) [##### 2\. 애플리케이션 배포하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/) [![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_03.svg?v=1469803628347)](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/) [##### 3\. 앱 조사하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/) [![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_04.svg?v=1469803628347)](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/expose/expose-intro/) [##### 4\. 앱 외부로 노출하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/expose/expose-intro/) [![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_05.svg?v=1469803628347)](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/scale/scale-intro/) [##### 5\. 애플리케이션 스케일링하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/scale/scale-intro/) [![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_06.svg?v=1469803628347)](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/update/update-intro/) [##### 6\. 앱 업데이트하기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/update/update-intro/) 1 - 클러스터 생성하기 ============= 쿠버네티스 [클러스터](https://kubernetes.io/ko/docs/reference/glossary/?all=true#term-cluster "컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.") 에 대한 내용을 확인하고 Minikube를 사용하여 간단한 클러스터를 생성해 본다. 1.1 - Minikube를 사용해서 클러스터 생성하기 ============================== ### 목표 * 쿠버네티스 클러스터가 무엇인지 배운다. * Minikube가 무엇인지 배운다. * 온라인 터미널을 사용해서 쿠버네티스 클러스터를 시작한다. ### 쿠버네티스 클러스터 **쿠버네티스는 컴퓨터들을 연결하여 단일 형상으로 동작하도록 컴퓨팅 클러스터를 구성하고 높은 가용성을 제공하도록 조율한다.** 사용자는 쿠버네티스의 추상화 개념을 통해 개별 머신에 얽매이지 않고 컨테이너화된 애플리케이션을 클러스터에 배포할 수 있다. 이렇게 새로운 배포 모델을 활용하려면, 애플리케이션을 개별 호스트에 독립적인 방식으로 패키징할 필요가 있다. 즉, 컨테이너화가 필요하다. 예전 배치 모델인 설치형 애플리케이션이 특정 머신의 호스트와 밀접하게 통합되는 패키지인 것에 비해, 컨테이너화된 애플리케이션은 유연성(flexible)과 가용성(available)이 훨씬 높다. **쿠버네티스는 이러한 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 더욱 효율적으로 자동화한다.** 쿠버네티스는 오픈소스 플랫폼이며 운영 수준의 안정성(production-ready)을 제공한다. 쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다. * **컨트롤 플레인**은 클러스터를 조율한다. * **노드**는 애플리케이션을 구동하는 작업자(worker)이다. ### 요약: * 쿠버네티스 클러스터 * Minikube _쿠버네티스는 컴퓨터 클러스터에 애플리케이션 컨테이너의 배치(스케줄링) 및 실행을 오케스트레이션하는 운영 수준의 오픈소스 플랫폼이다._ 클러스터 다이어그램 ---------- ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg) **컨트롤 플레인은 클러스터 관리를 담당한다.** 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다. **노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.** 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 하는데, 이는 한 노드가 다운되면 etcd 멤버와 컨트롤 플레인 인스턴스가 사라져 중복성(redundancy)을 잃기 때문이다. 컨트롤 플레인 노드를 추가하여 이러한 위험을 줄일 수 있다. _컨트롤 플레인은 실행 중인 애플리케이션을 호스팅하기 위해 사용되는 노드와 클러스터를 관리한다._ 애플리케이션을 쿠버네티스에 배포하기 위해서는, 컨트롤 플레인에 애플리케이션 컨테이너의 구동을 지시하면 된다. 그러면 컨트롤 플레인은 컨테이너를 클러스터의 어느 노드에 구동시킬지 스케줄한다. **노드는 컨트롤 플레인이 제공하는 [쿠버네티스 API](https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/) 를 통해서 컨트롤 플레인과 통신한다.** 최종 사용자도 쿠버네티스 API를 사용해서 클러스터와 직접 상호작용(interact)할 수 있다. 쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면 Minikube를 사용할 수 있다. Minikube는 가벼운 쿠버네티스 구현체이며, 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한 클러스터를 생성한다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서 구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인 부트스트래핑(bootstrapping) 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는 온라인 터미널을 사용할 것이다. 쿠버네티스가 무엇인지 알아봤으니, 이제 온라인 튜토리얼로 이동해서 우리의 첫 번째 클러스터를 시작해보자! [대화형 튜토리얼 시작하기 ›](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/) 1.2 - 대화형 튜토리얼 - 클러스터 생성하기 ========================== 화면이 너무 좁아 터미널과 상호작용할 수 없습니다. 데스크톱/태블릿을 사용해주세요. [홈으로 이동](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/) [모듈 2로 진행하기 >](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/) 2 - 앱 배포하기 ========== 2.1 - kubectl을 사용해서 디플로이먼트 생성하기 =============================== ### 목표 * 애플리케이션 디플로이먼트(Deployment)에 대해 배운다. * kubectl로 첫 애플리케이션을 쿠버네티스에 배포한다. ### 쿠버네티스 디플로이먼트 일단 쿠버네티스 클러스터를 구동시키면, 그 위에 컨테이너화된 애플리케이션을 배포할 수 있다. 그러기 위해서, 쿠버네티스 **디플로이먼트** 설정을 만들어야 한다. 디플로이먼트는 쿠버네티스가 애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다. 디플로이먼트가 만들어지면, 쿠버네티스 컨트롤 플레인이 해당 디플로이먼트에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄한다. 애플리케이션 인스턴스가 생성되면, 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를 모니터링한다. 인스턴스를 구동 중인 노드가 다운되거나 삭제되면, 디플로이먼트 컨트롤러가 인스턴스를 클러스터 내부의 다른 노드의 인스턴스로 교체시켜준다.**이렇게 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 메커니즘을 제공한다.** 오케스트레이션 기능이 없던 환경에서는, 설치 스크립트가 애플리케이션을 시작하는데 종종 사용되곤 했지만, 머신의 장애가 발생한 경우 복구를 해주지는 않았다. 쿠버네티스 디플로이먼트는 애플리케이션 인스턴스를 생성해주고 여러 노드에 걸쳐서 지속적으로 인스턴스가 구동되도록 하는 두 가지를 모두 하기 때문에 애플리케이션 관리를 위한 접근법에서 근본적인 차이를 가져다준다. ### 요약: * 디플로이먼트 * Kubectl _디플로이먼트는 애플리케이션 인스턴스를 생성하고 업데이트하는 역할을 담당한다._ 쿠버네티스에 첫 번째 애플리케이션 배포하기 ----------------------- ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg) **Kubectl**이라는 쿠버네티스 CLI를 통해 디플로이먼트를 생성하고 관리할 수 있다. Kubectl은 클러스터와 상호 작용하기 위해 쿠버네티스 API를 사용한다. 이 모듈에서는, 쿠버네티스 클러스터 상에 애플리케이션을 구동시키는 디플로이먼트를 생성하기 위해 필요한 가장 일반적인 Kubectl 명령어를 배우게 된다. 디플로이먼트를 생성할 때, 애플리케이션에 대한 컨테이너 이미지와 구동시키고자 하는 복제 수를 지정해야 한다. 디플로이먼트를 업데이트해서 이런 정보를 나중에 변경할 수 있다. 모듈 [5](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/scale/scale-intro/) 와 [6](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/update/update-intro/) 의 부트캠프에서 어떻게 스케일하고 업데이트하는지에 대해 다룬다. _애플리케이션이 쿠버네티스 상에 배포되려면 지원되는 컨테이너 형식 중 하나로 패키지 되어야한다._ 첫 번째 디플로이먼트로, NGINX를 사용해 모든 요청을 에코(echo)하는 도커 컨테이너로 패키지한 hello-node 애플리케이션을 사용해보자. (아직 hello-node 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면, [Hello Minikube 튜토리얼](https://kubernetes.io/ko/docs/tutorials/hello-minikube/) 의 지시를 따른다.) 이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자! [대화형 튜토리얼 시작하기 ›](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive/) 2.2 - 대화형 튜토리얼 - 앱 배포하기 ======================= 파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 각 파드는 클러스터에서 실행중인 워크로드의 일부를 나타낸다. [파드에 대해 더 자세히 알아본다](https://kubernetes.io/ko/docs/concepts/workloads/pods/) . 터미널로 상호 작용하기 위해서, 데스크탑/태블릿 버전을 사용해주세요 [< 모듈 1로 돌아가기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/) [홈으로 이동](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/) [모듈 3으로 진행하기 >](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/) 3 - 앱 조사하기 ========== 3.1 - 파드와 노드 보기 =============== ### 목표 * 쿠버네티스 파드에 대해 배운다. * 쿠버네티스 노드에 대해 배운다. * 배포된 애플리케이션의 문제를 해결한다. 쿠버네티스 파드 -------- 모듈 [2](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/) 에서 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 **파드**를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다: * 볼륨과 같은, 공유 스토리지 * 클러스터 IP 주소와 같은, 네트워킹 * 컨테이너 이미지 버전 또는 사용할 특정 포트와 같이, 각 컨테이너가 동작하는 방식에 대한 정보 파드는 특유한 "로컬호스트" 애플리케이션 모형을 만들어. 상대적으로 밀접하게 결합되어진 상이한 애플리케이션 컨테이너들을 수용할 수 있다. 가령, 파드는 Node.js 앱과 더불어 Node.js 웹서버에 의해 발행되는 데이터를 공급하는 상이한 컨테이너를 함께 수용할 수 있다. 파드 내 컨테이너는 IP 주소, 그리고 포트 스페이스를 공유하고 항상 함께 위치하고 함께 스케쥴링 되고 동일 노드 상의 컨텍스트를 공유하면서 동작한다. 파드는 쿠버네티스 플랫폼 상에서 최소 단위가 된다. 우리가 쿠버네티스에서 배포를 생성할 때, 그 배포는 컨테이너 내부에서 컨테이너와 함께 파드를 생성한다. 각 파드는 스케쥴 되어진 노드에게 묶여지게 된다. 그리고 (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 유지된다. 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케쥴되어진다. ### 요약: * 파드 * 노드 * Kubectl 주요 명령어 _파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹이고 공유 스토리지 (볼륨), IP 주소 그리고 그것을 동작시키는 방식에 대한 정보를 포함하고 있다._ 파드 개요 ----- ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg) 노드 -- 파드는 언제나 **노드** 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 컨트롤 플레인에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다. 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 모두 고려한다. 모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다. * Kubelet은, 쿠버네티스 컨트롤 플레인과 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다. * 컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다. _만약 컨테이너들이 밀접하게 결합되어 있고 디스크와 같은 자원을 공유해야 한다면 오직 하나의 단일 파드에 함께 스케쥴되어져야 한다._ 노드 개요 ----- ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg) kubectl로 문제해결하기 --------------- 모듈 [2](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/) 에서, Kubectl 커맨드-라인 인터페이스를 사용했다. 배포된 애플리케이션과 그 환경에 대한 정보를 얻기 위해 모듈3에서도 계속 그것을 사용할 것이다. 가장 보편적인 운용업무는 다음 kubectl 명령어를 이용하여 처리할 수 있다: * **kubectl get** - 자원을 나열한다 * **kubectl describe** - 자원에 대해 상세한 정보를 보여준다. * **kubectl logs** - 파드 내 컨테이너의 로그들을 출력한다 * **kubectl exec** - 파드 내 컨테이너에 대한 명령을 실행한다. 언제 애플리케이션이 배포되었으며, 현재 상태가 어떠한지, 그것의 구성은 어떠한지 등을 보기 위해 이러한 명령을 이용할 수 있다. 이제 클러스터 컴포넌트와 커맨드 라인에 대해 알아 보았으니, 애플리케이션을 조사해 보자. _노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있다. 여러 개의 파드는 하나의 노드 위에서 동작할 수 있다._ [대화형 튜토리얼 시작하기 ›](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive/) 3.2 - 대화형 튜토리얼 - 앱 조사하기 ======================= 터미널과 상호작용하기 위해, 데스크탑/태블릿 버전을 이용한다. [< 모듈 2로 돌아가기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/) [홈으로 이동](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/) [모듈 4로 진행하기 >](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/expose/expose-intro/) 4 - 앱 외부로 노출하기 ============== 4.1 - 앱 노출을 위해 서비스 이용하기 ======================= ### 목표 * 쿠버네티스의 서비스에 대해 배운다. * 레이블과 레이블셀랙터 오브젝트가 어떻게 서비스와 연관되는지 이해한다. * 서비스를 이용하여 쿠버네티스 클러스터 외부로 애플리케이션을 노출한다. ### 쿠버네티스 서비스들에 대한 개요 쿠버네티스 [파드들](https://kubernetes.io/ko/docs/concepts/workloads/pods/) 은 언젠가는 죽게된다. 파드들은 [생명주기](https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/) 를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. [레플리카셋(ReplicaSet)](https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicaset/) 은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다. 쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML [(보다 선호하는)](https://kubernetes.io/ko/docs/concepts/configuration/overview/#%EC%9D%BC%EB%B0%98%EC%A0%81%EC%9D%B8-%EA%B5%AC%EC%84%B1-%ED%8C%81) 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 _LabelSelector_에 의해 결정된다 (여러분이 왜 스펙에 `selector`가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자). 비록 각 파드들이 고유의 IP를 갖고 있기는 하지만, 그 IP들은 서비스의 도움없이 클러스터 외부로 노출되어질 수 없다. 서비스들은 여러분의 애플리케이션들에게 트래픽이 실릴 수 있도록 허용해준다. 서비스들은 ServiceSpec에서 `type`을 지정함으로써 다양한 방식들로 노출시킬 수 있다: * _ClusterIP_ (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다. * _NodePort_ - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. `:`를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다. * _LoadBalancer_ - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다. * _ExternalName_ - `CNAME` 레코드 및 값을 반환함으로써 서비스를 `externalName` 필드의 내용(예를 들면, `foo.bar.example.com`)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 `kube-dns` v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다. 다른 서비스 타입들에 대한 추가 정보는 [소스 IP 이용하기](https://kubernetes.io/ko/docs/tutorials/services/source-ip/) 튜토리얼에서 확인 가능하다. 또한 [서비스들로 애플리케이션에 접속하기](https://kubernetes.io/ko/docs/tutorials/services/connect-applications-service/) 도 참고해 보자. 부가적으로, spec에 `selector`를 정의하지 않고 말아넣은 서비스들의 몇 가지 유즈케이스들이 있음을 주의하자. `selector` 없이 생성된 서비스는 상응하는 엔드포인트 오브젝트들 또한 생성하지 않는다. 이로써 사용자들로 하여금 하나의 서비스를 특정한 엔드포인트에 매핑 시킬수 있도록 해준다. selector를 생략하게 되는 또 다른 가능성은 여러분이 `type: ExternalName`을 이용하겠다고 확고하게 의도하는 경우이다. ### 요약 * 파드들을 외부 트래픽에 노출하기 * 여러 파드에 걸쳐서 트래픽 로드밸런싱 하기 * 레이블 사용하기 _쿠버네티스 서비스는 논리적 파드 셋을 정의하고 외부 트래픽 노출, 로드밸런싱 그리고 그 파드들에 대한 서비스 디스커버리를 가능하게 해주는 추상 계층이다._ ### 서비스와 레이블 서비스는 파드 셋에 걸쳐서 트래픽을 라우트한다. 여러분의 애플리케이션에 영향을 주지 않으면서 쿠버네티스에서 파드들이 죽게도 하고, 복제가 되게도 해주는 추상적 개념이다. 종속적인 파드들 사이에서의 디스커버리와 라우팅은 (하나의 애플리케이션에서 프로트엔드와 백엔드 컴포넌트와 같은) 쿠버네티스 서비스들에 의해 처리된다. 서비스는 쿠버네티스의 객체들에 대해 논리 연산을 허용해주는 기본 그룹핑 단위인, [레이블과 셀렉터](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels) 를 이용하여 파드 셋과 매치시킨다. 레이블은 오브젝트들에 붙여진 키/밸류 쌍으로 다양한 방식으로 이용 가능하다: * 개발, 테스트, 그리고 상용환경에 대한 객체들의 지정 * 임베디드된 버전 태그들 * 태그들을 이용하는 객체들에 대한 분류 ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg) 레이블은 오브젝트의 생성 시점 또는 이후 시점에 붙여질 수 있다. 언제든지 수정이 가능하다. 이제 서비스를 이용하여 우리의 애플리케이션을 노출도 시켜보고 레이블도 적용해 보자. [대화형 튜토리얼 시작›](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive/) 4.2 - 대화형 튜토리얼 - 앱 노출하기 ======================= 터미널과 상호작용하기 위해, 데스크탑/태블릿 버전을 이용한다. [< 모듈 3으로 돌아가기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/) [홈으로 이동](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/) [모듈 5로 진행하기 >](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/scale/scale-intro/) 5 - 앱 스케일링하기 ============ 5.1 - 복수의 앱 인스턴스를 구동하기 ====================== ### 목표 * kubectl을 사용해서 애플리케이션을 스케일한다. ### 애플리케이션을 스케일하기 지난 모듈에서 [디플로이먼트](https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/) 를 만들고, [서비스](https://kubernetes.io/ko/docs/concepts/services-networking/service/) 를 통해서 디플로이먼트를 외부에 노출시켜 봤다. 해당 디플로이먼트는 애플리케이션을 구동하기 위해 단 하나의 파드만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 조정할 필요가 있다. 디플로이먼트의 복제 수를 변경하면 **스케일링**이 수행된다 ### 요약: * 디플로이먼트 스케일링하기 _kubectl create deployment 명령에 --replicas 파라미터를 사용해서 처음부터 복수의 인스턴스로 구동되는 디플로이먼트를 만들 수도 있다_ 스케일링 개요 ------- ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg) ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg) [이전](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#myCarousel) [다음](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#myCarousel) 디플로이먼트를 스케일 아웃하면 신규 파드가 생성되어서 가용한 자원이 있는 노드에 스케줄된다. 스케일링 기능은 새로 의도한 상태(desired state)까지 파드의 수를 늘린다. 쿠버네티스는 파드의 [오토스케일링](https://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/) 도 지원하지만 본 튜토리얼에서는 다루지 않는다. 0까지 스케일링하는 것도 가능하다. 이 경우 해당 디플로이먼트의 모든 파드가 종료된다. 애플리케이션의 인스턴스를 복수로 구동하게 되면 트래픽을 해당 인스턴스 모두에 분산시킬 방법이 필요해진다. 서비스는 노출된 디플로이먼트의 모든 파드에 네트워크 트래픽을 분산시켜줄 통합된 로드밸런서를 갖는다. 서비스는 엔드포인트를 이용해서 구동중인 파드를 지속적으로 모니터링함으로써 가용한 파드에만 트래픽이 전달되도록 해준다. _디플로이먼트의 복제 수를 변경하면 스케일링이 수행된다._ 일단 복수의 애플리케이션의 인스턴스가 구동 중이면, 다운타임 없이 롤링 업데이트를 할 수 있다. 다음 모듈에서 이 내용을 다루도록 하겠다. 이제 온라인 터미널로 가서 애플리케이션을 스케일해보자. [대화형 튜토리얼 시작하기 ›](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive/) 5.2 - 대화형 튜토리얼 - 앱 스케일링하기 ========================= 터미널로 상호 작용하기 위해서, 데스크탑/태블릿 버전을 사용해주세요 [< 모듈 4로 돌아가기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive/) [홈으로 이동](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/) [모듈 6으로 진행하기 >](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/update/update-intro/) [](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#top) 6 - 앱 업데이트하기 ============ 6.1 - 롤링 업데이트 수행하기 ================== ### 목표 * kubectl을 이용하여 롤링 업데이트 수행하기 ### 애플리케이션 업데이트하기 사용자들은 애플리케이션이 항상 가용한 상태일 것이라 여기고 개발자들은 하루에 여러번씩 새로운 버전을 배포하도록 요구 받고있다. 쿠버네티스에서는 이것을 롤링 업데이트를 통해 이루고 있다. **롤링 업데이트**는 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 해준다. 새로운 파드는 가용한 자원을 보유한 노드로 스케줄될 것이다. 이전 모듈에서 여러 개의 인스턴스를 동작시키도록 애플리케이션을 스케일했다. 이것은 애플리케이션의 가용성에 영향을 미치지 않으면서 업데이트를 수행하는 것에 대한 요구이다. 기본적으로, 업데이트가 이루어지는 동안 이용 불가한 파드의 최대 개수와 생성 가능한 새로운 파드의 최대 개수는 하나다. 두 옵션은 (파드에 대한) 개수 또는 백분율로 구성될 수 있다. 쿠버네티스에서, 업데이트는 버전으로 관리되고 어떠한 디플로이먼트 업데이트라도 이전의 (안정적인) 버전으로 원복이 가능하다. ### 요약: * 앱 업데이트하기 _롤링 업데이트는 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 해준다._ 롤링 업데이트 개요 ---------- ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg) ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg) ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg) ![](https://kubernetes.io/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg) [이전](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#myCarousel) [다음](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/_print/#myCarousel) 애플리케이션 스케일링과 유사하게, 디플로이먼트가 외부로 노출되면, 서비스는 업데이트가 이루어지는 동안 오직 가용한 파드에게만 트래픽을 로드밸런스 할 것이다. 가용한 파드란 애플리케이션의 사용자들에게 가용한 상태의 인스턴스를 말한다. 롤링 업데이트는 다음 동작들을 허용해준다: * 하나의 환경에서 또 다른 환경으로의 애플리케이션 프로모션 (컨테이너 이미지 업데이트를 통해) * 이전 버전으로의 롤백 * 서비스 중단 없는 애플리케이션의 지속적인 통합과 지속적인 전달 _디플로이먼트가 외부로 노출되면, 서비스는 업데이트가 이루어지는 동안 오직 가용한 파드에게만 트래픽을 로드밸런스 할 것이다._ 다음 대화형 튜토리얼에서, 새로운 버전으로 애플리케이션을 업데이트하고, 롤백 또한 수행해 볼 것이다. [대화형 튜토리얼 시작하기 ›](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/update/update-interactive/) 6.2 - 대화형 튜토리얼 - 앱 업데이트 하기 ========================== 터미널과 상호작용하기 위해, 데스크탑/태블릿 버전을 이용한다. [< 모듈 5로 돌아가기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive/) [쿠버네티스 기초로 돌아가기](https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/) --- # セットアップツールのリファレンス | Kubernetes これは、このセクションの複数ページの印刷可能なビューです。 [印刷するには、ここをクリックしてください](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#) . [このページの通常のビューに戻る](https://kubernetes.io/ja/docs/reference/setup-tools/) . セットアップツールのリファレンス ================ * 1: [Kubeadm](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-f351ced098abbb076bc8c4be1053672b) * 1.1: [Kubeadm Generated](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-36c22b52e8447eb3d2452d4f56fbea9b) * 1.1.1:[](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-8f73e208cc67d221165f6294393881a7) * 1.1.2:[](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-9aec3477159c105a46f4479de1c21418) * 1.1.3:[](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-045e41c28798930e21f77a90c3a90263) * 1.1.4:[](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-e7d83478123771ad14f475ee44440303) * 1.1.5:[](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-57a6b20d9571220989a7a445d4459468) * 1.1.6:[](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-92a2c11eef37937af846b55d9b87a544) * 1.1.7:[](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-c5e4907022112d55d4362659ec27b993) * 1.2: [kubeadm config](https://kubernetes.io/ja/docs/reference/setup-tools/_print/#pg-5042dc49c5348b3674d3878f37f7670b) 1 - Kubeadm =========== ![](https://kubernetes.io/images/kubeadm-stacked-color.png)kubeadmは、`kubeadm init`や`kubeadm join`などのコマンドを提供するツールで、Kubernetesクラスターを構築する上でのベストプラクティスを反映した「近道」を提供するものとして開発されました。 kubeadmは実用最小限のクラスターをセットアップするための処理を実行します。設計上、kubeadmはブートストラップのみを行い、マシンのプロビジョニングは行いません。同様に、Kubernetesダッシュボード、モニタリングソリューション、クラウド向けのアドオンなど、あれば便利でもなくても支障のない各種アドオンのインストールも範囲外です。 その代わりに、高度な特定用途向けのツールはkubeadmをベースに構築されることが期待されています。理想的には、すべてのデプロイのベースとしてkubeadmを使用することで、適合テストに通るクラスターを簡単に作れるようになります。 インストール方法 -------- kubeadmをインストールするには、[インストールガイド](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm) を参照してください。 次の項目 ---- * [kubeadm init](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init) を使用して、Kubernetesのコントロールプレーンノードをブートストラップする * [kubeadm join](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join) を使用して、Kubernetesのワーカーノードをブートストラップし、クラスターに参加させる * [kubeadm upgrade](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) で、Kubernetesクラスターを新しいバージョンにアップグレードする * [kubeadm config](https://kubernetes.io/ja/docs/reference/setup-tools/kubeadm/kubeadm-config/) を使用して、kubeadm v1.7.x以前で初期化されたクラスターを、`kubeadm upgrade`を利用できるように設定する * [kubeadm token](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token) で、`kubeadm join`のためのトークンを管理する * [kubeadm reset](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-reset) を使用して、`kubeadm init`または`kubeadm join`でホストに行われた変更を元に戻す * [kubeadm version](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-version) で、kubeadmのバージョンを表示する * [kubeadm alpha](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha) で、コミュニティからのフィードバックを集めるために有効にされた各種機能を試用する 1.1 - Kubeadm Generated ======================= 1.1.1 - ======= kubeadmが使用するイメージの一覧を出力します。 設定ファイルはイメージやイメージリポジトリをカスタマイズする際に使用されます。 ### 概要 kubeadmが使用するイメージの一覧を出力します。 設定ファイルはイメージやイメージリポジトリをカスタマイズする際に使用されます。 kubeadm config images list [flags] ### オプション | | | | --- | --- | | \--allow-missing-template-keys     デフォルト値: true | | | | trueならば、テンプレートの中にフィールドやマップキーが見つからない場合に、テンプレート内のエラーを無視します。golangまたはjsonpathを出力フォーマットとした場合にのみ適用されます。 | | \--config string | | | | kubeadmの設定ファイルのパス。 | | \-o, --experimental-output string     デフォルト値: "text" | | | | 出力フォーマット。次のいずれか: text\|json\|yaml\|go-template\|go-template-file\|template\|templatefile\|jsonpath\|jsonpath-as-json\|jsonpath-file. | | \--feature-gates string | | | | 様々な機能に対するフィーチャーゲートを記述するkey=valueペアのセット。オプション:
EtcdLearnerMode=true\|false (BETA - デフォルト値=true)
PublicKeysECDSA=true\|false (DEPRECATED - デフォルト値=false)
RootlessControlPlane=true\|false (ALPHA - デフォルト値=false)
UpgradeAddonsBeforeControlPlane=true\|false (DEPRECATED - デフォルト値=false)
WaitForAllControlPlaneComponents=true\|false (ALPHA - デフォルト値=false) | | \-h, --help | | | | listのヘルプ | | \--image-repository string     デフォルト値: "registry.k8s.io" | | | | コントロールプレーンのイメージをプルするコンテナレジストリを選択します。 | | \--kubernetes-version string     デフォルト値: "stable-1" | | | | コントロールプレーンの特定のKubernetesバージョンを選択します。 | | \--show-managed-fields | | | | trueならば、JSONまたはYAMLフォーマットでmanagedFieldsを省略せずにオブジェクトを出力します。 | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | 1.1.2 - ======= kubeadmによって使用されるイメージをプルします。 ### 概要 kubeadmによって使用されるイメージをプルします。 kubeadm config images pull [flags] ### オプション | | | | --- | --- | | \--config string | | | | kubeadmの設定ファイルのパス。 | | \--cri-socket string | | | | 接続するCRIソケットへのパス。空の場合、kubeadmはこの値を自動検出しようとします。このオプションは、複数のCRIがインストールされているか、標準ではないCRIソケットがある場合のみ使用してください。 | | \--feature-gates string | | | | 様々な機能に対するフィーチャーゲートを記述するkey=valueペアのセット。オプション:
EtcdLearnerMode=true\|false (BETA - デフォルト値=true)
PublicKeysECDSA=true\|false (DEPRECATED - デフォルト値=false)
RootlessControlPlane=true\|false (ALPHA - デフォルト値=false)
UpgradeAddonsBeforeControlPlane=true\|false (DEPRECATED - デフォルト値=false)
WaitForAllControlPlaneComponents=true\|false (ALPHA - デフォルト値=false) | | \-h, --help | | | | pullのヘルプ | | \--image-repository string     デフォルト値: "registry.k8s.io" | | | | コントロールプレーンのイメージをプルするコンテナレジストリを選択します。 | | \--kubernetes-version string     デフォルト値: "stable-1" | | | | コントロールプレーンの特定のKubernetesバージョンを選択します。 | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | 1.1.3 - ======= ファイルから古いバージョンのAPIタイプのkubeadmの設定を読み込み、新しいバージョンの同等の設定オブジェクトを出力します。 ### 概要 このコマンドは、古いバージョンの設定オブジェクトを、サポートされている最新のバージョンに変換します。 これはクラスターを何も触ることなく、CLIツール内に閉じています。 kubeadmのこのバージョンでは、次のAPIバージョンがサポートされています: * kubeadm.k8s.io/v1beta3 さらに、kubeadmはバージョン"kubeadm.k8s.io/v1beta3"の設定しか出力できませんが、両方の種類を読むことができます。 このため、どのバージョンを--old-configパラメーターに渡したとしても、APIオブジェクトは読み込まれ、デシリアライズ、デフォルト化、変換、検証、再シリアライズされて、標準出力または--new-configで指定されたファイルに出力されます。 言い換えると、このコマンドの出力は、そのファイルを"kubeadm init"に渡した時にkubeadmが実際に内部で読むものとなります。 kubeadm config migrate [flags] ### オプション | | | | --- | --- | | \--allow-experimental-api | | | | 実験的な未リリースのAPIへの移行を許可します。 | | \-h, --help | | | | migrateのヘルプ | | \--new-config string | | | | 新しいAPIバージョンを使用して得られた同等の内容のkubeadm設定ファイルのパス。この設定はオプションで、指定しない場合は標準出力に出力されます。 | | \--old-config string | | | | 古いAPIバージョンを使用している、変換対象のkubeadm設定ファイルのパス。このフラグは必須です。 | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | 1.1.4 - ======= 設定を出力します。 ### 概要 このコマンドは、指定されたサブコマンドに対する設定を出力します。 詳細については次を参照してください: [https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories) kubeadm config print [flags] ### オプション | | | | --- | --- | | \-h, --help | | | | printのヘルプ | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | 1.1.5 - ======= `kubeadm init`で使用できるデフォルトのInitConfigurationを出力します。 ### 概要 このコマンドは、'kubeadm init'で使用されるデフォルトのInitConfigurationオブジェクトを出力します。 Bootstrap Tokenフィールドのような機密性が高い値は、実際にトークンを生成する計算は実行しませんが、検証をパスするために"abcdef.0123456789abcdef"のようなプレースホルダーの値に置き換えられることに注意してください。 kubeadm config print init-defaults [flags] ### オプション | | | | --- | --- | | \--component-configs strings | | | | デフォルト値を出力するコンポーネントの設定APIオブジェクトのカンマ区切りのリスト。利用可能な値: \[KubeProxyConfiguration KubeletConfiguration\]。このフラグが設定されていない場合は、どのコンポーネントの設定も出力されません。 | | \-h, --help | | | | init-defaultsのヘルプ | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | 1.1.6 - ======= `kubeadm join`で使用できるデフォルトのJoinConfigurationを出力します。 ### 概要 このコマンドは`kubeadm join`で使用されるデフォルトのJoinConfigurationオブジェクトを出力します Bootstrap Tokenフィールドのような機密性が高い値は、実際にトークンを生成する計算は実行しませんが、検証をパスするために"abcdef.0123456789abcdef"のようなプレースホルダーの値に置き換えられることに注意してください。 kubeadm config print join-defaults [flags] ### オプション | | | | --- | --- | | \-h, --help | | | | join-defaultsのヘルプ | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | 1.1.7 - ======= kubeadm設定APIを含むファイルを読み込み、検証に問題があれば報告します。 ### 概要 このコマンドはkubeadm設定APIファイルを検証して、警告やエラーがあれば報告します。 エラーが無い場合は終了ステータスはゼロ、それ以外の場合はゼロ以外の値となります。 不明なAPIフィールドのようなデータ変換できない問題については、エラーが発生します。 不明なAPIバージョンや不正な値を持つフィールドについてもエラーとなります。 入力ファイルの内容によっては、その他のエラーや警告が報告されることもあります。 このバージョンのkubeadmでは、次のAPIバージョンがサポートされています: * kubeadm.k8s.io/v1beta3 kubeadm config validate [flags] ### オプション | | | | --- | --- | | \--allow-experimental-api | | | | 実験的な未リリースのAPIの検証を許可する。 | | \--config string | | | | kubeadm設定ファイルへのパス。 | | \-h, --help | | | | validateのヘルプ | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | 1.2 - kubeadm config ==================== `kubeadm init`の実行中、kubeadmはクラスターに対して、`kube-system`名前空間内の`kubeadm-config`という名前のConfigMapに`ClusterConfiguration`オブジェクトをアップロードします。 この設定は`kubeadm join`、`kubeadm reset`および`kubeadm upgrade`の実行中に読み込まれます。 `kubeadm config print`によって、kubeadmが`kubeadm init`や`kubeadm join`で使用する、デフォルトの静的な設定を表示することができます。 #### 備考: コマンドの出力は一例として提供されるものです。 自身のセットアップに合わせるためには、コマンドの出力を手動で編集する必要があります。 不明確なフィールドは削除してください。 kubeadmは実行時にホストを調べ、そのフィールドにデフォルト値を設定しようとします。 `init`と`join`のより詳細な情報については、[設定ファイルを使ったkubeadm initの利用](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) 、または[設定ファイルを使ったkubeadm joinの利用](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file) を参照してください。 kubeadmの設定APIの使用法に関するより詳細な情報については、[kubeadm APIを使ったコンポーネントのカスタマイズ](https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags) を参照してください。 非推奨のAPIバージョンを含んだ古い設定ファイルを、サポートされた新しいAPIバージョンに変換する際には、`kubeadm config migrate`コマンドを使用することができます。 設定ファイルを検証するためには、`kubeadm config validate`を使用することができます。 kubeadmが必要とするイメージを表示、取得するために、`kbueadm config images list`や`kubeadm config images pull`を使用することができます。 kubeadm config print -------------------- 設定を出力します。 ### 概要 このコマンドは、指定されたサブコマンドに対する設定を出力します。 詳細については次を参照してください: [https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories) kubeadm config print [flags] ### オプション | | | | --- | --- | | \-h, --help | | | | printのヘルプ | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | kubeadm config print init-defaults ---------------------------------- `kubeadm init`で使用できるデフォルトのInitConfigurationを出力します。 ### 概要 このコマンドは、'kubeadm init'で使用されるデフォルトのInitConfigurationオブジェクトを出力します。 Bootstrap Tokenフィールドのような機密性が高い値は、実際にトークンを生成する計算は実行しませんが、検証をパスするために"abcdef.0123456789abcdef"のようなプレースホルダーの値に置き換えられることに注意してください。 kubeadm config print init-defaults [flags] ### オプション | | | | --- | --- | | \--component-configs strings | | | | デフォルト値を出力するコンポーネントの設定APIオブジェクトのカンマ区切りのリスト。利用可能な値: \[KubeProxyConfiguration KubeletConfiguration\]。このフラグが設定されていない場合は、どのコンポーネントの設定も出力されません。 | | \-h, --help | | | | init-defaultsのヘルプ | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | kubeadm config print join-defaults ---------------------------------- `kubeadm join`で使用できるデフォルトのJoinConfigurationを出力します。 ### 概要 このコマンドは`kubeadm join`で使用されるデフォルトのJoinConfigurationオブジェクトを出力します Bootstrap Tokenフィールドのような機密性が高い値は、実際にトークンを生成する計算は実行しませんが、検証をパスするために"abcdef.0123456789abcdef"のようなプレースホルダーの値に置き換えられることに注意してください。 kubeadm config print join-defaults [flags] ### オプション | | | | --- | --- | | \-h, --help | | | | join-defaultsのヘルプ | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | kubeadm config migrate ---------------------- ファイルから古いバージョンのAPIタイプのkubeadmの設定を読み込み、新しいバージョンの同等の設定オブジェクトを出力します。 ### 概要 このコマンドは、古いバージョンの設定オブジェクトを、サポートされている最新のバージョンに変換します。 これはクラスターを何も触ることなく、CLIツール内に閉じています。 kubeadmのこのバージョンでは、次のAPIバージョンがサポートされています: * kubeadm.k8s.io/v1beta3 さらに、kubeadmはバージョン"kubeadm.k8s.io/v1beta3"の設定しか出力できませんが、両方の種類を読むことができます。 このため、どのバージョンを--old-configパラメーターに渡したとしても、APIオブジェクトは読み込まれ、デシリアライズ、デフォルト化、変換、検証、再シリアライズされて、標準出力または--new-configで指定されたファイルに出力されます。 言い換えると、このコマンドの出力は、そのファイルを"kubeadm init"に渡した時にkubeadmが実際に内部で読むものとなります。 kubeadm config migrate [flags] ### オプション | | | | --- | --- | | \--allow-experimental-api | | | | 実験的な未リリースのAPIへの移行を許可します。 | | \-h, --help | | | | migrateのヘルプ | | \--new-config string | | | | 新しいAPIバージョンを使用して得られた同等の内容のkubeadm設定ファイルのパス。この設定はオプションで、指定しない場合は標準出力に出力されます。 | | \--old-config string | | | | 古いAPIバージョンを使用している、変換対象のkubeadm設定ファイルのパス。このフラグは必須です。 | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | kubeadm config validate ----------------------- kubeadm設定APIを含むファイルを読み込み、検証に問題があれば報告します。 ### 概要 このコマンドはkubeadm設定APIファイルを検証して、警告やエラーがあれば報告します。 エラーが無い場合は終了ステータスはゼロ、それ以外の場合はゼロ以外の値となります。 不明なAPIフィールドのようなデータ変換できない問題については、エラーが発生します。 不明なAPIバージョンや不正な値を持つフィールドについてもエラーとなります。 入力ファイルの内容によっては、その他のエラーや警告が報告されることもあります。 このバージョンのkubeadmでは、次のAPIバージョンがサポートされています: * kubeadm.k8s.io/v1beta3 kubeadm config validate [flags] ### オプション | | | | --- | --- | | \--allow-experimental-api | | | | 実験的な未リリースのAPIの検証を許可する。 | | \--config string | | | | kubeadm設定ファイルへのパス。 | | \-h, --help | | | | validateのヘルプ | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | kubeadm config images list -------------------------- kubeadmが使用するイメージの一覧を出力します。 設定ファイルはイメージやイメージリポジトリをカスタマイズする際に使用されます。 ### 概要 kubeadmが使用するイメージの一覧を出力します。 設定ファイルはイメージやイメージリポジトリをカスタマイズする際に使用されます。 kubeadm config images list [flags] ### オプション | | | | --- | --- | | \--allow-missing-template-keys     デフォルト値: true | | | | trueならば、テンプレートの中にフィールドやマップキーが見つからない場合に、テンプレート内のエラーを無視します。golangまたはjsonpathを出力フォーマットとした場合にのみ適用されます。 | | \--config string | | | | kubeadmの設定ファイルのパス。 | | \-o, --experimental-output string     デフォルト値: "text" | | | | 出力フォーマット。次のいずれか: text\|json\|yaml\|go-template\|go-template-file\|template\|templatefile\|jsonpath\|jsonpath-as-json\|jsonpath-file. | | \--feature-gates string | | | | 様々な機能に対するフィーチャーゲートを記述するkey=valueペアのセット。オプション:
EtcdLearnerMode=true\|false (BETA - デフォルト値=true)
PublicKeysECDSA=true\|false (DEPRECATED - デフォルト値=false)
RootlessControlPlane=true\|false (ALPHA - デフォルト値=false)
UpgradeAddonsBeforeControlPlane=true\|false (DEPRECATED - デフォルト値=false)
WaitForAllControlPlaneComponents=true\|false (ALPHA - デフォルト値=false) | | \-h, --help | | | | listのヘルプ | | \--image-repository string     デフォルト値: "registry.k8s.io" | | | | コントロールプレーンのイメージをプルするコンテナレジストリを選択します。 | | \--kubernetes-version string     デフォルト値: "stable-1" | | | | コントロールプレーンの特定のKubernetesバージョンを選択します。 | | \--show-managed-fields | | | | trueならば、JSONまたはYAMLフォーマットでmanagedFieldsを省略せずにオブジェクトを出力します。 | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | kubeadm config images pull -------------------------- kubeadmによって使用されるイメージをプルします。 ### 概要 kubeadmによって使用されるイメージをプルします。 kubeadm config images pull [flags] ### オプション | | | | --- | --- | | \--config string | | | | kubeadmの設定ファイルのパス。 | | \--cri-socket string | | | | 接続するCRIソケットへのパス。空の場合、kubeadmはこの値を自動検出しようとします。このオプションは、複数のCRIがインストールされているか、標準ではないCRIソケットがある場合のみ使用してください。 | | \--feature-gates string | | | | 様々な機能に対するフィーチャーゲートを記述するkey=valueペアのセット。オプション:
EtcdLearnerMode=true\|false (BETA - デフォルト値=true)
PublicKeysECDSA=true\|false (DEPRECATED - デフォルト値=false)
RootlessControlPlane=true\|false (ALPHA - デフォルト値=false)
UpgradeAddonsBeforeControlPlane=true\|false (DEPRECATED - デフォルト値=false)
WaitForAllControlPlaneComponents=true\|false (ALPHA - デフォルト値=false) | | \-h, --help | | | | pullのヘルプ | | \--image-repository string     デフォルト値: "registry.k8s.io" | | | | コントロールプレーンのイメージをプルするコンテナレジストリを選択します。 | | \--kubernetes-version string     デフォルト値: "stable-1" | | | | コントロールプレーンの特定のKubernetesバージョンを選択します。 | ### 親コマンドから継承されたオプション | | | | --- | --- | | \--kubeconfig string     デフォルト値: "/etc/kubernetes/admin.conf" | | | | クラスターと通信する時に使用するkubeconfigファイル。フラグが設定されていない場合は、標準的な場所の中から既存のkubeconfigファイルが検索されます。 | | \--rootfs string | | | | \[実験的\]'実際の'ホストのルートファイルシステムのパス。 | 次の項目 ---- * [kubeadm upgrade](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) を使用すると、Kubernetesクラスターを最新のバージョンにアップグレードすることができます --- # 노드 레퍼런스 정보 | Kubernetes 이 섹션의 다중 페이지 출력 화면임. [여기를 클릭하여 프린트](https://kubernetes.io/ko/docs/reference/node/_print/#) . [이 페이지의 일반 화면으로 돌아가기](https://kubernetes.io/ko/docs/reference/node/) . 노드 레퍼런스 정보 ========== * 1: [kubelet 체크포인트 API](https://kubernetes.io/ko/docs/reference/node/_print/#pg-e9c91b750d5dd5acbbdb9e49c89d35ad) * 2: [리눅스 커널 버전 요구 사항](https://kubernetes.io/ko/docs/reference/node/_print/#pg-e9a4493b142cccdd4fcb813365f400bd) * 3: [도커심 제거 및 CRI 호환 런타임 사용에 대한 기사](https://kubernetes.io/ko/docs/reference/node/_print/#pg-26e96c9d268f9c39dfc525b98f477a12) * 4: [노드 상태](https://kubernetes.io/ko/docs/reference/node/_print/#pg-8cc3d980ae362cd0e958120dd2072673) 이 섹션에서는 노드에 관한 다음의 레퍼런스 주제를 다룬다. * kubelet의 [체크포인트 API](https://kubernetes.io/ko/docs/reference/node/kubelet-checkpoint-api/) * [도커심 제거 및 CRI 호환 런타임 사용에 대한 글](https://kubernetes.io/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) 목록 다음과 같은 다른 쿠버네티스 문서에서도 노드 레퍼런스 상세에 대해 읽어볼 수 있다. * [노드 메트릭 데이터](https://kubernetes.io/ko/docs/reference/instrumentation/node-metrics/) . 1 - kubelet 체크포인트 API ===================== 기능 상태: `Kubernetes v1.25 [alpha]` 컨테이너 체크포인트는 실행 중인 컨테이너의 스테이트풀(stateful) 복사본을 생성하는 기능이다. 컨테이너의 스테이트풀 복사본이 있으면, 디버깅 또는 다른 목적을 위해 이를 다른 컴퓨터로 이동할 수 있다. 체크포인트 컨테이너 데이터를 복원할 수 있는 컴퓨터로 이동하면, 복원된 컨테이너는 체크포인트된 지점과 정확히 동일한 지점에서 계속 실행된다. 적절한 도구가 있다면, 저장된 데이터를 검사해 볼 수도 있다. 컨테이너 체크포인트 생성 시에는 유의해야 할 보안 사항이 있다. 일반적으로 각 체크포인트는 체크포인트된 컨테이너의 모든 프로세스의 메모리 페이지를 포함한다. 이는 곧 메모리에 있던 모든 데이터가 로컬 디스크에 저장되어 열람이 가능함을 의미한다. 이 아카이브(archive)에는 모든 개인 데이터와 암호화 키가 포함된다. 따라서, 내부 CRI 구현체(노드의 컨테이너 런타임)는 체크포인트 아카이브를 생성 시 `root` 사용자만 액세스 가능하도록 처리해야 한다. 그럼에도 여전히 주의가 필요한데, 체크포인트 아카이브를 다른 시스템으로 전송하게 되면 해당 시스템의 체크포인트 아카이브 소유자가 모든 메모리 페이지를 읽을 수 있기 때문이다. 운영 -- ### `POST` 특정 컨테이너의 체크포인트 생성 지정된 파드의 특정 컨테이너를 체크포인트하도록 kubelet에 지시한다. kubelet 체크포인트 인터페이스로의 접근이 어떻게 제어되는지에 대한 자세한 내용은 [Kubelet 인증/인가 레퍼런스](https://kubernetes.io/ko/docs/reference/access-authn-authz/kubelet-authn-authz/) 를 참고한다. kubelet은 내부 [CRI](https://kubernetes.io/ko/docs/concepts/overview/components/#%ec%bb%a8%ed%85%8c%ec%9d%b4%eb%84%88-%eb%9f%b0%ed%83%80%ec%9e%84 "Kubelet과 컨테이너 런타임을 통합시키기 위한 API") 구현체에 체크포인트를 요청한다. 체크포인트 요청 시, kubelet은 체크포인트 아카이브의 이름을 `checkpoint---.tar`로 지정하고 루트 디렉토리(`--root-dir` 로 지정 가능) 아래의 `checkpoints` 디렉토리에 체크포인트 아카이브를 저장하도록 요청한다. 기본값은 `/var/lib/kubelet/checkpoints`이다. 체크포인트 아카이브는 _tar_ 형식이며 [`tar`](https://pubs.opengroup.org/onlinepubs/7908799/xcu/tar.html) 유틸리티를 사용하여 조회해 볼 수 있다. 아카이브의 내용은 내부 CRI 구현체(노드의 컨테이너 런타임)에 따라 다르다. #### HTTP 요청 POST /checkpoint/{namespace}/{pod}/{container} #### 파라미터 * **namespace** (_경로 내 파라미터_): 문자열(string), 필수 [네임스페이스 (원문, Namespace)](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/ "쿠버네티스에서, 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상화.") * **pod** (_경로 내 파라미터_): 문자열(string), 필수 [파드 (원문, Pod)](https://kubernetes.io/ko/docs/concepts/workloads/pods/ "파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.") * **container** (_경로 내 파라미터_): 문자열(string), 필수 [컨테이너 (원문, Container)](https://kubernetes.io/ko/docs/concepts/containers/ "소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지.") * **timeout** (_쿼리 파라미터_): 정수(integer) 체크포인트 생성이 완료될 때까지 대기할 시간제한(초)이다. 시간 제한이 0 또는 지정되지 않은 경우 기본 [CRI](https://kubernetes.io/ko/docs/concepts/overview/components/#%ec%bb%a8%ed%85%8c%ec%9d%b4%eb%84%88-%eb%9f%b0%ed%83%80%ec%9e%84 "Kubelet과 컨테이너 런타임을 통합시키기 위한 API") 시간 제한 값이 사용될 것이다. 체크포인트 생성 시간은 컨테이너가 사용하고 있는 메모리에 따라 다르다. 컨테이너가 사용하는 메모리가 많을수록 해당 체크포인트를 생성하는 데 더 많은 시간이 필요하다. #### 응답 200: OK 401: Unauthorized 404: Not Found (`ContainerCheckpoint` 기능 게이트가 비활성화된 경우) 404: Not Found (명시한 `namespace`, `pod` 또는 `container`를 찾을 수 없는 경우) 500: Internal Server Error (CRI 구현체가 체크포인트를 수행하는 중에 오류가 발생한 경우 (자세한 내용은 오류 메시지를 확인한다.)) 500: Internal Server Error (CRI 구현체가 체크포인트 CRI API를 구현하지 않은 경우 (자세한 내용은 오류 메시지를 확인한다.)) 2 - 리눅스 커널 버전 요구 사항 =================== **참고:** 이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 [CNCF 웹사이트 가이드라인](https://github.com/cncf/foundation/blob/master/website-guidelines.md) 에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 [콘텐츠 가이드](https://kubernetes.io/contribute/style/content-guide/#third-party-content) 를 읽어본다. 많은 기능이 특정 커널 기능에 의존하며 최소 커널 버전 요구 사항이 존재한다. 그러나 특정 운영 체제 배포판에서는 커널 버전 번호에만 의존하는 것이 충분하지 않을 수 있다. RHEL, 우분투, SUSE와 같은 배포판의 메인테이너들이 선택된 기능을 이전 커널 릴리스에 (이전 커널 버전을 유지하면서) 백포트(backport)하는 경우가 많기 때문이다. 파드 sysctl --------- 리눅스에서 `sysctl()` 시스템 콜은 런타임에 커널 파라미터를 설정한다. 이러한 파라미터를 설정하는 데 사용할 수 있는 `sysctl`이라는 커맨드라인 툴이 있으며, 많은 파라미터가 `proc` 파일시스템을 통해 노출된다. 일부 sysctl은 커널 버전이 충분히 최신인 경우에만 사용할 수 있다. 다음 sysctl은 최소 커널 버전 요구 사항이 있으며, [안전한 집합(safe set)](https://kubernetes.io/ko/docs/tasks/administer-cluster/sysctl-cluster/#safe-and-unsafe-sysctls) 에서 지원된다. * `net.ipv4.ip_local_reserved_ports` (쿠버네티스 1.27부터, 커널 3.16+ 필요); * `net.ipv4.tcp_keepalive_time` (쿠버네티스 1.29부터, 커널 4.5+ 필요); * `net.ipv4.tcp_fin_timeout` (쿠버네티스 1.29부터, 커널 4.6+ 필요); * `net.ipv4.tcp_keepalive_intvl` (쿠버네티스 1.29부터, 커널 4.5+ 필요); * `net.ipv4.tcp_keepalive_probes` (쿠버네티스 1.29부터, 커널 4.5+ 필요); * `net.ipv4.tcp_syncookies` (커널 4.6+부터 네임스페이스 지원). * `net.ipv4.tcp_rmem` (쿠버네티스 1.32부터, 커널 4.15+ 필요). * `net.ipv4.tcp_wmem` (쿠버네티스 1.32부터, 커널 4.15+ 필요). * `net.ipv4.vs.conn_reuse_mode` (`ipvs` 프록시 모드에서 사용, 커널 4.1+ 필요); ### kube proxy `nftables` 프록시 모드 쿠버네티스 1.35에서, kube-proxy의 [`nftables` 모드](https://kubernetes.io/ko/docs/reference/networking/virtual-ips/#proxy-mode-nftables) 는 nft 커맨드라인 툴의 버전 1.0.1 이상과 커널 5.13 이상이 필요하다. 테스트/개발 목적으로는 kube-proxy 설정에서 `nftables.skipKernelVersionCheck` 옵션을 설정하면 커널 5.4까지 낮춰 사용할 수 있다. 그러나 시스템의 다른 nftables 사용자와 문제를 일으킬 수 있으므로 프로덕션 환경에서는 권장하지 않는다. 버전 2 컨트롤 그룹(control group) -------------------------- 쿠버네티스 v1.31부터 cgroup v1 지원은 유지 관리 모드이며, cgroup v2 사용을 권장한다. [리눅스 5.8](https://github.com/torvalds/linux/commit/4a7e89c5ec0238017a757131eb9ab8dc111f961c) 에서는 편의를 위해 시스템 레벨 `cpu.stat` 파일이 루트 cgroup에 추가되었다. runc 문서에서는 freezer 부재로 인해 커널 5.2 이전 버전은 권장하지 않는다. Pressure Stall Information (PSI) -------------------------------- [PSI(Pressure Stall Information)](https://kubernetes.io/docs/reference/instrumentation/understand-psi-metrics/) 는 리눅스 커널 버전 4.20 이상에서 지원되지만, 다음 설정이 필요하다. * 커널이 `CONFIG_PSI=y` 옵션으로 컴파일되어야 한다. 대부분의 최신 배포판은 이를 기본적으로 활성화한다. `zgrep CONFIG_PSI /proc/config.gz`를 실행하여 커널 설정을 확인할 수 있다. * 일부 리눅스 배포판은 PSI를 커널에 컴파일하지만 기본적으로 비활성화할 수 있다. 이 경우, 커널 커맨드라인에 `psi=1` 파라미터를 추가하여 부트 시 활성화해야 한다. 기타 커널 요구 사항 ----------- 일부 기능은 새로운 커널 기능에 의존할 수 있으며 특정 커널 요구 사항이 있다. 1. [재귀적 읽기 전용 마운트](https://kubernetes.io/ko/docs/concepts/storage/volumes/#recursive-read-only-mounts) : 리눅스 커널 v5.12에 추가된 `mount_setattr`(2)를 사용하여 `AT_RECURSIVE` 플래그와 함께 `MOUNT_ATTR_RDONLY` 속성을 적용하여 구현된다. 2. 파드 사용자 네임스페이스 지원은 [KEP-127](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-user-namespaces/README.md) 에 따라 최소 커널 버전 6.5+가 필요하다. 3. [노드 시스템 스왑(swap)](https://kubernetes.io/ko/docs/concepts/architecture/nodes/#swap-memory) 의 경우, `noswap`으로 설정된 tmpfs는 커널 6.3 이전 버전은 지원되지 않는다. 리눅스 커널 장기 유지 관리 --------------- 활성 커널 릴리스는 [kernel.org](https://www.kernel.org/category/releases.html) 에서 확인할 수 있다. 이전 커널 트리에 대한 버그 수정을 백포트하기 위해 보통 여러 _장기 유지 관리(long term maintenance)_ 커널 릴리스가 제공된다. 이러한 커널에는 중요한 버그 수정만 적용되며, 특히 오래된 트리의 경우 자주 릴리스되지 않는다. 리눅스 커널 웹사이트의 _Longterm_ 카테고리에서 [릴리스 목록](https://www.kernel.org/category/releases.html) 을 참고한다. 다음 내용 ----- * 자세한 내용은 [sysctl](https://kubernetes.io/ko/docs/tasks/administer-cluster/sysctl-cluster/) 을 참고한다. * kube-proxy를 [nftables 모드](https://kubernetes.io/ko/docs/reference/networking/virtual-ips/#proxy-mode-nftables) 로 실행할 수 있다. * [cgroup v2](https://kubernetes.io/ko/docs/concepts/architecture/cgroups/) 에서 더 많은 정보를 확인한다. 3 - 도커심 제거 및 CRI 호환 런타임 사용에 대한 기사 ================================= 이 문서는 쿠버네티스의 _도커심_ 사용 중단(deprecation) 및 제거, 또는 해당 제거를 고려한 CRI 호환 컨테이너 런타임 사용에 관한 기사 및 기타 페이지 목록을 제공한다. 쿠버네티스 프로젝트 ---------- * 쿠버네티스 블로그: [도커심 제거 FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/) (originally published 2020/12/02) * 쿠버네티스 블로그: [업데이트: 도커심 제거 FAQ](https://kubernetes.io/blog/2022/02/17/dockershim-faq/) (updated published 2022/02/17) * 쿠버네티스 블로그: [도커심에서 움직이는 쿠버네티스: 약속과 다음 단계](https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/) (published 2022/01/07) * 쿠버네티스 블로그: [도커심 제거가 다가오고 있다. 준비됐는가?](https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/) (published 2021/11/12) * 쿠버네티스 문서: [도커심에서 마이그레이션하기](https://kubernetes.io/ko/docs/tasks/administer-cluster/migrating-from-dockershim/) * 쿠버네티스 문서: [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/) * 쿠버네티스 개선 제안 이슈: [KEP-2221: kubelet에서 도커심 제거하기](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2221-remove-dockershim/README.md) * 쿠버네티스 개선 제안 이슈: [kubelet에서 도커심 제거하기](https://github.com/kubernetes/enhancements/issues/2221) (_k/enhancements#2221_) GitHub 이슈를 통해 피드백을 제공할 수 있다. [**도커심 제거 피드백 및 이슈**](https://github.com/kubernetes/kubernetes/issues/106917) . (_k/kubernetes/#106917_) 외부 소스 ----- * 아마존 웹 서비스 EKS 문서: [아마존 EKS 도커심 지원 종료](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html) * CNCF 컨퍼런스 영상: [도커에서 containerd 런타임으로 마이그레이션하며 얻은 교훈](https://www.youtube.com/watch?v=uDOu6rK4yOk) (Ana Caylin, at KubeCon Europe 2019) * 도커닷컴 블로그: [개발자가 도커, 도커 엔진 및 쿠버네티스 v1.20에 관해 알아야 할 사항](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/) (published 2020/12/04) * "_구글 오픈소스_" 유튜브 채널: [구글과 함께 쿠버네티스 배우기 - 도커심에서 containerd로 마이그레이션하기](https://youtu.be/fl7_4hjT52g) * Azure의 Microsoft 앱 블로그: [도커심 지원 중단 및 AKS](https://techcommunity.microsoft.com/t5/apps-on-azure-blog/dockershim-deprecation-and-aks/ba-p/3055902) (published 2022/01/21) * Mirantis 블로그: [도커심의 미래는 cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/) (published 2021/04/21) * Mirantis: [Mirantis/cri-dockerd](https://github.com/Mirantis/cri-dockerd) Git 리포지터리 (깃허브) * Tripwire: [곧 다가올 도커심의 지원 중단이 당신의 쿠버네티스에 미칠 영향](https://www.tripwire.com/state-of-security/security-data-protection/cloud/how-dockershim-forthcoming-deprecation-affects-your-kubernetes/) (published 2021/07/01) 4 - 노드 상태 ========= 쿠버네티스에서 [노드](https://kubernetes.io/ko/docs/concepts/architecture/nodes/) 상태는 클러스터 관리에서 중요한 부분이다. 이 문서에서는 건강하고 안정적인 클러스터를 보장하기 위해 노드 상태를 모니터링하고 관리하는 기초를 다룬다. 노드 상태 필드 -------- 노드의 상태는 다음의 정보를 포함한다: * [주소](https://kubernetes.io/ko/docs/reference/node/_print/#addresses) * [컨디션](https://kubernetes.io/ko/docs/reference/node/_print/#condition) * [용량과 할당가능](https://kubernetes.io/ko/docs/reference/node/_print/#capacity) * [정보](https://kubernetes.io/ko/docs/reference/node/_print/#info) `kubectl`을 사용해서 노드의 상태와 다른 세부 정보를 볼 수 있다: kubectl describe node 출력의 각 섹션은 아래에서 설명된다. 주소 -- 이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다. * HostName: 노드의 커널에 의해 알려진 호스트명이다. `--hostname-override` 파라미터를 통해 치환될 수 있다. * ExternalIP: 일반적으로 노드의 IP 주소는 외부로 라우트 가능 (클러스터 외부에서 이용 가능) 하다 . * InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다. 컨디션 --- `conditions` 필드는 모든 `Running` 노드의 상태를 기술한다. 컨디션의 예로 다음을 포함한다. | | | | --- | --- |노드 컨디션과 각 컨디션이 적용되는 시기에 대한 설명들이다. | 노드 컨디션 | 설명 | | --- | --- | | `Ready` | 노드가 상태 양호하며 파드를 수용할 준비가 되어 있는 경우 `True`, 노드의 상태가 불량하여 파드를 수용하지 못할 경우 `False`, 그리고 노드 컨트롤러가 마지막 `node-monitor-grace-period` (기본값 40 기간 동안 노드로부터 응답을 받지 못한 경우) `Unknown` | | `DiskPressure` | 디스크 사이즈 상에 압박이 있는 경우, 즉 디스크 용량이 넉넉치 않은 경우 `True`, 반대의 경우 `False` | | `MemoryPressure` | 노드 메모리 상에 압박이 있는 경우, 즉 노드 메모리가 넉넉치 않은 경우 `True`, 반대의 경우 `False` | | `PIDPressure` | 프로세스 상에 압박이 있는 경우, 즉 노드 상에 많은 프로세스들이 존재하는 경우 `True`, 반대의 경우 `False` | | `NetworkUnavailable` | 노드에 대해 네트워크가 올바르게 구성되지 않은 경우 `True`, 반대의 경우 `False` | #### 참고: 커맨드 라인 도구를 사용해서 통제된(cordoned) 노드의 세부 정보를 출력하는 경우 조건에는 `SchedulingDisabled` 이 포함된다. `SchedulingDisabled` 은 쿠버네티스 API의 조건이 아니며, 대신 통제된(cordoned) 노드는 사양에 스케줄 불가로 표시된다. 쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다. "conditions": [\ {\ "type": "Ready",\ "status": "True",\ "reason": "KubeletReady",\ "message": "kubelet is posting ready status",\ "lastHeartbeatTime": "2019-06-05T18:38:35Z",\ "lastTransitionTime": "2019-06-05T11:41:27Z"\ }\ ] ready 컨디션의 `status`가 `pod-eviction-timeout` ([kube-controller-manager](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/kube-controller-manager/ "컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.") 에 전달된 인수)보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, [노드 컨트롤러](https://kubernetes.io/ko/docs/reference/node/_print/#node-controller) 가 해당 노드에 할당된 전체 파드에 대해 [API를 이용한 축출](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/api-eviction/ "API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는 축출 오브젝트를 만드는 프로세스이다") 을 트리거한다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, API 서버는 노드 상의 kubelet과 통신이 불가하다. API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다. 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작 중인 모든 파드 오브젝트가 API 서버로부터 삭제되며 파드가 사용하던 이름을 다시 사용할 수 있게 된다. 노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는 [테인트(taints)](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/) 를 생성한다. 스케줄러는 파드를 노드에 할당할 때 노드의 테인트를 고려한다. 또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록 [톨러레이션(toleration)](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/ "세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.") 을 가질 수 있다. 자세한 내용은 [컨디션별 노드 테인트하기](https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#%EC%BB%A8%EB%94%94%EC%85%98%EB%B3%84-%EB%85%B8%EB%93%9C-%ED%85%8C%EC%9D%B8%ED%8A%B8%ED%95%98%EA%B8%B0) 를 참조한다. 용량과 할당가능 -------- 노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다. 용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다. 할당가능 블록은 일반 파드에서 사용할 수 있는 노드의 리소스 양을 나타낸다. 노드에서 [컴퓨팅 리소스 예약](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 하는 방법을 배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자. 정보 -- 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 런타임 상세 정보 및 노드가 사용하는 운영 체제가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다. 이 정보는 Kubelet이 노드에서 수집하여 쿠버네티스 API로 전송한다. 하트비트 ---- 쿠버네티스 노드가 보내는 하트비트는 클러스터가 개별 노드가 가용한지를 판단할 수 있도록 도움을 주고, 장애가 발견된 경우 조치를 할 수 있게한다. 노드에는 두 가지 형태의 하트비트가 있다. * 노드의 `.status`에 대한 업데이트 * `kube-node-lease` [네임스페이스](https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/ "쿠버네티스에서, 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상화.") 내의 [리스(Lease)](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트. 각 노드는 연관된 리스 오브젝트를 갖는다. 노드의 `.status`에 비하면, 리스는 경량의 리소스이다. 큰 규모의 클러스터에서는 리스를 하트비트에 사용하여 업데이트로 인한 성능 영향을 줄일 수 있다. kubelet은 노드의 `.status` 생성과 업데이트 및 관련된 리스의 업데이트를 담당한다. * kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 노드의 `.status`를 업데이트한다. 노드의 `.status` 업데이트에 대한 기본 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 40초 보다 훨씬 긴 5분이다. * kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 생성하고 업데이트한다. 리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다. 만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다. --- # 設定 | Kubernetes これは、このセクションの複数ページの印刷可能なビューです。 [印刷するには、ここをクリックしてください](https://kubernetes.io/ja/docs/tutorials/configuration/_print/#) . [このページの通常のビューに戻る](https://kubernetes.io/ja/docs/tutorials/configuration/) . 設定 == * 1: [ConfigMapを使ったRedisの設定](https://kubernetes.io/ja/docs/tutorials/configuration/_print/#pg-2efe621cc085b350c8c4574e6f7f1311) 1 - ConfigMapを使ったRedisの設定 ========================= 本ページでは、[ConfigMapを使ったコンテナの設定](https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-pod-configmap/) に基づき、ConfigMapを使ってRedisの設定を行う実践的な例を提供します。 目標 -- * 以下の要素を含む`kustomization.yaml`ファイルを作成する: * ConfigMapGenerator * ConfigMapを使ったPodリソースの設定 * `kubectl apply -k ./`コマンドにてディレクトリ全体を適用する * 設定が正しく反映されていることを確認する 始める前に ----- Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) を使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます: * [iximiuz Labs](https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all) * [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [KodeKloud](https://kodekloud.com/public-playgrounds) バージョンを確認するには次のコマンドを実行してください: `kubectl version`. * この例は、バージョン1.14以上での動作を確認しています。 * [ConfigMapを使ったコンテナの設定](https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-pod-configmap/) を読んで理解しておいてください。 実践例: ConfigMapを使ったRedisの設定 -------------------------- 以下の手順に従って、ConfigMapに保存されているデータを使用してRedisキャッシュを設定できます。 最初に、`redis-config`ファイルからConfigMapを含む`kustomization.yaml`を作成します: [`pods/config/redis-config`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/config/redis-config) ![](https://kubernetes.io/images/copycode.svg "Copy pods/config/redis-config to clipboard") maxmemory 2mb maxmemory-policy allkeys-lru curl -OL https://k8s.io/examples/pods/config/redis-config cat <./kustomization.yaml configMapGenerator: - name: example-redis-config files: - redis-config EOF Podリソースの設定を`kustomization.yaml`に入れます: [`pods/config/redis-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/config/redis-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy pods/config/redis-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: kubernetes/redis:v1 env: - name: MASTER value: "true" ports: - containerPort: 6379 resources: limits: cpu: "0.1" volumeMounts: - mountPath: /redis-master-data name: data - mountPath: /redis-master name: config volumes: - name: data emptyDir: {} - name: config configMap: name: example-redis-config items: - key: redis-config path: redis.conf curl -OL https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml cat <>./kustomization.yaml resources: - redis-pod.yaml EOF kustomizationディレクトリを反映して、ConfigMapオブジェクトとPodオブジェクトの両方を作成します: kubectl apply -k . 作成されたオブジェクトを確認します > kubectl get -k . NAME DATA AGE configmap/example-redis-config-dgh9dg555m 1 52s NAME READY STATUS RESTARTS AGE pod/redis 1/1 Running 0 52s この例では、設定ファイルのボリュームは`/redis-master`にマウントされています。 `path`を使って`redis-config`キーを`redis.conf`という名前のファイルに追加します。 したがって、redisコンフィグのファイルパスは`/redis-master/redis.conf`です。 ここが、コンテナイメージがredisマスターの設定ファイルを探す場所です。 `kubectl exec`を使ってPodに入り、`redis-cli`ツールを実行して設定が正しく適用されたことを確認してください: kubectl exec -it pod/redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" 127.0.0.1:6379> CONFIG GET maxmemory-policy 1) "maxmemory-policy" 2) "allkeys-lru" 作成したPodを削除します: kubectl delete pod redis 次の項目 ---- * [ConfigMap](https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-pod-configmap/) について学ぶ --- # セキュリティ | Kubernetes これは、このセクションの複数ページの印刷可能なビューです。 [印刷するには、ここをクリックしてください](https://kubernetes.io/ja/docs/tutorials/security/_print/#) . [このページの通常のビューに戻る](https://kubernetes.io/ja/docs/tutorials/security/) . セキュリティ ====== * 1: [クラスターレベルでのPodセキュリティの標準の適用](https://kubernetes.io/ja/docs/tutorials/security/_print/#pg-d5f847bcdb6f7efbfc9c8a180d73e29a) * 2: [名前空間レベルでのPodセキュリティの標準の適用](https://kubernetes.io/ja/docs/tutorials/security/_print/#pg-31a6c137cfc5bfea9d88f4b109109465) * 3: [AppArmorを使用してコンテナのリソースへのアクセスを制限する](https://kubernetes.io/ja/docs/tutorials/security/_print/#pg-fca078b8ac6b82352ed52187a2da91b7) * 4: [seccompを使用してコンテナのシステムコールを制限する](https://kubernetes.io/ja/docs/tutorials/security/_print/#pg-8b105172a11322c70d0223bc9dff1904) 1 - クラスターレベルでのPodセキュリティの標準の適用 ============================= #### Note このチュートリアルは、新しいクラスターにのみ適用されます。 Podセキュリティアドミッション(PSA)は、[ベータへ進み](https://kubernetes.io/blog/2021/12/09/pod-security-admission-beta/) 、v1.23以降でデフォルトで有効になっています。 Podセキュリティアドミッションは、Podが作成される際に、[Podセキュリティの標準](https://kubernetes.io/ja/docs/concepts/security/pod-security-standards/) の適用の認可を制御するものです。 このチュートリアルでは、クラスター内の全ての名前空間に標準設定を適用することで、クラスターレベルで`baseline` Podセキュリティの標準を強制する方法を示します。 Podセキュリティの標準を特定の名前空間に適用するには、[名前空間レベルでのPodセキュリティの標準の適用](https://kubernetes.io/ja/docs/tutorials/security/ns-level-pss/) を参照してください。 v1.35以外のKubernetesバージョンを実行している場合は、そのバージョンのドキュメントを確認してください。 始める前に ----- ワークステーションに以下をインストールしてください: * [kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) * [kubectl](https://kubernetes.io/ja/docs/tasks/tools/) このチュートリアルでは、完全な制御下にあるKubernetesクラスターの何を設定できるかをデモンストレーションします。 コントロールプレーンを設定できない管理されたクラスターのPodセキュリティアドミッションに対しての設定方法を知りたいのであれば、[名前空間レベルでのPodセキュリティの標準の適用](https://kubernetes.io/ja/docs/tutorials/security/ns-level-pss/) を参照してください。 適用する正しいPodセキュリティの標準の選択 ---------------------- [Podのセキュリティアドミッション](https://kubernetes.io/ja/docs/concepts/security/pod-security-admission/) は、以下のモードでビルトインの[Podセキュリティの標準](https://kubernetes.io/ja/docs/concepts/security/pod-security-standards/) の適用を促します: `enforce`、`audit`、`warn`。 設定に最適なPodセキュリティの標準を選択するにあたって助けになる情報を収集するために、以下を行ってください: 1. Podセキュリティの標準を適用していないクラスターを作成します: kind create cluster --name psa-wo-cluster-pss 出力は次のようになります: Creating cluster "psa-wo-cluster-pss" ... ✓ Ensuring node image (kindest/node:v1.35.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to "kind-psa-wo-cluster-pss" You can now use your cluster with: kubectl cluster-info --context kind-psa-wo-cluster-pss Thanks for using kind! 😊 2. kubectl contextを新しいクラスターにセットします: kubectl cluster-info --context kind-psa-wo-cluster-pss 出力は次のようになります: Kubernetes control plane is running at https://127.0.0.1:61350 CoreDNS is running at https://127.0.0.1:61350/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. 3. クラスター内の名前空間の一覧を取得します: kubectl get ns 出力は次のようになります: NAME STATUS AGE default Active 9m30s kube-node-lease Active 9m32s kube-public Active 9m32s kube-system Active 9m32s local-path-storage Active 9m26s 4. 異なるPodセキュリティの標準が適用されたときに何が起きるかを理解するために、`-dry-run=server`を使います: 1. privileged kubectl label --dry-run=server --overwrite ns --all \ pod-security.kubernetes.io/enforce=privileged 出力は次のようになります: namespace/default labeled namespace/kube-node-lease labeled namespace/kube-public labeled namespace/kube-system labeled namespace/local-path-storage labeled 2. baseline kubectl label --dry-run=server --overwrite ns --all \ pod-security.kubernetes.io/enforce=baseline 出力は次のようになります: namespace/default labeled namespace/kube-node-lease labeled namespace/kube-public labeled Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "baseline:latest" Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged namespace/kube-system labeled namespace/local-path-storage labeled 3. restricted kubectl label --dry-run=server --overwrite ns --all \ pod-security.kubernetes.io/enforce=restricted 出力は次のようになります: namespace/default labeled namespace/kube-node-lease labeled namespace/kube-public labeled Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "restricted:latest" Warning: coredns-7bb9c7b568-hsptc (and 1 other pod): unrestricted capabilities, runAsNonRoot != true, seccompProfile Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile namespace/kube-system labeled Warning: existing pods in namespace "local-path-storage" violate the new PodSecurity enforce level "restricted:latest" Warning: local-path-provisioner-d6d9f7ffc-lw9lh: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile namespace/local-path-storage labeled この出力から、`privileged` Podセキュリティの標準を適用すると、名前空間のどれにも警告が示されないことに気付くでしょう。 これに対し、`baseline`と`restrict`の標準ではどちらも、とりわけ`kube-system`名前空間に対して警告が示されています。 モード、バージョン、標準のセット ---------------- このセクションでは、`latest`バージョンに以下のPodセキュリティの標準を適用します: * `enforce`モードで`baseline`標準。 * `warn`および`audit`モードで`restricted`標準。 `baseline` Podセキュリティの標準は、免除リストを短く保てて、かつ既知の特権昇格を防ぐような、利便性のある中庸を提供します。 加えて、`kube-system`内の失敗からPodを守るために、適用されるPodセキュリティの標準の対象から名前空間を免除します。 環境にPodセキュリティアドミッションを実装する際には、以下の点を考慮してください: 1. クラスターに適用されるリスク状況に基づくと、`restricted`のようにより厳格なPodセキュリティの標準のほうが、より良い選択肢かもしれません。 2. `kube-system`名前空間の免除は、Podがその名前空間で`privileged`として実行するのを許容することになります。 実世界で使うにあたっては、以下の最小権限の原則に従って`kube-system`へのアクセスを制限する厳格なRBACポリシーを適用することを、Kubernetesプロジェクトは強く推奨します。 上記の標準を実装するには、次のようにします: 3. 目的のPodセキュリティの標準を実装するために、Podセキュリティアドミッションコントローラーで利用可能な設定ファイルを作成します: mkdir -p /tmp/pss cat < /tmp/pss/cluster-level-pss.yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: - name: PodSecurity configuration: apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "baseline" enforce-version: "latest" audit: "restricted" audit-version: "latest" warn: "restricted" warn-version: "latest" exemptions: usernames: [] runtimeClasses: [] namespaces: [kube-system] EOF #### 備考: `pod-security.admission.config.k8s.io/v1`設定はv1.25+での対応です。 v1.23とv1.24では[v1beta1](https://v1-24.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) を使用してください。 v1.22では[v1alpha1](https://v1-22.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) を使用してください。 4. クラスターの作成中にこのファイルを取り込むAPIサーバーを設定します: cat < /tmp/pss/cluster-config.yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane kubeadmConfigPatches: - | kind: ClusterConfiguration apiServer: extraArgs: admission-control-config-file: /etc/config/cluster-level-pss.yaml extraVolumes: - name: accf hostPath: /etc/config mountPath: /etc/config readOnly: false pathType: "DirectoryOrCreate" extraMounts: - hostPath: /tmp/pss containerPath: /etc/config # optional: if set, the mount is read-only. # default false readOnly: false # optional: if set, the mount needs SELinux relabeling. # default false selinuxRelabel: false # optional: set propagation mode (None, HostToContainer or Bidirectional) # see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation # default None propagation: None EOF #### 備考: macOSでDocker Desktopと_kind_を利用している場合は、**Preferences > Resources > File Sharing**のメニュー項目からShared Directoryとして`/tmp`を追加できます。 5. 目的のPodセキュリティの標準を適用するために、Podセキュリティアドミッションを使うクラスターを作成します: kind create cluster --name psa-with-cluster-pss --config /tmp/pss/cluster-config.yaml 出力は次のようになります: Creating cluster "psa-with-cluster-pss" ... ✓ Ensuring node image (kindest/node:v1.35.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to "kind-psa-with-cluster-pss" You can now use your cluster with: kubectl cluster-info --context kind-psa-with-cluster-pss Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂 6. kubectlをこのクラスターに向けます: kubectl cluster-info --context kind-psa-with-cluster-pss 出力は次のようになります: Kubernetes control plane is running at https://127.0.0.1:63855 CoreDNS is running at https://127.0.0.1:63855/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. 7. デフォルトの名前空間にPodを作成します: kubectl apply -f https://k8s.io/examples/security/example-baseline-pod.yaml Podは正常に開始されますが、出力には警告が含まれます: Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") pod/nginx created 後片付け ---- では、上記で作成したクラスターを、以下のコマンドを実行して削除します: kind delete cluster --name psa-with-cluster-pss kind delete cluster --name psa-wo-cluster-pss 次の項目 ---- * 前出の一連の手順を一度に全て行うために[シェルスクリプト](https://kubernetes.io/examples/security/kind-with-cluster-level-baseline-pod-security.sh) を実行します: 1. クラスターレベルの設定に基づきPodセキュリティの標準を作成します。 2. APIサーバーでこの設定を取り込むようにファイルを作成します。 3. この設定のAPIサーバーを立てるクラスターを作成します。 4. この新しいクラスターにkubectl contextをセットします。 5. 最小限のPod YAMLファイルを作成します。 6. 新しいクラスター内でPodを作成するために、このファイルを適用します。 * [Podのセキュリティアドミッション](https://kubernetes.io/ja/docs/concepts/security/pod-security-admission/) * [Podセキュリティの標準](https://kubernetes.io/ja/docs/concepts/security/pod-security-standards/) * [名前空間レベルでのPodセキュリティの標準の適用](https://kubernetes.io/ja/docs/tutorials/security/ns-level-pss/) 2 - 名前空間レベルでのPodセキュリティの標準の適用 ============================ #### Note このチュートリアルは、新しいクラスターにのみ適用されます。 Podセキュリティアドミッション(PSA)は、[ベータへ進み](https://kubernetes.io/blog/2021/12/09/pod-security-admission-beta/) 、v1.23以降でデフォルトで有効になっています。 Podセキュリティアドミッションは、Podが作成される際に、[Podセキュリティの標準](https://kubernetes.io/ja/docs/concepts/security/pod-security-standards/) の適用の認可を制御するものです。 このチュートリアルでは、一度に1つの名前空間で`baseline` Podセキュリティ標準を強制します。 Podセキュリティの標準を複数の名前空間に一度にクラスターレベルで適用することもできます。やり方については[クラスターレベルでのPodセキュリティの標準の適用](https://kubernetes.io/ja/docs/tutorials/security/cluster-level-pss/) を参照してください。 始める前に ----- ワークステーションに以下をインストールしてください: * [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) * [kubectl](https://kubernetes.io/ja/docs/tasks/tools/) クラスターの作成 -------- 1. 以下のように`KinD`クラスターを作成します。 kind create cluster --name psa-ns-level 出力は次のようになります: Creating cluster "psa-ns-level" ... ✓ Ensuring node image (kindest/node:v1.35.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to "kind-psa-ns-level" You can now use your cluster with: kubectl cluster-info --context kind-psa-ns-level Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/ 2. kubectl のコンテキストを新しいクラスターにセットします: kubectl cluster-info --context kind-psa-ns-level 出力は次のようになります: Kubernetes control plane is running at https://127.0.0.1:50996 CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. 名前空間の作成 ------- `example`と呼ぶ新しい名前空間を作成します: kubectl create ns example 出力は次のようになります: namespace/example created 名前空間へのPodセキュリティの標準チェックの有効化 -------------------------- 1. ビルトインのPod Security Admissionでサポートされているラベルを使って、この名前空間のPodセキュリティの標準を有効にします。 このステップでは、_baseline_ Podセキュリティの標準の最新バージョンに合わないPodについて警告するチェックを設定します。 kubectl label --overwrite ns example \ pod-security.kubernetes.io/warn=baseline \ pod-security.kubernetes.io/warn-version=latest 2. ラベルを使って、任意の名前空間に対して複数のPodセキュリティの標準チェックを設定できます。 以下のコマンドは、`baseline` Podセキュリティの標準を`enforce`(強制)としますが、`restricted` Podセキュリティの標準には最新バージョンに準じて`warn`(警告)および`audit`(監査)とします(デフォルト値)。 kubectl label --overwrite ns example \ pod-security.kubernetes.io/enforce=baseline \ pod-security.kubernetes.io/enforce-version=latest \ pod-security.kubernetes.io/warn=restricted \ pod-security.kubernetes.io/warn-version=latest \ pod-security.kubernetes.io/audit=restricted \ pod-security.kubernetes.io/audit-version=latest Podセキュリティの標準の強制の実証 ------------------ 1. `example`名前空間内に`baseline` Podを作成します: kubectl apply -n example -f https://k8s.io/examples/security/example-baseline-pod.yaml Podは正常に起動しますが、出力には警告が含まれています。例えば: Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") pod/nginx created 2. `default`名前空間内に`baseline` Podを作成します: kubectl apply -n default -f https://k8s.io/examples/security/example-baseline-pod.yaml 出力は次のようになります: pod/nginx created `example`名前空間にだけ、Podセキュリティの標準のenforceと警告の設定が適用されました。 `default`名前空間内では、警告なしに同じPodを作成できました。 後片付け ---- では、上記で作成したクラスターを、以下のコマンドを実行して削除します: kind delete cluster --name psa-ns-level 次の項目 ---- * 前出の一連の手順を一度に全て行うために[シェルスクリプト](https://kubernetes.io/examples/security/kind-with-namespace-level-baseline-pod-security.sh) を実行します。 1. KinDクラスターを作成します。 2. 新しい名前空間を作成します。 3. `enforce`モードでは`baseline` Podセキュリティの標準を適用し、`warn`および`audit`モードでは`restricted` Podセキュリティの標準を適用します。 4. これらのPodセキュリティの標準を適用した新しいPodを作成します。 * [Podのセキュリティアドミッション](https://kubernetes.io/ja/docs/concepts/security/pod-security-admission/) * [Podセキュリティの標準](https://kubernetes.io/ja/docs/concepts/security/pod-security-standards/) * [クラスターレベルでのPodセキュリティの標準の適用](https://kubernetes.io/ja/docs/tutorials/security/cluster-level-pss/) 3 - AppArmorを使用してコンテナのリソースへのアクセスを制限する ===================================== FEATURE STATE: `Kubernetes v1.31 [stable]`(enabled by default) このページでは、ノードでAppArmorプロファイルを読み込み、それらのプロファイルをPodに適用する方法を説明します。 AppArmorを使用してPodを制限するKubernetesの仕組みについて詳しく知りたい場合は、[PodとコンテナのためのLinuxカーネルのセキュリティ制約](https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/#apparmor) をご覧ください。 目標 -- * プロファイルをノードに読み込む方法の例を見る * Pod上でプロファイルを強制する方法を学ぶ * プロファイルが読み込まれたかを確認する方法を学ぶ * プロファイルに違反した場合に何が起こるのかを見る * プロファイルが読み込めなかった場合に何が起こるのかを見る 始める前に ----- AppArmorはカーネルモジュールおよびKubernetesのオプション機能です。 そのため、先に進む前にノード上でAppArmorがサポートされていることを確認してください: 1. AppArmorカーネルモジュールが有効であること。 LinuxカーネルがAppArmorプロファイルを強制するためには、AppArmorカーネルモジュールのインストールと有効化が必須です。 UbuntuやSUSEなどのディストリビューションではデフォルトで有効化されますが、他の多くのディストリビューションでのサポートはオプションです。 モジュールが有効になっているかどうかを確認するためには、`/sys/module/apparmor/parameters/enabled`ファイルを確認します: cat /sys/module/apparmor/parameters/enabled Y Kubeletは、AppArmorが明示的に設定されたPodを受け入れる前にホスト上でAppArmorが有効になっているかどうかを検証します。 2. コンテナランタイムがAppArmorをサポートしていること。 Kubernetesがサポートする[containerd](https://containerd.io/docs/ "シンプルさ、堅牢性、移植性を重視したコンテナランタイムです。") や[CRI-O](https://cri-o.io/#what-is-cri-o "Kubernetesに特化した軽量コンテナランタイム") などのすべての一般的なコンテナランタイムは、AppArmorをサポートしています。 関連するランタイムのドキュメントを参照して、クラスターがAppArmorを利用するための要求を満たしているかどうかを検証してください。 3. プロファイルが読み込まれていること。 AppArmorがPodに適用されるのは、各コンテナが実行するAppArmorプロファイルを指定したときです。 もし指定されたプロファイルがまだカーネルに読み込まれていなければ、KubeletはPodを拒否します。 どのプロファイルがノードに読み込まれているのかを確かめるには、`/sys/kernel/security/apparmor/profiles`を確認します。 例えば: ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort" apparmor-test-deny-write (enforce) apparmor-test-audit-write (enforce) docker-default (enforce) k8s-nginx (enforce) ノード上でのプロファイルの読み込みの詳細については、[プロファイルを使用したノードのセットアップ](https://kubernetes.io/ja/docs/tutorials/security/_print/#setting-up-nodes-with-profiles) を参照してください。 Podをセキュアにする ----------- #### 備考: Kubernetes v1.30より前では、AppArmorはアノテーションを通じて指定されていました。 この非推奨となったAPIに関するドキュメントを表示するには、ドキュメントのバージョンセレクターを使用してください。 AppArmorプロファイルは、Podレベルまたはコンテナレベルで指定することができます。 コンテナのAppArmorプロファイルは、Podのプロファイルよりも優先されます。 securityContext: appArmorProfile: type: ここで、``には次の値のうち1つを指定します: * `RuntimeDefault`: ランタイムのデフォルトのプロファイルを適用します。 * `Localhost`: ホストに読み込まれたプロファイルを適用します(下記を参照してください)。 * `unconfined`: AppArmorなしで実行します。 AppArmorプロファイルAPIの詳細については、[AppArmorによる制限の指定](https://kubernetes.io/ja/docs/tutorials/security/_print/#specifying-apparmor-confinement) を参照してください。 プロファイルが適用されたかどうかを確認するには、proc attrを調べることでコンテナのルートプロセスが正しいプロファイルで実行されているかどうかを確認します: kubectl exec -- cat /proc/1/attr/current 出力は以下のようになるはずです: cri-containerd.apparmor.d (enforce) 例 - _この例は、クラスターがすでにAppArmorのサポート付きでセットアップ済みであることを前提としています。_ まず、使用したいプロファイルをノード上に読み込む必要があります。 このプロファイルは、すべてのファイル書き込みを拒否します: #include profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include file, # Deny all file writes. deny /** w, } Podがどのノードにスケジュールされるかは予測できないため、プロファイルはすべてのノードに読み込ませる必要があります。 この例では、単純にSSHを使ってプロファイルをインストールしますが、[プロファイルを使用したノードのセットアップ](https://kubernetes.io/ja/docs/tutorials/security/_print/#setting-up-nodes-with-profiles) では、他のアプローチについて議論しています。 # この例では、ノード名がホスト名と一致し、SSHで到達可能であることを前提としています。 NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' )) for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q < profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include file, # Deny all file writes. deny /** w, } EOF' done 次に、deny-writeプロファイルを使用した単純な"Hello AppArmor" Podを実行します。 [`pods/security/hello-apparmor.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/hello-apparmor.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/hello-apparmor.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: hello-apparmor spec: securityContext: appArmorProfile: type: Localhost localhostProfile: k8s-apparmor-example-deny-write containers: - name: hello image: busybox:1.28 command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ] kubectl create -f hello-apparmor.yaml `/proc/1/attr/current`を確認することで、コンテナがこのプロファイルで実際に実行されていることを検証できます: kubectl exec hello-apparmor -- cat /proc/1/attr/current 出力は以下のようになるはずです: k8s-apparmor-example-deny-write (enforce) 最後に、ファイルへの書き込みを行おうとすることで、プロファイルに違反すると何が起こるか見てみましょう: kubectl exec hello-apparmor -- touch /tmp/test touch: /tmp/test: Permission denied error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1 まとめとして、読み込まれていないプロファイルを指定しようとするとどうなるのか見てみましょう: kubectl create -f /dev/stdin < Annotations: container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write Status: Pending ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 10s default-scheduler Successfully assigned default/hello-apparmor to gke-test-default-pool-239f5d02-x1kf Normal Pulled 8s kubelet Successfully pulled image "busybox:1.28" in 370.157088ms (370.172701ms including waiting) Normal Pulling 7s (x2 over 9s) kubelet Pulling image "busybox:1.28" Warning Failed 7s (x2 over 8s) kubelet Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found k8s-apparmor-example-allow-write Normal Pulled 7s kubelet Successfully pulled image "busybox:1.28" in 90.980331ms (91.005869ms including waiting) イベントにはエラーメッセージとその理由が表示されます。 具体的な文言はランタイムによって異なります: Warning Failed 7s (x2 over 8s) kubelet Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found 管理 -- ### プロファイルを使用したノードのセットアップ Kubernetes 1.35は、AppArmorプロファイルをノードに読み込むネイティブの仕組みは提供していません。 プロファイルは、カスタムインフラストラクチャーや[Kubernetes Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator) などのツールを通じて読み込むことができます。 スケジューラーはどのプロファイルがどのノードに読み込まれているのかがわからないため、すべてのプロファイルがすべてのノードに読み込まれていなければなりません。 もう1つのアプローチとしては、各プロファイル(あるいはプロファイルのクラス)ごとにノードラベルを追加し、[ノードセレクター](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/assign-pod-node/) を用いてPodが必要なプロファイルを読み込んだノードで実行されるようにする方法もあります。 Profilesの作成 ----------- AppArmorプロファイルを正しく指定するのはやっかいな作業です。 幸い、その作業を補助するツールがいくつかあります: * `aa-genprof`および`aa-logprof`は、アプリケーションの動作とログを監視し、実行されるアクションを許可することで、プロファイルのルールを生成します。 詳しい説明については、[AppArmor documentation](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools) を参照してください。 * [bane](https://github.com/jfrazelle/bane) は、Docker向けのAppArmorプロファイル・ジェネレーターです。簡略化されたプロファイル言語を使用しています。 AppArmorに関する問題をデバッグするには、システムログを確認して、特に何が拒否されたのかを確認できます。 AppArmorのログは`dmesg`にverboseメッセージを送り、エラーは通常システムログまたは`journalctl`で確認できます。 詳しい情報は、[AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures) で提供されています。 AppArmorによる制限の指定 ---------------- #### 注意: Kubernetes v1.30より前では、AppArmorはアノテーションを通じて指定されていました。 この非推奨となったAPIに関するドキュメントを表示するには、ドキュメントのバージョンセレクターを使用してください。 ### セキュリティコンテキスト内のAppArmorプロファイル `appArmorProfile`は、コンテナの`securityContext`またはPodの`securityContext`のいずれかで指定できます。 プロファイルがPodレベルで設定されている場合、Pod内のすべてのコンテナ(initコンテナ、サイドカーコンテナ、およびエフェメラルコンテナを含む)のデフォルトのプロファイルとして使用されます。 Podとコンテナの両方でAppArmorプロファイルが設定されている場合は、コンテナのプロファイルが使用されます。 AppArmorプロファイルには2つのフィールドがあります: `type` _(必須)_ - 適用されるAppArmorプロファイルの種類を示します。 有効なオプションは以下の通りです: `Localhost` ノードに事前に読み込まれているプロファイル(`localhostProfile`で指定します)。 `RuntimeDefault` コンテナランタイムのデフォルトのプロファイル。 `Unconfined` AppArmorによる制限を適用しません。 `localhostProfile` - ノード上に読み込まれている、使用すべきプロファイルの名前。 このプロファイルは、ノード上であらかじめ設定されている必要があります。 このオプションは、`type`が`Localhost`の場合にのみ指定する必要があります。 次の項目 ---- 追加のリソースとしては以下のものがあります: * [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) * [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) 4 - seccompを使用してコンテナのシステムコールを制限する ================================= FEATURE STATE: `Kubernetes v1.19 [stable]` seccomp(SECure COMPuting mode)はLinuxカーネル2.6.12以降の機能です。 この機能を用いると、ユーザー空間からカーネルに対して発行できるシステムコールを制限することで、プロセス権限のサンドボックスを構築することができます。 Kubernetesでは、[ノード](https://kubernetes.io/ja/docs/concepts/architecture/nodes/ "ノードはKubernetesのワーカーマシンです。") 上で読み込んだseccompプロファイルをPodやコンテナに対して自動で適用することができます。 あなたのワークロードが必要とする権限を特定するのは、実際には難しい作業になるかもしれません。 このチュートリアルでは、ローカルのKubernetesクラスターでseccompプロファイルを読み込むための方法を説明し、seccompプロファイルのPodへの適用方法について学んだ上で、コンテナプロセスに対して必要な権限のみを付与するためのseccompプロファイルを作成する方法を概観していきます。 目標 -- * ノードでseccompプロファイルを読み込む方法を学ぶ。 * seccompプロファイルをコンテナに適用する方法を学ぶ。 * コンテナプロセスが生成するシステムコールの監査出力を確認する。 * seccompプロファイルが指定されない場合の挙動を確認する。 * seccompプロファイルの違反を確認する。 * きめ細やかなseccompプロファイルの作成方法を学ぶ。 * コンテナランタイムの標準seccompプロファイルを適用する方法を学ぶ。 始める前に ----- このチュートリアルのステップを完了するためには、[kind](https://kubernetes.io/ja/docs/tasks/tools/#kind) と[kubectl](https://kubernetes.io/ja/docs/tasks/tools/#kubectl) をインストールしておく必要があります。 このチュートリアルで利用するコマンドは、[Docker](https://www.docker.com/) をコンテナランタイムとして利用していることを前提としています。 (`kind`が作成するクラスターは内部的に異なるコンテナランタイムを利用する可能性があります)。 [Podman](https://podman.io/) を使うこともできますが、チュートリアルを完了するためには、所定の[手順](https://kind.sigs.k8s.io/docs/user/rootless/) に従う必要があります。 このチュートリアルでは、現時点(v1.25以降)でのベータ機能を利用する設定例をいくつか示しますが、その他の例についてはGAなseccomp関連機能を用いています。 利用するKubernetesバージョンを対象としたクラスターの[正しい設定](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version) がなされていることを確認してください。 チュートリアル内では、サンプルをダウンロードするために`curl`を利用します。 この手順については、ほかの好きなツールを用いて実施してもかまいません。 #### 備考: `securityContext`に`privileged: true`が設定されているContainerに対しては、seccompプロファイルを適用することができません。 特権コンテナは常に`Unconfined`な状態で動作します。 サンプルのseccompプロファイルをダウンロードする --------------------------- プロファイルの内容については後で解説しますので、まずはクラスターで読み込むためのseccompプロファイルを`profiles/`ディレクトリ内にダウンロードしましょう。 * [audit.json](https://kubernetes.io/ja/docs/tutorials/security/_print/#tab-with-code-0) * [violation.json](https://kubernetes.io/ja/docs/tutorials/security/_print/#tab-with-code-1) * [fine-grained.json](https://kubernetes.io/ja/docs/tutorials/security/_print/#tab-with-code-2) [`pods/security/seccomp/profiles/audit.json`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/seccomp/profiles/audit.json) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/seccomp/profiles/audit.json to clipboard") { "defaultAction": "SCMP_ACT_LOG" } [`pods/security/seccomp/profiles/violation.json`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/seccomp/profiles/violation.json) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/seccomp/profiles/violation.json to clipboard") { "defaultAction": "SCMP_ACT_ERRNO" } [`pods/security/seccomp/profiles/fine-grained.json`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/seccomp/profiles/fine-grained.json) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/seccomp/profiles/fine-grained.json to clipboard") { "defaultAction": "SCMP_ACT_ERRNO", "architectures": [\ "SCMP_ARCH_X86_64",\ "SCMP_ARCH_X86",\ "SCMP_ARCH_X32"\ ], "syscalls": [\ {\ "names": [\ "accept4",\ "epoll_wait",\ "pselect6",\ "futex",\ "madvise",\ "epoll_ctl",\ "getsockname",\ "setsockopt",\ "vfork",\ "mmap",\ "read",\ "write",\ "close",\ "arch_prctl",\ "sched_getaffinity",\ "munmap",\ "brk",\ "rt_sigaction",\ "rt_sigprocmask",\ "sigaltstack",\ "gettid",\ "clone",\ "bind",\ "socket",\ "openat",\ "readlinkat",\ "exit_group",\ "epoll_create1",\ "listen",\ "rt_sigreturn",\ "sched_yield",\ "clock_gettime",\ "connect",\ "dup2",\ "epoll_pwait",\ "execve",\ "exit",\ "fcntl",\ "getpid",\ "getuid",\ "ioctl",\ "mprotect",\ "nanosleep",\ "open",\ "poll",\ "recvfrom",\ "sendto",\ "set_tid_address",\ "setitimer",\ "writev",\ "fstatfs",\ "getdents64",\ "pipe2",\ "getrlimit"\ ],\ "action": "SCMP_ACT_ALLOW"\ }\ ] } 次のコマンドを実行してください: mkdir ./profiles curl -L -o profiles/audit.json https://k8s.io/examples/pods/security/seccomp/profiles/audit.json curl -L -o profiles/violation.json https://k8s.io/examples/pods/security/seccomp/profiles/violation.json curl -L -o profiles/fine-grained.json https://k8s.io/examples/pods/security/seccomp/profiles/fine-grained.json ls profiles 最終的に3つのプロファイルが確認できるはずです: audit.json fine-grained.json violation.json kindでローカルKubernetesクラスターを構築する ----------------------------- 手軽な方法として、[kind](https://kind.sigs.k8s.io/) を利用することで、seccompプロファイルを読み込んだ単一ノードクラスターを構築できます。 kindはKubernetesをDocker内で稼働させるため、クラスターの各ノードはコンテナとなります。 これにより、ノード上にファイルを展開するのと同じように、各コンテナのファイルシステムに対してファイルをマウントすることが可能です。 [`pods/security/seccomp/kind.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/seccomp/kind.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/seccomp/kind.yaml to clipboard") apiVersion: kind.x-k8s.io/v1alpha4 kind: Cluster nodes: - role: control-plane extraMounts: - hostPath: "./profiles" containerPath: "/var/lib/kubelet/seccomp/profiles" kindの設定サンプルをダウンロードして、`kind.yaml`の名前で保存してください: curl -L -O https://k8s.io/examples/pods/security/seccomp/kind.yaml ノードのコンテナイメージを設定する際には、特定のKubernetesバージョンを指定することもできます。 この設定方法の詳細については、kindのドキュメント内の、[ノード](https://kind.sigs.k8s.io/docs/user/configuration/#nodes) の項目を参照してください。 このチュートリアルではKubernetes v1.35を使用することを前提とします。 ベータ機能として、`Unconfined`にフォールバックするのではなく、[コンテナランタイム](https://kubernetes.io/ja/docs/setup/production-environment/container-runtimes "コンテナランタイムは、コンテナの実行を担当するソフトウェアです。") がデフォルトで推奨するプロファイルを利用するようにKubernetesを設定することもできます。 この機能を試したい場合、これ以降の手順に進む前に、[全ワークロードに対する標準seccompプロファイルとして`RuntimeDefault`を使用する](https://kubernetes.io/ja/docs/tutorials/security/_print/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads) を参照してください。 kindの設定ファイルを設置したら、kindクラスターを作成します: kind create cluster --config=kind.yaml Kubernetesクラスターが準備できたら、単一ノードクラスターが稼働しているDockerコンテナを特定してください: docker ps `kind-control-plane`という名前のコンテナが稼働していることが確認できるはずです。 出力は次のようになるでしょう: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6a96207fed4b kindest/node:v1.18.2 "/usr/local/bin/entr…" 27 seconds ago Up 24 seconds 127.0.0.1:42223->6443/tcp kind-control-plane このコンテナのファイルシステムを観察すると、`profiles/`ディレクトリがkubeletのデフォルトのseccompパスとして正しく読み込まれていることを確認できるはずです。 Pod内でコマンドを実行するために`docker exec`を使います: # 6a96207fed4bを"docker ps"で確認したコンテナIDに変更してください。 docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles audit.json fine-grained.json violation.json kind内で稼働しているkubeletがseccompプロファイルを利用可能であることを確認しました。 コンテナランタイムの標準seccompプロファイルを利用してPodを作成する -------------------------------------- ほとんどのコンテナランタイムは、許可・拒否の対象とする標準的なシステムコールの集合を提供しています。 PodやContainerのセキュリティコンテキストでseccompタイプを`RuntimeDefault`に設定すると、コンテナランタイムが提供するデフォルトのプロファイルをワークロードに適用することができます。 #### 備考: `seccompDefault`の[設定](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/) を有効化している場合、他にseccompプロファイルを定義しなくても、Podは`RuntimeDefault` seccompプロファイルを使用します。 `seccompDefault`が無効の場合のデフォルトは`Unconfined`です。 Pod内の全てのContainerに対して`RuntimeDefault` seccompプロファイルを要求するマニフェストは次のようなものです: [`pods/security/seccomp/ga/default-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/seccomp/ga/default-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/seccomp/ga/default-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: default-pod labels: app: default-pod spec: securityContext: seccompProfile: type: RuntimeDefault containers: - name: test-container image: hashicorp/http-echo:1.0 args: - "-text=just made some more syscalls!" securityContext: allowPrivilegeEscalation: false このPodを作成してみます: kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml kubectl get pod default-pod Podが正常に起動できていることを確認できるはずです: NAME READY STATUS RESTARTS AGE default-pod 1/1 Running 0 20s 次のセクションに進む前に、Podを削除します: kubectl delete pod default-pod --wait --now システムコール監査のためのseccompプロファイルを利用してPodを作成する --------------------------------------- 最初に、新しいPodにプロセスの全システムコールを記録するための`audit.json`プロファイルを適用します。 このPodのためのマニフェストは次の通りです: [`pods/security/seccomp/ga/audit-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/seccomp/ga/audit-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/seccomp/ga/audit-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: audit-pod labels: app: audit-pod spec: securityContext: seccompProfile: type: Localhost localhostProfile: profiles/audit.json containers: - name: test-container image: hashicorp/http-echo:1.0 args: - "-text=just made some syscalls!" securityContext: allowPrivilegeEscalation: false #### 備考: 過去のバージョンのKubernetesでは、[アノテーション](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/annotations "任意の非識別メタデータをオブジェクトにアタッチするために使用されるキーと値のペア。") を用いてseccompの挙動を制御することができました。 Kubernetes 1.35におけるseccompの設定では`.spec.securityContext`フィールドのみをサポートしており、このチュートリアルではKubernetes 1.35における手順を解説しています。 クラスター内にPodを作成します: kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/audit-pod.yaml このプロファイルは、いかなるシステムコールも制限しないため、Podは正常に起動するはずです。 kubectl get pod audit-pod NAME READY STATUS RESTARTS AGE audit-pod 1/1 Running 0 30s このコンテナが公開するエンドポイントとやりとりするために、kindのコントロールプレーンコンテナの内部からこのエンドポイントにアクセスできるように、NodePort [Service](https://kubernetes.io/ja/docs/concepts/services-networking/service/ "Podの集合で実行されているアプリケーションをネットワークサービスとして公開する方法。") を作成します。 kubectl expose pod audit-pod --type NodePort --port 5678 どのポートがノード上のServiceに割り当てられたのかを確認しましょう。 kubectl get service audit-pod 次のような出力が得られます: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE audit-pod NodePort 10.111.36.142 5678:32373/TCP 72s ここまで来れば、kindのコントロールプレーンコンテナの内部からエンドポイントに対して、Serviceが公開するポートを通じて`curl`で接続することができます。 `docker exec`を使って、コントロールプレーンコンテナに属するコンテナの中から`curl`を実行しましょう: # 6a96207fed4bと32373を、それぞれ"docker ps"で確認したコンテナIDとポート番号に変更してください。 docker exec -it 6a96207fed4b curl localhost:32373 just made some syscalls! プロセスが実行されていることは確認できましたが、実際にどんなシステムコールが発行されているのでしょうか？ このPodはローカルクラスターで稼働しているため、発行されたシステムコールを`/var/log/syslog`で確認することができるはずです。 新しいターミナルを開いて、`http-echo`が発行するシステムコールを`tail`してみましょう: # あなたのマシンのログは"/var/log/syslog"以外の場所にあるかもしれません。 tail -f /var/log/syslog | grep 'http-echo' すでに`http-echo`が発行したいくつかのシステムコールのログが見えているはずです。 コントロールプレーンコンテナ内から再度`curl`を実行すると、新たにログに追記された内容が出力されます。 例えば、次のような出力が得られるでしょう: Jul 6 15:37:40 my-machine kernel: [369128.669452] audit: type=1326 audit(1594067860.484:14536): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=51 compat=0 ip=0x46fe1f code=0x7ffc0000 Jul 6 15:37:40 my-machine kernel: [369128.669453] audit: type=1326 audit(1594067860.484:14537): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=54 compat=0 ip=0x46fdba code=0x7ffc0000 Jul 6 15:37:40 my-machine kernel: [369128.669455] audit: type=1326 audit(1594067860.484:14538): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000 Jul 6 15:37:40 my-machine kernel: [369128.669456] audit: type=1326 audit(1594067860.484:14539): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=288 compat=0 ip=0x46fdba code=0x7ffc0000 Jul 6 15:37:40 my-machine kernel: [369128.669517] audit: type=1326 audit(1594067860.484:14540): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=0 compat=0 ip=0x46fd44 code=0x7ffc0000 Jul 6 15:37:40 my-machine kernel: [369128.669519] audit: type=1326 audit(1594067860.484:14541): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000 Jul 6 15:38:40 my-machine kernel: [369188.671648] audit: type=1326 audit(1594067920.488:14559): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000 Jul 6 15:38:40 my-machine kernel: [369188.671726] audit: type=1326 audit(1594067920.488:14560): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000 各行の`syscall=`エントリに着目することで、`http-echo`プロセスが必要とするシステムコールを理解していくことができるでしょう。 このプロセスが利用する全てのシステムコールを網羅するものではないかもしれませんが、このコンテナのseccompプロファイルを作成する上での基礎とすることは可能です。 次のセクションに進む前にServiceとPodを削除します: kubectl delete service audit-pod --wait kubectl delete pod audit-pod --wait --now 違反が発生するseccompプロファイルでPodを作成する ----------------------------- デモとして、いかなるシステムコールも許可しないseccompプロファイルをPodに適用してみましょう。 マニフェストは次の通りです: [`pods/security/seccomp/ga/violation-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/seccomp/ga/violation-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/seccomp/ga/violation-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: violation-pod labels: app: violation-pod spec: securityContext: seccompProfile: type: Localhost localhostProfile: profiles/violation.json containers: - name: test-container image: hashicorp/http-echo:1.0 args: - "-text=just made some syscalls!" securityContext: allowPrivilegeEscalation: false クラスターにPodを作成してみます: kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/violation-pod.yaml Podを作成しても問題が発生します。 Podの状態を確認すると、起動に失敗していることが確認できるはずです。 kubectl get pod violation-pod NAME READY STATUS RESTARTS AGE violation-pod 0/1 CrashLoopBackOff 1 6s 直前の事例で見てきたように、`http-echo`プロセスは多くのシステムコールを必要とします。 ここでは`"defaultAction": "SCMP_ACT_ERRNO"`が設定されているため、あらゆるシステムコールに対してseccompがエラーを発生させました。 この構成はとてもセキュアですが、有意義な処理は何もできないことを意味します。 私たちが実際にやりたいのは、ワークロードが必要とする権限のみを付与することです。 次のセクションに進む前にPodを削除します。 kubectl delete pod violation-pod --wait --now 必要なシステムコールのみを許可するseccompプロファイルを用いてPodを作成する ------------------------------------------ `fine-grained.json`プロファイルの内容を見れば、最初の例で`"defaultAction":"SCMP_ACT_LOG"`を設定していた際に、ログに表示されたシステムコールが含まれていることに気づくでしょう。 今回のプロファイルでも`"defaultAction": "SCMP_ACT_ERRNO"`を設定しているものの、`"action": "SCMP_ACT_ALLOW"`ブロックで明示的に一連のシステムコールを許可しています。 理想的な状況下であれば、コンテナが正常に稼働することに加え、`syslog`へのメッセージ送信を見ることはなくなるでしょう。 この事例のマニフェストは次の通りです: [`pods/security/seccomp/ga/fine-pod.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/ja/examples/pods/security/seccomp/ga/fine-pod.yaml) ![](https://kubernetes.io/images/copycode.svg "Copy pods/security/seccomp/ga/fine-pod.yaml to clipboard") apiVersion: v1 kind: Pod metadata: name: fine-pod labels: app: fine-pod spec: securityContext: seccompProfile: type: Localhost localhostProfile: profiles/fine-grained.json containers: - name: test-container image: hashicorp/http-echo:1.0 args: - "-text=just made some syscalls!" securityContext: allowPrivilegeEscalation: false クラスター内にPodを作成します: kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/fine-pod.yaml kubectl get pod fine-pod Podは正常に起動しているはずです: NAME READY STATUS RESTARTS AGE fine-pod 1/1 Running 0 30s 新しいターミナルを開いて、`http-echo`からのシステムコールに関するログエントリを`tail`で監視しましょう: # あなたのマシンのログは"/var/log/syslog"以外の場所にあるかもしれません。 tail -f /var/log/syslog | grep 'http-echo' 次のPodをNodePort Serviceで公開します: kubectl expose pod fine-pod --type NodePort --port 5678 ノード上のServiceに割り当てられたポートを確認します: kubectl get service fine-pod 出力は次のようになるでしょう: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE fine-pod NodePort 10.111.36.142 5678:32373/TCP 72s kindのコントロールプレーンコンテナの内部から、`curl`を用いてエンドポイントにアクセスします: # 6a96207fed4bと32373を、それぞれ"docker ps"で確認したコンテナIDとポート番号に変更してください。 docker exec -it 6a96207fed4b curl localhost:32373 just made some syscalls! `syslog`には何も出力されないはずです。 なぜなら、このプロファイルは必要なシステムコールを全て許可しており、一覧にないシステムコールが呼び出された時にのみエラーを発生させるように構成しているためです。 これはセキュリティの観点からすると理想的なシチュエーションといえますが、seccompプロファイルを作成するためのプログラムの解析には多少の労力が必要です。 多くの労力を割かなくてもこれに近いセキュリティが得られるシンプルな手法があったなら、きっと素晴らしいものになるでしょう。 次のセクションに進む前にServiceとPodを削除します: kubectl delete service fine-pod --wait kubectl delete pod fine-pod --wait --now 全ワークロードに対する標準seccompプロファイルとして`RuntimeDefault`を使用する -------------------------------------------------- FEATURE STATE: `Kubernetes v1.27 [stable]` 標準seccompプロファイルを指定するためには、この機能を利用したい全てのノードで`--seccomp-default`[コマンドラインフラグ](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) を用いてkubeletを起動する必要があります。 この機能を有効化すると、kubeletはコンテナランタイムが定義する`RuntimeDefault`のseccompプロファイルをデフォルトで使用するようになり、`Unconfined`モード(seccomp無効化)になることはありません。 コンテナランタイムが用意する標準プロファイルは、ワークロードの機能性を維持しつつ、強力な標準セキュリティルールの一式を用意することを目指しています。 標準のプロファイルはコンテナランタイムやリリースバージョンによって異なる可能性があります。 例えば、CRI-Oとcontainerdの標準プロファイルを比較してみるとよいでしょう。 #### 備考: この機能を有効化しても、PodやContainerなどの`securityContext.seccompProfile`フィールドは変更されず、非推奨のアノテーションがワークロードに追加されることもありません。 したがって、ユーザーはワークロードの設定を変更せずにロールバックすることが可能です。 [`crictl inspect`](https://github.com/kubernetes-sigs/cri-tools) のようなツールを使うことで、コンテナがどのseccompプロファイルを利用しているのかを確認できます。 いくつかのワークロードでは、他のワークロードよりもシステムコール制限を少なくすることが必要な場合があります。 つまり、`RuntimeDefault`を適用する場合、こうしたワークロードの実行が失敗する可能性があります。 このような障害を緩和するために、次のような対策を講じることができます: * ワークロードを明示的に`Unconfined`として稼働させる。 * `SeccompDefault`機能をノードで無効化する。 また、機能を無効化したノードに対してワークロードが配置されていることを確認しておく。 * ワークロードを対象とするカスタムseccompプロファイルを作成する。 実運用環境に近いクラスターに対してこの機能を展開する場合、クラスター全体に対して変更をロールアウトする前に、一部ノードのみを対象にしてこのフィーチャーゲートを有効化し、ワークロードが実行できることを検証しておくことをお勧めします。 クラスターに対してとりうるアップグレード・ダウングレード戦略について更に詳細な情報を知りたい場合は、関連するKubernetes Enhancement Proposal (KEP)である[Enable seccomp by default](https://github.com/kubernetes/enhancements/tree/9a124fd29d1f9ddf2ff455c49a630e3181992c25/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy) を参照してください。 Kubernetes 1.35では、specで特定のseccompプロファイルを指定していないPodに対して、デフォルトで適用するseccompプロファイルを設定することができます。 ただし、この標準seccompプロファイルを利用する場合、対象とする全ノードでこの機能を有効化しておく必要があります。 稼働中のKubernetes 1.35クラスターでこの機能を有効化する場合、kubeletに`--seccomp-default`コマンドラインフラグを付与して起動するか、[Kubernetesの設定ファイル](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/) でこの機能を有効化する必要があります。 このフィーチャーゲートを[kind](https://kind.sigs.k8s.io/) で有効化する場合、`kind`が最低限必要なKubernetesバージョンを満たしていて、かつ[kindの設定ファイル](https://kind.sigs.k8s.io/docs/user/quick-start/#enable-feature-gates-in-your-cluster) で`SeccompDefault`を有効化してください: kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: seccomp-default: "true" - role: worker image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: seccomp-default: "true" クラスターの準備ができたら、Podを実行します: kubectl run --rm -it --restart=Never --image=alpine alpine -- sh このコマンドで標準のseccompプロファイルを紐付けられるはずです。 この結果を確認するには、`docker exec`経由で`crictl inspect`を実行することで、kindワーカー上のコンテナを確認します: docker exec -it kind-worker bash -c \ 'crictl inspect $(crictl ps --name=alpine -q) | jq .info.runtimeSpec.linux.seccomp' { "defaultAction": "SCMP_ACT_ERRNO", "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"], "syscalls": [\ {\ "names": ["..."]\ }\ ] } 次の項目 ---- Linuxのseccompについて更に学びたい場合は、次の記事を参考にすると良いでしょう: * [A seccomp Overview](https://lwn.net/Articles/656307/) * [Seccomp Security Profiles for Docker](https://docs.docker.com/engine/security/seccomp/) ---