Kubernetes

01Ինչ խնդիրներ է լուծում Kubernetes-ը

Մեկ սերվերի վրա մի քանի կոնտեյների համար Docker Compose-ը բավական է։ Քսան մեքենայի վրա տասնյակ ծառայությունների դեպքում նոր հարցեր են առաջանում։ Որ մեքենան տեղ ունի այս կոնտեյների համար (scheduling)։ Ով կվերագործարկի այն, երբ crash լինի, կամ կտեղափոխի, երբ մեքենան մահանա (self-healing)։ Ինչպես ավելացնել պատճեններ, երբ տրաֆիկը մեծանում է (scaling)։ Ինչպես թողարկել նոր տարբերակ առանց downtime-ի և հետ գլորել, եթե այն ձախողվի (rolling update-ներ)։ Ինչպես են ծառայությունները գտնում իրար, երբ դրանց հասցեները անընդհատ փոխվում են (service discovery)։ Kubernetes-ը բոլորին պատասխանում է մեկ գաղափարով. դու հայտարարում ես ցանկալի վիճակը, օրինակ՝ web-ի 1.4.2 տարբերակի երեք replica, իսկ controller-ները անընդհատ համեմատում են իրական վիճակը դրա հետ և գործում՝ տարբերությունը վերացնելու համար։ Այս reconciliation loop-ը Kubernetes-ի սիրտն է։

• Control plane՝ API server, scheduler, controller-ներ, etcd (cluster-ի բազան)։
• Worker node-եր՝ kubelet-ը աշխատեցնում է pod-երը, container runtime-ը՝ կոնտեյներները։
• Ամեն ինչ API օբյեկտ է, որը ստեղծում, կարդում և թարմացնում ես kubectl-ով կամ GitOps գործիքներով։

02Pod-եր և Deployment-ներ

Pod-ը Kubernetes-ի աշխատեցրած ամենափոքր միավորն է՝ մեկ կամ ավելի կոնտեյներ, որոնք կիսում են մեկ ցանցային հասցե և կարող են կիսել volume-ներ։ Pod-երը մեկանգամյա են. փոխարինվելիս նոր անուններ ու IP-ներ են ստանում, ուստի դրանք գրեթե երբեք ուղղակիորեն չես ստեղծում։ Deployment-ը քո փոխարեն կառավարում է pod-երը. այն պահում է replica-ների պահանջված քանակը աշխատող վիճակում և rolling update է անում, երբ փոխում ես image-ը։ Երկու health check է կարևոր։ Readiness probe-ը Kubernetes-ին ասում է, թե երբ pod-ը կարող է տրաֆիկ ստանալ, liveness probe-ը՝ երբ pod-ը կախվել է և պետք է վերագործարկվի։ Resource request-ները scheduler-ին ասում են, թե որքան CPU և հիշողություն ամրագրել, limit-ները սահմանափակում են օգտագործումը։ Առանց request-ների scheduling-ն ու autoscaling-ը վատ որոշումներ են կայացնում։

1apiVersion: apps/v1
2kind: Deployment
3metadata: { name: web }
4spec:
5  replicas: 3
6  selector: { matchLabels: { app: web } }
7  template:
8    metadata: { labels: { app: web } }
9    spec:
10      containers:
11        - name: web
12          image: registry.example.com/web:1.4.2
13          ports: [{ containerPort: 3000 }]
14          readinessProbe: { httpGet: { path: /healthz, port: 3000 } }
15          resources:
16            requests: { cpu: 250m, memory: 256Mi }
17            limits: { memory: 512Mi }

03Service-ներ, կոնֆիգուրացիա և autoscaling

Service-ը կայուն անուն և վիրտուալ IP է տալիս pod-երի փոփոխվող բազմությանը, որոնք ընտրվում են label-ներով, և load balance է անում պատրաստ pod-երի միջև։ Մյուս pod-երը հասնում են դրան DNS-ով, օրինակ՝ http://web։ ClusterIP service-ները միայն ներքին են, LoadBalancer service-ները cloud-ից արտաքին load balancer են խնդրում։ Կոնֆիգուրացիան պահվում է image-ներից դուրս. ConfigMap-ը պահում է ոչ գաղտնի կարգավորումներ, Secret-ը՝ գաղտնաբառեր և key-եր։ Ուշադրություն. լռելյայն Secret-ները միայն base64-ով են կոդավորված, ուստի միացրու encryption at rest և սահմանափակիր, թե ով կարող է կարդալ դրանք, կամ համաժամեցրու դրանք արտաքին secret manager-ից։ HorizontalPodAutoscaler-ը (HPA) կարգավորում է replica-ների քանակը CPU-ի, հիշողության կամ custom մետրիկաների հիման վրա՝ քո սահմանած նվազագույնի ու առավելագույնի միջակայքում։

