حول الشعبية المتزايدة لـ Kubernetes

يا هبر!

وفي نهاية الصيف، نريد أن نذكركم بأننا نواصل العمل على هذا الموضوع Kubernetes وقررت نشر مقال من Stackoverflow يوضح الوضع في هذا المشروع في بداية شهر يونيو.

استمتع القراءة!

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

بدأت الحاويات كتصميم خاص لعزل العمليات في نظام Linux؛ تم تضمين الحاويات منذ عام 2007 مجموعات cgroupsومنذ عام 2002 – مساحات الأسماء. وقد تم تصميم الحاويات بشكل أفضل بحلول عام 2008، عندما أصبحت متاحة ال إكس سي، وقامت Google بتطوير آلية مؤسسية داخلية خاصة بها تسمى برجحيث "يتم تنفيذ كل العمل في حاويات." من هنا ننتقل سريعًا إلى عام 2013، عندما تم إطلاق الإصدار الأول من Docker، وأصبحت الحاويات أخيرًا حلاً جماعيًا شائعًا. في ذلك الوقت، كانت الأداة الرئيسية لتنسيق الحاويات هي الميزوسعلى الرغم من أنه لم يكن يحظى بشعبية كبيرة. تم إصدار Kubernetes لأول مرة في عام 2015، وبعد ذلك أصبحت هذه الأداة هي المعيار الفعلي في مجال تنسيق الحاويات.

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

البنية التحتية مثل YAML

في العالم الذي انتقل من Puppet and Chef إلى Kubernetes، كان أحد أكبر التغييرات هو الانتقال من "البنية التحتية كرمز" إلى "البنية التحتية كبيانات" - على وجه التحديد، مثل YAML. يمكن بسهولة وصف جميع الموارد في Kubernetes، والتي تتضمن البودات والتكوينات والمثيلات المنشورة والمجلدات وما إلى ذلك، في ملف YAML. على سبيل المثال:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

يُسهل هذا العرض على محترفي DevOps أو SRE التعبير بشكل كامل عن أعباء العمل الخاصة بهم دون الحاجة إلى كتابة التعليمات البرمجية بلغات مثل Python أو Javascript.

تشمل المزايا الأخرى لتنظيم البنية التحتية كبيانات ما يلي:

• التحكم في إصدار GitOps أو Git Operations. يتيح لك هذا الأسلوب الاحتفاظ بجميع ملفات Kubernetes YAML في مستودعات git، حتى تتمكن من تتبع وقت إجراء التغيير بالضبط، ومن قام به، وما الذي تغير بالضبط. وهذا يزيد من شفافية العمليات في جميع أنحاء المنظمة ويحسن الكفاءة التشغيلية من خلال القضاء على الغموض، خاصة في المكان الذي يجب أن يبحث فيه الموظفون عن الموارد التي يحتاجون إليها. وفي الوقت نفسه، يصبح من الأسهل إجراء تغييرات تلقائيًا على موارد Kubernetes بمجرد دمج طلب السحب.
• قابلية التوسع. عندما يتم تعريف الموارد على أنها YAML، يصبح من السهل للغاية على مشغلي المجموعة تغيير رقم أو رقمين في مورد Kubernetes، وبالتالي تغيير كيفية توسيع نطاقه. يوفر Kubernetes آلية للقياس التلقائي الأفقي للحاويات، والتي يمكن استخدامها لتحديد الحد الأدنى والحد الأقصى لعدد الحجيرات المطلوبة في تكوين نشر معين بشكل ملائم للتعامل مع مستويات حركة المرور المنخفضة والعالية. على سبيل المثال، إذا قمت بنشر تكوين يتطلب سعة إضافية بسبب الارتفاع المفاجئ في حركة المرور، فيمكن تغيير الحد الأقصى للنسخ المتماثلة من 10 إلى 20:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• الأمن والإدارة. يعد YAML أمرًا رائعًا لتقييم كيفية نشر الأشياء في Kubernetes. على سبيل المثال، يتعلق أحد المخاوف الأمنية الرئيسية بما إذا كانت أعباء العمل الخاصة بك تعمل كمستخدم غير إداري. في هذه الحالة، قد نحتاج إلى أدوات مثل مسابقة، مدقق YAML/JSON، بالإضافة إلى افتح وكيل السياسة، أداة التحقق من صحة السياسة لضمان السياق SecurityContext أعباء العمل الخاصة بك لا تسمح للحاوية بالعمل بامتيازات المسؤول. إذا كان ذلك مطلوبًا، فيمكن للمستخدمين تطبيق سياسة بسيطة ريغو، مثله:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• خيارات التكامل مع مزود السحابة. أحد أبرز الاتجاهات في التكنولوجيا المتقدمة اليوم هو تشغيل أعباء العمل على موفري الخدمات السحابية العامة. باستخدام المكون مزود السحابة يسمح Kubernetes لأي مجموعة بالتكامل مع موفر السحابة الذي تعمل عليه. على سبيل المثال، إذا قام مستخدم بتشغيل تطبيق في Kubernetes على AWS وأراد الكشف عن هذا التطبيق من خلال خدمة، فإن موفر السحابة يساعد في إنشاء الخدمة تلقائيًا LoadBalancerوالتي سوف توفر تلقائيا موازن التحميل موازن التحميل المرن من أمازونلإعادة توجيه حركة المرور إلى كبسولات التطبيق.

