Əsas fikir
İstifadəçi və workload identity-ni ayırın, Kubernetes RBAC-ı minimum səlahiyyətlə verin, namespace-ləri network policy ilə izolyasiya edin və AKS log kateqoriyalarını xərc və araşdırma ehtiyacına uyğun seçin.
Kubernetes klasteri control plane və node-lardan ibarətdir
Control plane API sorğularını qəbul edir, klaster vəziyyətini saxlayır və pod-ları node-lara planlaşdırır. Node-larda kubelet və container runtime workload-u işlədir; şəbəkə data plane-i xidmət trafikini yönləndirir. Declarative manifest istənilən vəziyyəti təsvir edir, controller-lər faktiki vəziyyəti ona yaxınlaşdırır. Bu avtomatlaşdırma self-healing və miqyaslandırmaya imkan verir, lakin açıq API, artıq hüquqlu service account, geniş network policy və köhnəlmiş image riskini aradan qaldırmır.
AKS platform əməliyyatını workload məsuliyyətindən ayırın
AKS Azure-da idarə olunan Kubernetes xidmətidir. Microsoft control plane komponentlərini idarə edir; node-lar, workload-lar, identity, şəbəkə, storage, məlumat və seçilmiş təhlükəsizlik/monitorinq sazlamaları üzrə məsuliyyət klaster rejimi və quruluşdan asılıdır. AKS Automatic daha çox əvvəlcədən qurulmuş əməliyyat və monitorinq seçimi verə bilər, AKS Standard isə operatora daha çox sazlama nəzarəti saxlayır. Bunları “provayder hər şeyi qoruyur” kimi qəbul etməyin: istifadə etdiyiniz mode, region, versiya və aktiv edilmiş funksiyalar üçün cari sənədi yoxlayın.
İstifadəçi və pod identikliyini ayrıca idarə edin
Kubernetes API üçün istifadəçi autentifikasiyasını cluster RBAC icazələri ilə bağlayın; insanlara daimi cluster-admin verməyin və rolları mütəmadi nəzərdən keçirin. AKS-də Microsoft Entra ID istifadəçi girişini mərkəzi identity siyasəti ilə birləşdirə bilər; Kubernetes RBAC və Azure RBAC for Kubernetes authorization fərqli icazə modelidir, klasterinizdə hansının işlədiyini dəqiqləşdirin. Pod-un Azure xidmətinə çıxışı üçün uzunömürlü tətbiq sirrini saxlamaq əvəzinə workload identity və federasiya edilmiş service account token istifadə edin; tokenləri də qoruyun; tətbiq sirrini image və manifestə yerləşdirməyin. Break-glass girişini məhdud və auditli saxlayın.
Network policy və probe-ları məqsədinə uyğun qurun
Default-deny ingress və egress qaydaları ilə namespace və workload əlaqələrini bağlayın, sonra tələb olunan xidmət axınlarını açın; istifadə etdiyiniz CNI network policy-ni dəstəklədiyini təsdiqləyin. API server-ə şəbəkə girişini etibarlı inzibati yollarla məhdudlaşdırın və kubelet-i ictimaiyyətə açmayın. Uğursuz liveness yoxlamaları konteynerin yenidən başlamasına səbəb ola bilər; readiness hazır olmayan pod-a yeni Kubernetes Service trafikini dayandırır, lakin bütün şəbəkə girişini bloklamır. Ağır dependency yoxlamasını liveness-ə bağlamaq bütün pod-ları eyni vaxtda restart edib nasazlığı böyüdə bilər. Yavaş başlayan tətbiq üçün startup probe-u, sağlam servis üçün readiness-i ayrıca təyin edin. Image scan, patch, non-root user, minimal capability və resurs limitlərini workload pipeline-ına daxil edin.
Startup
İlkin yüklənmə tamamlanana qədər liveness və readiness yoxlamalarını gözlədir.
Liveness
Bərpa olunmayan ilişmə olduqda container-in yenidən başladılmasını dəstəkləyir.
Readiness
Hazır olmayan pod-u yeni Kubernetes Service trafikinin hədəflərindən çıxarır.
Telemetriyanı aktiv edin və ingestion xərclərini idarə edin
Klaster sağlamlığını tək dashboard-la ölçməyin. Platform metric-ləri, workload log-ları, control-plane audit log-ları və tətbiq trace-ləri müxtəlif suallara cavab verir. AKS control-plane resource log-ları yaradıldıqda öz-özünə saxlanmır: diagnostic setting ilə Log Analytics və ya uyğun hədəfə yönləndirilməlidir. Container insights, Prometheus və Grafana imkanlarının aktivliyi AKS rejimindən və quruluşdan asılı ola bilər. Audit log-larında həssas əməliyyatları seçin, lazımsız kateqoriya və yüksək həcmli get/list hadisələrini xərc və məxfilik baxımından dəyərləndirin. Deploy, node restart, autoscaler və tətbiq xətalarını eyni vaxt xəttində əlaqələndirin.
Mesos-u müasir seçim kimi deyil, tarixən müqayisə edin
Kubernetes workload-ları deklarativ model, pod-lar, service discovery və controller-lər vasitəsilə idarə edir. Apache Mesos ümumi klaster resurs meneceri idi: scheduler framework-ləri master-dən CPU və yaddaş təklifləri alırdı, Marathon isə uzunömürlü xidmətləri idarə edirdi. Apache Mesos layihəsi artıq dayandırılıb. Mövcud Mesos mühitində versiyalar, təhlükəsizlik yeniləmələri, framework asılılıqları və miqrasiya planı üçün məsul təyin edin. Yeni platforma seçimində aktiv dəstəyi və komandanın əməliyyat tələblərini əsas götürün.
Mesos hazırda Kubernetes-ə bərabər alternativdirmi?
Xeyr. Apache layihəsi təqaüdə çıxarılıb; müqayisə yalnız arxitektura tarixini və mövcud köhnə mühiti anlamaq üçün faydalıdır.
AKS bütün cluster idarəsini öz üzərinə götürürmü?
Microsoft idarəetmə qatını idarə edir. Komanda tətbiqlərə, məlumatlara və giriş qaydalarına cavabdehdir; node əməliyyatları, şəbəkə və monitorinq üzrə vəzifələrin bölgüsünü seçilmiş AKS rejiminə görə yoxlayın.