1apiVersion: v1
2kind: Service
3metadata: { name: web }
4spec:
5  selector: { app: web }
6  ports: [{ port: 80, targetPort: 3000 }]
7---
8apiVersion: autoscaling/v2
9kind: HorizontalPodAutoscaler
10metadata: { name: web }
11spec:
12  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: web }
13  minReplicas: 3
14  maxReplicas: 10
15  metrics:
16    - type: Resource
17      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

04Ինչպես է request-ը հասնում pod-ին

Հետևենք մեկ request-ի։ Բրաուզերը DNS-ով app.example.com-ը resolve է անում cloud load balancer-ի հասցեին։ Load balancer-ը փոխանցում է cluster-ի եզրային proxy-ին, որը կա՛մ Ingress controller է, կա՛մ, ավելի ու ավելի հաճախ, Gateway API-ի իրականացում։ Այդ proxy-ն կարդում է routing կանոնները (host և path) և request-ը ուղարկում համապատասխան Service-ին։ Service-ը, որը յուրաքանչյուր node-ի վրա իրականացվում է kube-proxy-ով կամ eBPF data plane-ով, օրինակ՝ Cilium-ով, իր endpoint-ներից ընտրում է մեկ պատրաստ pod և request-ը փոխանցում pod-ի IP-ին ու port-ին։ Այդ ցուցակում են միայն readiness probe-ն անցած pod-երը. հենց այդպես են rolling update-ները խուսափում դեռ գործարկվող կոնտեյներներին տրաֆիկ ուղարկելուց։ Նկատի ունեցիր, որ community-ի տարածված ingress-nginx controller-ը դադարեցվել է 2026-ի մարտին. նոր cluster-ները պետք է օգտագործեն Gateway API կամ սպասարկվող controller։

1apiVersion: gateway.networking.k8s.io/v1
2kind: HTTPRoute
3metadata: { name: web }
4spec:
5  parentRefs: [{ name: public-gateway }]
6  hostnames: ["app.example.com"]
7  rules:
8    - matches: [{ path: { type: PathPrefix, value: / } }]
9      backendRefs: [{ name: web, port: 80 }]

05Helm և managed Kubernetes

Իրական հավելվածներին պետք են բազմաթիվ YAML ֆայլեր, որոնք staging-ի ու production-ի միջև մի փոքր տարբերվում են։ Helm-ը դրանք փաթեթավորում է chart-ի մեջ՝ template-ներ գումարած values ֆայլ, որպեսզի ամբողջ հավելվածը տեղադրես կամ թարմացնես մեկ հրամանով և կարողանաս հետ գլորել նախորդ release-ին։ Երրորդ կողմի շատ գործիքներ (բազաներ, մոնիթորինգ, cert-manager) տարածվում են որպես Helm chart-եր։ Kustomize-ը առանց template-ների այլընտրանք է, որը ներկառուցված է kubectl-ում և օգտագործում է overlay-ներ ամեն միջավայրի համար։ Control plane-ը ինքդ աշխատեցնելը դժվար է, ուստի թիմերի մեծ մասն օգտագործում է managed Kubernetes՝ Amazon EKS, Google GKE, Azure AKS կամ DigitalOcean DOKS։ Մատակարարը աշխատեցնում և թարմացնում է control plane-ը, իսկ դու դեռ կառավարում ես node pool-երը, քո workload-ների թարմացումները, ցանցային add-on-ները, անվտանգության policy-ները և ծախսը։ Պատրաստ եղիր Kubernetes-ի տարբերակը պարբերաբար թարմացնելու, քանի որ upstream-ում յուրաքանչյուր minor release աջակցվում է մոտավորապես մեկ տարի։

1helm install web ./charts/web -f values.prod.yaml -n prod --create-namespace
2helm upgrade web ./charts/web -f values.prod.yaml -n prod --atomic --wait
3helm history web -n prod
4helm rollback web 3 -n prod
5kubectl rollout status deployment/web -n prod

06Երբ Kubernetes-ը չափազանց է, և ինչ օգտագործել փոխարենը

Kubernetes-ը շատ բան է բերում՝ ցանցային plugin-ներ, ingress կամ gateway-ներ, սերտիֆիկատներ, secret-ներ, RBAC, մոնիթորինգ, թարմացումներ և YAML ամեն ինչի համար։ Մի քանի ծրագրավորողից բաղկացած թիմի համար, որը մեկ արտադրանք է աշխատեցնում, այդ պլատֆորմային աշխատանքը կարող է ավելի թանկ նստել, քան արտադրանքի իրական ենթակառուցվածքը։ Եթե հավելվածդ տեղավորվում է մեկ կամ երկու սերվերի վրա, Docker Compose-ը լավ backup-ներով ու մոնիթորինգով ավելի պարզ է, էժան և հեշտ debug անելու համար։ Եթե ուզում ես կոնտեյներներ ավելի քիչ գործառնական աշխատանքով, managed կոնտեյներային ծառայությունները, ինչպիսիք են AWS ECS-ը Fargate-ով, Google Cloud Run-ը կամ Fly.io-ն, իրականացնում են scheduling և scaling՝ առանց cluster կառավարելու։ Kamal-ի նման գործիքները կոնտեյներներ են deploy անում սովորական սերվերների վրա՝ zero-downtime փոխարկումով։ Ընտրիր Kubernetes, երբ ունես բազմաթիվ ծառայություններ, իրական scaling-ի կարիքներ և մարդիկ, ովքեր կարող են տիրապետել պլատֆորմին։

• Մեկ կամ երկու սերվեր՝ Docker Compose։
• Կոնտեյներներ առանց cluster ops-ի՝ ECS/Fargate, Cloud Run, Fly.io։
• Պարզ multi-server deploy-ներ՝ Kamal, Docker Swarm, Nomad։

07Control plane-ի ներսում՝ API server, etcd և watch-եր

Kubernetes-ի յուրաքանչյուր բաղադրիչ խոսում է միայն API server-ի հետ. ոչ ոք ուղղակիորեն չի դիմում etcd-ին կամ միմյանց։ API server-ը նույնականացնում է հարցումը, ստուգում RBAC-ը, գործարկում admission controller-ները (mutating-ները կարող են ավելացնել լռելյայն արժեքներ կամ sidecar-ներ, validating-ները՝ մերժել policy-ն խախտող օբյեկտները) և օբյեկտը պահում etcd-ում՝ Raft պրոտոկոլով աշխատող consistent key-value պահոցում։ Գրելու համար etcd-ին անհրաժեշտ է անդամների մեծամասնությունը, այդ պատճառով cluster-ները պահում են երեք կամ հինգ անդամ. երեքը դիմանում են մեկ խափանման, հինգը՝ երկուսի։ Controller-ները polling չեն անում. նրանք բացում են երկարակյաց watch-եր, ստանում փոփոխությունների հոսք, պահում լոկալ քեշ և կատարում reconcile։ Scheduler-ը հետևում է առանց node-ի pod-երին, զտում է այն node-երը, որոնց վրա pod-ը չի տեղավորվում, գնահատում մնացածները և իր ընտրությունը գրում հետ։ Ընտրված node-ի kubelet-ը տեսնում է իրեն նշանակված pod-ը և container runtime-ի միջոցով մեկնարկում դրա կոնտեյներները։

• Admission՝ սկզբում mutating webhook-ներ, ապա validating webhook-ներ և policy-ներ։
• etcd quorum՝ 3 անդամը դիմանում է 1 խափանման, 5-ը՝ 2-ի։
• Backup արա etcd-ն կամ համոզվիր, որ դա անում է managed մատակարարը։

08Requests, limits, QoS դասեր և CPU throttling

Requests-ը այն է, ինչ ամրագրում է scheduler-ը, limits-ը՝ այն, ինչ պարտադրում է kernel-ը։ Միասին դրանք յուրաքանչյուր pod-ի համար որոշում են quality of service դասը։ Guaranteed՝ յուրաքանչյուր կոնտեյների CPU-ի և հիշողության requests-ը հավասար են limits-ին։ Burstable՝ սահմանված են որոշ requests կամ limits։ BestEffort՝ ոչինչ սահմանված չէ։ Երբ node-ի հիշողությունը պակասում է, kubelet-ը նախ դուրս է հանում BestEffort pod-երը, ապա իրենց requests-ը գերազանցած Burstable pod-երը։ Հիշողության limit-ի գերազանցումը քննարկման ենթակա չէ. կոնտեյները սպանվում է OOM-ով, ցույց է տալիս exit code 137 և OOMKilled պատճառը ու վերագործարկվում։ CPU limit-ի գերազանցումը փոխարենը բերում է throttling-ի kernel-ի CFS quota-ի միջոցով, և throttling-ը ծանրաբեռնված service-ին կարող է տալ latency-ի մեծ ցատկեր, նույնիսկ երբ node-ում ազատ CPU կա։ Ահա թե ինչու շատ թիմեր հիշողության limit-ը դնում են request-ին հավասար, CPU requests-ը ընտրում են զգուշորեն և latency-ի նկատմամբ զգայուն service-ների համար CPU limit չեն դնում, իսկ ընդհանուր ծավալը վերահսկում են namespace quota-ներով։