التوسعة

Kubernetes قابل للتوسعة للغاية ويحبه المطورون. هناك مجموعة من الموارد المتاحة مثل القرون، وعمليات النشر، StatefulSets، أسرار، ConfigMaps، إلخ. صحيح أنه يمكن للمستخدمين والمطورين إضافة موارد أخرى في النموذج تعريفات الموارد المخصصة.

على سبيل المثال، إذا أردنا تحديد مورد CronTab، فيمكنك أن تفعل شيئًا مثل هذا:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

يمكننا لاحقًا إنشاء مورد CronTab على النحو التالي:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

خيار آخر للتوسعة في Kubernetes هو أن المطور يمكنه كتابة بياناته الخاصة. عامل هي عملية خاصة في مجموعة Kubernetes تعمل وفقًا لـ "دائرة التحكم" بمساعدة المشغل، يمكن للمستخدم أتمتة إدارة CRDs (تعريفات الموارد المخصصة) من خلال تبادل المعلومات مع Kubernetes API.

هناك العديد من الأدوات في المجتمع التي تسهل على المطورين إنشاء مشغليهم الخاصين. فيما بينها - إطار المشغل و مشغل SDK. يوفر SDK هذا الأساس الذي يمكن للمطور من خلاله البدء بسرعة في إنشاء عامل التشغيل. لنفترض أنه يمكنك البدء من سطر الأوامر بشيء مثل هذا:

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

يؤدي هذا إلى إنشاء كافة التعليمات البرمجية المعيارية للمشغل الخاص بك، بما في ذلك ملفات YAML وكود Golang:

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

ثم يمكنك إضافة واجهات برمجة التطبيقات ووحدة التحكم المطلوبة، مثل هذا:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

ثم، أخيرًا، قم بتجميع العامل وإرساله إلى سجل الحاوية الخاصة بك:

$ operator-sdk build your.container.registry/youruser/myapp-operator

إذا كان المطور يريد مزيدًا من التحكم، فيمكن تغيير التعليمات البرمجية المعيارية في ملفات Go. على سبيل المثال، لتعديل تفاصيل وحدة التحكم، يمكنك إجراء تغييرات على الملف controller.go.

مشروع آخر كودو، يسمح لك بإنشاء بيانات باستخدام ملفات YAML التعريفية فقط. على سبيل المثال، سيتم تعريف عامل التشغيل لـ Apache Kafka بشكل تقريبي هكذا. باستخدامه، يمكنك تثبيت مجموعة كافكا أعلى Kubernetes باستخدام أمرين فقط:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

ثم قم بتكوينه باستخدام أمر آخر:

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

الابتكارات

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

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

مجتمع

الجانب الرئيسي الآخر لشعبية Kubernetes هو قوة مجتمعها. في عام 2015، عند الوصول إلى الإصدار 1.0، تمت رعاية Kubernetes بواسطة مؤسسة الحوسبة السحابية الأصلية.

هناك أيضًا مجتمعات مختلفة SIG (مجموعات الاهتمامات الخاصة) ركزت على العمل في مجالات مختلفة من Kubernetes مع تطور المشروع. تضيف هذه المجموعات باستمرار ميزات جديدة، مما يجعل العمل مع Kubernetes أكثر ملاءمة وملاءمة.

تستضيف مؤسسة Cloud Native Foundation أيضًا CloudNativeCon/KubeCon، والذي يعد، في وقت كتابة هذا التقرير، أكبر مؤتمر مفتوح المصدر في العالم. يُعقد عادةً ثلاث مرات سنويًا، ويجمع آلاف المحترفين الذين يرغبون في تحسين Kubernetes ونظامه البيئي، بالإضافة إلى تعلم الميزات الجديدة التي تظهر كل ثلاثة أشهر.

علاوة على ذلك، تمتلك مؤسسة Cloud Native Foundation لجنة الإشراف الفني، والتي تقوم، جنبًا إلى جنب مع SIGs، بمراجعة الجديد والحالي مشاريع تركز الأموال على النظام البيئي السحابي. تساعد معظم هذه المشاريع على تحسين نقاط قوة Kubernetes.

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

المستقبل

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

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

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