مدیریت چندکلاستری در Kubernetes با ابزارهایی مانند Kubefed

با رشد زیرساخت‌های Cloud Native، ممکن است یک Kubernetes Cluster دیگر پاسخگوی تمام نیازهای یک سازمان نباشد. افزایش تعداد تیم‌ها و Applicationها، نیاز به جداسازی محیط‌ها، توزیع Workload در چند Data Center، الزامات Disaster Recovery یا نیاز به اجرای سرویس‌ها در چند Region می‌تواند سازمان را به سمت معماری Multi-Cluster Kubernetes هدایت کند.

در معماری Multi-Cluster، به‌جای اینکه تمام Workloadها روی یک Kubernetes Cluster اجرا شوند، چند Cluster مستقل ایجاد و در صورت نیاز به‌صورت متمرکز مدیریت می‌شوند.

یکی از پروژه‌هایی که برای مدیریت و Federation چند Kubernetes Cluster طراحی شده، KubeFed (Kubernetes Cluster Federation) است. با این حال، KubeFed تنها راهکار موجود نیست و امروزه روش‌هایی مانند GitOps و ابزارهایی مانند Argo CD نیز در بسیاری از معماری‌ها برای مدیریت چند Cluster مورد استفاده قرار می‌گیرند.

در این مقاله ابتدا مفهوم Multi-Cluster را بررسی می‌کنیم، سپس به معماری Federation، KubeFed، مزایا و محدودیت‌های آن و در نهایت رویکردهای مدرن‌تر برای مدیریت چند Kubernetes Cluster می‌پردازیم.

Multi-Cluster Kubernetes چیست؟

Multi-Cluster به معماری‌ای گفته می‌شود که در آن بیش از یک Kubernetes Cluster به‌صورت هم‌زمان مورد استفاده قرار می‌گیرد.

این Clusterها می‌توانند برای اهداف مختلفی ایجاد شوند. برای مثال:

• Production و Staging
• تیم‌های مختلف سازمان
• Data Centerهای مختلف
• Regionهای جغرافیایی مختلف
• Workloadهای حساس و غیرحساس
• Disaster Recovery
• تفکیک محیط‌های امنیتی

نکته مهم این است که Multi-Cluster الزاماً به معنی این نیست که همه Clusterها یک Application یکسان را اجرا می‌کنند. ممکن است هر Cluster کاملاً مستقل باشد و تنها از یک سیستم مدیریتی مشترک استفاده کند.

چرا به چند Kubernetes Cluster نیاز داریم؟

در پروژه‌های کوچک، یک Cluster معمولاً کافی است. اما با افزایش مقیاس، دلایل مختلفی می‌توانند استفاده از چند Cluster را توجیه کنند.

۱. جداسازی محیط‌ها

یکی از ساده‌ترین سناریوها، ایجاد Clusterهای جدا برای محیط‌های مختلف است.

Development Cluster
        │
        ├── Staging Cluster
        │
        └── Production Cluster

این مدل می‌تواند Blast Radius یک خطای عملیاتی را کاهش دهد؛ برای مثال یک مشکل در Cluster توسعه، مستقیماً Cluster Production را تحت تأثیر قرار نمی‌دهد.

۲. Multi-Data Center

ممکن است سازمان زیرساخت خود را در چند Data Center داشته باشد و بخواهد Workloadها را در بیش از یک مکان اجرا کند.

             Global Traffic
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     Kubernetes A        Kubernetes B
      Data Center 1       Data Center 2

این معماری می‌تواند برای افزایش Availability یا طراحی Disaster Recovery مورد استفاده قرار گیرد.

۳. Multi-Region

در محیط‌های بین‌المللی ممکن است Application در چند Region اجرا شود تا کاربران به نزدیک‌ترین محل سرویس متصل شوند یا Availability معماری افزایش پیدا کند.

۴. تفکیک Workloadها

گاهی اوقات بهتر است Workloadهای خاصی در Cluster جداگانه اجرا شوند. برای مثال:

• Workloadهای حساس
• پردازش‌های سنگین
• Machine Learning
• Workloadهای دارای الزامات امنیتی خاص
• محیط‌های Dedicated برای تیم‌های خاص

Multi-Cluster چه تفاوتی با Multi-Node دارد؟

این دو مفهوم نباید با یکدیگر اشتباه گرفته شوند.

در یک Cluster، چندین Worker Node می‌توانند وجود داشته باشند و Kubernetes Workloadها را میان آن‌ها توزیع کند.

در Multi-Cluster، چند Kubernetes Control Plane مستقل داریم.

آیا Multi-Cluster همان High Availability است؟

خیر.

داشتن چند Cluster به‌تنهایی به معنی High Availability نیست.

برای مثال اگر دو Cluster داشته باشیم اما هر دو در یک Data Center و روی یک زیرساخت مشترک اجرا شوند، یک Failure بزرگ ممکن است هر دو را از دسترس خارج کند.

برای طراحی HA باید وابستگی‌های زیر نیز بررسی شوند:

• Data Center
• Network
• Load Balancer
• DNS
• Storage
• Database
• External Dependencies

در نتیجه Multi-Cluster می‌تواند بخشی از معماری HA باشد، اما جایگزین طراحی کامل High Availability نیست.

Federation در Kubernetes چیست؟

Kubernetes Federation ایده‌ای است که هدف آن ایجاد یک لایه مدیریتی برای چند Kubernetes Cluster است.

در Federation می‌توان برخی Resourceها یا Policyها را از یک نقطه مرکزی تعریف و آن‌ها را در Clusterهای مختلف Propagate کرد.

به‌صورت مفهومی:

                 Federation Control Plane
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
          Cluster A    Cluster B    Cluster C

در این مدل، Federation تلاش می‌کند مدیریت برخی Resourceها را در چند Cluster ساده‌تر کند.

KubeFed چیست؟

KubeFed یا Kubernetes Cluster Federation یک پروژه Open Source برای Federation کردن چند Kubernetes Cluster است.

ایده اصلی KubeFed این است که بتوان Resourceهای مشخصی را در یک Federation Control Plane تعریف کرد و آن‌ها را براساس Policy به Clusterهای عضو منتشر کرد.

برای مثال ممکن است یک Application را به چند Cluster منتشر کنیم و مشخص کنیم که Workload در کدام Clusterها قرار بگیرد.

معماری KubeFed

در معماری KubeFed، یک Cluster به‌عنوان محل اجرای Federation Control Plane استفاده می‌شود و Clusterهای دیگر به‌عنوان Member Cluster در Federation قرار می‌گیرند.

                  Host / Federation Cluster
                           │
                    ┌──────┴──────┐
                    │   KubeFed   │
                    └──────┬──────┘
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
        Member A       Member B      Member C
       Kubernetes      Kubernetes    Kubernetes

Federation Layer مسئول هماهنگ‌سازی Resourceهای تعریف‌شده با Clusterهای عضو است.

Federated Resource چیست؟

در Federation، همه Kubernetes Resourceها لزوماً به یک شکل و با یک هدف مدیریت نمی‌شوند.

KubeFed امکان Federation کردن Resourceهای مشخصی را فراهم می‌کند و برای آن‌ها Template و Placement Policy تعریف می‌شود.

برای مثال می‌توان مشخص کرد یک Deployment در کدام Clusterها قرار گیرد.

به‌صورت مفهومی:

Application Template
        │
        ▼
Placement Policy
        │
   ┌────┼────┐
   ▼    ▼    ▼
  DC1  DC2  DC3

این مدل برای سناریوهایی که یک Application باید در چند Cluster مستقر شود، کاربرد دارد.

Cluster و Placement Policy

یکی از مسائل مهم در Multi-Cluster این است که مشخص کنیم هر Workload در کدام Cluster اجرا شود.

ممکن است Policy به شکل ساده‌ای باشد:

• Application A → Cluster 1 و 2
• Application B → فقط Cluster 2
• Application C → Cluster 3

یا بر اساس ویژگی‌های Clusterها تصمیم‌گیری شود.

این مفهوم در معماری‌های Multi-Region اهمیت بیشتری پیدا می‌کند؛ زیرا ممکن است هر Cluster ویژگی‌های متفاوتی از نظر منابع، Location یا نوع Workload داشته باشد.

مزایای KubeFed

مدیریت متمرکز

Federation می‌تواند برخی عملیات مربوط به چند Cluster را از یک نقطه مرکزی مدیریت کند.

توزیع Application

می‌توان Applicationهای مشخص را در چند Cluster مستقر کرد.

Policy-based Placement

می‌توان برای تعیین Cluster مقصد از Policy استفاده کرد.

مدیریت چند Cluster

برای سازمان‌هایی که تعداد زیادی Kubernetes Cluster دارند، داشتن یک لایه مدیریتی متمرکز می‌تواند فرآیند مدیریت را ساده‌تر کند.

چالش‌های KubeFed و Kubernetes Federation

Federation در کنار مزایا، Complexity قابل توجهی ایجاد می‌کند.

۱. افزایش Complexity

اکنون علاوه بر Kubernetes Clusterها، یک Federation Layer نیز باید مدیریت و Monitoring شود.

۲. Dependency روی Control Plane

در صورت طراحی نادرست، مشکلات Federation Control Plane می‌توانند روی فرآیندهای مدیریتی چند Cluster تأثیر بگذارند.

۳. تفاوت Clusterها

اگر Clusterها از نظر Version، CNI، Storage و قابلیت‌های نصب‌شده تفاوت زیادی داشته باشند، مدیریت متمرکز دشوارتر می‌شود.

۴. پیچیدگی Networking

ارتباط بین Workloadهای چند Cluster موضوع جداگانه‌ای است و Federation به‌تنهایی تمام مشکلات Multi-Cluster Networking را حل نمی‌کند.

۵. State Management

Federation نباید با Database Replication یا Synchronization داده‌های Application اشتباه گرفته شود.

Replication داده باید در لایه Database یا Storage و براساس نیاز Application طراحی شود.

KubeFed یا GitOps؟

یکی از سؤالات مهم در معماری‌های مدرن این است که آیا برای Multi-Cluster باید از Federation استفاده کنیم یا GitOps.

این دو رویکرد دقیقاً یک مسئله را حل نمی‌کنند.

در بسیاری از معماری‌های امروزی، GitOps با ابزارهایی مانند Argo CD یا Flux برای مدیریت چند Cluster انتخاب می‌شود؛ زیرا Configuration را در Git نگهداری می‌کند و فرآیند Deployment را قابل مشاهده و قابل Audit می‌سازد.

مدیریت Multi-Cluster با Argo CD

Argo CD یک ابزار GitOps برای Kubernetes است که می‌تواند چند Cluster را از یک Control Plane مدیریت کند.

مدل مفهومی آن به شکل زیر است:

                    Git Repository
                          │
                          ▼
                       Argo CD
                          │
            ┌─────────────┼─────────────┐
            ▼             ▼             ▼
        Cluster A     Cluster B     Cluster C

در این معماری، Configuration Applicationها در Git قرار دارد و Argo CD تلاش می‌کند وضعیت Clusterها را با وضعیت تعریف‌شده در Repository هماهنگ کند.

برای سازمان‌هایی که از GitOps استفاده می‌کنند، این مدل می‌تواند رویکرد مناسبی برای Multi-Cluster Deployment باشد.

برای آشنایی بیشتر با GitOps می‌توانید مقاله GitOps و ابزارهایی مانند ArgoCD برای مدیریت زیرساخت را مطالعه کنید.

KubeFed، Argo CD یا ابزار دیگر؟

انتخاب ابزار باید براساس مسئله واقعی معماری انجام شود.

در بسیاری از پروژه‌ها لازم نیست فقط یک ابزار انتخاب شود. ممکن است برای Lifecycle خود Clusterها از یک ابزار، برای Application Deployment از GitOps و برای Traffic Management از یک راهکار دیگر استفاده شود.

Multi-Cluster و GitOps؛ یک معماری عملی

برای بسیاری از سازمان‌ها، معماری زیر می‌تواند رویکرد قابل بررسی‌ای باشد:

                 Git Repository
                       │
                       ▼
                    Argo CD
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
   Kubernetes A   Kubernetes B   Kubernetes C
        │              │              │
        └──────────────┼──────────────┘
                       │
                 Observability
             Metrics / Logs / Traces

در این مدل، هر Cluster استقلال عملیاتی خود را حفظ می‌کند، اما Deploymentها از یک فرآیند استاندارد و قابل کنترل پیروی می‌کنند.

Multi-Cluster Networking

یکی از سخت‌ترین قسمت‌های معماری Multi-Cluster، Networking است.

اگر Applicationها در Clusterهای مختلف نیاز به ارتباط داشته باشند، باید موارد زیر مشخص شوند:

