Get best of the week

Packer, Terraform dan Ansible: penyebaran cluster Kubernetes dalam satu jam



Hai, nama saya Andrey Schukin, saya membantu perusahaan besar memigrasi layanan dan sistem ke Cloud CROC. Bersama dengan rekan-rekan dari Southbridge, yang menjalankan kursus Kubernetes di pusat pelatihan Slerm, kami baru-baru ini mengadakan webinar untuk pelanggan kami.

Saya memutuskan untuk mengambil materi dari kuliah yang sangat baik oleh Pavel Selivanov dan menulis posting untuk mereka yang baru mulai bekerja dengan alat penyedia cloud dan tidak tahu harus mulai dari mana. Oleh karena itu, saya akan berbicara tentang tumpukan teknologi yang digunakan dalam pelatihan dan produksi CROC Cloud kami. Mari kita bicara tentang pendekatan modern untuk manajemen infrastruktur, tentang sekelompok Packer, komponen Terraform dan Ansible, serta tentang alat Kubeadm yang akan kita instal.

Di bawah potongan akan banyak teks dan konfigurasi. Ada banyak materi, jadi saya menambahkan navigasi posting. Kami juga menyiapkan repositori kecil di mana kami meletakkan semua yang kami butuhkan untuk penempatan pelatihan kami.

Jangan beri nama ayam.
Kue panggang lebih sehat daripada yang digoreng.
Kita mulai oven. Packer
Terraform - infrastruktur sebagai kode
Luncurkan
struktur Terraform Cluster Kubernetes
Kubeadm
Repository dengan semua file

Jangan memberi nama untuk ayam




Ada banyak konsep manajemen infrastruktur yang berbeda. Salah satunya disebut Hewan peliharaan vs. Sapi, yaitu, "hewan peliharaan melawan ternak." Konsep ini menggambarkan dua pendekatan yang bertentangan dengan infrastruktur.

Bayangkan kita punya anjing favorit. Kami merawatnya, membawanya ke dokter hewan, menyisir bulu, dan secara umum itu unik bagi kami di antara banyak anjing lain.

Dalam kasus lain, kami memiliki kandang ayam. Kami juga merawat ayam, memberi makan, memanaskan, dan mencoba menciptakan kondisi yang paling nyaman. Namun demikian, ayam adalah sumber daya yang agak tidak berwajah bagi kita, yang memenuhi fungsinya bertelur, dan paling baik kita menunjuk mereka sebagai "bubuk hitam yang selalu mematuk semen". Jika ayam berhenti bertelur atau mematahkan cakarnya, maka kemungkinan besar ia hanya akan memberi kita kaldu yang lezat untuk makan siang. Faktanya, kita tidak peduli dengan nasib seekor ayam, tetapi tentang kandang ayam secara keseluruhan sebagai jalur produksi.

Di IT, pendekatan yang serupa mulai diterapkan segera setelah alat muncul yang menurunkan ambang masuk untuk para insinyur dan memungkinkan untuk menyebarkan dan memelihara cluster kompleks dalam mode otomatis penuh.

Sebelumnya, kami memiliki sejumlah kecil server yang dipantau, disetel secara manual, dan dijaga dengan berbagai cara. Dalam pemantauan, log dari server Cthulhu, Aylith, dan Dagon menyala. Tradisi.

Kemudian virtualisasi dengan kuat memasuki kehidupan kita, dan nama-nama dari karya Lovecraft dan Star Trek memberi jalan kepada "vlg-vlt-vault01.company.ru" yang lebih utilitarian. Ada banyak server, tetapi kami masih meningkatkan layanan lebih atau kurang secara manual, menghilangkan masalah pada setiap mesin jika perlu.

Sekarang pendekatan untuk memelihara infrastruktur sepenuhnya bertepatan dengan pemrograman. Kami menambahkan level abstraksi lain dan berhenti menghiraukan node individual. Masing-masing memiliki indeks berwajah bukannya nama, dan dalam kasus masalah mesin virtual hanya membunuh dan bangkit dari snapshot yang berfungsi. Ada alat yang memungkinkan Anda untuk menerapkan pendekatan ini. Dalam kasus kami, alat pertama adalah CROC Cloud, yang kedua adalah Terraform.

Kue panggang lebih sehat daripada digoreng




Dalam manajemen infrastruktur ada perbedaan antara dua pendekatan. Panggang, yaitu, "digoreng dengan dipanggang".

