باكر ، Terraform و Ansible: نشر مجموعة Kubernetes في غضون ساعة



مرحبًا ، اسمي أندري شوكين ، أساعد الشركات الكبيرة في ترحيل الخدمات والأنظمة إلى CROC Cloud. بالتعاون مع زملاء من Southbridge ، الذي يدير دورات Kubernetes في مركز تدريب Slerm ، أجرينا مؤخرًا ندوة عبر الإنترنت لعملائنا.

قررت أخذ مواد من محاضرة ممتازة قدمها Pavel Selivanov وكتابة منشور لأولئك الذين بدأوا للتو في العمل مع أدوات التزويد السحابية ولا يعرفون من أين يبدأون. لذلك ، سأتحدث عن مجموعة التقنيات المستخدمة في تدريبنا وإنتاج CROC Cloud. دعونا نتحدث عن الأساليب الحديثة لإدارة البنية التحتية ، عن مجموعة من مكونات باكر ، Terraform و Ansible ، بالإضافة إلى أداة Kubeadm التي سنقوم بتثبيتها.

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

لا تعطِ أسماء الدجاج ،
فالكعك المخبوز أكثر صحة من المقلية ،
فنحن نبدأ الفرن. Packer
Terraform - البنية التحتية كرمز
إطلاق
بنية الكتلة Terraform Cluster Kubernetes
Kubeadm
Repository مع جميع الملفات

لا تعط أسماء للدجاج




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

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

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

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

في السابق ، كان لدينا عدد قليل من الخوادم التي تتم مراقبتها وضبطها يدويًا والعناية بها بكل طريقة ممكنة. في المراقبة ، تومض السجلات من خوادم Cthulhu و Aylith و Dagon. التقاليد.

ثم دخلت المحاكاة الافتراضية حياتنا بقوة ، وأعطت أسماء أعمال Lovecraft و Star Trek الطريق إلى "vlg-vlt-vault01.company.ru" الأكثر فائدة. هناك الكثير من الخوادم ، لكننا ما زلنا نرفع الخدمات يدويًا بشكل أو بآخر ، مما يزيل المشاكل على كل جهاز إذا لزم الأمر.

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

الكيك المخبوز أكثر صحة من المقلية




في إدارة البنية التحتية ، هناك تباين بين النهجين فريد مقابل. مخبوز ، أي "مقلي على خبز".

يشير منهج Fried إلى أن لديك صورة لنظام تشغيل الفانيليا ، على سبيل المثال ، CentOS 7. ثم ، بعد نشر نظام التشغيل ، نستخدم نظام إدارة التكوين لإحضار النظام إلى الحالة المستهدفة. على سبيل المثال ، استخدام Ansible أو Chef أو Puppet أو SaltStack.

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

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

نبدأ الفرن. باكر



في بنيتنا التحتية ، نستخدم العديد من منتجات Hashicorp ، والتي تبين أن بعضها ناجح للغاية. لنبدأ سحرنا بإعداد صورة وخبزها باستخدام أداة Packer.

يستخدم Packer نموذج JSON ، أي ملفات النماذج التي تحتوي على وصف لما يجب الحصول عليه كآلة افتراضية "مخبوزة" (VM). بعد إنشاء القالب ، يتم نقل الملف إلى Packer ، ويتم تكوين الأذونات اللازمة لإنشاء الخادم في السحابة.

يتيح لك Packer رفع VMs محليًا في KVM و VirtualBox و Vagrant و AWS و GCP و Alibaba Cloud و OpenStack وما إلى ذلك. وهو ملائم للعمل مع Packer في CROC Cloud ، نظرًا لأنه يطبق واجهات AWS ، أي جميع الأدوات التي تمت كتابتها من أجل العمل مع سحابة CROC.

بعد تعيين القوالب اللازمة ، يرفع Packer VM CROC في السحابة ، وينتظر أن يبدأ ، ثم يدخل "الموفر" إلى مزود العمل: أداة مساعدة يجب أن تكمل إعداد الصورة. في حالتنا ، هذا Ansible ، على الرغم من أن باكر يمكن أن يعمل مع خيارات أخرى.

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

هيكل Base.json


يوجد في بداية الملف قسم يتم فيه الإعلان عن المتغيرات:

المفسد
"variables" : {
 "source_ami_name": "{{env SOURCE_AMI_NAME}}",
 "ami_name": "{{env AMI_NAME}}",
 "instance_type": "{{env INSTANCE_TYPE}}",
 "kubernetes_version": "{{env KUBERNETES_VERSION}}",
 "docker_version": "{{env DOCKER_VERSION}}",
 "subnet_id": "",
 "availability_zone": "",
},


سيتم تعيين المجموعة الرئيسية من هذه المتغيرات من ملف settings.json. وتلك المتغيرات التي تتغير بشكل متكرر أكثر ملاءمة للتعيين من وحدة التحكم عند بدء Packer وبناء صورة جديدة.

فيما يلي قسم البنائين:

المفسد
"builders" : [
 {
  "type": "amazon-ebs",
  "region": "croc",
  "skip_region_validation": true,
  "custom_endpoint_ec2": "https://api.cloud.croc.ru",
  "source_ami": "",
  "source_ami_filter": {
   "filters": {
    "name": "{{user `source_ami_name`}}"
    "state": "available",
    "virtualization-type": "kvm-virtio"
     },
...


تم وصف السحب المستهدفة وأسلوب بدء تشغيل VM هنا. يرجى ملاحظة أنه في هذه الحالة يتم الإعلان عن نوع amazon-ebs ، ولكن لكي يعمل Packer مع CROC Cloud ، يتم تعيين العنوان المقابل في custom_endpoint_ec2. تحتوي بنيتنا التحتية على واجهة برمجة تطبيقات متوافقة تمامًا تقريبًا مع Amazon Web Services ، لذلك إذا كانت لديك تطورات جاهزة لهذا النظام الأساسي ، فعندئذٍ ستحتاج في الغالب فقط إلى تحديد نقطة إدخال مخصصة لواجهة برمجة التطبيقات - api.cloud.croc.ru في مثالنا.

تجدر الإشارة إلى قسم source_ami_filter بشكل منفصل. هنا يتم تعيين الصورة الأولية للجهاز الظاهري ، حيث سيتم إجراء التغييرات اللازمة. ومع ذلك ، يتطلب Packer وجود AMI لهذه الصورة ، أي معرفها العشوائي. نظرًا لأن هذا المعرف نادرًا ما يكون معروفًا مسبقًا ويتغير مع كل تحديث ، لم يتم تعيين مصدر AMI كقيمة محددة ، ولكن كمتغير source_ami_filter. في هذه الحالة ، المعلمة المحددة للمرشح هي اسم الصورة. يتم تعيين هذا الاسم في المتغيرات من خلال ملف settings.json.

بعد ذلك ، يتم تحديد إعدادات VM: يتم تحديد نوع المثيل والمعالج وحجم الذاكرة والمساحة المخصصة وما إلى ذلك:

المفسد
"instance_type": "{{user `instance_type`}}",
"launch_block_device_mappings": [
 {
  "device_name": "disk1",
  "volume_type": "io1",
  "volume_size": "8",
  "iops": "1000",
  "delete_on_termination": "true"
 }
],

فيما يلي في base.json هي معلمات الاتصال بجهاز VM هذا:

المفسد
"availability_zone": "{{user `availability_zone`}}",
"subnet_id": "{{user `subnet_id`}}",
"associate_public_ip_address": true,
"ssh_username": "ec2-user",
"ami_name": "{{user `ami_name`}}"


من المهم ملاحظة معلمة subnet_id هنا. يجب ضبطها يدويًا ، لأنه بدون تحديد الشبكة الفرعية VM في سحابة CROC ، من المستحيل إنشاءها.

معلمة أخرى تتطلب الإعداد المسبق هي Associate_public_ip_address. تحتاج إلى تحديد عنوان IP أبيض ، لأنه بعد إنشاء VM Packer سيبدأ في تطبيق الإعدادات الضرورية من خلال Ansible. في هذه الحالة ، يتصل Ansible بـ VM عبر SSH ، الأمر الذي يتطلب عنوان IP أبيض أو VPN.

القسم الأخير هو الموفرون:

المفسد
"provisioners": [
 {
  "type": "ansible",
  "playbook_file": "playbook.yml",
  "extra_arguments": [
   "--extra-vars",
   "kubernetes_version={{user `kubernetes_version`}}",
   "--extra-vars",
   "docker_version={{user `docker_version`}}"
   ]
  }
]


هؤلاء هم الموفرون ، أي الأدوات المساعدة التي يقوم بها باكر بتكوين الخادم. في هذه الحالة ، يتم استخدام مزود نوع غير مرئي. فيما يلي معلمة playbook_file ، التي تحدد الأدوار Ansible والمضيفين الذين سيتم تطبيق الأدوار المحددة عليهم. فيما يلي خيارات إضافية إضافية ، والتي ، عند بدء Ansible ، تنقل إصدارات Kubernetes و Docker.

إعداد سحابة CROC




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

  1. انقر فوق تمييز العنوان. سيجد Packer عنوان IP الأبيض المطلوب بمفرده.
  2. انقر فوق إنشاء شبكة فرعية وحدد شبكة فرعية وقناع.
  3. انسخ معرف الشبكة الفرعية.
  4. أدخل هذه القيمة في معلمة subnet_id لأمر بدء تشغيل Packer.



ثم قم بتشغيل Packer. يجد صورة VM الأصلية ، وينشرها في CROC Cloud ، ويقوم بدور Ansible عليها. يمكن رؤية الجهاز الظاهري الجديد في سحابة CROC في قسم "المثيلات".





بعد الانتهاء من العمل ، يقوم Packer بإزالة VM من السحابة ويترك صورة جاهزة في مكانها ، والتي يمكن العثور عليها في قسم "القوالب". سيتم إنشاء البنية التحتية Kubernetes بأكملها من هذه الصورة.

Ansible


كما ذكرنا سابقًا ، يتم تمرير معلمة playbook في معلمات موفر Ansible. يبدو ملف playbook.yml نفسه كما يلي:

- hosts: all
  become: true

  roles:
  | - base

ينقل الملف إلى Ansible أنه من الضروري على جميع المضيفين أداء دور القاعدة. إذا كانت هناك أدوار أخرى ، يمكنك إضافتها إلى نفس الملف كقائمة.

يسمح لك الدور الأساسي بالحصول على مجموعة جاهزة باستخدام أمر واحد. يوضح ملف main.yml ما يقوم به هذا الدور بالضبط:

  1. يضيف مستودع Docker إلى قالب النظام.
  2. يضيف مستودع Kubernetes إلى قالب النظام.
  3. تثبيت الحزم اللازمة.
  4. يقوم بإنشاء دليل لتكوين Docker daemon.
  5. لتكوين الجهاز وفقًا لملف التكوين daemon.json.j2.
  6. لتحميل نواة br_netfilter.
  7. يتضمن الخيارات الضرورية لـ br_netfilter.
  8. يتضمن مكونات Docker و Kubelet.
  9. يقوم بتشغيل Docker في VM.
  10. يقوم بتشغيل أمر يقوم بتنزيل صور Docker اللازمة لعمل Kubernetes.

في هذه الحالة ، يتم تعيين الحزم المثبتة في ملف main.yml من دليل vars. في حالتنا ، نقوم بتثبيت حزمة docker-ce ، بالإضافة إلى الحزم الثلاث اللازمة لعمل Kubernetes: kubelet و kubeadm و kubectl.

Terraform - البنية التحتية كرمز




Terraform هي أداة وظيفية للغاية من HashiCorp للتنسيق السحابي. لديها لغة HCL الخاصة بها ، والتي يتم استخدامها غالبًا في منتجات أخرى للشركة ، على سبيل المثال ، في HashiCorp Vault و Consul.

المبدأ الأساسي مشابه لجميع أنظمة إدارة التكوين. أنت تشير ببساطة إلى حالة الهدف بالتنسيق المطلوب ، ويحسب النظام خوارزمية كيفية تحقيق ذلك. شيء آخر هو أنه على عكس Ansible نفسه ، الذي يعمل كمربع أسود على كتب اللعب المعقدة ، يمكن لـ Terraform تقديم خطة من الإجراءات المستقبلية في شكل مناسب للتحليل. هذا مهم عند التخطيط لتغييرات البنية التحتية المعقدة. بعد تخطيط الإجراءات اللازمة ، قم بتشغيل الأمر " تطبيق terraform" وسيقوم Terraform بنشر البنية التحتية الموضحة في الملفات.

مثل Packer ، تدعم هذه الأداة AWS و GCP و Alibaba Cloud و Azure و OpenStack و VMware وما إلى ذلك.

نصف المشروع


يحتوي دليل Terraform على مجموعة من الملفات ذات الامتداد .tf. تصف هذه الملفات مكونات البنية التحتية التي سنعمل معها. قسّم المشروع إلى وحدات وظيفية. مثل هذا الهيكل يجعل من السهل التحكم في الإصدارات وتجميع كل مشروع من الكتل المريحة الجاهزة. بالنسبة لخيارنا ، فإن الهيكل التالي مناسب:

  1. main.tf
  2. network.tf
  3. security_groups.tf
  4. سيد
  5. سيد

هيكل ملف Main.tf


لنبدأ بالملف main.tf ، حيث يتم تكوين الوصول إلى السحابة. على وجه الخصوص ، تم الإعلان عن العديد من المعلمات التي تقوم بتكوين Terraform للعمل مع CROC Cloud:

provider "aws" {
 endpoints {
  ec2 = "https://api.cloud.croc.ru"
 }

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

resource "tls_private_key" "ssh" {
 algorithm = "RSA"
}
resource "aws_key_pair" "kube" {
 key_name = "terraform"
 public_key = "${tls_private_key.ssh.public_key_openssh}"
}
output "ssh" {
value = "${tls_private_key.ssh.private_key_pem}"
}

هيكل ملف network.tf


يصف هذا الملف مكونات الشبكة اللازمة لبدء تشغيل الجهاز الظاهري:

المفسد
data "aws_availability_zones" "az" {
 state = "available"
}
resource "aws_vpc" "kube" {
 cidr_block = "${var.vpc_cidr}"
}
resource "aws_eip" "master" {
 count = "1"
 vpc = true
}
resource "aws_subnet" "private" {
 vpc_id = "${aws_vpc.kube.id}"
 count = "${length(data.aws_availability_zones.az.names)}"
 cidr_block = "${var.private_subnet_cidr_list[count.index]}"
 availability_zone = "${data.aws_availability_zones.az.names[count.index]}"
}


يستخدم Terraform نوعين من المكونات:

  • الموارد - ما يلزم إنشاؤه ؛
  • البيانات - ما تحتاج إلى الحصول عليه.

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

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

علاوة على ذلك ، في كل من مناطق إمكانية الوصول ، وفي الوقت الحالي لدى CROC خدمتان سحابيتان ، يتم إنشاء شبكتها الفرعية الخاصة. تم التصريح عن مورد من نوع aws_subnet ، وتم تمرير معرف aws_vpc الذي تم إنشاؤه كجزء من هذه المعلمة. ولكن نظرًا لأن معرّف هذا المورد لا يزال غير معروف ، فإننا نحدد المعلمة aws_vpc.kube.id ، التي تشير إلى المورد الذي تم إنشاؤه وتحل محل القيمة من حقل المعرف.

نظرًا لأن عدد الشبكات الفرعية التي تم إنشاؤها يتم تحديدها من خلال عدد مناطق توافر السحابة ويمكن أن يتغير هذا الرقم بمرور الوقت ، يتم تعيين هذه المعلمة من خلال متغير الطول (data.aws_availability_zones.az.names) ، أي طول قائمة مناطق الوصول المستلمة من خلال معلمة البيانات.

المعلمتان الأخيرتان هما cidr_block (الشبكة الفرعية المخصصة) ومنطقة التوافر التي يتم إنشاء هذه الشبكة الفرعية فيها. يتم أيضًا تعيين المعلمة الأخيرة عبر متغير يأخذ قيمة من قائمة البيانات وفقًا لفهرس الحلقة المعلنة بواسطة [count.index] .

بنية ملف Security_groups.tf


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

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

تنشئ القاعدة الثانية مجموعة أمان ssh. يسمح باتصال SSH من أي عنوان IP إلى المنفذ 22 من مجموعة Kubernetes VM:

المفسد
resource "aws_security_group" "kube" {
 vpc_id = "${aws_vpc.kube.id}"
 name   = "kubernetes"
 # Allow all outbound
 egress {
  from_port = 0
  to_port = 0
  protocol = "-1"
  cidr_blocks = ["0.0.0.0/0"]
 }
 # Allow all internal
 ingress {
  from_port = 0
  to_port = 0
  protocol = "-1"
  cidr_blocks = ["${var.vpc_cidr}"]
 }
}
resource "aws_security_group" "ssh" {
 vpc_id = "${aws_vpc.kube.id}"
 name   = "ssh"

 # Allow all inbound
 ingress {
  from_port = 22
  to_port = 22
  protocol = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
 }
}


العقدة الرئيسية. هيكل ملف Master.tf


يصف ملف master.tf إنشاء العديد من القوالب والمثيلات. على وجه الخصوص ، يتم إنشاء نسخة رئيسية Kubernetes.

يقوم المتغير ami بتعيين AMI للصورة المصدر لـ VM. فيما يلي وصف لنوع VM والشبكة الفرعية التي يتم إنشاؤها فيها. عند تحديد شبكة فرعية ، يتم استخدام الدورة مرة أخرى لإنشاء VMs في كل منطقة توفر.

بعد ذلك ، يتم الإعلان عن مجموعات الأمان المستخدمة والمفتاح الذي تم تحديده في ملف main.tf. يحتوي حقل بيانات المستخدم على تنفيذ مجموعة من سكربت سحابة التهيئة ، والتي سيتم تنفيذ نتائجها في الجهاز الظاهري:

المفسد
resource "aws_instance" "master" {
 count = "1"
 ami = "${var.kubernetes_ami}"
 instance_type = "c3.large"
 disable_api_termination = false
 instance_initiated_shutdown_behavior = "terminate"
 source_dest_check = false
 subnet_id = "${aws_subnet.private.*.id[count.index % length(data.aws_availability_zones.az.names)]}"
 associate_public_ip_address = true
 vpc_security_group_ids = [
  "${aws_security_group.ssh.id}",
  "${aws_security_group.kube.id}",
 ]
 key_name = "${aws_key_pair.kube.key_name}"
 user_data = "${data.template_cloudinit_config.master.rendered}"
 monitoring = "true"
}


العقدة الرئيسية. الحرف السحابي


Cloud-init هي أداة تطورها Canonical. يسمح لك بتنفيذ مجموعة معينة من الأوامر تلقائيًا في البنية التحتية السحابية بعد بدء تشغيل VM. لدى Terraform آليات للتكامل معها باستخدام القوالب .

نظرًا لأنه من المستحيل "خبز" كل شيء ضروري في VM ، بعد البدء ، اعتمادًا على نوعه ، يجب إما الانضمام إلى مجموعة Kubernetes أو تهيئة مجموعة Kubernetes. في قالب ملف cloud-init يسمى master.tpl ، يتم تنفيذ العديد من الإجراءات.

1. يتم تسجيل ملفات التكوين ل Kubeadm:

#cloud-config

    write_files:
    - path: etc/kubernetes/kubeadm.conf
      owner: root:root
      content:
    ...


2. يتم تنفيذ مجموعة من الأوامر:

  • تتم كتابة عنوان IP للمعالج في ملف التكوين الذي تم إنشاؤه ؛
  • تتم تهيئة الرئيسي في مجموعة Kubernetes باستخدام الأمر kubeadm init ؛
  • في كتلة Kubernetes ، يتم تثبيت شبكة تراكب Calico باستخدام الأمر kubectl.

runcmd:
         - sed -i "s/CONTROL_PLANE_IP/$(curl http://169.254.169.254/latest/meta-data-local-ipv4)/g" /etc/kubernetes/kubeadm.conf
         - kubeadm init --config /etc/kubernetes/kubeadm.conf
         - mkdir -p $HOME/.kube
         - sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
         - sudo chown $(id -u):$(id -g) $HOME/.kube/config
         - kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml

بعد تنفيذ الأوامر عند بدء تشغيل VM ، يتم الحصول على كتلة Kubernetes عاملة من عقدة رئيسية واحدة. ستنضم العقد المتبقية إلى هذه العقدة الرئيسية.

العقد العادية. عقدة. tf


يشبه ملف node.tf ملف master.tf. يتم أيضًا إنشاء الموارد هنا ، والتي تسمى في هذه الحالة العقدة. والفرق الوحيد هو أن العقدة الرئيسية يتم إنشاؤها في مثيل واحد ، ويتم تعيين عدد عقد العمل التي تم إنشاؤها عبر متغير nodes_count:

resource "aws_instance" "node" {
 count = "${var.nodes_count}"
 ami = "${var.kubernetes_ami}"
 instance_type = "c3.large"

ينفذ ملف cloud-init للعقد العاملة أمرًا واحدًا فقط - انضمام kubeadm. يقوم هذا الأمر بإرفاق الجهاز النهائي بمجموعة Kubernetes باستخدام رمز التفويض الذي نرسله.

شغّل Terraform


عند إطلاقه ، يستخدم Terraform عدة وحدات:

  • وحدة AWS
  • وحدة قالب
  • وحدة TLS المسؤولة عن توليد المفتاح.

يجب تثبيت هذه الوحدات على الجهاز المحلي:

terraform init terraform/

مع هذا الأمر ، يشار إلى الدليل الذي توجد فيه جميع الملفات الضرورية. عند التهيئة ، يقوم Terraform بتنزيل جميع الوحدات المحددة ، وبعد ذلك تحتاج إلى تنفيذ أمر خطة terraform:

terraform plan -var-file terraform/vars/dev.tfvars terraform/

يرجى ملاحظة أنه بالإضافة إلى الدليل الذي يحتوي على ملفات Terraform ، يشار إلى ملف var ، والذي يحتوي على قيم المتغيرات المستخدمة في ملفات Terraform. يمكن أن يحتوي دليل vars على ملفات .tfvars متعددة ، مما يسمح لك بإدارة أنواع مختلفة من البنى التحتية من خلال مجموعة واحدة من ملفات Terraform.

يحتوي ملف dev.tfvars نفسه على المتغيرات الهامة التالية:

  • Kubernetes_version (نسخة قابلة للتثبيت من Kubernetes) ؛
  • Kubernetes_ami (صورة AMI التي أنشأها Packer).

بعد تعيين القيم الضرورية للمتغيرات ، قم بتشغيل أمر خطة terraform ، وبعد ذلك سيقدم Terraform قائمة بالإجراءات اللازمة لتحقيق الحالة الموضحة في ملفات Terraform.

بعد التحقق من هذه القائمة ، قم بتطبيق التغييرات المقترحة:

terraform apply -auto-approve -var-file terraform/vars/dev.tfvars terraform/

من أمر خطة terraform ، تتميز بوجود مفتاح - الموافقة التلقائية ، مما يلغي الحاجة إلى تأكيد التغييرات التي تم إجراؤها. يمكنك حذف هذا المفتاح ، ولكن بعد ذلك سيلزم تأكيد كل إجراء يدويًا.

هيكل مجموعة Kubernetes




تتكون مجموعة Kubernetes من عقدة رئيسية تؤدي وظائف إدارية وعقد عمل تعمل على تشغيل التطبيقات المثبتة في المجموعة.

يتم تثبيت أربعة مكونات على العقدة الرئيسية التي تضمن تشغيل هذا النظام:

  • ETCD ، أي قاعدة بيانات Kubernetes
  • API Server ، الذي نقوم من خلاله بتخزين المعلومات في Kubernetes والحصول على المعلومات منها ؛
  • مدير تحكم
  • المجدول

يتم تثبيت مكونين إضافيين على عقد العمل:

  • Kube-proxy (المسؤول عن إنشاء قواعد الشبكة في مجموعة Kubernetes) ؛
  • Kubelet (المسؤول عن إرسال الأمر إلى Docker daemon لتشغيل التطبيقات في مجموعة Kubernetes).

بين العقد ، يعمل البرنامج المساعد لشبكة كاليكو.

مخطط سير عمل الكتلة

, Kubernetes replicaset.

  1. API-, ETCD. .
  2. API- .
  3. Controller-manager API- , «», .
  4. Scheduler . ETCD API-.
  5. Kubelet API- Docker .
  6. Docker .
  7. Kubelet API- , .

, Kubernetes , . , , YAML-. , , API-. .

Kubeadm




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

يتيح لك:

  • قم بتثبيت وتكوين وتشغيل جميع مكونات الكتلة الرئيسية
  • إدارة الشهادات ، بما في ذلك تدويرها وكتابة شهادات جديدة ؛
  • إدارة إصدارات مكون الكتلة (الترقية والإرجاع).

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

مستودع بجميع الملفات


هنا نضع جميع الملفات والتكوينات في مكان واحد ، بحيث يكون أكثر ملاءمة لك. إذا لم يكن لديك سحابة خاصة في متناول يدك ، ولكنك تريد إجراء كل هذه الخطوات بنفسك واختبار النشر في الممارسة العملية ، فاكتب إلينا على cloud@croc.ru.

سنقدم لك نسخة تجريبية للاختبارات وتقديم المشورة بشأن جميع القضايا.

وقريبًا سيكون هناك Slurm جديد ، حيث يمكنك إنشاء مجموعتك الخاصة. خصم 10٪ على الرمز الترويجي CROC.

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

الزملاء ، Habraparser يكسر ترميز المدونة. يرجى أخذ المصدر من جيثب من الرابط أعلاه.

All Articles