• Cluster-to-Cluster Connectivity
• Service Discovery
• DNS
• Routing
• Encryption
• Network Policy
• Load Balancing
• Failure Handling

راهکارهایی مانند Cilium، Istio و سایر ابزارهای Multi-Cluster Networking می‌توانند بسته به معماری مورد استفاده قرار گیرند.

اما نباید بدون نیاز واقعی، صرفاً به دلیل استفاده از Multi-Cluster، پیچیدگی شبکه را افزایش داد.

Multi-Cluster و Service Discovery

Service Discovery در یک Cluster نسبتاً ساده است، اما زمانی که Serviceها در چند Cluster قرار می‌گیرند، مسئله پیچیده‌تر می‌شود.

برای مثال:

api.production
        │
        ├── Cluster A
        │
        ├── Cluster B
        │
        └── Cluster C

باید مشخص باشد که Client چگونه Service مقصد را پیدا می‌کند و در صورت Failure یک Cluster چه اتفاقی برای Traffic می‌افتد.

این مسئله می‌تواند با ترکیبی از DNS، Global Load Balancer، Service Mesh یا سایر راهکارهای Traffic Management حل شود.

Multi-Cluster و Disaster Recovery

یکی از کاربردهای مهم چند Cluster، طراحی Disaster Recovery است.

برای مثال می‌توان یک Cluster اصلی و یک Cluster آماده برای Recovery داشت:

Primary Cluster
      │
      │ Replication / Backup
      ▼
DR Cluster

اما ایجاد Cluster دوم به‌تنهایی DR محسوب نمی‌شود.

باید مواردی مانند:

• Database Replication
• Object Storage
• Persistent Data
• Secrets
• Configuration
• DNS
• Traffic Switching
• Recovery Procedure

نیز طراحی شوند.

برای مطالعه بیشتر، مقاله Disaster Recovery چیست؟ را ببینید.

Multi-Cluster و Observability

هرچه تعداد Clusterها بیشتر شود، Monitoring و Observability اهمیت بیشتری پیدا می‌کند.

بهتر است بتوان وضعیت تمام Clusterها را از یک نقطه مشاهده کرد.

برای مثال Dashboard مرکزی می‌تواند اطلاعات زیر را نمایش دهد:

• Cluster Health
• Node Status
• CPU و Memory
• Pod Restarts
• Error Rate
• API Server Latency
• Application Availability
• Logs

استفاده از Prometheus، Grafana، Loki و OpenTelemetry می‌تواند بخشی از چنین معماری‌ای باشد.

در یک معماری Multi-Cluster، Observability باید خودش نیز تا حد امکان در برابر Failure یک Cluster مقاوم باشد.

برای طراحی چنین معماری‌هایی می‌توانید خدمات Monitoring آلتیمیت کلاد را بررسی کنید.

Security در معماری Multi-Cluster

تعداد بیشتر Clusterها به معنی افزایش سطح مدیریتی و در نتیجه افزایش نقاطی است که باید ایمن شوند.

برخی ملاحظات مهم عبارت‌اند از:

• RBAC مستقل و مناسب برای هر Cluster
• Least Privilege
• Secure Cluster-to-Cluster Communication
• Management Plane Security
• Secret Management
• Network Segmentation
• Audit Logging
• Certificate Management

به‌خصوص اگر یک Control Plane مرکزی بتواند روی چند Cluster تغییر ایجاد کند، حفاظت از Credentialها و دسترسی‌های آن اهمیت بسیار بالایی پیدا می‌کند.

هزینه و Complexity در Multi-Cluster

Multi-Cluster تقریباً همیشه هزینه عملیاتی بیشتری نسبت به یک Cluster دارد.

هر Cluster ممکن است نیازمند:

• Control Plane
• Worker Node
• Monitoring
• Logging
• Backup
• Security
• Upgrade
• Network Management

باشد.

بنابراین قبل از ایجاد Cluster جدید باید مشخص شود که چه مسئله‌ای با آن حل می‌شود.

اگر هدف فقط افزایش ظرفیت باشد، ممکن است اضافه کردن Node به Cluster فعلی راهکار ساده‌تری باشد.

Best Practiceهای معماری Multi-Cluster

۱. دلیل هر Cluster را مشخص کنید

