🕗 🛂 ⛹🏿 تزايد شعبية Kubernetes 🤚🏾 👐 🚵🏼

مرحبا هبر!

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

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

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

نشأت الحاويات كإنشاء خاص لعزل العملية في Linux ؛ كانت الحاويات عبارة عن مجموعات cgroups منذ عام 2007 ومساحات الأسماء منذ 2002. أخذت الحاويات شكلها بشكل أفضل بحلول عام 2008 ، عندما أصبح LXC متاحًا ، وطورت Google آليتها الداخلية الخاصة بها والتي تسمى Borg.حيث "يتم تنفيذ كل العمل في حاويات." من هنا ، تقدم سريعًا إلى عام 2013 ، عندما تم إطلاق أول إصدار لـ Docker ، وانتقلت الحاويات أخيرًا إلى فئة الحلول الجماعية الشائعة. في ذلك الوقت ، كانت Mesos هي الأداة الرئيسية لتنظيم الحاويات ، على الرغم من أنها لم تكن شائعة جدًا. تم إطلاق الإصدار الأول من 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 أو SREs التعبير عن أعباء العمل بشكل كامل دون الحاجة إلى كتابة تعليمات برمجية بلغات مثل Python أو Javascript.

المزايا الأخرى لتنظيم البنية التحتية كبيانات ، على وجه الخصوص ، هي كما يلي:

GitOps Git Operations Version. YAML- Kubernetes git, , , , . , , , , . , Kubernetes – pull-.
. YAML, Kubernetes, . Kubernetes , , , , . , , - , maxReplicas 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. , , , , - , . conftest, YAML/JSON, Open Policy Agent, , , SecurityContext . , rego, :

package main

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

. – . cloud-provider Kubernetes , . , Kubernetes AWS , LoadBalancer, Amazon Elastic Load Balancer, .

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.

مشروع آخر ، KUDO ، يسمح لك بإنشاء بيانات باستخدام ملفات 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 بواسطة Cloud Native Computing Foundation .

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

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

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

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

مستقبل

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

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

تزايد شعبية Kubernetes

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

ابتكار

تواصل اجتماعي

مستقبل

More articles: