أصبحت 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؟
يوصف Knative بأنه "نظام قائم على Kubernetes لتقديم وإدارة أعباء العمل باستخدام الحوسبة الحديثة بدون خادم." بإعلان نفسها على أنها منصة كهذه ، تقوم Knative بنشاط بتوسيع نطاق الحاويات تلقائيًا بما يتناسب مع طلبات HTTP المتزامنة. يتم في النهاية توسيع نطاق الخدمات غير المستخدمة إلى الصفر ، مما يوفر تحجيمًا عند الطلب بأسلوب الحوسبة بدون خادم.
يتكون Knative من مجموعة من وحدات التحكم المثبتة في أي كتلة Kubernetes وتوفير الميزات التالية:
- تجميع التطبيقات ذات الحاوية من الكود المصدري (التي يوفرها مكون البناء ) ،
- توفير الوصول إلى حركة المرور الواردة إلى التطبيقات (التي يوفرها مكون التقديم ) ،
- التسليم والتوسيع التلقائي للتطبيقات حسب الطلب (التي يوفرها أيضًا مكون التقديم ) ،
- تحديد مصادر الأحداث التي تؤدي إلى إطلاق التطبيقات (المقدمة من مكون الأحداث).
يتمثل أحد المكونات الرئيسية في الخدمة ، والتي توفر التسليم والتحجيم التلقائي والتحكم في حركة المرور للتطبيقات المدارة. بعد تثبيت Knative ، لا يزال بإمكانك الوصول الكامل إلى واجهة برمجة تطبيقات Kubernetes ، والتي تتيح للمستخدمين إدارة التطبيقات بالطريقة المعتادة ، كما تعمل أيضًا على تصحيح خدمات Knative من خلال العمل مع نفس ميزات واجهة برمجة التطبيقات (API) التي تستخدمها هذه الخدمات (الوحدات النمطية والخدمات وما إلى ذلك).
بمساعدة الخدمة ، يتم أيضًا توجيه حركة المرور باللون الأزرق والأخضر تلقائيًا ، مما يوفر فصل حركة المرور بين الإصدارات الجديدة والقديمة من التطبيق عندما يقوم المستخدم بتسليم إصدار محدث من التطبيق.
Knative نفسه يعتمد على تثبيت وحدة تحكم دخول متوافق. في وقت كتابة هذا التقرير ، يتم دعم Gloo API Gateway و Istio Service Mesh . وسيقوم بتكوين الدخول المتاح لتوجيه حركة المرور إلى التطبيقات التي تعتمد على 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 - مقارنةً بنموذج Deployment + Service + Ingress المعتاد. سنعمل مع هذا المثال:
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" الخاصة بنا :
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 واجهة برمجة التطبيقات هذه كتكوين له لفضح الخصائص الموروثة في 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 ، 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 يشبه الصندوق باستخدام بوابة Gloo API عالية الأداء والكاملة المزايا. هذه المذكرة فقط لمست قليلا من عدد كبير من ميزات Knative المتاحة للتخصيص ، فضلا عن ميزات إضافية. بالمثل مع Gloo!
على الرغم من حقيقة أن Knative لا يزال مشروعًا شابًا ، فإن فريقه يصدر إصدارات جديدة كل ستة أسابيع ، وقد بدأ تنفيذ الوظائف المتقدمة ، على سبيل المثال ، نشر TLS التلقائي ، والتحجيم التلقائي للوحة التحكم. هناك احتمال كبير أنه نتيجة للتعاون بين العديد من الشركات السحابية ، فضلاً عن أساس العرض السحابي الجديد من Google ، قد تصبح Knative الخيار الرئيسي لتنظيم الحوسبة بدون خادم و PaaS في Kubernetes. اتبع الأخبار!
من ساوثبريدج
إن رأي القراء مهم بالنسبة لنا ، لذلك نطلب منك المشاركة في استطلاع صغير يتعلق بالمقالات المستقبلية حول Knative و Kubernetes والحوسبة بدون خادم: