Knative - النظام الأساسي كخدمة المستند إلى k8s مع دعم بدون خادم

Knative - النظام الأساسي كخدمة المستند إلى k8s مع دعم بدون خادم

أصبحت Kubernetes بلا شك المنصة المهيمنة لنشر الحاويات. فهو يوفر القدرة على التحكم في أي شيء تقريبًا باستخدام واجهات برمجة التطبيقات الخاصة به ووحدات التحكم المخصصة التي تعمل على توسيع واجهات برمجة التطبيقات الخاصة به بموارد مخصصة.

ومع ذلك، لا يزال يتعين على المستخدم اتخاذ قرارات تفصيلية حول كيفية نشر التطبيقات وتكوينها وإدارتها وتوسيع نطاقها. تظل مشكلات توسيع نطاق التطبيق والحماية وتدفق حركة المرور وفقًا لتقدير المستخدم. وهذا ما يميز Kubernetes عن المنصات التقليدية كخدمة (PaaS)، مثل Cloud Foundry وHeroku.

تحتوي الأنظمة الأساسية على واجهة مستخدم مبسطة وتستهدف مطوري التطبيقات الذين يشاركون غالبًا في إعداد التطبيقات الفردية. تتم إدارة التوجيه والنشر والمقاييس بشفافية للمستخدم من خلال نظام PaaS الأساسي.

تتم معالجة سير العمل من المصدر إلى السفينة بواسطة PaaS عن طريق إنشاء صورة حاوية مخصصة ونشرها وإعداد مسار جديد ونطاق DNS الفرعي لحركة المرور الواردة. يتم إطلاق كل هذا عند الطلب git push.

يوفر Kubernetes (عمدًا) فقط اللبنات الأساسية لمثل هذه المنصات، مما يترك للمجتمع الحرية في القيام بالعمل بنفسه. كيف قال كيلسي هايتاور:

Kubernetes عبارة عن منصة لبناء المنصات. أفضل وضع للبدء، وليس الانتهاء.

ونتيجة لذلك، نرى مجموعة من تصميمات Kubernetes، بالإضافة إلى شركات الاستضافة التي تحاول إنشاء PaaS لـ Kubernetes، مثل OpenShift وRancher. وسط سوق Kube-PaaS المتنامي، تدخل Knative، التي تأسست في يوليو 2018 بواسطة Google وPivotal، الحلبة.

كان Knative عبارة عن تعاون بين Google وPivotal، مع القليل من المساعدة من شركات أخرى مثل IBM وRedHat وSolo.im. إنه يقدم أشياء PaaS مماثلة لـ Kubernetes مع دعم من الدرجة الأولى للتطبيقات المستندة إلى الحوسبة بدون خادم. على عكس إصدارات Kubernetes، يتم تثبيت Knative كإضافة على أي مجموعة Kubernetes متوافقة ويتم تكوينه من خلال موارد المستخدم.

ما هو كناتيف؟

توصف Knative بأنها "منصة قائمة على Kubernetes لتقديم وإدارة أعباء العمل باستخدام الحوسبة الحديثة بدون خادم." Knative، أثناء إعداد فواتير نفسها على أنها منصة كهذه، تقوم تلقائيًا بقياس الحاويات بما يتناسب مع طلبات HTTP المتزامنة. يتم تقليص الخدمات غير المستخدمة في النهاية إلى الصفر، مما يوفر إمكانية التوسع حسب الطلب بدون خادم.

يتكون Knative من مجموعة من وحدات التحكم التي يتم تثبيتها في أي مجموعة Kubernetes وتوفر الإمكانيات التالية:

  • بناء تطبيقات محتواة من التعليمات البرمجية المصدر (التي يوفرها المكون البناء),
  • توفير الوصول إلى حركة المرور الواردة إلى التطبيقات (التي يوفرها المكون خدمة),
  • التسليم والقياس التلقائي للتطبيقات عند الطلب (يتم توفيره أيضًا بواسطة المكون خدمة),
  • تحديد مصادر الأحداث التي تؤدي إلى إطلاق التطبيق (المقدمة من المكون الفروسية).

أحد المكونات الرئيسية هو العرض، الذي يوفر التوفير والقياس التلقائي وإدارة حركة المرور للتطبيقات المُدارة. بعد تثبيت Knative، لا يزال لديك حق الوصول الكامل إلى واجهة برمجة تطبيقات Kubernetes، مما يسمح للمستخدمين بإدارة التطبيقات المعتاد يعمل أيضًا على تصحيح أخطاء خدمات Knative، والعمل مع نفس أساسيات واجهة برمجة التطبيقات (API) التي تستخدمها هذه الخدمات (الوحدات، والخدمات، وما إلى ذلك).

وبمساعدة العرض، يتم أيضًا توجيه حركة المرور باللونين الأزرق والأخضر تلقائيًا، مما يضمن فصل حركة المرور بين الإصدارات الجديدة والقديمة من التطبيق عندما يقوم المستخدم بتسليم إصدار محدث من التطبيق.

يعتمد Knative نفسه على تثبيت وحدة تحكم دخول متوافقة. في وقت كتابة هذه المقالة مدعومة بوابة API جلو и شبكة خدمة إستيو. سيقوم بتكوين الدخول المتاح لتوجيه حركة المرور إلى التطبيقات التي يديرها Knative.

يمكن أن تكون Istio Service Mesh بمثابة تبعية كبيرة لمستخدمي Knative الذين يرغبون في تجربتها دون تثبيت لوحة تحكم Istio، نظرًا لأن Knative يعتمد فقط على البوابة.