هر Cluster باید یک هدف مشخص داشته باشد؛ مانند Isolation، Multi-DC، Security یا DR.

۲. Clusterها را استاندارد کنید

تا حد امکان Version، Networking، Security و ابزارهای پایه Clusterها باید استاندارد باشند.

۳. Deployment را Declarative کنید

استفاده از GitOps می‌تواند Configuration و Deployment را قابل تکرار و قابل Audit کند.

۴. Monitoring متمرکز داشته باشید

وضعیت Clusterها و Applicationها باید از یک سیستم Observability قابل مشاهده باشد.

۵. Secrets را متمرکز اما امن مدیریت کنید

Credentialهای Multi-Cluster نباید در Repositoryها یا فایل‌های Configuration به‌شکل ناامن نگهداری شوند.

۶. Failure Domainها را مشخص کنید

اگر هدف Multi-Cluster افزایش Resilience است، Clusterها باید تا حد امکان Failure Domainهای مستقلی داشته باشند.

۷. Recovery را آزمایش کنید

داشتن Cluster دوم بدون آزمایش فرآیند Failover و Recovery، تضمین‌کننده DR نیست.

۸. Complexity را کنترل کنید

هر ابزار جدید باید یک مشکل مشخص را حل کند. اضافه کردن Federation، Service Mesh و Multi-Cluster Networking بدون نیاز واقعی می‌تواند هزینه عملیاتی را افزایش دهد.

چک‌لیست طراحی Multi-Cluster

چه زمانی Multi-Cluster انتخاب مناسبی است؟

Multi-Cluster معمولاً زمانی ارزش بیشتری پیدا می‌کند که یکی از نیازهای زیر وجود داشته باشد:

• نیاز واقعی به چند Data Center
• نیاز به Multi-Region
• Isolation شدید بین Workloadها
• الزامات امنیتی یا سازمانی
• Disaster Recovery
• تعداد زیاد تیم‌ها و Workloadها
• نیاز به Failure Domainهای مستقل

اما اگر تنها هدف افزایش CPU و Memory باشد، ممکن است ابتدا بررسی Scaling همان Cluster گزینه منطقی‌تری باشد.

یک معماری پیشنهادی برای سازمان‌های Enterprise

برای یک سازمان بزرگ می‌توان معماری چندلایه‌ای زیر را در نظر گرفت:

                    Git Repository
                           │
                           ▼
                    GitOps Platform
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
        Cluster A     Cluster B     Cluster C
          DC 1          DC 2          DR
             │             │             │
             └─────────────┼─────────────┘
                           │
                    Global Traffic
                           │
                           ▼
                    End Users

در این مدل، GitOps مسئول Deployment است، هر Cluster استقلال خود را حفظ می‌کند و Traffic Management وظیفه هدایت کاربران را برعهده دارد.

در کنار این معماری، یک Observability Platform مرکزی نیز می‌تواند وضعیت Clusterها و Applicationها را جمع‌آوری کند.

آیا KubeFed هنوز باید استفاده شود؟

KubeFed از نظر مفهومی برای درک Kubernetes Federation و مدیریت Resourceها در چند Cluster بسیار مهم است. با این حال، قبل از انتخاب آن برای یک پروژه جدید باید وضعیت نگهداری پروژه، نیازهای فعلی معماری و گزینه‌های جایگزین بررسی شوند.

در بسیاری از معماری‌های جدید، به‌جای Federation مستقیم Resourceها، از ترکیب GitOps + Multi-Cluster Management استفاده می‌شود.

در چنین رویکردی، هر Cluster تا حد زیادی مستقل باقی می‌ماند و یک سیستم مرکزی صرفاً وضعیت مطلوب Applicationها را در Clusterهای مختلف اعمال می‌کند.

این جداسازی می‌تواند مدیریت Failure و Troubleshooting را ساده‌تر کند و در عین حال امکان مدیریت متمرکز Deployment را حفظ کند.

جمع‌بندی

Multi-Cluster Kubernetes یک الگوی معماری برای زمانی است که یک Kubernetes Cluster به‌تنهایی پاسخگوی نیازهای سازمان نیست یا لازم است Failure Domain، محیط، Region یا Workloadها از یکدیگر جدا شوند.