Pendekatan Fried menyiratkan bahwa Anda memiliki gambar OS vanilla, misalnya, CentOS 7. Kemudian, setelah menggunakan OS, kami menggunakan sistem manajemen konfigurasi untuk membawa sistem ke status target. Misalnya, menggunakan Ansible, Chef, Puppet atau SaltStack.

Semuanya berfungsi dengan baik, terutama ketika tidak ada banyak server. Ketika ada kebutuhan untuk penyebaran besar-besaran, kami dihadapkan dengan masalah kinerja. Ratusan server secara serentak mulai melahap sumber daya jaringan, CPU, RAM dan IOPS dalam proses menggulirkan banyak paket baru. Apalagi proses ini bisa ditunda untuk waktu yang agak lama. Singkatnya, sirkuit ini benar-benar operasional, tetapi tidak begitu menarik dari sudut pandang meminimalkan waktu henti selama kecelakaan.

Pendekatan Baked menyiratkan bahwa Anda memiliki gambar OS "dipanggang" yang sudah jadi yang telah Anda instal semua paket yang diperlukan, mengkonfigurasi konfigurasi dan yang lainnya. Pada output, kami memiliki template snapshot abstrak, dipertajam untuk kinerja beberapa fungsi. Menyebarkan infrastruktur dari gambar yang dipanggang tersebut membutuhkan waktu lebih sedikit dan mengurangi waktu henti seminimal mungkin. Ideologi yang sangat mirip digunakan dalam gambar Docker multi-layer, di mana tidak ada yang menjulurkan tangannya dengan tidak perlu. Memaku wadah - mengangkat yang baru.

Kami memulai oven. Packer



Dalam infrastruktur kami, kami menggunakan beberapa produk Hashicorp, beberapa di antaranya ternyata sangat sukses. Mari mulai sihir kita dengan menyiapkan dan membuat gambar menggunakan alat Packer.

Packer menggunakan JSON Template, yaitu file template yang berisi deskripsi tentang apa yang perlu diperoleh sebagai mesin virtual (baked) virtual (VM). Setelah membuat templat, file ditransfer ke Packer, dan izin yang diperlukan untuk membuat server di cloud dikonfigurasikan.

Packer memungkinkan Anda untuk meningkatkan VM secara lokal di KVM, VirtualBox, Vagrant, AWS, GCP, Alibaba Cloud, OpenStack, dll. Lebih mudah untuk bekerja dengan Packer di CROC Cloud, karena mengimplementasikan antarmuka AWS, yaitu, semua alat yang ditulis untuk AWS, bekerja dengan CROC Cloud.

Setelah mengatur templat yang diperlukan, Packer menaikkan VM CROC di Cloud, menunggunya untuk memulai, dan kemudian "provider" memasuki work - provisioner: utilitas yang harus menyelesaikan persiapan gambar. Dalam kasus kami, ini Ansible, meskipun Packer dapat bekerja dengan opsi lain.

Ketika VM siap, Packer membuat gambarnya dan menempatkannya di CROC Cloud sehingga VM lain dapat diluncurkan dari gambar yang sama.

Struktur Base.json


Di awal file ada bagian di mana variabel dinyatakan:

Spoiler
"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": "",
},


Set utama dari variabel-variabel ini akan ditetapkan dari file settings.json. Dan variabel yang sering berubah lebih mudah diatur dari konsol saat memulai Packer dan membuat gambar baru.

Berikut ini adalah bagian Builders:

Spoiler
"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"
     },
...


Cloud target dan metode startup VM dijelaskan di sini. Harap dicatat bahwa dalam hal ini tipe amazon-ebs dideklarasikan, tetapi untuk Packer bekerja dengan CROC Cloud, alamat yang sesuai di custom_endpoint_ec2 diatur. Infrastruktur kami memiliki API yang hampir sepenuhnya kompatibel dengan Amazon Web Services, jadi jika Anda memiliki pengembangan siap pakai untuk platform ini, maka untuk sebagian besar Anda hanya perlu menentukan titik masuk API khusus - api.cloud.croc.ru dalam contoh kami.

Perlu dicatat bagian source_ami_filter secara terpisah. Di sini gambar awal VM diatur, di mana perubahan yang diperlukan akan dibuat. Namun, Packer membutuhkan AMI untuk gambar ini, yaitu pengidentifikasi acaknya. Karena pengidentifikasi ini jarang diketahui sebelumnya dan berubah dengan setiap pembaruan, sumber AMI ditetapkan bukan sebagai nilai spesifik, tetapi sebagai variabel source_ami_filter. Dalam hal ini, parameter penentu filter adalah nama gambar. Nama ini diatur dalam variabel melalui file settings.json.

Selanjutnya, pengaturan VM didefinisikan: jenis instance, prosesor, ukuran memori, ruang yang dialokasikan, dll ditentukan:

Spoiler
"instance_type": "{{user `instance_type`}}",
"launch_block_device_mappings": [
 {
  "device_name": "disk1",
  "volume_type": "io1",
  "volume_size": "8",
  "iops": "1000",
  "delete_on_termination": "true"
 }
],

Berikut ini di base.json adalah parameter untuk menghubungkan ke VM ini:

Spoiler
"availability_zone": "{{user `availability_zone`}}",
"subnet_id": "{{user `subnet_id`}}",
"associate_public_ip_address": true,
"ssh_username": "ec2-user",
"ami_name": "{{user `ami_name`}}"


Penting untuk mencatat parameter subnet_id di sini. Itu harus ditetapkan secara manual, karena tanpa menentukan subnet VM di CROC Cloud tidak mungkin dibuat.

Parameter lain yang memerlukan persiapan sebelumnya adalah associate_public_ip_address. Anda perlu memilih alamat IP putih, karena setelah membuat VM Packer akan mulai menerapkan pengaturan yang diperlukan melalui Ansible. Dalam hal ini, Ansible terhubung ke VM melalui SSH, yang memerlukan alamat IP putih atau VPN.

Bagian terakhir adalah Penyedia:

Spoiler
"provisioners": [
 {
  "type": "ansible",
  "playbook_file": "playbook.yml",
  "extra_arguments": [
   "--extra-vars",
   "kubernetes_version={{user `kubernetes_version`}}",
   "--extra-vars",
   "docker_version={{user `docker_version`}}"
   ]
  }
]


Ini adalah penyedia, yaitu utilitas yang digunakan Packer untuk mengkonfigurasi server. Dalam hal ini, penyedia jenis yang mungkin digunakan. Berikut ini adalah parameter playbook_file, yang menentukan peran yang Mungkin dan host di mana peran yang ditentukan akan diterapkan. Opsi tambahan extra_arguments disajikan di bawah ini, yang, ketika memulai Ansible, mengirimkan versi Kubernetes dan Docker.

Persiapan Cloud CROC




Selain file konfigurasi kami, kami perlu melakukan beberapa hal dari sisi panel kontrol cloud agar semua keajaiban bekerja. Kita perlu memilih IP putih dan membuat subnet yang berfungsi, yang akan kita gunakan saat menggunakan.

  1. Klik Sorot Alamat. Packer akan menemukan alamat IP putih yang diinginkan sendiri.
  2. Klik Buat Subnet dan tentukan subnet dan mask.
  3. Salin ID subnet.
  4. Masukkan nilai ini ke dalam parameter subnet_id dari perintah startup Packer.



Kemudian jalankan Packer. Dia menemukan gambar VM asli, menyebarkannya di CROC Cloud, dan melakukan peran Ansible di atasnya. VM baru dapat dilihat di CROC Cloud di bagian "Mesin Virtual".





Setelah menyelesaikan pekerjaan, Packer menghapus VM dari cloud dan meninggalkan gambar yang sudah jadi di tempatnya, yang dapat ditemukan di bagian "Templates". Seluruh infrastruktur Kubernetes akan dibuat dari gambar ini.

Mungkin


Seperti disebutkan sebelumnya, parameter playbook dilewatkan dalam parameter penyedia Ansible. File playbook.yml itu sendiri terlihat seperti ini:

- hosts: all
  become: true

  roles:
  | - base

Transfer file ke Ansible bahwa pada semua host perlu untuk memenuhi peran basis. Jika ada peran lain, Anda dapat menambahkannya ke file yang sama dengan daftar.

