نحوه اتصال خوشه های Kubernetes در مراکز داده مختلف

به سری شروع سریع Kubernetes خوش آمدید. این یک ستون منظم با جالب ترین سوالاتی است که به صورت آنلاین و در آموزش های خود دریافت می کنیم. پاسخ کارشناس کوبرنتیس

کارشناس امروز دانیل پولنچیک (دانیله پولنسیچ). دانیل به عنوان یک مربی و توسعه دهنده نرم افزار در Learnk8s.

اگر می خواهید در پست بعدی به سوال خود پاسخ دهید از طریق ایمیل با ما تماس بگیرید یا توییتر: @learnk8s.

پست های قبلی را از دست داده اید؟ در اینجا به دنبال آنها بگرد.

چگونه خوشه های Kubernetes را در مراکز داده مختلف متصل کنیم؟

خلاصه: Kubefed v2 به زودی عرضه می شود، و همچنین به شما توصیه می کنم در مورد آن بخوانید دریا نورد и پروژه چند خوشه ای زمانبندی.

اغلب، زیرساخت ها در مناطق مختلف، به ویژه در محیط های کنترل شده، تکثیر و توزیع می شوند.

اگر یک منطقه در دسترس نباشد، ترافیک به منطقه دیگر هدایت می شود تا از وقفه جلوگیری شود.

با Kubernetes، می توانید از یک استراتژی مشابه استفاده کنید و بارهای کاری را در مناطق مختلف توزیع کنید.

شما می توانید یک یا چند کلاستر در هر تیم، منطقه، محیط یا ترکیبی از اینها داشته باشید.

خوشه های شما را می توان در چندین ابر و در محل میزبانی کرد.

اما چگونه می توان زیرساخت را برای چنین گسترش جغرافیایی برنامه ریزی کرد؟
آیا نیاز به ایجاد یک خوشه بزرگ برای چندین محیط ابری از طریق یک شبکه دارید؟
یا خوشه های کوچک زیادی دارید و راهی برای کنترل و همگام سازی آنها پیدا می کنید؟

یک خوشه رهبری

ایجاد یک خوشه بر روی یک شبکه چندان آسان نیست.

تصور کنید تصادف کرده اید، اتصال بین بخش های خوشه ای از بین رفته است.

اگر یک سرور اصلی داشته باشید، نیمی از منابع قادر به دریافت دستورات جدید نخواهند بود زیرا قادر به تماس با استاد نیستند.

و در عین حال شما جدول های مسیریابی قدیمی دارید (kube-proxy نمی‌توان موارد جدید را دانلود کرد) و هیچ غلاف اضافی (kubelet نمی‌تواند برای به‌روزرسانی‌ها درخواست کند).

حتی بدتر از آن، اگر Kubernetes نتواند یک گره را ببیند، آن را به عنوان یتیم علامت گذاری می کند و غلاف های از دست رفته را در گره های موجود توزیع می کند.

در نتیجه، شما دو برابر بیشتر غلاف دارید.

اگر در هر منطقه یک سرور اصلی بسازید، با الگوریتم اجماع در پایگاه داده etcd مشکلاتی وجود خواهد داشت. (تقریبا ویرایش - در واقع پایگاه داده etcd نباید بر روی سرورهای اصلی قرار داشته باشد. می توان آن را روی یک گروه جداگانه از سرورها در همان منطقه اجرا کرد. با این حال، با دریافت همزمان نقطه شکست یک خوشه. اما به سرعت.)

etcd استفاده می کند الگوریتم raftبرای توافق بر روی یک مقدار قبل از نوشتن آن روی دیسک.
به این معنا که اکثر موارد باید قبل از اینکه حالت در etcd نوشته شود به اجماع برسند.

اگر تأخیر بین نمونه‌های etcd بالا برود، همانطور که در مورد سه نمونه etcd در مناطق مختلف اتفاق می‌افتد، زمان زیادی طول می‌کشد تا روی یک مقدار توافق شود و آن را روی دیسک بنویسید.
این موضوع در کنترلرهای Kubernetes نیز منعکس شده است.

مدیر کنترلر برای اطلاع از تغییر و نوشتن پاسخ در پایگاه داده به زمان بیشتری نیاز دارد.

و از آنجایی که کنترل کننده یک نیست، بلکه چندین است، یک واکنش زنجیره ای به دست می آید و کل خوشه بسیار آهسته شروع به کار می کند.

etcd آنقدر به تأخیر حساس است که اسناد رسمی استفاده از SSD را به جای هارد دیسک های معمولی توصیه می کند.