لهذا السبب، يفضل معظم المستخدمين Gloo كبوابة لـ Knative، مما يوفر مجموعة مماثلة من الإمكانات لـ Istio (لغرض استخدام Knative فقط)، مع استخدام موارد أقل بكثير وتكاليف تشغيل أقل.

دعونا نختبر Knative أثناء العمل على المنصة. سأستخدم مجموعة مثبتة حديثًا تعمل في GKE:

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

لنبدأ في تثبيت Knative وGloo. يمكن القيام بذلك بأي ترتيب:

# ставим Knative-Serving
kubectl apply -f 
 https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f 
  https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...

نتحقق من أن جميع البودات في حالة "التشغيل":

kubectl get pod -n knative-serving
NAME                              READY   STATUS    RESTARTS   AGE
activator-5dd55958cc-fkp7r        1/1     Running   0          7m32s
autoscaler-fd66459b7-7d5s2        1/1     Running   0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Running   0          7m32s
controller-85c8bb7ffd-nj9cs       1/1     Running   0          7m29s
webhook-5bd79b5c8b-7czrm          1/1     Running   0          7m29s
kubectl get pod -n gloo-system
NAME                                      READY   STATUS    RESTARTS   AGE
discovery-69548c8475-fvh7q                1/1     Running   0          44s
gloo-5b6954d7c7-7rfk9                     1/1     Running   0          45s
ingress-6c46cdf6f6-jwj7m                  1/1     Running   0          44s
knative-external-proxy-7dd7665869-x9xkg   1/1     Running   0          44s
knative-internal-proxy-7775476875-9xvdg   1/1     Running   0          44s

Gloo جاهز للتوجيه، فلنقم بإنشاء خدمة Knative قابلة للتحجيم تلقائيًا (دعنا نسميها kservice) ونوجه حركة المرور إليها.

توفر خدمات Knative مسارًا أسهل لتقديم التطبيقات إلى Kubernetes مقارنةً بنموذج النشر + الخدمة + الدخول التقليدي. سنعمل بهذا المثال:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: gcr.io/knative-samples/helloworld-go
         env:
           - name: TARGET
             Value: Knative user

لقد قمت بنسخ هذا إلى ملف، ثم قمت بتطبيقه على مجموعة Kubernetes الخاصة بي بهذه الطريقة:

kubectl apply -f ksvc.yaml -n default

يمكننا عرض الموارد التي أنشأتها Knative في المجموعة بعد تسليم "helloworld-go" الخاص بنا kservice:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

يتم إطلاق الكبسولة التي تحتوي على صورة "helloworld-go" الخاصة بنا عند نشر الخدمة kservice. إذا لم تكن هناك حركة مرور، فسيتم تقليل عدد القرون إلى الصفر. والعكس صحيح، إذا تجاوز عدد الطلبات المتزامنة حدًا معينًا قابلاً للتكوين، فسيزداد عدد القرون.

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

يقوم Knative بتكوين دخوله باستخدام مورد "دخول" خاص في واجهة برمجة تطبيقات Knative الداخلية. يستخدم Gloo واجهة برمجة التطبيقات (API) هذه كتكوين خاص به لتوفير ميزات تشبه PaaS، بما في ذلك نموذج النشر باللون الأزرق والأخضر، وتطبيق TLS التلقائي، والمهلات، وميزات التوجيه المتقدمة الأخرى.

بعد مرور بعض الوقت، نرى أن البودات الخاصة بنا قد اختفت (بسبب عدم وجود حركة مرور واردة):

kubectl get pod -n default

No resources found.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

وأخيرا سنحاول الوصول إليهم. يمكنك بسهولة الحصول على عنوان URL لـ Knative Proxy باستخدام glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

بدون تثبيت glooctl يمكنك رؤية العنوان والمنفذ في خدمة kube:

kubectl get svc -n gloo-system knative-external-proxy
NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

لنقم بتشغيل بعض البيانات باستخدام cURL:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

يوفر Knative نظام PaaS تقريبًا للمطورين بالإضافة إلى Kubernetes الجاهزة باستخدام بوابة واجهة برمجة التطبيقات (API) عالية الأداء والمتكاملة من Gloo. لقد خدش هذا المنشور فقط سطح خيارات التخصيص الشاملة والميزات الإضافية لـ Knative. نفس الشيء مع جلو!

على الرغم من أن Knative لا يزال مشروعًا شابًا، إلا أن فريقه يصدر إصدارات جديدة كل ستة أسابيع، وقد بدأ تنفيذ الميزات المتقدمة، مثل النشر التلقائي لـ TLS، والقياس التلقائي للوحة التحكم. هناك احتمال كبير أنه، نتيجة للتعاون بين شركات سحابية متعددة، وكأساس لعرض Cloud Run الجديد من Google، يمكن أن يصبح Knative الخيار الأساسي للحوسبة بدون خادم وPaaS على Kubernetes. متابعة الأخبار!

من محرري ساوثبريدج
آراء القراء تهمنا، لذا نطلب منك المشاركة في استطلاع قصير يتعلق بالمقالات المستقبلية حول Knative وKubernetes والحوسبة بدون خادم:

يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. تسجيل الدخول، من فضلك.

هل تريد الاستمرار في كتابة المقالات والأدلة حول الحوسبة Knative والحوسبة بدون خادم؟

  • نعم من فضلك.

  • لا شكرا.

صوت 28 مستخدمًا. امتنع 4 مستخدما عن التصويت.

المصدر: www.habr.com

إضافة تعليق