Peran dasar memungkinkan Anda untuk mendapatkan cluster yang siap pakai dengan satu perintah. File main.yml menunjukkan apa sebenarnya peran ini:

  1. Menambahkan repositori Docker ke templat sistem.
  2. Menambahkan repositori Kubernet ke templat sistem.
  3. Instal paket yang diperlukan.
  4. Membuat direktori untuk mengkonfigurasi daemon Docker.
  5. Mengkonfigurasi mesin sesuai dengan file konfigurasi daemon.json.j2.
  6. Memuat kernel br_netfilter.
  7. Termasuk opsi yang diperlukan untuk br_netfilter.
  8. Termasuk komponen Docker dan Kubelet.
  9. Menjalankan Docker di VM.
  10. Menjalankan perintah yang mengunduh gambar Docker yang diperlukan agar Kubernet berfungsi.

Dalam hal ini, paket yang diinstal diatur dalam file main.yml dari direktori vars. Dalam kasus kami, kami memasang paket docker-ce, serta tiga paket yang diperlukan agar Kubernet berfungsi: kubelet, kubeadm, dan kubectl.

Terraform - infrastruktur sebagai kode




Terraform adalah alat yang sangat fungsional dari HashiCorp untuk orkestrasi cloud. Ini memiliki bahasa HCL spesifiknya sendiri, yang sering digunakan dalam produk lain dari perusahaan, misalnya, di HashiCorp Vault and Consul.

Prinsip dasarnya mirip dengan semua sistem manajemen konfigurasi. Anda cukup menunjukkan status target dalam format yang diinginkan, dan sistem menghitung algoritma cara mencapai ini. Hal lain adalah bahwa, tidak seperti Ansible yang sama, yang berfungsi sebagai kotak hitam pada buku pedoman yang kompleks, Terraform dapat mengeluarkan rencana tindakan masa depan dalam bentuk yang nyaman untuk dianalisis. Ini penting ketika merencanakan perubahan infrastruktur yang kompleks. Setelah merencanakan tindakan yang diperlukan, jalankan perintah terraform apply dan Terraform akan menggunakan infrastruktur yang dijelaskan dalam file.

Seperti Packer, alat ini mendukung AWS, GCP, Alibaba Cloud, Azure, OpenStack, VMware, dll.

Kami menggambarkan proyek tersebut


Direktori Terraform memiliki serangkaian file dengan ekstensi .tf. File-file ini menjelaskan komponen-komponen infrastruktur yang dengannya kami akan bekerja. Hancurkan proyek menjadi modul fungsional. Struktur seperti itu membuatnya lebih mudah untuk mengontrol versi dan merakit setiap proyek dari blok nyaman yang sudah jadi. Untuk opsi kami, struktur berikut ini cocok:

  1. main.tf
  2. network.tf
  3. security_groups.tf
  4. master.tf
  5. master.tpl

Struktur file main.tf


Mari kita mulai dengan file main.tf, di mana akses ke cloud dikonfigurasi. Secara khusus, beberapa parameter diumumkan yang mengonfigurasi Terraform agar berfungsi dengan CROC Cloud:

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

Selain itu, file tersebut menjelaskan bahwa Terraform harus secara independen membuat kunci pribadi dan mengunggah bagian publiknya ke semua server. Kunci pribadi itu sendiri dikeluarkan pada akhir 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}"
}

Struktur file network.tf


File ini menjelaskan komponen-komponen jaringan yang diperlukan untuk memulai VM:

Spoiler
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 menggunakan dua jenis komponen:

  • sumber daya - apa yang perlu dibuat;
  • data - apa yang perlu Anda dapatkan.

Dalam hal ini, parameter data menunjukkan bahwa Terraform harus menerima zona ketersediaan cloud yang ditentukan, yang berada dalam keadaan tersedia.

Sumber daya parameter pertama menjelaskan pembuatan cloud pribadi virtual, dan parameter berikutnya menjelaskan pembuatan Alamat IP Elastis. Untuk kluster Kubernetes, kami memesan alamat IP ini melalui Terraform.

Lebih jauh, di setiap zona aksesibilitas, dan saat ini CROC memiliki dua layanan cloud, subnetnya sendiri dibuat. Sumber daya tipe aws_subnet dideklarasikan, dan ID dari aws_vpc yang dihasilkan dilewatkan sebagai bagian dari parameter ini. Namun, karena ID sumber daya ini masih belum diketahui, kami menentukan parameter aws_vpc.kube.id, yang merujuk pada sumber daya yang dibuat dan menggantikan nilai dari bidang ID.

Karena jumlah subnet yang dibuat ditentukan oleh jumlah zona ketersediaan cloud dan angka ini dapat berubah seiring waktu, parameter ini ditetapkan melalui variabel panjang (data.aws_available_zones.az.names), yaitu panjangnya daftar zona akses yang diterima melalui parameter data.