در حال حاضر هیچ نمونه خوبی از یک شبکه بزرگ برای یک خوشه وجود ندارد.

اساساً، جامعه توسعه‌دهنده و گروه SIG-cluster در تلاش هستند تا چگونگی هماهنگی خوشه‌ها را به همان روشی که Kubernetes کانتینرها را هماهنگ می‌کند، بیابند.

گزینه 1: خوشه های فدرال با kubefed

پاسخ رسمی از SIG-cluster - kubefed2، نسخه جدیدی از مشتری و اپراتور اصلی فدراسیون Kube.

برای اولین بار، سعی کردیم مجموعه ای از خوشه ها را به عنوان یک شی واحد با استفاده از ابزار federation kube مدیریت کنیم.

شروع خوب بود، اما در نهایت، فدراسیون کوبه محبوب نشد، زیرا از همه منابع پشتیبانی نمی کرد.

به عنوان مثال، از منابع و خدمات فدرال پشتیبانی می کند، اما نه از StatefulSets.
همچنین پیکربندی فدراسیون به صورت حاشیه نویسی تصویب شد و انعطاف پذیر نبود.

تصور کنید چگونه می توانید با استفاده از یک حاشیه نویسی، تقسیم کپی ها را برای هر خوشه در یک فدراسیون توصیف کنید.

معلوم شد که یک آشفتگی کامل است.

SIG-cluster پس از kubefed v1 کار بسیار خوبی انجام داد و تصمیم گرفت از زاویه ای متفاوت به مشکل نزدیک شود.

به جای حاشیه نویسی، آنها تصمیم گرفتند یک کنترلر را منتشر کنند که روی خوشه ها نصب شده است. می توان آن را با استفاده از تعاریف منابع سفارشی (تعریف منابع سفارشی، CRD) پیکربندی کرد.

برای هر منبعی که فدرال می شود، یک تعریف CRD سفارشی در سه بخش دارید:

• یک تعریف استاندارد از یک منبع، مانند استقرار؛
• بخش placement، جایی که شما نحوه توزیع منبع در فدراسیون را تعریف می کنید.
• بخش override، جایی که برای یک منبع خاص می توانید وزن و پارامترهای مربوط به قرارگیری را لغو کنید.

در اینجا نمونه ای از یک تحویل همراه با بخش های قرار دادن و نادیده گرفته شده است.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

همانطور که می بینید، عرضه به دو دسته تقسیم می شود: cluster1 и cluster2.

خوشه اول سه ماکت را ارائه می دهد و خوشه دوم دارای ارزش 5 است.

اگر به کنترل بیشتری بر روی تعداد کپی ها نیاز دارید، kubefed2 یک شی ReplicaSchedulingPreference جدید را ارائه می دهد که در آن replica ها می توانند وزن شوند:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

ساختار CRD و API هنوز کاملا آماده نیستند و کار فعال در مخزن رسمی پروژه در حال انجام است.

مراقب kubefed2 باشید، اما به خاطر داشته باشید که هنوز به اندازه کافی برای یک محیط تولید خوب نیست.

درباره kubefed2 بیشتر بیاموزید مقاله رسمی در مورد kubefed2 در وبلاگ Kubernetes و مخزن رسمی پروژه kubefed.

گزینه 2: خوشه بندی سبک Booking.com

توسعه دهندگان Booking.com با kubefed v2 سروکار نداشتند، اما Shipper را ارائه کردند، اپراتور برای تحویل در چندین کلاستر، چندین منطقه و چندین ابر.

دریا نورد تا حدودی شبیه به kubefed2 است.

هر دو ابزار به شما این امکان را می دهند که استراتژی استقرار چند خوشه ای خود را سفارشی کنید (از کدام خوشه ها استفاده می شود و چه تعداد کپی دارند).

اما وظیفه ارسال کننده کاهش خطر خطاهای تحویل است.

در Shipper، می‌توانید یک سری مراحل را تعریف کنید که تقسیم‌بندی کپی‌ها بین استقرار قبلی و فعلی و میزان ترافیک ورودی را توضیح می‌دهد.

هنگامی که یک منبع را به یک خوشه فشار می دهید، کنترل کننده Shipper به طور تدریجی آن تغییر را در همه خوشه های فدرال مستقر می کند.

همچنین ارسال کننده بسیار محدود است.

