نشر موارد Kubernetes من نظام مجموعة المركز إلى مجموعات الأعضاء (معاينة)

توضح هذه المقالة مفهوم نشر موارد Kubernetes من مجموعات المركز إلى مجموعات الأعضاء باستخدام Azure Kubernetes Fleet Manager (Fleet).

غالبا ما يحتاج مسؤولو النظام الأساسي إلى نشر موارد Kubernetes في مجموعات متعددة لأسباب مختلفة، على سبيل المثال:

• إدارة التحكم في الوصول باستخدام الأدوار وروابط الأدوار عبر مجموعات متعددة.
• تشغيل تطبيقات البنية الأساسية، مثل Prometheus أو Flux، التي يجب أن تكون على جميع المجموعات.

غالبا ما يحتاج مطورو التطبيقات إلى نشر موارد Kubernetes في مجموعات متعددة لأسباب مختلفة، على سبيل المثال:

• نشر تطبيق خدمة فيديو في مجموعات متعددة في مناطق مختلفة للحصول على تجربة مشاهدة ذات زمن انتقال منخفض.
• نشر تطبيق عربة التسوق في منطقتين مقترنتين للعملاء للاستمرار في التسوق أثناء انقطاع منطقة واحدة.
• نشر تطبيق حساب دفعي في مجموعات مع تجمعات عقدة موضعية غير مكلفة متوفرة.

من الممل إنشاء موارد Kubernetes هذه وتحديثها وتتبعها عبر مجموعات متعددة يدويا. يوفر الأسطول نشر موارد Kubernetes لتمكين الإدارة على نطاق واسع لموارد Kubernetes. باستخدام Fleet، يمكنك إنشاء موارد Kubernetes في مجموعة المركز ونشرها إلى مجموعات الأعضاء المحددة عبر موارد Kubernetes المخصصة: MemberCluster و ClusterResourcePlacement. يدعم Fleet هذه الموارد المخصصة استنادا إلى حل متعدد المجموعات السحابي المصدر مفتوح المصدر. لمزيد من المعلومات، راجع وثائق الأسطول المصدر.

هام

تتوفر ميزات معاينة Azure Kubernetes Fleet Manager على أساس الخدمة الذاتية والاشتراك. يتم توفير المعاينات "كما هي" و"كما هي متوفرة"، ويتم استبعادها من اتفاقيات مستوى الخدمة والضمان المحدود. تتم تغطية معاينات Azure Kubernetes Fleet Manager جزئيا من خلال دعم العملاء على أساس أفضل جهد. على هذا النحو، هذه الميزات ليست مخصصة للاستخدام الإنتاجي.

سير عمل نشر الموارد

ما هو MemberCluster؟

بمجرد انضمام نظام مجموعة إلى أسطول، يتم إنشاء مورد مخصص مقابل MemberCluster على نظام مجموعة المركز. يمكنك استخدام هذا المورد المخصص لتحديد المجموعات المستهدفة في نشر الموارد.

يمكن استخدام التسميات التالية لتحديد نظام المجموعة الهدف في نشر الموارد وتتم إضافتها تلقائيا إلى كافة مجموعات الأعضاء:

• fleet.azure.com/location
• fleet.azure.com/resource-group
• fleet.azure.com/subscription-id

لمزيد من المعلومات، راجع مرجع واجهة برمجة تطبيقات MemberCluster.

ما هو ClusterResourcePlacement؟

ClusterResourcePlacement يتم استخدام كائن لإخبار جدول الأسطول بكيفية وضع مجموعة معينة من الكائنات ذات نطاق المجموعة من نظام مجموعة المركز في مجموعات الأعضاء. يتم تضمين الكائنات ذات نطاق مساحة الاسم مثل Deployments و StatefulSets و DaemonSets و Config الخرائط و Secrets و PersistentVolumeClaims عند تحديد مساحة الاسم التي تحتوي عليها.

باستخدام ClusterResourcePlacement، يمكنك:

