digitalocean cloud controller manager
v0.1.56
digitalocean-cloud-controller-manager هو تطبيق Kubernetes Cloud Controller Manager لـ Digitalocean. اقرأ المزيد عن مديري وحدة التحكم السحابية هنا. يتيح لك تشغيل digitalocean-cloud-controller-manager الاستفادة من العديد من ميزات مزود السحابة التي تقدمها DigitaloCean على مجموعات Kubernetes الخاصة بك.
يتبع Manager Cloud Controller الإصدار الدلالي. على الرغم من أن الإصدار لا يزال أقل من V1 ، إلا أن المشروع يعتبر جاهزًا للإنتاج.
نظرًا لدورات إصدار Kubernetes السريعة ، ستدعم CCM (Cloud Controller Manager) فقط الإصدار المدعوم أيضًا على منتج Digitalocean Kubernetes. لن يتم دعم أي إصدارات أخرى رسميًا من قبلنا.
تعرف على المزيد حول تشغيل مدير وحدة تحكم Cloud Digitalocean هنا!
لاحظ أن هذا CCM مثبت افتراضيًا على Doks (Kubernetes Digitalocean) ، لا يتعين عليك القيام بذلك بنفسك.
فيما يلي بعض الأمثلة على كيفية الاستفادة من digitalocean-cloud-controller-manager :
عندما تقوم بإنشاء أجهزة التحميل من خلال CCM (عبر الخدمات المغطاة بـ LoadBalancer ) ، من المهم جدًا عدم تغيير تكوين DO-Balancer يدويًا. سيتم إعادة هذه التغييرات في النهاية بواسطة حلقة المصالحة المدمجة في CCM. يوجد استثناء واحد في اسم التحميل الذي يمكن تغييره (انظر أيضًا الوثائق المتعلقة بتعليقات معرف التحميل-معرف).
بخلاف ذلك ، فإن المكان الآمن الوحيد لجعل تغييرات تكوين التحميل من خلال كائن الخدمة.
لأسباب تقنية ، لا يمكن استخدام المنافذ 50053 و 50054 و 50055 كمنافذ إدخال للحمل (أي ، المنفذ الذي يستمع إليه الحمل على الطلبات). إن محاولة استخدام أحد المنافذ المتأثرة كمنفذ خدمة تتسبب في منفذ إدخال 422 هي استجابة خطأ HTTP غير صالحة لإرجاعها من قبل API DO (وظهرت كحدث Kubernetes).
الحل هو تغيير منفذ الخدمة إلى منطقة مختلفة وغير متطورة.
v1.17.x يستخدم هذا المشروع وحدات GO لإدارة التبعية ويعمل على توظيف Vendoring. يرجى التأكد من تشغيل make vendor بعد أي تعديلات التبعية.
بعد إجراء تغييرات الكود الخاص بك ، قم بتشغيل الاختبارات وشيكات CI:
make ci إذا كنت ترغب في تشغيل digitalocean-cloud-controller-manager محليًا ضد مجموعة معينة ، فاحرص على استعداد kubeConfig وابدأ الثنائي في الدليل الرئيسي الذي يستضيفه الحزمة مثل هذا:
cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
REGION=fra1 DO_ACCESS_TOKEN=your_access_token go run main.go
--kubeconfig < path to your kubeconfig file >
--leader-elect=false --v=5 --cloud-provider=digitalocean يأخذ متغير البيئة REGION منطقة رقمية صالحة. يمكن تعيينه للحفاظ على digitalocean-cloud-controller-manager من محاولة الوصول إلى خدمة بيانات التعريف الرقمية التي تتوفر فقط على القطرات. إذا تم تعيين متغير المنطقة ، فسيتم استخدام خدمة Do Mostions للتحقق من صحة المنطقة المحددة. يمكن أيضًا تعيينه لأغراض التنمية المحلية. بشكل عام ، لا ينبغي أن لا تهم المنطقة التي تختارها كثيرًا طالما اخترت واحدة.
قد تحتاج أيضًا إلى توفير رمز الوصول إلى DigitaloCan في متغير بيئة DO_ACCESS_TOKEN . لا يلزم أن يكون الرمز المميز صالحًا لبدء وحدة التحكم السحابية ، ولكن في هذه الحالة ، لن تتمكن من التحقق من التكامل مع API DigitalOcean.
يرجى ملاحظة أنه إذا كنت تستخدم مجموعة Kubernetes التي تم إنشاؤها على DigitalOcean ، فسيكون هناك مدير وحدة تحكم سحابة يعمل في المجموعة بالفعل ، لذلك سوف تتنافس مجموعة محلية على وصول API معها.
يمكن أن يكون لديك digitalocean-cloud-controller-manager إدارة جدار حماية رقمي من شأنه أن يعدل بشكل ديناميكي القواعد للوصول إلى NodePorts: بمجرد إنشاء خدمة من النوع NodePort ، ستقوم وحدة تحكم جدار الحماية بتحديث جدار الحماية للسماح للجمهور بالوصول إلى هذا العدوى. وبالمثل ، يتم سحب الوصول تلقائيًا إذا تم حذف الخدمة أو تغييرها إلى نوع مختلف.
مثال على الاحتجاج:
cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
DO_ACCESS_TOKEN= < your_access_token >
PUBLIC_ACCESS_FIREWALL_NAME=firewall_name
PUBLIC_ACCESS_FIREWALL_TAGS=worker-droplet
digitalocean-cloud-controller-manager
--kubeconfig < path to your kubeconfig file >
--leader-elect=false --v=5 --cloud-provider=digitalocean يحدد متغير البيئة PUBLIC_ACCESS_FIREWALL_NAME اسم جدار الحماية. يتم إنشاء جدار الحماية إذا لم يتم العثور على جدار الحماية بهذا الاسم.
يشير متغير البيئة PUBLIC_ACCESS_FIREWALL_TAGS إلى العلامات المرتبطة بالقطرات التي يجب أن يطبق عليها جدار الحماية. عادة ، هذه علامة متصلة بقطرات عقدة العمال. يتم تطبيق علامات متعددة بطريقة منطقية أو موضة.
في بعض الحالات ، قد لا تكون إدارة جدار الحماية لخدمة معينة مرغوبة. أحد الأمثلة على ذلك هو أنه من المفترض أن يكون الوصول إلى NodePort متاحًا على VPC فقط. في مثل هذه الحالات ، يمكن استخدام شرح الخدمة kubernetes.digitalocean.com/firewall-managed إذا تم تعيينه على "false" ، فلن يتم إنشاء قواعد واردة للخدمة ، مما يؤدي إلى تعطيل الوصول العام بشكل فعال إلى NodePort. (لاحظ أن علامات الاقتباس التي يجب تضمينها مع قيم التعليقات التوضيحية "المنطقية".) ينطبق السلوك الافتراضي إذا تم حذف التعليقات التوضيحية ، أو تم تعيينه على "true " ، أو يحتوي على قيمة غير صالحة.
لا تتم إدارة جدار الحماية إذا كانت متغيرات البيئة مفقودة أو تركت فارغة. بمجرد إنشاء جدار الحماية ، لا يُسمح بالوصول العام سوى إلى NodePorts. يجب على المستخدمين إنشاء جدران حماية إضافية لتوسيع نطاق الوصول.
إذا كنت مهتمًا بفضح مقاييس Prometheus ، فيمكنك تمرير نقطة نهاية المقاييس التي ستعرضها. سيبدو الأمر مشابهًا لهذا:
cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
DO_ACCESS_TOKEN=your_access_token
METRICS_ADDR= < host > : < port >
digitalocean-cloud-controller-manager
--kubeconfig < path to your kubeconfig file >
--leader-elect=false --v=5 --cloud-provider=digitalocean يأخذ متغير بيئة METRICS_ADDR نقطة نهاية صالحة ترغب في استخدامها لخدمة مقاييس Prometheus الخاصة بك. لتكون صالحة ، يجب أن يكون في النموذج <host>:<port> .
بعد أن تبدأ في إدارة digitalocean-cloud-controller-manager ، قم بتشغيل أمر Curl التالي لعرض إخراج مقاييس Prometheus:
curl < host > : < port > /metricsخادم القبول هو مكون اختياري يهدف إلى تقليل تغييرات التكوين السيئة للكائنات المدارة DO (LBS ، إلخ). إذا كنت تريد معرفة المزيد عنها ، فاقرأ المستندات.
هل استخدام API يخضع لبعض حدود المعدل. من أجل الحماية من نفاد الحصص من أجل الاستخدام العادي الثقيل أو الحالات المرضية (على سبيل المثال ، الأخطاء أو API سحق بسبب وحدة تحكم تداخل تابعة لجهة خارجية) ، يمكن تكوين حد معدل مخصص عبر متغير بيئة DO_API_RATE_LIMIT_QPS . إنه يقبل قيمة التعويم ، على سبيل المثال ، DO_API_RATE_LIMIT_QPS=3.5 لتقييد استخدام API إلى 3.5 استعلامات في الثانية.
إذا كنت ترغب في اختبار التغييرات الخاصة بك في بيئة حاوية ، فقم بإنشاء صورة جديدة مع الإصدار الذي تم تعيينه على dev :
VERSION=dev make publish سيؤدي ذلك إلى إنشاء صورة ثنائية مع إصدار dev و Docker الذي تم دفعه إلى digitalocean/digitalocean-cloud-controller-manager:dev .
go get -u ./...
go mod tidy
go mod vendor لإنشاء صورة Docker وإنشاء البيان ، انتقل إلى صفحة الإجراءات على Github وانقر فوق "تشغيل سير العمل". حدد github <tag> الذي تريد إنشاؤه ، والتأكد من أنه مسبوق مع v يتطلب تشغيل سير العمل أيضًا أن تقوم بإيقاف تشغيل "طلب سحب طلب" قبل دمج "إعداد" إعدادات قواعد حماية الفرع الرئيسية. لا تنسَ تشغيله مرة أخرى بمجرد الانتهاء من الإصدار!
سير العمل ما يلي:
make bump-version مع <tag><tag>.yamlreleases/ الدليل في الريبو<tag> المحدد عند تشغيل سير العملdigitalocean/digitalocean-cloud-controller-manager:<tag>digitalocean/digitalocean-cloud-controller-manager:<tag> to DockerHubملاحظة: تم إهمال سير العمل هذا ، يرجى تفضيل سير عمل GitHub Action الموضح أعلاه.
لإصدار إصدار جديد يدويًا ، أول إصدار للنسخة:
make NEW_VERSION=v1.0.0 bump-versionتأكد من أن كل شيء يبدو جيدًا. قم بإنشاء فرع جديد بجميع التغييرات:
git checkout -b release- < new version > origin/master
git commit -a -v
git push origin release- < new version >بعد دمجها لإتقان ، وضع علامة على الالتزام ودفعه:
git checkout master
git pull
git tag < new version >
git push origin < new version >أخيرًا ، قم بإنشاء إصدار GitHub من Master مع الإصدار الجديد ونشره:
make publish سيؤدي ذلك إلى تجميع ثنائي يحتوي على الإصدار الجديد المجمل في صورة Docker تم دفعها إلى digitalocean/digitalocean-cloud-controller-manager:<new version>
في Digitalocean نحن نقدر ونحب مجتمعنا! إذا كان لديك أي مشاكل أو ترغب في المساهمة ، فلا تتردد في فتح مشكلة/PR و CC أي من المشرفين أدناه.