1resources:
2  requests: { cpu: 500m, memory: 512Mi }
3  limits:   { memory: 512Mi }       # no CPU limit: avoid throttling
4 
5# diagnose
6# kubectl describe pod web-7d9f -n prod | grep -A3 "Last State"
7# kubectl top pod -n prod --containers

09Graceful shutdown և կամավոր ընդհատումներ

Երբ pod-ը ջնջվում է՝ rollout-ի, replica-ների կրճատման կամ node drain-ի ժամանակ, միաժամանակ տեղի է ունենում երկու բան. kubelet-ը կոնտեյներներին ուղարկում է SIGTERM, իսկ endpoint controller-ը pod-ը հանում է Service-ի endpoint-ներից։ Proxy-ները և load balancer-ները այդ մասին իմանում են մի փոքր ուշ, ուստի մեկ-երկու վայրկյան տրաֆիկը դեռ կարող է հասնել արդեն անջատվող պրոցեսին։ Կարճ preStop sleep-ը հետաձգում է SIGTERM-ը, մինչև routing-ը «հասնի»։ Այնուհետև հավելվածը պետք է դադարի նոր աշխատանք ընդունել, ավարտի ընթացիկ հարցումները և դուրս գա terminationGracePeriodSeconds-ի ընթացքում (լռելյայն՝ 30), որից հետո այն սպանվում է։ Պլանավորված իրադարձությունների համար, օրինակ node-երի թարմացման, PodDisruptionBudget-ը Kubernetes-ին ասում է, թե քանի replica կարող է միաժամանակ անհասանելի լինել, և drain-երը դա հարգում են։ Topology spread constraint-ները replica-ները բաշխում են տարբեր node-երի և zone-երի վրա, որպեսզի մեկ խափանումը երբեք բոլորին չտանի։

1spec:
2  terminationGracePeriodSeconds: 45
3  topologySpreadConstraints:
4    - maxSkew: 1
5      topologyKey: topology.kubernetes.io/zone
6      whenUnsatisfiable: ScheduleAnyway
7      labelSelector: { matchLabels: { app: web } }
8  containers:
9    - name: web
10      lifecycle:
11        preStop: { exec: { command: ["sleep", "5"] } }
12---
13apiVersion: policy/v1
14kind: PodDisruptionBudget
15metadata: { name: web }
16spec: { minAvailable: 2, selector: { matchLabels: { app: web } } }

10Անվտանգության բազային մակարդակ՝ Pod Security, RBAC և NetworkPolicy

Լռելյայն Kubernetes cluster-ը թույլատու է. ցանկացած pod կարող է խոսել ցանկացած այլ pod-ի հետ, և pod-ը կարող է աշխատել root-ով՝ լայն արտոնություններով։ Երեք ներկառուցված մեխանիզմ սա խստացնում են։ Pod Security Admission-ը namespace-ի մակարդակով label-ների միջոցով կիրառում է Pod Security Standards-ը՝ privileged, baseline կամ restricted։ Restricted-ը պահանջում է non-root, արտոնությունների բարձրացման արգելք, հանված capability-ներ և seccomp profile, և դա լավ նպատակ է հավելվածների namespace-ների համար։ RBAC-ը պետք է հետևի նվազագույն արտոնությունների սկզբունքին. հնարավորության դեպքում namespace-ային Role-եր՝ ClusterRole-երի փոխարեն, ոչ մի wildcard verb, և անջատված service account token-ի ավտոմատ mount այն pod-երի համար, որոնք երբեք API չեն կանչում։ NetworkPolicy-ն firewall է pod-երի համար. յուրաքանչյուր namespace սկսիր default deny-ով, ապա թույլ տուր միայն անհրաժեշտ հոսքերը, օրինակ՝ ingress gateway-ից և egress դեպի բազա ու DNS։ NetworkPolicy-ները կիրառվում են միայն այն դեպքում, եթե CNI plugin-ը դրանք աջակցում է, ինչպես Calico-ն և Cilium-ը։

1apiVersion: v1
2kind: Namespace
3metadata:
4  name: prod
5  labels:
6    pod-security.kubernetes.io/enforce: restricted
7---
8apiVersion: networking.k8s.io/v1
9kind: NetworkPolicy
10metadata: { name: default-deny, namespace: prod }
11spec:
12  podSelector: {}
13  policyTypes: [Ingress, Egress]