# Kubernetes: Cloud Native Orkestatsiyaning Professional Anatomiyasi Kubernetes — bu zamonaviy IT infrastrukturasining eng muhim va murakkab orkestrator platformasi bo'lib, bugungi kunda dunyodagi deyarli barcha yirik kompaniyalar tomonidan qo'llanilmoqda. Ushbu chuqur texnik qo'llanmada biz Kubernetes ning tarixiy kelib chiqishi, arxitekturaviy tuzilishi va real-world deployment strategiyalarini professional darajada tahlil qilamiz. Kubernetes nafaqat oddiy konteyner orkestrator, balki butun cloud native ekotizimning asosi hisoblanadi. Netflix ning 700+ mikroservis arxitekturasi, Spotify ning real-time musiqa streaming platformasi, va Pokemon GO ning viral ommaviyligi paytidagi traffic spike — bularning barchasi Kubernetes ustida ishlaydi va muvaffaqiyatga erishadi. ## Kubernetes ning Tarixiy Evolyutsiyasi va Strategik Ahamiyati Kubernetes tarixini tushunish uchun biz Google ning ichki konteyner orkestrator tizimi bo'lgan Borg dan boshlaymiz. 2003 yilda yaratilgan Borg tizimi Google ning eng muhim loyihalari — Search, Gmail, YouTube, Maps — ularning barcha infratuzilmasini boshqargan. Google ning dasturchi-muhandislari Borg bilan 15 yil davomida tajriba to'plab, konteynerlashtirish va orkestatsiyaning eng chuqur sirlarini o'zlashtirganlar. Borg tizimi qator fundamental principle'larni yaratdi: declarative configuration, immutable infrastructure, va self-healing capabilities. Google'ning internal ma'lumotlariga ko'ra, Borg har soniyada ming'lab task'larni schedule qiladi va petabyte'lab ma'lumotni process qiladi. Bu scale va reliability Kubernetes'ning genetik kodiga singib ketgan. 2014 yilda Google jamg'armasi qaror qiladiki, ushbu bilim va tajribani butun dunyoga ochiq qilib bersin. Shunda Kubernetes loyihasi tug'ilib, birinchi commit Joe Beda, Brendan Burns va Craig McLuckie tomonidan qilinadi. Dastur nomi yunon tilidan olingan bo'lib, "kemachi" yoki "pilot" ma'nosini anglatadi — bu konteynerlar okeanida yo'l ko'rsatuvchi sifatida tanlangan nom. Kubernetes ning eng strategik qadami — bu CNCF (Cloud Native Computing Foundation) ga o'tkazilishi bo'ldi. 2015 yilda Linux Foundation ostida tashkil etilgan CNCF ga Kubernetes birinchi loyiha sifatida qo'shiladi. Bu qaror natijasida AWS, Microsoft, Red Hat, VMware va boshqa yirik kompaniyalar birgalikda ishlay boshladilar. Bugun CNCF da 150+ loyiha mavjud, lekin Kubernetes hali ham eng muhimi hisoblanadi. Kubernetes'ning sanoatga ta'siri revolution darajasidagi bo'ldi. Traditional IT'da server provisioning haftalar talab qilgan bo'lsa, Kubernetes bilan bir necha daqiqada resource'lar tayyorlanadi. Infrastructure as Code (IaC) paradigmasi orqali manual configuration'dan declarative orchestration'ga o'tish sodir bo'ldi. Bu DevOps madaniyatining rivojlanishiga katta hissa qo'shdi. Arxitekturaviy jihatdan Kubernetes declarative API modelini joriy etdi. Bu degani, siz tizimga "nima kerak" deb aytasiz, "qanday qilish kerakligini" emas. Misol uchun, "3 ta pod kerak" desangiz, K8s o'zi cluster da 3 ta pod ishlayotganini ta'minlaydi. Agar birontasi nobud bo'lsa, avtomatik ravishda yangisini yaratadi. Bu self-healing xususiyat traditional IT operatsiyalarida inqilob qildi. Kubernetes ning sanoat miqyosidagi ta'siri haqida gapirish uchun, PayPal ning case study sini ko'rib chiqaylik. 2016 yilda PayPal traditional virtualizatsiya arxitekturasidan Kubernetes ga o'tdi. Natijada deployment vaqti 30 daqiqadan 2 daqiqaga tushdi, resource utilization 40% ga oshdi, va developer productivity ikki baravar ko'paydi. > [!NOTE] > Kubernetes'ning global adoption statistikasi: > - 96% yirik enterprise'lar Kubernetes ishlatadi > - GitHub'da 100,000+ star bilan eng mashhur orchestrator > - 2.8 million developer'lar faol ravishda ishlatadi > - 80% cloud provider'lar managed Kubernetes service beradi ## Kubernetes Cluster Arxitekturasi: Control Plane va Worker Node Anatomy Kubernetes cluster ikkita asosiy komponentdan iborat: Control Plane va Worker Node'lar. Bu arxitektura master-slave pattern dan ilhomlangan, lekin zamonaviy distributed system prinsiplarini qo'llaydi. Control Plane clusterni "miyasi" hisoblanadi — u barcha qarorlar qabul qiladi, resource'larni nazorat qiladi va API endpoint'larni ta'minlaydi. Control Plane'ning distributed nature'i uni highly available qiladi. Production environment'larda kamida 3 ta control plane node bo'lishi kerak, bu 1 ta node failure'da ham cluster ishlashini davom ettiradi. Load balancer orqali API traffic distribute qilinadi va leader election mechanism orqali faqat bitta instance active bo'ladi. Control Plane'ning eng muhim komponenti API Server (kube-apiserver) hisoblanadi. Bu RESTful HTTP API orqali barcha cluster operatsiyalari amalga oshiriladi. kubectl, web UI, yoki boshqa har qanday tool API Server orqali ishlaydi. API Server stateless bo'lib, barcha state ma'lumotlarini etcd da saqlaydi. Bu horizontally scalable qilish imkonini beradi — siz bir nechta API Server instance yaratib, load balancer orqasiga qo'yishingiz mumkin. API Server'ning authentication va authorization layer'lari enterprise security requirement'larini qondiradi. RBAC (Role-Based Access Control), OIDC integration, webhook authorization kabi mechanism'lar mavjud. Admission controller'lar request validation va mutation uchun ishlatiladi. OPA (Open Policy Agent) Gatekeeper orqali complex policy enforcement mumkin. etcd — bu distributed key-value store bo'lib, Kubernetes ning barcha cluster ma'lumotlarini saqlaydi. Pod'lar, Service'lar, ConfigMap'lar, Secret'lar — hammasi etcd da JSON formatida saqlanadi. etcd Raft consensus algoritmi asosida ishlaydi, bu high availability va data consistency'ni ta'minlaydi. Google Cloud'da ishlayotgan Kubernetes cluster'larda ko'pincha etcd uchun 5 ta node ishlatiladi — bu 2 ta node fail bo'lsa ham cluster ishlay berishni ta'minlaydi. etcd'ning performance characteristics juda muhim. Write throughput limited bo'lgani uchun, large-scale cluster'larda etcd bottleneck bo'lishi mumkin. shuning uchun etcd optimization, proper backup strategy va monitoring critical. etcd corruption cluster'ning complete failure'iga olib kelishi mumkin. Scheduler (kube-scheduler) komponenti esa yangi pod'larni qaysi worker node'ga joylashtirish kerakligini belgilaydi. Bu decision-making jarayoni juda murakkab bo'lib, node resource'lari, pod requirement'lari, affinity/anti-affinity qoidalar, taints va tolerations hisobga olinadi. Netflix ning microservice'lari uchun custom scheduler yaratilgan — bu media encoding workload'lar uchun GPU-rich node'larni, database pod'lari uchun SSD-rich node'larni avtomatik tanlaydi. Scheduler'ning algorithm'i sophisticated bo'lib, predicates (filtering) va priorities (scoring) bosqichlaridan iborat. Node'lar avval filter qilinadi (resource availability, taint/toleration), keyin priority score beriladi (resource balance, affinity rules). Custom scheduler plugin'lar yozish mumkin specific workload requirement'lari uchun. Controller Manager bir nechta control loop'larni ishlatadi: Deployment Controller, ReplicaSet Controller, Service Controller va hokazo. Har bir controller desired state'ni actual state bilan compare qilib, reconciliation qiladi. Bu eventual consistency modelining namunasi. ```mermaid flowchart TD A["API Server"] --> B["etcd Cluster"] A --> C["Scheduler"] A --> D["Controller Manager"] C --> F["kubelet"] F --> G["Container Runtime"] F --> H["Pods"] I["kube-proxy"] --> H J["kubectl CLI"] --> A K["Load Balancer"] --> A ``` Worker node'larda esa kubelet jarayoni ishlaydi. kubelet — bu har bir node'dagi "agent" bo'lib, API Server bilan doimiy aloqada bo'ladi. U pod'larning lifecycle'ini boshqaradi: yangi pod'larni yaratish, health check'lar o'tkazish, resource monitoring qilish. kubelet container runtime (Docker, containerd, CRI-O) bilan CRI (Container Runtime Interface) orqali ishlaydi. kubelet'ning garbage collection mechanism'i disk space'ni manage qiladi. Old container image'lar va dead container'lar automatic ravishda delete qilinadi. eviction policy node resource pressure'da pod'larni graceful terminate qiladi. kube-proxy esa network component hisoblanadi. U Service abstraction'ni implement qiladi — ya'ni pod'lar o'rtasidagi load balancing va service discovery. kube-proxy har bir node'da iptables yoki IPVS qoidalarini dynamic ravishda boshqaradi. AWS EKS'da, misol uchun, kube-proxy AWS Load Balancer Controller bilan birgalikda ishlayadi. Modern kube-proxy implementation'lari IPVS (IP Virtual Server) ishlatadi, bu iptables'dan ko'ra samaraliroq. IPVS kernel-level load balancing beradi va ming'lab service'lar bilan scale qiladi. iptables rule'lari linear lookup talab qilganda, IPVS hash table lookup ishlatadi. | Komponent | Vazifasi | Joylashuvi | Critical Level | | ----------- | ---------- | ------------- | ---------------- | | API Server | RESTful API, Authentication | Control Plane | Critical | | etcd | Key-Value Store, State Management | Control Plane | Critical | | Scheduler | Pod Placement, Resource Allocation | Control Plane | High | | Controller Manager | Reconciliation, Desired State | Control Plane | High | | kubelet | Node Agent, Pod Lifecycle | Worker Node | Critical | | kube-proxy | Network Proxy, Service Discovery | Worker Node | High | ## Pod'lar va Container Orchestration: Atomic Unit'ning Chuqur Tahlili Pod — Kubernetes'dagi eng kichik deploy qilinadigan unit hisoblanadi. Bir pod ichida bir yoki bir nechta container bo'lishi mumkin, lekin ko'pincha bitta container bo'ladi. Pod'ning philosophical approach'i shundaki, u traditional physical server yoki VM'ning o'rnini bosadi. Bir pod ichidagi container'lar bir-biri bilan localhost orqali muloqot qilishi mumkin va volume'larni share qiladi. Pod'ning shared context'i juda muhim kontseptsiya. Pod ichidagi container'lar bir xil network namespace, IPC namespace va UTS namespace'ni share qiladi. Bu degani, ular bir xil IP address'ga ega, localhost orqali muloqot qiladi va volume'larni mount qila oladi. Lekin PID namespace default'da ajratilgan, garchi shareProcessNamespace: true bilan birlashtirish mumkin. Pod'ning lifecycle'i juda muhim kontseptsiya. Pod'lar ephemeral hisoblanadi — ular istalgan vaqtda o'chib, boshqa node'da qayta yaratilishi mumkin. Shuning uchun stateful application'lar uchun StatefulSet ishlatiladi. MongoDB yoki PostgreSQL kabi database'lar uchun StatefulSet ordered deployment, stable network identifier va persistent storage'ni ta'minlaydi. Pod lifecycle hook'lari advanced orchestration uchun ishlatiladi. PostStart hook pod start bo'lgandan keyin bajariladi, PreStop hook esa pod terminate bo'lishidan oldin. Bu hook'lar graceful shutdown, initialization task'lar, cleanup operation'lar uchun foydali. Multi-container pod'lar advanced pattern hisoblanadi. Sidecar pattern — eng mashhurlari. Misol uchun, web server container va log aggregator container bitta pod da bo'lishi mumkin. Google Cloud'ning Istio service mesh'ida har bir pod'ga Envoy proxy sidecar inject qilinadi. Bu pod ichidagi traffic'ni intercept qilib, security, monitoring va routing feature'larni qo'shadi. Ambassador pattern yana bir multi-container use case. Main application container va ambassador container birgalikda ishlaydi. Ambassador external service'lar bilan integration uchun proxy vazifasini bajaradi. Bu connection pooling, circuit breaking, retry logic kabi feature'lar beradi application code'ni o'zgartirmasdan. Pod resource management juda critical. CPU va memory limit'lar Quality of Service (QoS) class'larini belgilaydi: Guaranteed, Burstable va BestEffort. Guaranteed QoS uchun request va limit bir xil bo'lishi kerak. Kubernetes node'da resource shortage bo'lsa, avval BestEffort pod'lar o'chiriladi, keyin Burstable, oxirida Guaranteed. Resource limit'lar kernel-level enforcement orqali amalga oshiriladi. Memory limit cgroup memory controller orqali, CPU limit esa CFS (Completely Fair Scheduler) orqali nazorat qilinadi. GPU kabi extended resource'lar uchun device plugin framework ishlatiladi. ```yaml apiVersion: v1 kind: Pod metadata: name: advanced-webapp namespace: production labels: app: webapp tier: frontend version: v2.1.0 annotations: prometheus.io/scrape: "true" prometheus.io/port: "8080" spec: containers: - name: web-server image: nginx:1.21-alpine resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "500m" ports: - containerPort: 80 name: http - containerPort: 8080 name: metrics volumeMounts: - name: shared-data mountPath: /usr/share/nginx/html - name: nginx-config mountPath: /etc/nginx/conf.d livenessProbe: httpGet: path: /health port: 80 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 80 initialDelaySeconds: 5 periodSeconds: 5 lifecycle: preStop: exec: command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"] - name: log-collector image: fluent/fluent-bit:2.0 resources: requests: memory: "128Mi" cpu: "100m" limits: memory: "256Mi" cpu: "200m" volumeMounts: - name: shared-data mountPath: /var/log/nginx - name: fluent-config mountPath: /fluent-bit/etc env: - name: FLUENTD_CONF value: "fluent.conf" - name: ELASTICSEARCH_HOST value: "elasticsearch.logging.svc.cluster.local" volumes: - name: shared-data emptyDir: sizeLimit: 1Gi - name: nginx-config configMap: name: nginx-config - name: fluent-config configMap: name: fluent-config restartPolicy: Always terminationGracePeriodSeconds: 30 dnsPolicy: ClusterFirst serviceAccountName: webapp-sa ``` Yuqoridagi Pod manifest'i production-ready multi-container pod'ni ko'rsatadi. Bu yerda nginx web server va fluent-bit log collector birgalikda ishlamoqda. `emptyDir` volume orqali ular log file'larni share qiladilar. Resource request/limit'lar Quality of Service'ni Burstable qiladi. Health check'lar, lifecycle hook'lar va proper configuration mount'lari mavjud. Init Container'lar ham muhim pattern. Ular asosiy container'lar ishga tushishidan oldin bajariladi. Database schema migration, configuration file download, dependency check — bunday task'lar uchun ishlatiladi. Spotify'ning deployment pipeline'ida init container'lar configuration management va secret provisioning uchun ishlatiladi. Init Container'lar sequential ravishda bajariladi va har biri successfully complete bo'lishi kerak keyingisi uchun. Bu dependency management va complex initialization scenario'lar uchun juda foydali. Init Container'lar main container'lar bilan image, volume, security context share qiladi. Pod Security Context cluster-wide security policy'ni enforce qiladi. runAsUser, runAsGroup, fsGroup kabi field'lar security posture'ni belgilaydi. securityContext pod yoki container level'da set qilinadi. Pod Security Standard (PSS) predefined security profile'lar beradi: privileged, baseline, restricted. > [!TIP] > Pod design best practice'lari: > - Bitta pod ichida bir xil lifecycle'ga ega container'larni joylashtiring > - Tightly coupled container'larni bitta pod'da, loosely coupled'larni alohida pod'larda saqlang > - Resource request/limit'larni realistic qilib belgilang > - Health check'larni proper configure qiling > - Graceful shutdown uchun preStop hook ishlatilang ## Service Discovery va Networking: Cluster Ichidagi Communication Anatomiyasi Kubernetes networking modeli flat network topology'ga asoslangan. Har bir pod o'zining unique IP address'iga ega va cluster ichidagi boshqa har qanday pod bilan to'g'ridan-to'g'ri muloqot qila oladi. Bu philosophy traditional networking'dan farq qiladi, u yerda NAT va port mapping kerak bo'ladi. Bu flat network model CNI (Container Network Interface) orqali implement qilinadi. Flannel, Calico, Weave Net, Cilium kabi CNI plugin'lar turli xil networking solution'lar beradi. Calico network policy enforcement beradi, Cilium eBPF-based high-performance networking, Flannel simple overlay network. Pod-to-Pod communication L3 routing orqali amalga oshadi. Har bir node'da pod CIDR range mavjud va routing table'lar orqali inter-node communication ta'minlanadi. Overlay network (VXLAN, IPSec) yoki underlay network (BGP routing) ishlatilishi mumkin cloud provider'ga bog'liq. Service abstraction Kubernetes'ning eng genial innovation'laridan biri. Service — bu pod'larning logical group'i va ularga stable endpoint beradi. Pod'lar ephemeral bo'lgani uchun, ularning IP address'lari o'zgaradi. Service esa stable virtual IP (ClusterIP) beradi va kube-proxy orqali traffic'ni healthy pod'larga distribute qiladi. Service Discovery Kubernetes'da DNS-based bo'ladi. CoreDNS cluster DNS server sifatida ishlaydi va Service name'larni IP address'larga resolve qiladi. `..svc.cluster.local` FQDN format ishlatiladi. Short name lookup ham mumkin agar same namespace ichida bo'lsa. Service'larning turli xil type'lari mavjud va har birining o'z use case'i bor: ClusterIP — default Service type bo'lib, cluster ichidagi internal communication uchun. Virtual IP assign qilinadi va kube-proxy load balancing qiladi. Internal microservice communication uchun ishlatiladi. NodePort — external traffic'ni specific node port'i orqali cluster ichiga o'tkazadi. 30000-32767 port range'da random port assign qilinadi. Development va testing uchun qulay, production'da kam ishlatiladi. LoadBalancer — cloud provider integration orqali external load balancer yaratadi. AWS'da bu Application Load Balancer yoki Network Load Balancer bo'lishi mumkin. Cloud provider'ning native load balancer feature'larini leverage qiladi. ExternalName — external service'lar uchun CNAME record yaratadi. Database yoki external API'larga service abstraction berish uchun ishlatiladi. Headless Service — ClusterIP bo'lmagan service bo'lib, to'g'ridan-to'g'ri pod IP'lar return qiladi. StatefulSet'lar va service mesh'lar bilan ishlatiladi. ```mermaid flowchart TB U["User Request"] --> LB["Cloud Load Balancer"] LB --> IG["Ingress Controller"] IG --> S1["Service: webapp"] IG --> S2["Service: api"] S1 --> P1["Pod: webapp-1"] S1 --> P2["Pod: webapp-2"] S2 --> P3["Pod: api-1"] S2 --> P4["Pod: api-2"] S3["Service: db"] --> P5["Pod: postgres-0"] KP["kube-proxy"] -.-> S1 KP -.-> S2 KP -.-> S3 DNS["CoreDNS"] -.-> S1 DNS -.-> S2 DNS -.-> S3 ``` Ingress controller esa HTTP/HTTPS traffic routing uchun ishlatiladi. Ingress Service'lardan yuqori darajali abstraction bo'lib, domain-based routing, SSL termination, path-based routing kabi feature'lar beradi. NGINX Ingress Controller eng mashhurlari, lekin Traefik, HAProxy, AWS Load Balancer Controller ham ishlatiladi. Ingress Controller'ning annotation'lari advanced feature'lar beradi: rate limiting, authentication, SSL redirect, custom headers. cert-manager bilan birgalikda automatic SSL certificate provisioning qilinadi. Let's Encrypt yoki corporate CA integration mumkin. Network Policy Kubernetes'da micro-segmentation uchun ishlatiladi. Default holatda barcha pod'lar bir-biri bilan muloqot qila oladi, lekin Network Policy bilan traffic'ni restrict qilish mumkin. Bank application'larda, misol uchun, frontend pod'lar faqat API pod'lar bilan, API pod'lar esa faqat database pod'lar bilan gaplashishi mumkin. Network Policy implementation CNI plugin'ga bog'liq. Calico, Cilium, Weave Net support qiladi, lekin Flannel support qilmaydi. Policy enforcement iptables, eBPF yoki OVS orqali amalga oshiriladi performance va feature requirement'larga qarab. Service Mesh (Istio, Linkerd, Consul Connect) advanced networking beradi. Sidecar proxy pattern orqali automatic TLS, traffic management, observability, security policy enforce qilinadi. Application code o'zgartirishlarsiz sophisticated networking feature'lar qo'shiladi. DNS Kubernetes cluster'da automatic service discovery ta'minlaydi. CoreDNS cluster ichidagi DNS server bo'lib, Service name'larni IP address'larga resolve qiladi. `webapp.default.svc.cluster.local` formatidagi FQDN orqali Service'larga murojaat qilish mumkin. Bu microservice architecture uchun juda qulay — hard-coded IP address'lar o'rniga service name ishlatiladi. CoreDNS plugin'lari extended functionality beradi: external DNS integration, custom DNS record'lar, conditional forwarding. DNS-based service discovery'ning performance impact'i minimal, chunki DNS response'lar cache qilinadi. > [!WARNING] > Network troubleshooting uchun: > - `kubectl exec -it pod-name -- nslookup service-name` DNS resolution test qilish uchun > - `kubectl get endpoints service-name` Service backend pod'larni ko'rish uchun > - Network Policy test qilish uchun `netpol` tool ishlatilang > - Service mesh istiak-proxy sidecar log'larni check qiling | Service Type | Use Case | External Access | Load Balancing | Port Range | | ------------- | ---------- | ----------------- | ---------------- | ------------- | | ClusterIP | Internal services | No | Yes | Any | | NodePort | Development/Testing | Yes | Yes | 30000-32767 | | LoadBalancer | Production external access | Yes | Yes | Any | | ExternalName | External service proxy | No | No | N/A | ## ConfigMap, Secret va Volume Management: State va Configuration Strategiyalari Twelve-Factor App methodology'ga ko'ra, configuration va secret'lar application code'dan ajratilgan bo'lishi kerak. Kubernetes bu principle'ni ConfigMap va Secret orqali implement qiladi. ConfigMap plain text configuration data saqlash uchun, Secret esa sensitive data (password, certificate, API key) uchun ishlatiladi. ConfigMap creation'ning bir nechta pattern'i mavjud. Literal value'lar, file'dan, directory'dan yaratish mumkin. kubectl imperative command'lar ham, manifest-based declarative approach ham qo'llaniladi. Enterprise environment'larda GitOps approach preferred — barcha ConfigMap'lar Git repository'da version control ostida bo'ladi. ConfigMap'ni Pod'da consumption qilishning ikki xil yo'li bor: environment variable sifatida va volume mount sifatida. Environment variable approach simple configuration uchun, volume mount esa file-based configuration uchun yaxshi. Hot-reload capability faqat volume mount bilan possible. Configuration management'da layered approach ishlatiladi. Base configuration common value'lar uchun, environment-specific overlay'lar esa per-environment customization uchun. Kustomize yoki Helm template'lari bu pattern'ni support qiladi. Secret'lar base64 encoded holda saqlansa ham, bu encryption emas, balki encoding. etcd'da Secret'lar plain text saqlanadi, shuning uchun etcd encryption at-rest feature'ini enable qilish muhim. Real production'da Secret'lar uchun external secret management system ishlatiladi: AWS Secrets Manager, Azure Key Vault, HashiCorp Vault. External Secrets Operator (ESO) external secret store'lar bilan integration qiladi. Vault, AWS, Azure, GCP secret manager'lar bilan work qiladi. SecretStore va ClusterSecretStore CRD'lar orqali provider configuration qilinadi. Automatic secret rotation va synchronization support qilinadi. Secret type'lari turli xil data format'lar uchun optimized: Opaque (generic), TLS (certificate), Docker registry credential, Service Account token. Har bir type'ning o'z validation rule'lari va usage pattern'lari bor. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: app-config namespace: production labels: app: webapp config-version: v2.1 data: # Application configuration app.properties: | server.port=8080 server.servlet.context-path=/api management.endpoints.web.exposure.include=health,metrics,info # Database configuration database.conf: | host=postgres.database.svc.cluster.local port=5432 dbname=myapp connection_pool=10 connection_timeout=5000 idle_timeout=300000 # Redis configuration redis.conf: | host=redis.cache.svc.cluster.local port=6379 max_connections=50 timeout=3000 # Logging configuration logback.xml: | %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n

--- apiVersion: v1 kind: Secret metadata: name: app-secrets namespace: production labels: app: webapp secret-version: v2.1 type: Opaque data: # Base64 encoded values DB_PASSWORD: cG9zdGdyZXNfcGFzc3dvcmQ= # postgres_ ```