• حدد موارد Kubernetes ذات نطاق المجموعة التي سيتم نشرها إلى مجموعات الأعضاء.
• حدد نهج الموضع لتحديد مجموعة فرعية أو جميع مجموعات الأعضاء يدويا أو تلقائيا كتجمعات مستهدفة.
• حدد استراتيجيات الإطلاق التدريجي لطرح أي تحديثات لموارد Kubernetes المحددة بأمان إلى مجموعات مستهدفة متعددة.
• عرض تقدم النشر نحو كل مجموعة مستهدفة.

ClusterResourcePlacement يدعم الكائن استخدام ConfigMap لمغلف الكائن للمساعدة في النشر إلى مجموعات الأعضاء دون أي آثار جانبية غير مقصودة. تتضمن أساليب التحديد ما يلي:

• المجموعة والإصدار والنوع: حدد جميع الموارد من النوع المحدد وضعها.
• المجموعة والإصدار والنوع والاسم: حدد موردا معينا واحدا من نوع معين وضعه.
• التجميع والإصدار والنوع والتسميات: حدد جميع الموارد من نوع معين التي تطابق التسميات المتوفرة وضعها.

لمزيد من المعلومات، راجع ClusterResourcePlacement مرجع واجهة برمجة التطبيقات.

عند إنشاء ClusterResourcePlacement، يمكن تحديد أنواع الترابط التالية:

• requiredDuringSchedulingIgnoredDuringExecution: نظرا لأن هذا الترابط من النوع المطلوب أثناء الجدولة، فإنه يقوم بتصفية المجموعات استنادا إلى خصائصها.
• preferredDuringSchedulingIgnoredDuringExecution: نظرا لأن هذا الترابط هو فقط من النوع المفضل، ولكنه غير مطلوب أثناء الجدولة، فإنه يوفر ترتيبا تفضيليا للمجموعات استنادا إلى الخصائص المحددة من قبلك مثل التكلفة أو توفر الموارد.

تتوفر أنواع موضع متعددة للتحكم في عدد المجموعات التي يحتاج مورد Kubernetes إلى نشرها:

• PickAll يضع الموارد في جميع مجموعات الأعضاء المتوفرة. هذا النهج مفيد لوضع أحمال عمل البنية الأساسية، مثل مراقبة نظام المجموعة أو الإبلاغ عن التطبيقات.
• PickFixed يضع الموارد في قائمة محددة من مجموعات الأعضاء حسب الاسم.
• PickN هو خيار الموضع الأكثر مرونة ويسمح باختيار المجموعات بناء على قيود انتشار التقارب أو الطوبولوجيا وهو مفيد عند نشر أحمال العمل عبر مجموعات مناسبة متعددة لضمان التوفر المطلوب.

PickAll نهج الموضع

يمكنك استخدام نهج PickAll وضع لنشر حمل عمل عبر جميع مجموعات الأعضاء في الأسطول (مطابقة مجموعة من المعايير اختياريا).

يوضح المثال التالي كيفية نشر test-deployment مساحة اسم وكافة كائناتها عبر جميع المجموعات المسماة ب environment: production:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-1
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

يأخذ test-deployment هذا النهج البسيط مساحة الاسم وجميع الموارد الموجودة داخلها ويوزعها على جميع مجموعات الأعضاء في الأسطول مع التسمية المحددة environment . إذا كانت جميع المجموعات مطلوبة، يمكنك إزالة affinity المصطلح بالكامل.

PickFixed نهج الموضع

إذا كنت ترغب في نشر حمل عمل في مجموعة معروفة من مجموعات الأعضاء، يمكنك استخدام نهج PickFixed وضع لتحديد المجموعات حسب الاسم.

يوضح المثال التالي كيفية نشر مساحة الاسم في test-deployment مجموعات cluster1 الأعضاء و cluster2:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-2
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

PickN نهج الموضع

نهج PickN الموضع هو الخيار الأكثر مرونة ويسمح بوضع الموارد في عدد قابل للتكوين من المجموعات استنادا إلى كل من الترابطات وقيود انتشار المخطط.

PickN مع أوجه الترابط