برای مثال، نمودارهای Helm را به عنوان ورودی می گیرد و از منابع وانیل پشتیبانی نمی کند.
به طور کلی، Shipper به شرح زیر عمل می کند.

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

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Shipper گزینه خوبی برای مدیریت چندین خوشه است، اما رابطه نزدیک آن با Helm تنها مانع ایجاد می شود.

چه می شود اگر همه ما از Helm به سفارشی کردن یا کاپیتان?

در مورد شیپر و فلسفه او بیشتر بدانید این بیانیه رسمی مطبوعاتی.

اگر می خواهید کد را بررسی کنید، به مخزن رسمی پروژه بروید.

گزینه 3: ادغام خوشه "جادویی".

Kubefed v2 و Shipper با ارائه منابع جدید به کلاسترها از طریق تعریف منابع سفارشی، با فدراسیون کلاستر کار می کنند.

اما اگر نخواهید همه منابع، StatefulSets، DaemonSets و غیره را برای ادغام دوباره بنویسید، چه؟

چگونه یک خوشه موجود را بدون تغییر YAML در فدراسیون قرار دهیم؟

چند خوشه-زمانبندی پروژه Admirality است، که به زمان بندی بارهای کاری در خوشه ها می پردازد.

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

هر غلاف ایجاد شده بلافاصله با یک ساختگی جایگزین می شود.

استفاده از زمانبندی چند خوشه ای قلاب های وب برای تغییر دسترسیبرای قطع تماس و ایجاد یک غلاف ساختگی بیکار.

پاد اصلی چرخه زمانبندی دیگری را طی می کند که در آن پس از نظرسنجی از کل فدراسیون، تصمیم میزبانی گرفته می شود.

در نهایت، غلاف به خوشه هدف تحویل داده می شود.

در نتیجه، یک غلاف اضافی دارید که هیچ کاری انجام نمی دهد، فقط فضا را اشغال می کند.

مزیت این است که برای ترکیب منابع نیازی به نوشتن منابع جدید ندارید.

هر منبعی که یک pod ایجاد می کند به طور خودکار آماده فدرال شدن است.

این جالب است، زیرا شما به طور ناگهانی منابع در چندین منطقه توزیع شده است، و شما متوجه نشدید. با این حال، این بسیار خطرناک است، زیرا در اینجا همه چیز بر جادو استوار است.

اما در حالی که Shipper عمدتاً در تلاش است تا اثرات محموله‌ها را کاهش دهد، زمان‌بندی چند خوشه‌ای عمومی‌تر است و شاید برای کارهای دسته‌ای مناسب‌تر باشد.

مکانیسم تحویل تدریجی پیشرفته ندارد.

اطلاعات بیشتر در مورد زمان‌بندی چند خوشه‌ای را می‌توانید در اینجا بیابید صفحه مخزن رسمی.

اگر می‌خواهید درباره برنامه‌ریزی چند خوشه‌ای در عمل مطالعه کنید، Admiralty این مطلب را دارد مورد استفاده جالب با آرگو - گردش کار، رویدادها، CI و CD Kubernetes.

سایر ابزارها و راهکارها

اتصال و مدیریت چندین خوشه یک کار پیچیده است و هیچ راه حلی برای همه وجود ندارد.

اگر می خواهید در مورد این موضوع بیشتر بدانید، در اینجا چند منبع آورده شده است:

• Submariner توسط Rancher ابزاری است که شبکه های همپوشانی خوشه های مختلف Kubernetes را به هم متصل می کند.
• زنجیره خرده فروشی Target استفاده می کند Unimatrix با Spinnaker ترکیب شد تا استقرار را در چندین خوشه هماهنگ کند.
• سعی کنید از IPV6 و شبکه واحد در چندین منطقه.
• برای مثال می توانید از مش سرویس استفاده کنید ایستیو برای اتصال چند خوشه.
• Cilium، یک پلاگین رابط شبکه کانتینری، ارائه می دهد عملکرد مش خوشه ای، که به شما امکان می دهد چندین خوشه را ترکیب کنید

برای امروز کافی است

ممنون که تا آخر خواندید!

اگر می‌دانید چگونه چندین خوشه را به طور مؤثرتری به هم متصل کنید، به ما بگو.

روش شما را به لینک ها اضافه می کنیم.

تشکر ویژه از کریس نسبیت اسمیت (کریس نسبیت اسمیت) و وینسنت دی اسمه (وینسنت دی اسمت) (به مهندس قابلیت اطمینان در swatmobile.io) برای خواندن مقاله و به اشتراک گذاشتن اطلاعات مفید در مورد نحوه عملکرد فدراسیون.

منبع: www.habr.com