Dua parameter terakhir adalah cidr_block (subnet yang dialokasikan) dan zona ketersediaan tempat subnet ini dibuat. Parameter terakhir juga ditetapkan melalui variabel yang mengambil nilai dari daftar data sesuai dengan indeks loop yang dinyatakan oleh [count.index] .

Struktur file Security_groups.tf


Grup keamanan adalah semacam firewall untuk cloud, yang dapat dibuat bukan di dalam VM itu sendiri, tetapi oleh cloud. Dalam hal ini, firewall menjelaskan dua aturan.

Aturan pertama membuat grup keamanan yang disebut kubus. Grup keamanan ini diperlukan untuk memungkinkan semua lalu lintas keluar dari node Kubernetes, memungkinkan node untuk secara bebas mengakses Internet. Lalu lintas masuk ke simpul Kubernetes dari subnet dari simpul itu sendiri juga diizinkan. Dengan demikian, node Kubernetes dapat bekerja di antara mereka sendiri tanpa batasan.

Aturan kedua membuat grup keamanan ssh. Ini memungkinkan koneksi SSH dari alamat IP apa pun ke port 22 dari kluster Kubernetes VM:

Spoiler
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 node. Struktur file Master.tf


File master.tf menjelaskan pembuatan beberapa templat dan instance. Secara khusus, instance master Kubernetes sedang dibuat.

Variabel ami mengatur AMI dari gambar sumber untuk VM. Berikut ini menjelaskan jenis VM dan subnet di mana ia dibuat. Saat mendefinisikan subnet, sebuah siklus lagi digunakan untuk membuat VM di setiap zona ketersediaan.

Selanjutnya, grup keamanan yang digunakan dan kunci yang ditentukan dalam file main.tf dideklarasikan. Bidang user_data berisi eksekusi satu set skrip cloud-init, yang hasilnya akan diimplementasikan dalam VM:

Spoiler
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"
}


Master node. Cloud init


Cloud-init adalah alat yang dikembangkan Canonical. Ini memungkinkan Anda untuk secara otomatis mengeksekusi dalam infrastruktur cloud seperangkat perintah tertentu setelah memulai VM. Terraform memiliki mekanisme untuk mengintegrasikannya menggunakan templat .

Karena tidak mungkin untuk "memanggang" semua yang diperlukan dalam VM, setelah memulai, tergantung pada jenisnya, ia harus bergabung dengan cluster Kubernetes atau menginisialisasi cluster Kubernetes. Dalam templat file cloud-init yang disebut master.tpl, beberapa tindakan dilakukan.

1. File konfigurasi untuk Kubeadm direkam:

#cloud-config

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


2. Serangkaian perintah dijalankan:

  • alamat IP dari wizard ditulis ke file konfigurasi yang dihasilkan;
  • master di cluster Kubernetes diinisialisasi dengan perintah init kubeadm;
  • di kluster Kubernetes, jaringan overlay Calico diinstal dengan perintah Kubectl apply.

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

Setelah mengeksekusi perintah ketika memulai VM, klaster Kubernet yang berfungsi diperoleh dari satu node master. Node yang tersisa akan bergabung dengan master node ini.

Node biasa. node.tf


File node.tf mirip dengan file master.tf. Sumber daya juga dibuat di sini, yang dalam hal ini disebut simpul. Satu-satunya perbedaan adalah bahwa node master dibuat dalam satu instance, dan jumlah node yang bekerja dibuat melalui variabel nodes_count:

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

File cloud-init untuk node yang bekerja mengeksekusi hanya satu perintah - kubeadm join. Perintah ini menempel mesin jadi ke kluster Kubernetes menggunakan token otorisasi yang kami kirim.

Luncurkan Terraform


Saat diluncurkan, Terraform menggunakan beberapa modul:

  • Modul AWS
  • modul template;
  • Modul TLS bertanggung jawab untuk pembuatan kunci.

Modul-modul ini harus diinstal pada mesin lokal:

terraform init terraform/

Bersama dengan perintah ini, direktori di mana semua file yang diperlukan berada ditunjukkan. Saat menginisialisasi, Terraform mengunduh semua modul yang ditentukan, setelah itu Anda perlu menjalankan perintah rencana terraform:

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