استخدام التقارب مع PickN وظائف نهج الموضع بشكل مشابه لاستخدام الترابط مع جدولة الجراب. يمكنك تعيين كل من التقارب المطلوب والمفضل. تمنع التقاربات المطلوبة إيداع المجموعات التي لا تتطابق معها مع تلك التقاربات المحددة، وتسمح التقاربات المفضلة بترتيب مجموعة المجموعات الصالحة عند اتخاذ قرار إيداع.

يوضح المثال التالي كيفية نشر حمل عمل في ثلاث مجموعات. المجموعات التي تحتوي على critical-allowed: "true" التسمية هي فقط أهداف موضع صالحة، ويتم إعطاء التفضيل للمجموعات ذات التسمية critical-level: 1:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

PickN مع قيود انتشار المخطط

يمكنك استخدام قيود انتشار المخطط لفرض تقسيم مواضع نظام المجموعة عبر حدود الطوبولوجيا لتلبية متطلبات التوفر، على سبيل المثال، تقسيم المواضع عبر المناطق أو حلقات التحديث. يمكنك أيضا تكوين قيود انتشار المخطط لمنع الجدولة إذا تعذر استيفاء القيد (whenUnsatisfiable: DoNotSchedule) أو جدولته بأفضل شكل ممكن (whenUnsatisfiable: ScheduleAnyway).

يوضح المثال التالي كيفية نشر مجموعة معينة من الموارد عبر مناطق متعددة ويحاول الجدولة عبر مجموعات الأعضاء مع أيام تحديث مختلفة:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

لمزيد من المعلومات، راجع طوبولوجيا نشر قيود المصدر وثائق الأسطول.

استراتيجية التحديث

يستخدم Fleet استراتيجية تحديث متجددة للتحكم في كيفية طرح التحديثات عبر مواضع نظام المجموعة المتعددة.

يوضح المثال التالي كيفية تكوين استراتيجية تحديث متجدد باستخدام الإعدادات الافتراضية:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

يقوم المجدول بطرح التحديثات لكل نظام مجموعة بشكل تسلسلي، مع الانتظار على الأقل unavailablePeriodSeconds بين المجموعات. تعتبر حالة الإطلاق الناجحة إذا تم تطبيق كافة الموارد بشكل صحيح على نظام المجموعة. لا يتتالى التحقق من حالة الإطلاق إلى الموارد التابعة، على سبيل المثال، لا يؤكد أن الحجيرات التي تم إنشاؤها بواسطة التوزيع تصبح جاهزة.

لمزيد من المعلومات، راجع وثائق أسطول استراتيجية الإطلاق الأولية.

حالة الموضع

يقوم برنامج جدولة الأسطول بتحديث التفاصيل والحالة الخاصة بقرارات الموضع على ClusterResourcePlacement العنصر. يمكنك عرض هذه المعلومات باستخدام kubectl describe crp <name> الأمر . يتضمن الإخراج المعلومات التالية:

• الشروط التي تنطبق حاليا على الموضع، والتي تشمل ما إذا كان الموضع قد اكتمل بنجاح.
• قسم حالة الموضع لكل مجموعة عضو، والذي يعرض حالة النشر إلى تلك المجموعة.

يوضح ClusterResourcePlacement المثال التالي الذي نشر test مساحة الاسم وConfigMap test-1 في نظامي مجموعة عضو باستخدام PickN. وقد اكتمل الإيداع بنجاح ووضعت الموارد في نظامي aks-member-1 المجموعات و aks-member-2 .

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
Kind:         ClusterResourcePlacement
Metadata:
  ...
Spec:
  Policy:
    Number Of Clusters:  2
    Placement Type:      PickN
  Resource Selectors:
    Group:
    Kind:                  Namespace
    Name:                  test
    Version:               v1
  Revision History Limit:  10
Status:
  Conditions:
    Last Transition Time:  2023-11-10T08:14:52Z
    Message:               found all the clusters needed as specified by the scheduling policy
    Observed Generation:   5
    Reason:                SchedulingPolicyFulfilled
    Status:                True
    Type:                  ClusterResourcePlacementScheduled
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               All 2 cluster(s) are synchronized to the latest resources on the hub cluster
    Observed Generation:   5
    Reason:                SynchronizeSucceeded
    Status:                True
    Type:                  ClusterResourcePlacementSynchronized
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               Successfully applied resources to 2 member clusters
    Observed Generation:   5
    Reason:                ApplySucceeded
    Status:                True
    Type:                  ClusterResourcePlacementApplied
  Placement Statuses:
    Cluster Name:  aks-member-1
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
    Cluster Name:            aks-member-2
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
  Selected Resources:
    Kind:       Namespace
    Name:       test
    Version:    v1
    Kind:       ConfigMap
    Name:       test-1
    Namespace:  test
    Version:    v1
Events:
  Type    Reason                     Age                    From                                   Message
  ----    ------                     ----                   ----                                   -------
  Normal  PlacementScheduleSuccess   12m (x5 over 3d22h)    cluster-resource-placement-controller  Successfully scheduled the placement
  Normal  PlacementSyncSuccess       3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Successfully synchronized the placement
  Normal  PlacementRolloutCompleted  3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Resources have been applied to the selected clusters

تغييرات الموضع

يحدد برنامج جدولة الأسطول الأولوية لاستقرار مواضع حمل العمل الحالية. يمكن أن يحد ترتيب الأولويات هذا من عدد التغييرات التي تتسبب في إزالة حمل العمل وإعادة جدولته. يمكن للسيناريوهات التالية تشغيل تغييرات الموضع:

• يمكن أن تؤدي تغييرات نهج الموضع في ClusterResourcePlacement الكائن إلى إزالة حمل العمل وإعادة جدولته.
  • تؤدي عمليات التوسيع (المتزايدة numberOfClusters دون أي تغييرات أخرى) إلى وضع أحمال العمل فقط على أنظمة المجموعات الجديدة ولا تؤثر على المواضع الموجودة.
• تغييرات نظام المجموعة، بما في ذلك:
  • قد تؤدي المجموعة الجديدة التي تصبح مؤهلة إلى تشغيل الموضع إذا كانت تفي بنهج الموضع، على سبيل المثال، النهج PickAll .
  • وستحاول المجموعة التي لديها موضع من الأسطول استبدال جميع أحمال العمل المتأثرة دون التأثير على مواضعها الأخرى.

يتم طرح تغييرات الموارد فقط (تحديث الموارد أو تحديث ResourceSelector في ClusterResourcePlacement العنصر) تدريجيا في المواضع الموجودة ولكن لا تؤدي إلى إعادة جدولة حمل العمل.

التفاوتات

ClusterResourcePlacement تدعم الكائنات مواصفات التفاوتات، والتي تنطبق على ClusterResourcePlacement العنصر. يتكون كل كائن تسامح من الحقول التالية:

• key: مفتاح التسامح.
• value: قيمة التسامح.
• effect: تأثير التسامح، مثل NoSchedule.
• operator: عامل تشغيل التسامح، مثل Exists أو Equal.

يتم استخدام كل تسامح للتسامح مع واحد أو أكثر من العيوب المحددة المطبقة ClusterResourcePlacementعلى . بمجرد التسامح مع جميع العيوب على MemberCluster ، يمكن للمجدول بعد ذلك نشر الموارد إلى نظام المجموعة. لا يمكنك تحديث التفاوتات أو إزالتها من كائن ClusterResourcePlacement بمجرد إنشائه.

لمزيد من المعلومات، راجع وثائق الأسطول المصدر.

الوصول إلى واجهة برمجة تطبيقات Kubernetes لمجموعة موارد Fleet

إذا قمت بإنشاء مورد Azure Kubernetes Fleet Manager مع تمكين نظام مجموعة المركز، يمكنك استخدامه للتحكم مركزيا في سيناريوهات مثل نشر كائن Kubernetes. للوصول إلى واجهة برمجة تطبيقات Kubernetes لمجموعة موارد Fleet، اتبع الخطوات الواردة في الوصول إلى واجهة برمجة تطبيقات Kubernetes لمجموعة موارد الأسطول باستخدام Azure Kubernetes Fleet Manager.

الخطوات التالية

إعداد نشر موارد Kubernetes من نظام مجموعة المركز إلى مجموعات الأعضاء.