KubeFed یکی از پروژه‌های مهم در مسیر Kubernetes Federation است که مفهوم مدیریت و Propagation Resourceها میان چند Cluster را معرفی می‌کند. با این حال، Federation تنها رویکرد موجود نیست و در معماری‌های جدید، GitOps و ابزارهایی مانند Argo CD نیز نقش مهمی در مدیریت چند Cluster دارند.

مهم‌تر از انتخاب ابزار، این است که ابتدا مشخص کنیم چرا به Multi-Cluster نیاز داریم. سپس باید Networking، Security، Observability، Storage، Deployment، Backup و Disaster Recovery را به‌صورت End-to-End طراحی کنیم.

یک معماری Multi-Cluster خوب لزوماً معماری‌ای نیست که بیشترین تعداد ابزار را داشته باشد؛ بلکه معماری‌ای است که Isolation، Reliability، Scalability و Operational Simplicity را متناسب با نیاز واقعی سازمان فراهم کند.

سؤالات متداول

Multi-Cluster Kubernetes چیست؟

معماری Multi-Cluster یعنی استفاده هم‌زمان از چند Kubernetes Cluster مستقل برای اهدافی مانند Isolation، Multi-DC، Multi-Region، Disaster Recovery یا مدیریت Workloadهای مختلف.

KubeFed چیست؟

KubeFed یک پروژه Open Source برای Kubernetes Federation است که امکان مدیریت و انتشار برخی Resourceها در چند Kubernetes Cluster را فراهم می‌کند.

آیا KubeFed همان Multi-Cluster Management است؟

خیر. Multi-Cluster یک الگوی معماری است و KubeFed یکی از ابزارهایی است که برای Federation و مدیریت برخی جنبه‌های چند Cluster طراحی شده است.

آیا Multi-Cluster باعث High Availability می‌شود؟

خیر. Multi-Cluster می‌تواند بخشی از معماری HA باشد، اما برای رسیدن به High Availability باید Network، Storage، Database، Traffic Management و سایر Failure Domainها نیز طراحی شوند.

KubeFed بهتر است یا Argo CD؟

این دو ابزار برای دقیقاً یک مسئله طراحی نشده‌اند. KubeFed روی Federation تمرکز دارد، در حالی که Argo CD یک ابزار GitOps برای Deployment و Synchronization وضعیت Kubernetes است. انتخاب باید براساس معماری و نیاز پروژه انجام شود.

آیا برای داشتن Multi-Cluster حتماً به Federation نیاز داریم؟

خیر. می‌توان چند Cluster مستقل داشت و Deployment آن‌ها را با GitOps یا سایر ابزارهای مدیریت Multi-Cluster انجام داد.

آیا Multi-Cluster برای همه سازمان‌ها مناسب است؟

خیر. Multi-Cluster Complexity و هزینه عملیاتی بیشتری دارد و بهتر است زمانی استفاده شود که نیازهایی مانند Isolation، Multi-DC، Multi-Region یا Disaster Recovery آن را توجیه کنند.

آیا Multi-Cluster می‌تواند جایگزین Disaster Recovery شود؟

خیر. Cluster دوم تنها بخشی از معماری DR است. Data Replication، Backup، DNS، Traffic Switching و فرآیند Recovery نیز باید طراحی و آزمایش شوند.

آیا می‌توان چند Kubernetes Cluster را از یک Grafana مدیریت کرد؟

بله. می‌توان Telemetry چند Cluster را به یک Observability Platform مرکزی ارسال کرد و وضعیت آن‌ها را در Grafana مشاهده کرد.

طراحی و پیاده‌سازی معماری Multi-Cluster

مدیریت چند Kubernetes Cluster زمانی ارزشمند است که بر اساس یک معماری مشخص و نیاز واقعی کسب‌وکار انجام شود. انتخاب بین Federation، GitOps، Multi-Cluster Networking و سایر ابزارها باید پس از بررسی دقیق زیرساخت و Failure Domainهای سازمان انجام شود.

آلتیمیت کلاد می‌تواند در طراحی معماری Kubernetes، پیاده‌سازی Multi-Cluster، GitOps، Observability، High Availability و Disaster Recovery متناسب با نیاز زیرساخت سازمان کمک کند.

برای بررسی معماری فعلی و طراحی مسیر مناسب برای Multi-Cluster Kubernetes، با آلتیمیت کلاد در ارتباط باشید.