Harap dicatat bahwa selain direktori dengan file Terraform, file var diindikasikan, yang berisi nilai-nilai variabel yang digunakan dalam file Terraform. Direktori vars dapat berisi beberapa file .tfvars, yang memungkinkan Anda untuk mengelola berbagai jenis infrastruktur dengan satu set file Terraform.

File dev.tfvars sendiri berisi variabel-variabel penting berikut:

  • Kubernetes_version (versi yang dapat diinstal dari Kubernetes);
  • Kubernetes_ami (gambar AMI yang dibuat Packer).

Setelah mengatur nilai-nilai yang diperlukan dari variabel, jalankan perintah rencana terraform, setelah itu Terraform akan menyajikan daftar tindakan yang diperlukan untuk mencapai keadaan yang dijelaskan dalam file Terraform.

Setelah memeriksa daftar ini, terapkan perubahan yang diajukan:

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

Dari perintah rencana terraform, dibedakan dengan adanya kunci - setujui otomatis, yang menghilangkan kebutuhan untuk mengonfirmasi perubahan yang dibuat. Anda dapat menghilangkan kunci ini, tetapi setiap tindakan perlu dikonfirmasi secara manual.

Struktur Cluster Kubernetes




Cluster Kubernetes terdiri dari node master yang melakukan fungsi manajemen dan node kerja yang menjalankan aplikasi yang diinstal dalam cluster.

Empat komponen diinstal pada master node yang memastikan pengoperasian sistem ini:

  • ETCD, mis. Basis Data Kubernetes
  • API Server, yang melaluinya kami menyimpan informasi di Kubernetes dan mendapatkan informasi darinya;
  • Manajer Pengendali
  • Penjadwal

Dua komponen tambahan dipasang pada node yang bekerja:

  • Kube-proxy (bertanggung jawab untuk membuat aturan jaringan di kluster Kubernetes);
  • Kubelet (bertanggung jawab untuk mengirim perintah ke daemon Docker untuk menjalankan aplikasi di kluster Kubernetes).

Antara node, plug-in jaringan Calico berfungsi.

Diagram Alur Kerja Cluster

, 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




Elemen terakhir yang layak disebut adalah Kubeadm. Menyebarkan sekelompok Kubernet baru selalu merupakan proses yang melelahkan. Pada setiap tahap, ada risiko kesalahan karena faktor manusia, dan banyak tugas yang sangat rutin dan panjang. Misalnya, menuangkan sertifikat untuk enkripsi TLS di antara node dan tetap memperbaruinya. Di sinilah utilitas untuk otomatisasi template dasar datang untuk menyelamatkan. Trik Kubeadm adalah bahwa ia secara resmi disertifikasi untuk bekerja dengan Kubernetes.

Ini memungkinkan Anda untuk:

  • Instal, konfigurasikan, dan jalankan semua komponen cluster utama
  • mengelola sertifikat, termasuk memutarnya dan menulis yang baru;
  • mengelola versi komponen klaster (pemutakhiran dan penurunan versi).

Pada saat yang sama, Kubeadm bukanlah sistem manajemen kluster Kubernetes yang lengkap, tetapi merupakan jenis blok bangunan yang memungkinkan Anda untuk mengkonfigurasi Kubernetes pada node di mana utilitas Kubeadm berjalan. Ini berarti bahwa sistem orkestrasi diperlukan yang akan menjalankan semua VM yang diperlukan, mengkonfigurasinya dan menjalankan Kubeadm pada semua node. Untuk keperluan inilah Terraform digunakan.

Repositori dengan semua file


Di sini kami meletakkan semua file dan konfigurasi di satu tempat, sehingga akan lebih nyaman bagi Anda. Jika Anda tidak memiliki cloud pribadi, tetapi Anda ingin melalui semua langkah ini sendiri dan menguji penerapannya dalam praktik, kirimkan kepada kami di cloud@croc.ru.

Kami akan memberi Anda versi demo untuk tes dan memberi saran tentang semua masalah.

Dan segera akan ada Slurm baru , di mana Anda dapat membuat cluster Anda sendiri. Kode promo CROC memiliki diskon 10%.

Bagi mereka yang sudah bekerja dengan Kubernetes, ada kursus lanjutan . Diskonnya sama.

Kolega, Habraparser memecah markup kode. Silakan ambil sumbernya dari GitHub dari tautan di atas.

More articles:


All Articles