[Note] Khóa học Kubernetes cơ bản (tiếng Việt) – Phần 2

Chapter 5. Installing Kubernetes

Chapter Overview

Chương này sẽ xem xét các vấn đề liên quan đến việc triển khai các cụm Kubernetes. Đầu tiên, chúng ta sẽ xem xét các tùy chọn cấu hình cụm Kubernetes. Sau đó, chúng ta sẽ xem xét các yêu cầu cơ sở hạ tầng và công cụ cài đặt cụ thể cho mỗi cluster deployment model.

Learning Objectives

Đến cuối chương này, bạn nên có thể:

Xem xét các lựa chọn cấu hình của Kubernetes.
Xem xét các vấn đề cơ sở hạ tầng trước khi cài đặt Kubernetes.
Thảo luận về các lựa chọn cơ sở hạ tầng cho việc triển khai Kubernetes cluster.

Kubernetes Configuration

Kubernetes có thể được cài đặt bằng cách sử dụng các cluster configurations khác nhau. Các loại cài đặt chính được mô tả dưới đây:

All-in-One Single-Node Installation: Trong thiết lập này, tất cả các bộ phận control plane và worker được cài đặt và chạy trên một node duy nhất. Mặc dù nó hữu ích cho việc học tập, phát triển và thử nghiệm, nhưng nó không được khuyến cáo cho mục đích sản xuất.
Single-Control Plane and Multi-Worker Installation: Trong thiết lập này, chúng ta có một single-control plane node chạy một stacked etcd instance. Multiple worker nodes có thể được quản lý bởi control plane node.
Single-Control Plane with Single-Node etcd, and Multi-Worker Installation: Trong thiết lập này, chúng ta có một nút single-control plane node với một external etcd instance. Multiple worker nodes có thể được quản lý bởi control plane node.
Multi-Control Plane and Multi-Worker Installation: Trong thiết lập này, chúng ta có nhiều control plane nodes được cấu hình mode High-Availability (HA), mỗi control plane node đi cùng (paired with) với 1 stacked etcd instance. The external etcd instances cũng được cấu hình trong một HA etcd clustee và nhiều worker nodes có thể được quản lý bởi HA control plane.
Multi-Control Plane with Multi-Node etcd, and Multi-Worker Installation: Trong thiết lập này, chúng ta có nhiều control plane nodes được cấu hình trong HA mode, mỗi control plane node đi cùng (paired with) với 1 external etcd instance.The external etcd instances cũng được cấu hình trong một HA etcd clustee và nhiều worker nodes có thể được quản lý bởi HA control plane. Đây là cấu hình cluster tiên tiến nhất được đề nghị cho môi trường sản xuất.

Sự phức tạp của cụm Kubernetes làm tăng nhu cầu phần cứng và nguồn lực. Mặc dù Kubernetes có thể được triển khai trên một máy chủ duy nhất cho mục đích học tập, phát triển và thử nghiệm, nhưng cộng đồng khuyên bạn nên sử dụng môi trường nhiều host vì những môi trường này có thể hỗ trợ High-Availability control plane setups và multiple worker nodes cho client workload

Infrastructure for Kubernetes Installation

Chúng ta phải chọn cơ sở hạ tầng trước khi chọn loại cài đặt. Môi trường mong muốn, chẳng hạn như môi trường học tập hoặc sản xuất, thường ảnh hưởng đến các quyết định về cơ sở hạ tầng. Chúng ta phải đưa ra những quyết định sau đây về cơ sở hạ tầng:

Chúng ta có nên cài đặt Kubernetes trên bare metal, public cloud, private, hay hybrid cloud?
Chúng ta nên sử dụng hệ điều hành nào? Chúng ta nên chọn Linux distribution – Red Hat-based, Debian-based, hay Windows?
Chúng ta nên sử dụng networking solution (CNI) nào?

Xem Kubernetes documentation để biết chi tiết về việc lựa chọn giải pháp phù hợp.

Installing Local Learning Clusters

Chúng ta có thể triển khai các cụm Kubernetes đơn hoặc đa node cho mục đích học tập và phát triển trên các workstation của mình bằng một số công cụ cài đặt khác nhau. Mặc dù danh sách này không đầy đủ, nhưng dưới đây là một số công cụ phổ biến:

Minikube Single- and multi-node local Kubernetes cluster, recommended for a learning environment deployed on a single host.
Kind Multi-node Kubernetes cluster deployed in Docker containers acting as Kubernetes nodes, recommended for a learning environment.
Docker Desktop Including a local Kubernetes cluster for Docker users.
MicroK8s Local and cloud Kubernetes cluster for developers and production, from Canonical.
K3S Lightweight Kubernetes cluster for local, cloud, edge, IoT deployments, originally from Rancher, currently a CNCF project.

Minikube là một phương pháp đơn giản và linh hoạt để tạo một local Kubernetes setup. Trong khóa học này, chúng ta sẽ sử dụng nó để quản lý một số yếu tố cụ thể của cụm Kubernetes, cũng như tận dụng một số tính năng tự động được thiết kế để giúp người dùng tương tác dễ dàng hơn với môi trường Kubernetes và các ứng dụng containerized.

Installing Production Clusters with Deployment Tools

Khi nói đến các giải pháp sẵn sàng cho sản xuất, một số công cụ được đề xuất cho việc bootstrapping các cụm Kubernetes, và một số công cụ khác có khả năng provisioning các máy chủ cần thiết trên cơ sở hạ tầng..

Hãy xem các công cụ cài đặt phổ biến nhất:

kubeadm: kubadm là first-class citizen của hệ sinh thái Kubernetes. Đó là một phương pháp an toàn và được khuyến cáo để bootstrap một multi-node production ready Highly Available Kubernetes cluster, on-premises hoặc in the cloud. kubeadm cũng có thể bootstrap một single-node cluster để học. Nó có một tập hợp các building blocks để thiết lập cluster, nhưng nó có thể dễ dàng mở rộng để thêm nhiều tính năng hơn. Xin lưu ý rằng kubeadm không hỗ trợ việc provisioning hosts.

kubespray kubespray (trước đây gọi là kargo) cho phép chúng ta cài đặt Highly Available production ready Kubernetes clusters trên AWS, GCP, Azure, OpenStack, vSphere, hoặc bare metal. kubespray dựa trên Ansible, và có sẵn trên hầu hết các bản phân phối Linux. Đây là một dự án của Kubernetes Incubator.

kops cho phép chúng ta tạo, nâng cấp và duy trì các production-grade, Highly Available Kubernetes clusters bằng command line. Nó cũng có thể cung cấp cơ sở hạ tầng cần thiết. Hiện tại, AWS được hỗ trợ chính thức. Hỗ trợ cho DigitalOcean và OpenStack đang trong giai đoạn beta, Azure và GCE đang ở giai đoạn hỗ trợ alpha, và các nền tảng khác đang được lên kế hoạch cho tương lai.

Ngoài ra, cho manual installation approach, dự án Kubernetes The Hard Way của Kelsey Hightower là một hướng dẫn và tài nguyên rất hữu ích. Dự án này nhằm mục đích dạy tất cả các bước chi tiết liên quan đến việc bootstrapping một cụm Kubernetes.

Production Clusters from Certified Solutions Providers

Sự phổ biến ngày càng tăng của Kubernetes đã đẩy nhanh sự áp dụng của nó bởi nhiều nhà cung cấp dịch vụ đám mây cùng với hosted platforms của certified Kubernetes distributions. Hiện nay có hơn 200 managed certified Kubernetes services providers, nhiều tổ chức trở thành đối tác của Kubernettes:

Hosted Solutions

Người dùng phải trả phí cho cả lưu trữ và quản lý, trong khi các nhà cung cấp giải pháp lưu trữ quản lý cung cấp toàn bộ kho phần mềm. Các giải pháp hosting cho Kubernetes được cung cấp bởi một số nhà cung cấp phổ biến, được liệt kê theo thứ tự bảng chữ cái:

Alibaba Cloud Container Service for Kubernetes (ACK)
Amazon Elastic Kubernetes Service (EKS)
Azure Kubernetes Service (AKS)
DigitalOcean Kubernetes
Google Kubernetes Engine (GKE)
IBM Cloud Kubernetes Service
Oracle Container Engine for Kubernetes (OKE)
Platform9 Managed Kubernetes (PMK)
Red Hat OpenShift
VMware Tanzu Kubernetes Grid

Partners

Các đối tác khác cung cấp nền tảng và dịch vụ Kubernetes được quản lý:

Altoros
Aqua Security
Canonical
D2IQ
Dell Technologies Consulting
Deloitte
Fujitsu
GitLab
HPE
Inovex
Kubermatic
Kublr
Mirantis
Nirmata
Rancher
SAP
Sysdig
Weaveworks

Turnkey Cloud Solutions

Turnkey Cloud Solutions install production ready Kubernetes clusters on cloud infrastructure:

Linode Kubernetes Engine
Nirmata Managed Kubernetes
Nutanix Karbon
Vultr Kubernetes Engine

Kubernetes on Windows

Hệ điều hành Windows đóng vai trò quan trọng trong việc chạy và quản lý các ứng dụng và dịch vụ của doanh nghiệp, cộng đồng Kubernetes đã làm việc rất chăm chỉ để mang lại sự hỗ trợ cho Windows.

Với việc phát hành Kubernetes v1.14, Windows đã được giới thiệu thành công như một hệ thống điều khiển sản xuất sẵn sàng chỉ dành cho worker nodes của một cụm Kubernetes (https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/). Điều này cho phép Kubernetes hỗ trợ việc sử dụng các container Windows trong các cluster—một cluster dành riêng cho Windows hoặc một cluster hybrid bao gồm các node Windows và node Linux. Hãy nhớ, tuy nhiên, rằng control plane nodes chỉ được giới hạn để chạy trên Linux, không có kế hoạch mở rộng hỗ trợ cho các Windows control plane node.

Với Windows Server 2019 là hệ điều hành Windows duy nhất được Kubernetes hỗ trợ, cùng một công cụ container workload orchestration có thể schedule và triển khai cả container Linux và Windows trong cùng một cụm. Người dùng chịu trách nhiệm cấu hình workload scheduling theo hệ điều hành dự kiến, chẳng hạn như cấu hình các container Linux và Windows trên các node với hệ điều hành tương ứng.

Chapter 6. Minikube – Installing Local Kubernetes Clusters

Chapter Overview

Minikube là một trong những phương pháp phổ biến, đơn giản và linh hoạt nhất để chạy một cluster Kubernetes all-in-one hoặc cluster Kubernetes multi-node local, được cô lập bởi máy ảo (VM) hoặc container, chạy trực tiếp trên các workstation của chúng tôi. Minikube là công cụ chịu trách nhiệm cài đặt các thành phần Kubernetes, cluster bootstrapping và cluster tear-down khi không còn cần thiết. Nó có thêm các tính năng giúp người dùng tương tác dễ dàng với Kubernetes cluster, rất thuận tiện cho mục đích học tập. Minikube có thể được cài đặt trên macOS, Windows và nhiều Linux distributions.

Learning Objectives

Đến cuối chương này, bạn nên có thể:

Hiểu Minikube.
Cài đặt Minikube.
Kiểm tra cài đặt.

What Is Minikube?

Minikube là một trong những phương pháp dễ dàng nhất, linh hoạt nhất và phổ biến nhất để chạy một all-in-one or a multi-node local Kubernetes cluster trực tiếp trên các local workstations. Nó cài đặt và chạy trên bất kỳ native OS nào như Linux, macOS, hoặc Windows. Tuy nhiên, để tận dụng đầy đủ tất cả các tính năng mà Minikube có thể cung cấp, nên cài đặt một Hypervisor Type-2 hoặc một Container Runtime trên máy local, để chạy cùng với MiniKube. Vai trò của hypervisor hoặc container runtime là cung cấp một cơ sở hạ tầng cô lập cho các thành phần Minikube Kubernetes cluster, dễ tái tạo, dễ sử dụng và tear down. Sự cô lập của các thành phần cluster đảm bảo rằng một khi không còn cần thiết, các bộ phận Minikube có thể được loại bỏ một cách an toàn không để lại bất kỳ thay đổi cấu hình cho máy local của chúng ta. Minikube bao gồm các adapters cần thiết để tương tác trực tiếp với isolation software để xây dựng toàn bộ cơ sở hạ tầng của nó miễn là Hypervisor Type-2 hoặc Container Runtime được cài đặt trên local workstations.

Minikube được xây dựng dựa trên thư viện libmachine ban đầu được thiết kế bởi Docker để xây dựng các Virtual Machine container hosts trên bất kỳ cơ sở hạ tầng vật lý nào. Theo thời gian, Minikube trở nên rất linh hoạt, hỗ trợ nhiều hypervisors và container runtimes, tùy thuộc vào hệ điều hành gốc của máy chủ.

Đối với những người thích khám phá, Minikube có thể được cài đặt mà không cần isolation software, trên bare-metal, có thể dẫn đến thay đổi cấu hình vĩnh viễn cho hệ điều hành máy chủ. Để ngăn chặn những thay đổi cấu hình vĩnh viễn như vậy, một hình thức cách ly thứ hai có thể đạt được bằng cách cài đặt Minikube bên trong một Máy ảo được cung cấp với một Hypervisor loại 2 tùy chọn, và một hệ điều hành khách desktop tùy chọn (with enabled GUI). Kết quả là, khi được cài đặt bên trong VM, Minikube sẽ làm thay đổi cấu hình cho môi trường khách trong khi vẫn bị cô lập với máy chủ. Do đó, chúng ta hiện có hai cách khác nhau để tách môi trường Minikube từ host workstation.

Isolation software có thể được chỉ định bởi người dùng với tùy chọn –driver, nếu không Minikube sẽ cố gắng tìm một preferred method.

Sau khi lựa chọn isolation method, bước tiếp theo là xác định số lượng cần thiết của các Kubernetes cluster nodes, và kích cỡ của chúng về CPU, bộ nhớ và không gian đĩa. Hypervisor được gọi bởi Minikube để provision các infrastructure VM(s) – nơi host các Kubernetes cluster node(s), hoặc runtime tùy chọn để chạy các infrastructure container(s) host cluster node(s). Hãy nhớ rằng Minikube bây giờ hỗ trợ all-in-one single-node và multi-node clusters. Một cụm Kubernetes Minikube local cuối cùng sẽ bị ảnh hưởng và/hoặc hạn chế bởi các nguồn lực vật lý của máy chủ, bất kể phương pháp cô lập hay kích cỡ cụm và node dự kiến. Chúng ta phải xem xét các yêu cầu của hệ điều hành host và các tính năng mà nó có thể chạy, sau đó là các yêu cầu về hypervisor hoặc runtime container, và cuối cùng là các nguồn lực còn lại có thể được cung cấp cho cụm Kubernetes của chúng ta. Đối với một môi trường học tập, các khuyến nghị là một nút Kubernetes phải có tối thiểu 2 lõi CPU (hoặc CPU ảo), ít nhất 2 GB bộ nhớ RAM (với 4 – 8 GB RAM được khuyến cáo để sử dụng tối ưu), và 20+ GB dung lượng lưu trữ đĩa. Các giá trị tài nguyên này nên được thay đổi để phù hợp với việc phát triển một nhóm sản xuất năng động hơn. Ngoài ra, các node Kubernetes phải có khả năng truy cập Internet, nhập phần mềm, tải xuống container image, và cho phép client truy cập.

Sau quá trình provisioning, Minikube sử dụng kubeadm để bootstrap Kubernetes kết hợp các thành phần trong node(s) đã dự trù trước đó. Để xây dựng môi trường, chúng ta phải đảm bảo rằng chúng ta có phần mềm và phần cứng cần thiết cho Minikube.

Requirements for Running Minikube

Dưới đây là các yêu cầu để chạy Minikube:

VT-x/AMD-v virtualization phải được bật.
kubectl là một binary được sử dụng để truy cập và quản lý bất kỳ cụm Kubernetes nào. Nó được cài đặt thông qua Minikube và truy cập thông qua lệnh minikube kubectl, hoặc nó có thể được cài đặt riêng và chạy như một công cụ độc lập.
Type-2 Hypervisor or Container Runtime: Nếu không có driver được chỉ định, Minikube sẽ cố gắng tìm một hypervisor đã cài đặt hoặc một runtime, theo thứ tự ưu tiên sau (trên máy chủ Linux): docker, kvm2, podman, vmware, và virtualbox. Nếu nhiều isolation software installations được tìm thấy, chẳng hạn như docker và virtualbox, Minikube sẽ chọn docker thay vì virtualbox nếu không có driver mong muốn được chỉ định bởi người dùng. Hypervisors và Container Runtimes được hỗ trợ bởi các hệ điều hành khác nhau: On Linux VirtualBox, KVM2, and QEMU hypervisors, or Docker and Podman runtimesOn macOS VirtualBox, HyperKit, VMware Fusion, Parallels, and QEMU hypervisors, or Docker runtimeOn Windows VirtualBox, Hyper-V, VMware Workstation, and QEMU hypervisors, or Docker runtime.

LƯU Ý: Minikube hỗ trợ một tùy chọn –driver=none (trên Linux) để chạy các thành phần Kubernetes bare-metal, trực tiếp trên hệ điều hành máy chủ và không phải trong VM. Tùy chọn này yêu cầu cài đặt Docker và hệ điều hành Linux trên local workstations, nhưng không cần hypervisor.

Cần có kết nối Internet trong lần chạy Minikube đầu tiên – để tải xuống các gói, phụ thuộc, cập nhật và kéo image cần thiết để khởi tạo các Minikube Kubernetes cluster components. Việc chạy Minikube tiếp theo sẽ chỉ yêu cầu kết nối Internet khi pull image mới từ public container registry hoặc khi các ứng dụng được triển khai cần kết nối với nó để client có thể truy cập. Sau khi một container image đã được pull, nó có thể được tái sử dụng từ local container runtime image cache mà không cần kết nối Internet.

Installing Minikube on Linux

Chuẩn bị:

1 EC2 instance t2.medium (2vCPU, 4GB RAM), 30GB EBS.

Tải và cài đặt minikube:

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb

sudo dpkg -i minikube_latest_amd64.deb

Để có thể khởi động Minikube, thì cần 1 trong số những driver dưới đây:

 docker
 kvm2
 qemu2
 podman
 virtualbox

Chúng ta sẽ sử dụng docker trong trường hợp này:

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update


sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Run 3 command below if you get error: docker: Got permission denied while trying to connect to the Docker daemon socket at unix:
# ///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.35/containers/create: 
# dial unix /var/run/docker.sock: connect: permission denied. See 'docker run --help'..

sudo chmod 666 /var/run/docker.sock
sudo groupadd docker
sudo usermod -aG docker $USER

Note:

Podman có thể sẽ gặp 1 số bug với Minikube, do đó không nên sử dụng podman làm container runtime cho minikube
Nếu cài đặt trên máy ảo, giả sử EC2 instance có thể sẽ gặp lỗi sau nếu dùng VirtualBox:

  Failed to start virtualbox VM. Running "minikube delete" may fix it: creating host: create: precreate: This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory

  Exiting due to HOST_VIRT_UNAVAILABLE: Failed to start host: creating host: create: precreate: This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory
  Suggestion: Virtualization support is disabled on your computer. If you are running minikube within a VM, try '--driver=docker'. Otherwise, consult your systems BIOS manual for how to enable virtualization.
  Related issues:
     https://github.com/kubernetes/minikube/issues/3900
     https://github.com/kubernetes/minikube/issues/4730

Start minikube:

minikube start --driver=docker

Note: For a specific Kubernetes version the –kubernetes-version option can be used as such minikube start –kubernetes-version v1.25.1 (where latest is default and acceptable version value, and stable is also acceptable).

Kết quả mong đợi:

Cài đặt kubectl:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# Check kubectl installed
kubectl version --client --output=yaml

NOTE*: An error message that reads “Unable to pick a default driver…” means that Minikube was not able to locate any one of the supported hypervisors or runtimes. The recommendation is to install or re-install a desired isolation tool, and ensure its executable is found in the default **PATH** of your OS distribution.*

Kiểm tra status:

minikube status

Kết quả mong đợi:

Stop minikube:

minikube stop

Nếu bạn muốn xóa tất cả những resources tạo ra bởi minikube:

minikube delete

Advanced Minikube Features (1)

Bây giờ chúng ta đã làm quen với lệnh mặc định minikube start, hãy đi sâu hơn vào Minikube để hiểu một số tính năng nâng cao hơn của nó.

minikube start theo mặc định sẽ chọn driver isolation software, chẳng hạn như hypervisor hoặc container runtime, nếu một (VitualBox) hoặc nhiều được cài đặt trên máy chủ. Ngoài ra nó tải xuống các latest Kubernetes version components. Với driver software đã chọn, nó provision một máy ảo duy nhất có tên minikube (với cấu hình phần cứng của CPUs=2, Memory=6GB, Disk=20GB) hoặc container để host tập hợp tất cả-trong-một của Kubernetes. Một khi node được provisioned, nó sẽ bootstraps Kubernetes control plane (với default kubeadm tool), và nó sẽ cài đặt phiên bản mới nhất của default container runtime, Docker, sẽ phục vụ như một môi trường chạy cho các ứng dụng containerized chúng ta sẽ deploy vào Kubernetes cluster. Lệnh minikube start tạo ra default cluster minikube với các thông số kỹ thuật được mô tả ở trên và nó sẽ lưu trữ những thông số đặc tả này để chúng ta có thể khởi động lại default cluster bất cứ khi nào chúng ta muốn. Đối tượng lưu trữ thông số kỹ thuật của tập hợp của chúng ta được gọi là profile.

Với profile, Minikube cho phép người dùng tạo ra các cụm có thể tái sử dụng tùy chỉnh mà tất cả có thể được quản lý từ một command line client duy nhất.

Lệnh minikube profile cho phép chúng ta xem trạng thái của tất cả các cụm của chúng ta trong một đầu ra được định dạng bảng. Giả sử chúng ta chỉ tạo ra cluster minikube default, chúng ta có thể liệt kê các thuộc tính xác định hồ sơ default profile với:

Bảng này trình bày các cột liên quan đến các default properties như tên hồ sơ: minikube, isolation driver: docker, thời gian chạy container: Docker, phiên bản Kubernetes: v1.28.3, trạng thái của cụm – running hoặc Stopped. Bảng cũng hiển thị số lượng node: 1 theo mặc định, địa chỉ IP private của máy của VM, và port cho phép API Server tiếp xúc với các control plane components, agents và clients: 8443.

Điều gì sẽ xảy ra nếu thay vào đó chúng ta muốn tạo ra nhiều cluster có thể tái sử dụng, với các drivers khác (Docker hoặc Podman (vẫn còn thử nghiệm trên Linux)) cho node isolation, hoặc các phiên bản Kubernetes khác nhau (v1.23.3 hoặc v1.24.4), một runtime khác (cri-o hoặc containerd), và có thể là 2, 3 hoặc nhiều nút hơn (nếu được các nguồn lực của hệ thống máy chủ cho phép)? Điều gì sẽ xảy ra nếu chúng ta muốn tùy chỉnh thêm các cụm với một tùy chọn mạng cụ thể hoặc plugin? Lệnh minikube start cho phép chúng ta tạo các hồ sơ tùy chỉnh như vậy với cờ –profile hoặc -p. Một số isolation drivers hỗ trợ việc tạo VM node hoặc container node có kích cỡ tùy chỉnh.

Dưới đây là một vài ví dụ về các lệnh start phức tạp hơn cho phép các cụm tùy chỉnh được tạo với Minikube. Assumption: driver software (Docker và/hoặc Podman) đã được cài đặt trên máy chủ. Không cần phải tải xuốngCNI (network plugin) hoặc container runtime, Minikube sẽ làm việc này thay chúng ta:

minikube start --kubernetes-version=v1.23.3 \
--driver=podman --profile minipod

minikube start --nodes=2 --kubernetes-version=v1.24.4 \
--driver=docker --profile doubledocker

minikube start --driver=virtualbox --nodes=3 --disk-size=10g \
--cpus=2 --memory=4g --kubernetes-version=v1.25.1 --cni=calico \
--container-runtime=cri-o -p multivbox

minikube start --driver=docker --cpus=6 --memory=8g \
--kubernetes-version="1.24.4" -p largedock

minikube start --driver=virtualbox -n 3 --container-runtime=containerd \
--cni=calico -p minibox

Sau khi có nhiều cluster profiles (default minikube và custom doubledocker), profiles table sẽ trông như thế này:

active marker cho biết target cluster profile của minikube command line tool. Bạn có thể đặt target cluster thành doubledocker bằng lệnh sau

minikube profile doubledocker

Quay lại profile default:

minikube profile minikube
minikube profile default

Advanced Minikube Features (2)

Hầu hết các lệnh minikube, chẳng hạn như start, stop, node, v.v. đều profile aware, nghĩa là người dùng được yêu cầu xác định target cluster của lệnh, thông profile name. Tuy nhiên, có thể quản lý default minikube cluster mà không cần chỉ định tên hồ sơ. Dừng lại và khởi động lại hai cụm được liệt kê ở trên, cụm doubledocker và minikube mặc định:

minikube stop -p doubledocker
minikube start -p doubledocker

minikube stop
minikube start

Các lệnh minikube hữu ích bổ sung:

ubuntu@ip-172-31-16-11:~$ minikube version

minikube version: v1.32.0
commit: 8220a6eb95f0a4d75f7f2d7b14cef975f050512d

Completion là một cấu hình sau khi cài đặt hữu ích để cho phép lệnh minikube đáp ứng các cơ chế tự động hoàn thành điển hình, chẳng hạn như hoàn thành một lệnh trong terminal bằng cách nhấn phím TAB. Để bật hoàn thành cho shell bash trên Ubuntu:

sudo apt install bash-completion
source /etc/bash_completion
source <(minikube completion bash)

Nếu cần, chạy câu command sau:

minikube completion bash

Lệnh cho phép người dùng liệt kê các nodes của một cụm, add new control plane hoặc worker nodes mới, xóa các cluster nodes hiện có, start or stop các individual nodes của một cụm:

minikube node list

minikube 192.168.59.100

minikube node list -p doubledocker

doubledocker    192.168.58.2
doubledocker-m02        192.168.58.3

Để hiển thị cluster control plane node’s IP address hoặc IP của node khác với cờ -node hoặc n :

minikube ip

192.168.49.2

minikube -p doubledocker ip

192.168.58.2

minikube -p doubledocker ip -n doubledocker-m02

192.168.58.3

Khi cluster configuration không còn được sử dụng nữa, cluster’s profile có thể bị xóa. Đây cũng là một profile aware command – nó xóa cụm minikube mặc định nếu không có hồ sơ nào được chỉ định hoặc một cụm tùy chỉnh nếu hồ sơ của nó được chỉ định:

minikube delete

  Deleting "minikube" in docker ...
  Deleting container "minikube" ...
  Removing /home/ubuntu/.minikube/machines/minikube ...
  Removed all traces of the "minikube" cluster.

minikube delete -p doubledocker

  Deleting "doubledocker" in docker ...
  Deleting container "doubledocker" ...
  Deleting container "doubledocker-m02" ...
  Removing /home/ubuntu/.minikube/machines/doubledocker ...
  Removing /home/ubuntu/.minikube/machines/doubledocker-m02 ...
  Removed all traces of the "doubledocker" cluster.

Xem thêm về Minikube: Minikube command line reference.

Chap 7. Accessing Minikube

Trong chương này, chúng ta sẽ tìm hiểu về các phương pháp khác nhau để truy cập vào một cụm Kubernetes (một hệ thống quản lý container). Chúng ta có thể sử dụng nhiều loại client ngoài hoặc các tập lệnh (script) tùy chỉnh để truy cập vào cụm của mình cho mục đích quản trị. Chúng ta sẽ khám phá kubectl như một công cụ dòng lệnh (CLI) để truy cập vào cụm Kubernetes Minikube, Kubernetes Dashboard như một giao diện người dùng dựa trên nền tảng web để tương tác với cụm và lệnh curl với thông tin xác thực phù hợp để truy cập cụm thông qua các API.

Đến cuối chương này, bạn sẽ có thể:

So sánh các phương pháp để truy cập một cụm Kubernetes.
Truy cập cụm Kubernetes Minikube bằng kubectl.
Truy cập cụm Kubernetes Minikube từ Dashboard (Bảng điều khiển).
Truy cập cụm Kubernetes Minikube thông qua các API.

Accessing Minikube

Bất kỳ cụm Kubernetes nào đang chạy ổn định đều có thể được truy cập thông qua một trong các phương pháp sau:

Công cụ Dòng lệnh (CLI) và các tập lệnh (script): Cho phép tương tác qua dòng lệnh.
Giao diện Người dùng trên nền tảng Web (Web UI) từ trình duyệt web: Cung cấp giao diện đồ họa, trực quan.
API từ CLI hoặc thông qua lập trình: Truy cập cụm Kubernetes thông qua các yêu cầu API, linh hoạt cho việc tích hợp tự động.

Các phương pháp này có thể được áp dụng cho tất cả các cụm Kubernetes.

Accessing Minikube: Command Line Interface (CLI)

kubectl là giao diện dòng lệnh (CLI) của Kubernetes để quản lý các tài nguyên và ứng dụng trong cụm. Nó rất linh hoạt và dễ dàng tích hợp với các hệ thống khác, do đó có thể được sử dụng độc lập hoặc như một phần trong các tập lệnh (script) và công cụ tự động hóa. Một khi tất cả các thông tin xác thực và điểm truy cập cụm cần thiết đã được cấu hình cho kubectl, nó có thể được sử dụng từ xa ở bất kỳ đâu để truy cập vào một cụm.

Accessing Minikube: Web-based User Interface (Web UI)

Kubernetes Dashboard cung cấp một Giao diện Người dùng trên nền tảng Web (Web UI) để tương tác với cụm Kubernetes, hỗ trợ việc quản lý tài nguyên và các ứng dụng dạng container. Mặc dù không linh hoạt bằng công cụ dòng lệnh (CLI) kubectl, Kubernetes Dashboard vẫn là lựa chọn ưu tiên cho những người dùng chưa thành thạo với giao diện dòng lệnh.

Accessing Minikube: APIs

Thành phần chính của mặt phẳng điều khiển (control plane) Kubernetes là API Server (máy chủ API), chịu trách nhiệm cung cấp các API của Kubernetes. Các API này cho phép người vận hành và người dùng tương tác trực tiếp với cụm. Sử dụng cả công cụ dòng lệnh (CLI) và giao diện người dùng Dashboard, chúng ta có thể truy cập API Server đang chạy trên control plane node để thực hiện các hoạt động khác nhau nhằm điều chỉnh trạng thái của cụm. API Server có thể được truy cập thông qua các điểm cuối (endpoint) của nó bởi các tác nhân (agent) và người dùng sở hữu thông tin xác thực cần thiết.

Dưới đây là biểu diễn sơ đồ dạng cây thư mục của HTTP API trong Kubernetes:

Cây thư mục HTTP API của Kubernetes có thể được chia thành ba nhóm loại độc lập:

Nhóm Core ( /api/v1 ): Nhóm này bao gồm các đối tượng như Pod, Service, Node, Namespace, ConfigMap, Secret, v.v.
Nhóm Tên Riêng (Named Group): Nhóm này bao gồm các đối tượng ở định dạng /apis/$NAME/$VERSION. Các phiên bản API khác nhau hàm ý các mức độ ổn định và hỗ trợ khác nhau:
- Alpha: Có thể bị loại bỏ bất cứ lúc nào mà không cần thông báo trước. Ví dụ: /apis/batch/v2alpha1.
- Beta: Đã được thử nghiệm kỹ lưỡng, nhưng ngữ nghĩa của các đối tượng có thể thay đổi theo cách không tương thích trong một phiên bản beta hoặc bản phát hành ổn định tiếp theo. Ví dụ: /apis/certificates.k8s.io/v1beta1.
- Stable (Ổn định): Xuất hiện trong phần mềm đã phát hành cho nhiều phiên bản tiếp theo. Ví dụ: /apis/networking.k8s.io/v1.
Toàn hệ thống (System-wide): Nhóm này bao gồm các điểm cuối API trên toàn hệ thống, như /healthz, /logs, /metrics, /ui, v.v.

Chúng ta có thể truy cập API Server theo một trong các cách sau:

Trực tiếp bằng cách gọi các điểm cuối API tương ứng.
Sử dụng các công cụ dòng lệnh (CLI).
Sử dụng giao diện Dashboard.

kubectl

kubectl cho phép chúng ta quản lý các cụm Kubernetes cục bộ (local) như cụm Minikube hoặc các cụm từ xa được triển khai trên nền tảng đám mây. Thường thì kubectl được cài đặt trước khi cài đặt và khởi động Minikube, nhưng nó cũng có thể được cài đặt sau bước khởi tạo cụm (cluster bootstrapping).

Bản cài đặt Minikube đã có sẵn công cụ kubectl CLI và có thể sử dụng ngay. Tuy nhiên, có một chút bất tiện vì lệnh kubectl trở thành một lệnh con của lệnh minikube. Người dùng sẽ phải gõ các lệnh dài hơn, chẳng hạn như minikube kubectl -- <lệnh con> <kiểu đối tượng> <tên đối tượng> -o --tùy chọn, thay vì chỉ cần kubectl <lệnh con> <kiểu đối tượng> <tên đối tượng> -o --tùy chọn. Một giải pháp đơn giản là thiết lập bí danh (alias), nhưng khuyến nghị chung là vẫn nên chạy công cụ kubectl CLI như một bản cài đặt độc lập.

Khi được cài đặt riêng, kubectl sẽ tự động nhận cấu hình để truy cập cụm Kubernetes Minikube. Tuy nhiên, trong các thiết lập cụm Kubernetes khác nhau, chúng ta có thể cần cấu hình thủ công các điểm truy cập cụm và chứng chỉ (certificate) cần thiết để kubectl truy cập cụm một cách an toàn.

Có nhiều phương pháp khác nhau có thể được sử dụng để cài đặt kubectl được liệt kê trong tài liệu Kubernetes. Để có kết quả tốt nhất, bạn nên giữ kubectl trong vòng một phiên bản phụ (minor version) so với phiên bản Kubernetes mong muốn. Tiếp theo, chúng ta sẽ mô tả quy trình cài đặt kubectl CLI.

Bạn có thể tìm thấy thông tin chi tiết bổ sung về công cụ dòng lệnh kubectl trong tài liệu chính thức của Kubernetes hoặc GitHub repo của nó.

Link:

Kubernetes documentation

kubectl book

Kubernetes official documentation

GitHub repository

Installing kubectl on Linux

Cách cài đặt kubectl trên Linux:

Hãy làm theo các bước hướng dẫn dưới đây, được trích từ tài liệu cài đặt chính thức.

Tải xuống và cài đặt phiên bản kubectl ổn định mới nhất:

$ curl -LO "https://dl.k8s.io/release/$(curl -L -s \
https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"

$ chmod +x ./kubectl

$ sudo mv ./kubectl /usr/local/bin/kubectl

$ sudo chown root: /usr/local/bin/kubectl

Trong đó, đường dẫn https://dl.k8s.io/release/stable.txt sẽ tự động lấy về số phiên bản Kubernetes ổn định (stable) mới nhất.

LƯU Ý: Để tải xuống và cài đặt một phiên bản cụ thể của kubectl (ví dụ: v1.25.1), hãy sử dụng lệnh sau:

curl -LO https://dl.k8s.io/release/v1.25.1/bin/linux/amd64/kubectl

Kiểm tra phiên bản đã cài đặt:

kubectl version --client

Cấu hình hữu ích sau khi cài đặt: Nên bật tính năng tự động hoàn thành lệnh (autocompletion) của shell cho kubectl. Đối với bash shell, bạn có thể đạt được điều này bằng cách chạy các lệnh sau:

$ sudo apt install -y bash-completion 
$ source /usr/share/bash-completion/bash_completion
$ source <(kubectl completion bash) 
$ echo 'source <(kubectl completion bash)' >>~/.bashrc

Chú ý: Dòng cuối đảm bảo tính năng tự động hoàn thành được kích hoạt mỗi khi bạn mở một terminal mới.

kubectl Configuration File

Để truy cập cụm Kubernetes, công cụ kubectl cần điểm cuối (endpoint) của control plane node và các thông tin đăng nhập phù hợp để có thể tương tác an toàn với API Server đang chạy trên control plane node. Trong quá trình khởi động Minikube, một tệp cấu hình tên là config sẽ được tạo tự động bên trong thư mục .kube (thường được gọi là kubeconfig), nằm trong thư mục home của người dùng. Tệp cấu hình này chứa tất cả các chi tiết kết nối cần thiết cho kubectl. Theo mặc định, chương trình kubectl phân tích tệp này để tìm điểm cuối kết nối của control plane node, cùng với các thông tin đăng nhập cần thiết. Bạn có thể cấu hình nhiều tệp kubeconfig với một chương trình kubectl. Để xem chi tiết kết nối, chúng ta có thể hiển thị nội dung của tệp ~/.kube/config (trên Linux) hoặc chạy lệnh sau (đầu ra đã được lược giản cho dễ đọc):

$ kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /home/student/.minikube/ca.crt
    server: https://192.168.99.100:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /home/student/.minikube/profiles/minikube/client.crt
    client-key: /home/student/.minikube/profiles/minikube/client.key

Tệp kubeconfig bao gồm điểm cuối của API Server server: https://192.168.99.100:8443 và khóa xác thực (authentication key) cũng như dữ liệu chứng chỉ (certificate) của người dùng Minikube.

Sau khi cài đặt kubectl, chúng ta có thể hiển thị thông tin về cụm Kubernetes Minikube bằng lệnh kubectl cluster-info:

$ kubectl cluster-info

Kubernetes master is running at https://192.168.99.100:8443
KubeDNS is running at https://192.168.99.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Bạn có thể tìm thêm thông tin chi tiết về các tùy chọn dòng lệnh của kubectl tại đây: https://kubernetes.io/docs/reference/kubectl/kubectl/

Mặc dù tệp ~/.kube/config được tạo tự động đối với cụm Kubernetes được cài đặt bởi Minikube, điều này có thể không đúng đối với các cụm Kubernetes được cài đặt bởi các công cụ khác. Trong những trường hợp đó, tệp cấu hình phải được tạo thủ công và đôi khi phải được cấu hình lại để phù hợp với các thiết lập mạng và client/server khác nhau.

Kubernetes Dashboard

Kubernetes Dashboard cung cấp giao diện người dùng trên nền tảng web để quản lý cụm Kubernetes. Minikube cài đặt Dashboard như một addon (phần mở rộng), nhưng theo mặc định nó bị vô hiệu hóa. Trước khi sử dụng Dashboard, chúng ta cần kích hoạt addon Dashboard cùng với addon metrics-server, đây là một addon hỗ trợ thu thập số liệu sử dụng (usage metrics) từ cụm Kubernetes. Để truy cập Dashboard từ Minikube, chúng ta có thể sử dụng lệnh minikube dashboard, lệnh này sẽ mở một tab mới trong trình duyệt web hiển thị Kubernetes Dashboard, nhưng chỉ sau khi chúng ta liệt kê, kích hoạt các addon cần thiết và kiểm tra trạng thái của chúng.

$ minikube addons list

$ minikube addons enable metrics-server

$ minikube addons enable dashboard

$ minikube addons list

$ minikube dashboard

LƯU Ý: Trong trường hợp trình duyệt không mở tab mới và không hiển thị Dashboard như mong đợi, hãy kiểm tra lại kết quả đầu ra trong terminal của bạn vì nó có thể hiển thị URL cho Dashboard (cùng với một số thông báo lỗi). Nếu URL không được hiển thị, chúng ta có thể yêu cầu nó hiển thị bằng lệnh sau:

$ minikube dashboard --url

Sao chép và dán URL được hiển thị vào một tab mới trong trình duyệt của bạn. Tùy theo tính năng của trình duyệt, bạn có thể chỉ cần nhấp chuột hoặc nhấp chuột phải vào URL để mở trực tiếp trong trình duyệt.

Sau khi đăng xuất/đăng nhập lại, hoặc sau khi khởi động lại máy tính của bạn, đôi khi lệnh minikube dashboard sẽ hoạt động như mong đợi (tự động mở tab mới trong trình duyệt để hiển thị Dashboard).

APIs with ‘kubectl proxy’

Khi thực hiện lệnh kubectl proxy, công cụ kubectl sẽ xác thực với máy chủ API (API Server) trên control plane node và làm cho các dịch vụ (service) khả dụng trên cổng proxy mặc định 8001.

Các bước:

Chạy lệnh kubectl proxy:

   $ kubectl proxy 
   Starting to serve on 127.0.0.1:8001

Lệnh này sẽ giữ (lock) terminal hiện tại chừng nào proxy còn đang hoạt động, trừ khi chúng ta chạy nó ở chế độ nền (background) bằng cách thêm & vào cuối lệnh kubectl proxy &.

Khi kubectl proxy đang chạy, chúng ta có thể gửi yêu cầu đến API thông qua localhost trên cổng proxy mặc định 8001 (từ một terminal khác, vì proxy giữ terminal đầu tiên khi chạy ở chế độ foreground):

$ curl http://localhost:8001/
{
"paths": [
"/api",
"/api/v1",
"/apis",
"/apis/apps",
......
......
"/logs",
"/metrics",
"/openapi/v2",
"/version"
]}

Với lệnh curl ở trên, chúng ta đã gửi yêu cầu lấy danh sách tất cả các điểm cuối API (API endpoints) từ API Server. Khi bấm vào đường dẫn trong lệnh curl, đầu ra tương tự sẽ được hiển thị trong một tab trình duyệt.

Chúng ta có thể khám phá nhiều tổ hợp đường dẫn khác nhau bằng curl hoặc trực tiếp trong trình duyệt, chẳng hạn như:

localhost:8001/api/v1 : Liệt kê các tài nguyên cốt lõi của Kubernetes (như Pods, Services, Namespaces, v.v.)
localhost:8001/apis/apps/v1 : Liệt kê các tài nguyên liên quan đến ứng dụng (như Deployments, ReplicaSets, v.v…)
localhost:8001/healthz : Kiểm tra tình trạng hoạt động của API Server
localhost:8001/metrics : Cung cấp các số liệu sử dụng (usage metrics) của cụm Kubernetes

APIs with Authentication

Khi không sử dụng kubectl proxy, chúng ta cần tự xác thực với API Server mỗi khi gửi yêu cầu API. Có thể xác thực bằng cách cung cấp Bearer Token khi dùng lệnh curl hoặc cung cấp một bộ khóa (key) và chứng chỉ (certificate).

Bearer Token: Là một mã token truy cập, được tạo bởi máy chủ xác thực (API Server trên control plane node) theo yêu cầu của máy khách (client). Sử dụng token này, client có thể giao tiếp an toàn với Kubernetes API Server mà không cần cung cấp thông tin xác thực bổ sung, từ đó truy cập tài nguyên. Token có thể cần được cung cấp lại cho các yêu cầu truy cập tài nguyên tiếp theo.
RBAC (Role Based Access Control): Cơ chế kiểm soát truy cập dựa trên vai trò trong Kubernetes. Nó cho phép quản trị viên định nghĩa các quyền hạn (permission) cụ thể gắn với các vai trò (role) khác nhau, sau đó gán các role đó cho người dùng hoặc các nhóm đối tượng trong cụm.

Giờ chúng ta sẽ đi tạo một access token cho ServiceAccount mặc định, cấp quyền đặc biệt để truy cập vào thư mục gốc của API (quyền này không cần thiết khi sử dụng kubectl proxy trước đó):

Tạo role đặc biệt: clusterrole được định nghĩa bên dưới.
Gán clusterrole qua clusterrolebinding . (Các khái niệm RBAC, clusterrole, clusterrolebinding sẽ được giải thích kỹ hơn ở các chương sau).

Quyền đặc biệt này chỉ cần thiết để truy cập vào thư mục gốc của API, chứ không bắt buộc để truy cập /api, /apis hoặc các thư mục con khác.

$ export TOKEN=$(kubectl create token default)

$ kubectl create clusterrole api-access-root \
  --verb=get --non-resource-url=/*

$ kubectl create clusterrolebinding api-access-root \
  --clusterrole api-access-root --serviceaccount=default:default

Retrieve the API Server endpoint:

$ export APISERVER=$(kubectl config view | grep https | \
cut -f 2- -d ":" | tr -d " ")

Xác nhận APISERVER đã lưu trữ đúng địa chỉ IP của Control Plane Kubernetes bằng cách thực hiện hai lệnh sau và so sánh đầu ra của chúng:

$ echo $APISERVER

https://192.168.99.100:8443

$ kubectl cluster-info

Kubernetes control plane is running at https://192.168.99.100:8443 ...

Truy cập API Server bằng lệnh curl như sau:

$ curl $APISERVER --header "Authorization: Bearer $TOKEN" --insecure

{
 "paths": [
   "/api",
   "/api/v1",
   "/apis",
   "/apis/apps",
   ......
   ......
   "/logs",
   "/metrics",
   "/openapi/v2",
   "/version"
 ]
}

Chúng ta có thể chạy các lệnh curl bổ sung để lấy thông tin chi tiết về các nhóm API cụ thể như sau. Các lệnh này sẽ hoạt động ngay cả khi không có quyền đặc biệt (được cấp ở bước trước đó):

$ curl $APISERVER/api/v1 --header "Authorization: Bearer $TOKEN" --insecure

$ curl $APISERVER/apis/apps/v1 --header "Authorization: Bearer $TOKEN" --insecure

$ curl $APISERVER/healthz --header "Authorization: Bearer $TOKEN" --insecure

$ curl $APISERVER/metrics --header "Authorization: Bearer $TOKEN" --insecure

Thay vì sử dụng access token, chúng ta có thể trích xuất chứng chỉ của máy khách (client certificate), khóa (client key) và dữ liệu cơ quan cấp chứng chỉ (certificate authority) từ tệp .kube/config. Sau khi trích xuất, chúng có thể được mã hóa (encode) và sau đó được truyền cùng với lệnh curl để xác thực. Lệnh curl mới sẽ tương tự như ví dụ dưới đây. Tuy nhiên, xin lưu ý rằng lệnh ví dụ sẽ chỉ hoạt động với dữ liệu client certificate, client key và certificate authority đã được mã hóa base64, và nó chỉ được cung cấp cho mục đích minh họa.

$ curl $APISERVER --cert encoded-cert --key encoded-key --cacert encoded-ca

Chapter 8. Kubernetes Building Blocks

Trong chương này, chúng ta sẽ khám phá mô hình đối tượng (object model) của Kubernetes và mô tả một số thành phần cơ bản của nó, chẳng hạn như Nodes (nút), Namespaces (không gian tên), Pods, ReplicaSets, Deployments, DaemonSets, v.v. Chúng ta cũng sẽ thảo luận về vai trò thiết yếu của Labels (nhãn) và Selectors (bộ chọn) trong kiến trúc hướng vi dịch vụ (microservice) vì chúng nhóm logic các đối tượng được tách rời với nhau.

Đến cuối chương này, bạn sẽ có thể:

Mô tả mô hình đối tượng Kubernetes.
Thảo luận về các thành phần cơ bản của Kubernetes, ví dụ: Nodes, Namespaces, Pods, ReplicaSets, Deployments, DaemonSets.
Thảo luận về Labels và Selectors.

Kubernetes Object Model

Kubernetes trở nên phổ biến nhờ vào các khả năng quản lý vòng đời ứng dụng (application lifecycle management) tiên tiến, được triển khai thông qua một mô hình đối tượng (object model) phong phú, đại diện cho các thực thể bền vững (persistent entity) khác nhau trong cụm Kubernetes. Những thực thể này mô tả:

Những ứng dụng dạng container nào của chúng ta đang chạy.
Các nút (node) nơi các ứng dụng dạng container được triển khai.
Mức tiêu thụ tài nguyên của ứng dụng.
Các chính sách được gắn với ứng dụng, như chính sách khởi động lại/nâng cấp, khả năng chịu lỗi (fault tolerance), lưu lượng vào/ra (ingress/egress), kiểm soát truy cập, v.v.

Với mỗi đối tượng (object), chúng ta khai báo mục tiêu hoặc trạng thái mong muốn của đối tượng trong phần spec (specification). Hệ thống Kubernetes quản lý phần status (trạng thái) cho các đối tượng, nơi nó ghi lại trạng thái thực tế của đối tượng. Tại bất kỳ thời điểm nào, Control Plane của Kubernetes cố gắng khớp trạng thái thực tế của đối tượng với trạng thái mong muốn của đối tượng. Bản khai báo định nghĩa đối tượng (object definition manifest) phải bao gồm các trường khác chỉ định phiên bản API được tham chiếu (apiVersion), loại đối tượng (kind) và dữ liệu bổ sung hữu ích cho cụm hoặc người dùng cho việc quản lý – phần metadata (siêu dữ liệu).

Ví dụ về các loại đối tượng Kubernetes là Nodes (nút), Namespaces (không gian tên), Pods, ReplicaSets, Deployments, DaemonSets, v.v. Chúng ta sẽ khám phá chúng ở phần sau.

Khi tạo một đối tượng, phần dữ liệu cấu hình đối tượng (spec) phải được gửi đến Kubernetes API Server. Yêu cầu API để tạo một đối tượng phải có phần spec, mô tả trạng thái mong muốn, cũng như các chi tiết khác. Mặc dù API Server chấp nhận định nghĩa đối tượng ở định dạng JSON, thường thì chúng ta cung cấp các bản khai báo định nghĩa ở định dạng YAML, format này sẽ được kubectl chuyển đổi thành dữ liệu tải trọng (payload) ở định dạng JSON và gửi nó đến API Server.

Nodes

Nodes (Nút) là các thực thể ảo được Kubernetes gán cho các hệ thống trong cụm – cho dù là Máy ảo (VM), máy vật lý (bare-metal), Container, v.v. Các thực thể này là duy nhất đối với mỗi hệ thống và được cụm sử dụng cho mục đích theo dõi và thống kê tài nguyên, hỗ trợ quản lý khối lượng công việc (workload) trong toàn bộ cụm.

Mỗi node được quản lý bởi hai tác nhân Kubernetes trên node – kubelet và kube-proxy, đồng thời nó cũng chứa một container runtime (môi trường thực thi container). Container runtime là bắt buộc để chạy tất cả các khối lượng công việc dạng container trên node – bao gồm các tác nhân control plane và khối lượng công việc của người dùng. Các tác nhân node kubelet và kube-proxy chịu trách nhiệm thực hiện tất cả các tác vụ liên quan đến quản lý khối lượng công việc cục bộ – tương tác với runtime để chạy container, giám sát container và tình trạng node, báo cáo sự cố và trạng thái node cho API Server, quản lý lưu lượng mạng đến container.

Dựa trên các chức năng được xác định trước, có hai loại nút riêng biệt – control plane và worker (nút điều khiển và nút làm việc). Một cụm Kubernetes điển hình bao gồm ít nhất một control plane node, nhưng có thể bao gồm nhiều control plane node để đạt được control plane có tính khả dụng cao (Highly Available – HA). Ngoài ra, cụm cũng bao gồm một hoặc nhiều worker node để đảm bảo tài nguyên dự phòng trong cụm. Có những trường hợp cụm tất cả-trong-một (all-in-one) được thiết lập (bootstrapped) thành một nút duy nhất trên một VM, máy vật lý hoặc Container, khi không cần tính khả dụng cao và tài nguyên dự phòng. Đây là các node lai (hybrid) hoặc hỗn hợp, chứa cả tác nhân control plane lẫn workload của người dùng trên cùng một hệ thống. Minikube cho phép thiết lập cụm nhiều node với các node control plane chuyên biệt, tuy nhiên, nếu hệ thống của bạn có giới hạn về tài nguyên, chúng ta vẫn có thể thiết lập dễ dàng một cụm tất cả-trong-một trên một node, và vẫn có thể khám phá hầu hết các chủ đề trong khóa học này, ngoại trừ các tính năng dành riêng cho cụm đa node, chẳng hạn như DaemonSets, mạng đa node, v.v.

Thực thể node được tạo và gán trong quá trình khởi tạo cụm (cluster bootstrapping) bởi công cụ chịu trách nhiệm khởi tạo các tác nhân (agent) của cụm. Minikube sử dụng công cụ khởi tạo kubeadm mặc định để khởi tạo control plane node trong giai đoạn init và phát triển cụm bằng cách thêm các node worker hoặc control plane với giai đoạn join.

Các control plane node chạy các tác nhân control plane, chẳng hạn như API Server, Scheduler, Controller Manager và etcd cùng với các tác nhân node kubelet và kube-proxy, container runtime và các add-on cho mạng container, giám sát, logging, DNS, v.v…

Các worker node chạy các tác nhân kubelet và kube-proxy, container runtime và các add-on cho mạng container, giám sát, logging, DNS, v.v…

Namespaces

Nếu nhiều người dùng và nhóm sử dụng cùng một cụm Kubernetes, chúng ta có thể phân vùng cụm thành các cụm con ảo bằng cách sử dụng Namespaces (không gian tên). Tên của các tài nguyên/đối tượng được tạo bên trong Namespace là duy nhất, nhưng không duy nhất giữa các Namespace trong cụm.

Để liệt kê tất cả các Namespace, chúng ta có thể chạy lệnh sau:

$ kubectl get namespaces

NAME              STATUS       AGE
default           Active       11h
kube-node-lease   Active       11h
kube-public       Active       11h
kube-system       Active       11h

Nói chung, Kubernetes tạo ra bốn Namespace mặc định:

kube-system: Chứa các đối tượng được tạo bởi hệ thống Kubernetes, chủ yếu là các tác nhân control plane.
default: Chứa các đối tượng và tài nguyên được tạo bởi quản trị viên và nhà phát triển. Các đối tượng được gán cho namespace này theo mặc định trừ khi người dùng cung cấp tên Namespace khác.
kube-public: Namespace đặc biệt, không bảo mật và có thể đọc được bởi bất kỳ ai, được sử dụng cho các mục đích đặc biệt như công khai thông tin (không nhạy cảm) về cụm.
kube-node-lease: Namespace mới nhất chứa các đối tượng node lease được sử dụng cho dữ liệu nhịp tim (heartbeat) của node.

Tuy nhiên, cách làm tốt nhất là tạo thêm các Namespace như mong muốn, để ảo hóa cụm và tách biệt người dùng, nhóm phát triển, ứng dụng hoặc các tầng (tier):

$ kubectl create namespace new-namespace-name

Namespaces là một trong những tính năng được mong đợi nhất của Kubernetes, củng cố vị trí dẫn đầu của nó so với các đối thủ, vì nó cung cấp giải pháp cho yêu cầu đa người dùng (multi-tenancy) của các nhóm phát triển doanh nghiệp ngày nay.

Resource quotas (hạn ngạch tài nguyên): Giúp người dùng giới hạn tổng tài nguyên được sử dụng trong Namespace
LimitRanges (giới hạn): Giúp giới hạn tài nguyên được sử dụng bởi các Container và các đối tượng chứa chúng trong một Namespace.

Pods

Pod là đối tượng đơn vị công việc (workload object) nhỏ nhất của Kubernetes. Nó là đơn vị triển khai (deployment) trong Kubernetes, đại diện cho một phiên bản duy nhất của ứng dụng. Pod là một tập hợp logic của một hoặc nhiều container, bao bọc và cô lập chúng để đảm bảo rằng chúng:

Được lên lịch (schedule) cùng nhau trên cùng một máy chủ (host) với Pod..
Chia sẻ chung network namespace (không gian tên mạng), nghĩa là chúng dùng chung một địa chỉ IP duy nhất được gán cho Pod.
Có quyền truy cập để gắn kết (mount) cùng một bộ nhớ ngoài (volume) và các phụ thuộc chung khác.

Pods bản chất là tạm thời (ephemeral) và không có khả năng tự sửa chữa (self-heal). Đó là lý do tại sao chúng được sử dụng với các bộ điều khiển (controller), hoặc các operator (hai khái niệm này có thể dùng tương đương nhau), có nhiệm vụ xử lý việc sao chép (replication), chịu lỗi (fault tolerance), tự sửa chữa cho Pods. Ví dụ về các bộ điều khiển điển hình: Deployment, ReplicaSet, DaemonSet, Job, v.v.

Khi một operator được sử dụng để quản lý ứng dụng, thông số cấu hình (specification) của Pod được lồng bên trong định nghĩa của bộ điều khiển thông qua Pod Template (khuôn mẫu Pod).

Bên dưới là một ví dụ về bản khai báo định nghĩa đối tượng Pod độc lập ở định dạng YAML, không sử dụng operator:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    run: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.22.1
    ports:
    - containerPort: 80

Thứ nhất: Trường apiVersion phải được thiết lập thành v1 cho định nghĩa đối tượng Pod.

Thứ hai: Trường bắt buộc thứ hai là kind chỉ định loại đối tượng là Pod.

Thứ ba: Trường bắt buộc thứ ba metadata chứa tên của đối tượng và các nhãn (label) và chú thích (annotation) tùy chọn.

Thứ tư: Trường bắt buộc thứ tư spec đánh dấu phần đầu của khối định nghĩa trạng thái mong muốn của đối tượng Pod – cũng được gọi là PodSpec. Pod của chúng ta tạo ra một container đơn lẻ chạy image nginx:1.22.1 được kéo từ registry chứa image container, trong trường hợp này là từ Docker Hub. Trường containerPort chỉ định cổng container sẽ được Kubernetes resources (tài nguyên Kubernetes) mở ra để truy cập giữa các ứng dụng hoặc truy cập của client bên ngoài – sẽ được đề cập chi tiết hơn trong chương Services (Dịch vụ). Nội dung của spec được đánh giá cho mục đích lên lịch (scheduling), sau đó kubelet của nút được chọn sẽ chịu trách nhiệm chạy image container với sự trợ giúp của container runtime trên nút đó. Tên và nhãn của Pod được sử dụng cho mục đích theo dõi khối lượng công việc.

Labels

Nhãn (label) là các cặp khóa-giá trị (key-value) được gắn với các đối tượng Kubernetes (ví dụ: Pod, ReplicaSet, Node, Namespace, Persistent Volume). Nhãn được sử dụng để tổ chức và chọn một tập hợp con của các đối tượng, dựa trên các yêu cầu có sẵn. Nhiều đối tượng có thể có chung Nhãn (label). Các nhãn không đảm bảo tính duy nhất cho các đối tượng. Bộ điều khiển (controller) sử dụng nhãn để nhóm các đối tượng tách rời một cách hợp lý, thay vì sử dụng tên hoặc ID của đối tượng.

Trong hình ảnh trên, chúng ta đã sử dụng hai khóa nhãn: app và env. Dựa trên yêu cầu của mình, chúng ta đã cung cấp các giá trị khác nhau cho bốn Pods. Nhãn env=dev về mặt logic sẽ chọn và nhóm hai Pod trên cùng, trong khi nhãn app=frontend về mặt logic sẽ chọn và nhóm hai Pod bên trái. Chúng ta có thể chọn một trong bốn Pods – phía dưới bên trái, bằng cách chọn hai nhãn: app=frontend AND env=qa.

Label Selectors

Các bộ điều khiển (controller), hoặc các operator, và Services (Dịch vụ) sử dụng bộ chọn nhãn (label selector) để chọn một tập hợp con của các đối tượng. Kubernetes hỗ trợ hai loại Bộ chọn:

Bộ chọn dựa trên phép so sánh bằng (Equality-Based Selectors): Cho phép lọc các đối tượng dựa trên khóa và giá trị của nhãn (Label). Sự trùng khớp được thực hiện bằng cách sử dụng các toán tử =, == (có thể dùng thay thế cho nhau) hoặc != (không bằng). Ví dụ: với env==dev hoặc env=dev chúng ta chọn các đối tượng có khóa nhãn env được đặt thành giá trị dev.
Bộ chọn dựa trên tập hợp (Set-Based Selectors): Cho phép lọc các đối tượng dựa trên một tập hợp các giá trị. Chúng ta có thể sử dụng các toán tử in (trong tập), notin (không trong tập) cho các giá trị nhãn (Label value) và các toán tử exists (tồn tại), does not exist (không tồn tại) cho khóa nhãn (Label key). Ví dụ:
- Với env in (dev,qa) chúng ta chọn các đối tượng có nhãn env được đặt thành dev hoặc qa.
- Với !app chúng ta chọn các đối tượng không có khóa nhãn app.

ReplicationControllers

Mặc dù không còn được khuyến nghị sử dụng, ReplicationController là một operator phức tạp, đảm bảo một số lượng bản sao (replica) cụ thể của Pod đang chạy tại bất kỳ thời điểm nào, bằng cách liên tục so sánh trạng thái thực tế với trạng thái mong muốn của ứng dụng được quản lý. Nếu có nhiều Pod hơn số lượng mong muốn, ReplicationController ngẫu nhiên loại bỏ số lượng Pod vượt quá, và, nếu có ít Pods hơn số lượng mong muốn, thì ReplicationController yêu cầu tạo thêm Pod cho đến khi số lượng thực tế khớp với số lượng mong muốn. Nói chung, chúng ta không triển khai Pod độc lập, vì nó sẽ không thể tự khởi động lại nếu bị chấm dứt do lỗi vì Pod thiếu tính năng tự sửa lỗi (self-healing) mà Kubernetes hứa hẹn. Phương pháp được khuyến nghị là sử dụng một số loại operator (bộ điều khiển) để chạy và quản lý Pod.

Ngoài việc sao chép (replication), operator ReplicationController còn hỗ trợ cập nhật ứng dụng.

Tuy nhiên, bộ điều khiển được khuyến nghị mặc định là Deployment, cấu hình nên một bộ điều khiển ReplicaSet để quản lý vòng đời của Pod ứng dụng.

ReplicaSets (1)

ReplicaSet là một phần kế thừa từ ReplicationController thế hệ tiếp theo, vì nó thực hiện các chức năng sao chép (replication) và tự sửa lỗi (self-healing) của ReplicationController. ReplicaSet hỗ trợ cả bộ chọn dựa trên phép so sánh bằng (equality-based) và bộ chọn dựa trên tập hợp (set-based), trong khi ReplicationController chỉ hỗ trợ bộ chọn dựa trên phép so sánh bằng.

Khi chỉ chạy một phiên bản duy nhất của ứng dụng, luôn có nguy cơ ứng dụng đó gặp sự cố bất ngờ, hoặc toàn bộ máy chủ chứa ứng dụng đó bị lỗi. Nếu chỉ dựa vào một phiên bản ứng dụng duy nhất, sự cố như vậy có thể ảnh hưởng xấu đến các ứng dụng, dịch vụ hoặc máy khách khác. Để tránh các sự cố hỏng hóc (failure) tiềm ẩn đó, chúng ta có thể chạy nhiều phiên bản của ứng dụng song song, do đó đạt được tính khả dụng cao. Vòng đời của ứng dụng được xác định bởi Pod sẽ được giám sát bởi một bộ điều khiển (controller) – ReplicaSet. ReplicaSet giúp chúng ta mở rộng (scale) số lượng Pod chạy một image container ứng dụng cụ thể. Việc mở rộng có thể được thực hiện thủ công hoặc bằng cách sử dụng bộ tự động mở rộng (autoscaler).

Bên dưới chúng ta mô tả hình ảnh một ReplicaSet, với số lượng bản sao (replica) được đặt thành 3 cho một khuôn mẫu Pod cụ thể. Pod-1, Pod-2, và Pod-3 giống hệt nhau, chạy cùng một image container ứng dụng, được nhân bản từ cùng một khuôn mẫu Pod. Hiện tại, trạng thái thực tế khớp với trạng thái mong muốn. Tuy nhiên, hãy nhớ rằng mặc dù ba bản sao Pod được cho là giống hệt nhau – chạy một thể hiện (instance) của cùng một ứng dụng, cùng cấu hình, chúng vẫn khác biệt nhau về danh tính – tên Pod, địa chỉ IP, và đối tượng Pod đảm bảo rằng ứng dụng có thể được đặt riêng lẻ vào bất kỳ nút worker nào của cụm do kết quả của quá trình lên lịch (scheduling).

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: guestbook
  template:
    metadata:
      labels:
        app: guestbook
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

ReplicaSets (2)

Hãy cùng tiếp tục với ví dụ ReplicaSet trước đó và giả sử rằng một trong các Pod bị buộc phải chấm dứt bất ngờ (do không đủ tài nguyên, timeout, node chứa nó gặp sự cố, v.v…), khiến trạng thái thực tế không còn khớp với trạng thái mong muốn.

ReplicaSet sẽ phát hiện ra trạng thái thực tế không còn khớp với trạng thái mong muốn và kích hoạt yêu cầu tạo thêm một Pod, do đó đảm bảo trạng thái thực tế một lần nữa khớp với trạng thái mong muốn.

ReplicaSet có thể được sử dụng độc lập như bộ điều khiển Pod nhưng chúng chỉ cung cấp một tập hợp các tính năng hạn chế. Deployments, loại bộ điều khiển được khuyến nghị sử dụng cho việc dàn xếp (orchestration) các Pod, cung cấp một tập hợp các tính năng bổ sung. Deployment quản lý việc tạo, xóa và cập nhật Pod. Deployment sẽ tự động tạo ra một ReplicaSet, sau đó ReplicaSet này mới tạo ra Pod. Chúng ta không cần quản lý ReplicaSet và Pod một cách riêng biệt, Deployment sẽ quản lý chúng thay cho ta.

Chúng ta sẽ xem xét kỹ hơn về Deployment ở phần tiếp theo.

Deployments (1)

Đối tượng Deployment cung cấp các bản cập nhật mang tính khai báo (declarative) cho Pod và ReplicaSet. DeploymentController là một phần của trình quản lý bộ điều khiển (controller manager) trên control plane node, và với vai trò là một bộ điều khiển, nó đảm bảo rằng trạng thái hiện tại luôn khớp với trạng thái mong muốn của ứng dụng dạng container đang chạy. Nó cho phép cập nhật và khôi phục (rollback) ứng dụng liền mạch, được biết đến như chiến lược RollingUpdate mặc định, thông qua các hoạt động rollout (triển khai) và rollback (khôi phục), đồng thời trực tiếp quản lý các ReplicaSet của nó để mở rộng quy mô ứng dụng. Nó cũng hỗ trợ một chiến lược cập nhật khác ít phổ biến hơn, được gọi là Recreate (tái tạo).

Dưới đây là một ví dụ về bản khai báo định nghĩa đối tượng Deployment ở định dạng YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      labels:
        app: nginx-deployment
    spec:
      containers:
      - name: nginx
        image: nginx:1.20.2
        ports:
        - containerPort: 80

Trường apiVersion: Trường bắt buộc đầu tiên này chỉ định điểm cuối API (API endpoint) trên API Server mà chúng ta muốn kết nối; nó phải khớp với phiên bản API hiện có cho loại đối tượng được định nghĩa.

Trường kind: Trường thứ hai bắt buộc, chỉ định loại đối tượng – trong trường hợp của chúng ta, nó là Deployment, nhưng nó cũng có thể là Pod, ReplicaSet, Namespace, Service, v.v.

Trường metadata: Trường thứ ba bắt buộc, chứa thông tin cơ bản của đối tượng, như tên (name), chú thích (annotation), nhãn (label), namespace, v.v.

Trường spec: Trường thứ tư bắt buộc này đánh dấu phần đầu của khối định nghĩa trạng thái mong muốn của đối tượng Deployment. Trong ví dụ, chúng ta đang yêu cầu 3 replica, tức là 3 phiên bản của Pod, đang chạy tại bất kỳ thời điểm nào. Các Pod được tạo bằng cách sử dụng khuôn mẫu Pod (Pod Template) được định nghĩa trong spec.template. Một đối tượng được lồng bên trong (nested object), chẳng hạn như Pod là một phần của Deployment, sẽ giữ lại metadata và spec của nó, và bỏ đi apiVersion và kind – cả hai đều được thay thế bằng template (khuôn mẫu). Trong spec.template.spec, chúng ta định nghĩa trạng thái mong muốn của Pod. Pod của chúng ta tạo ra một container đơn lẻ chạy image nginx:1.20.2 từ Docker Hub.

Khi đối tượng Deployment được tạo, hệ thống Kubernetes sẽ đính kèm trường status vào đối tượng và điền vào đó tất cả các trường trạng thái cần thiết.

Ví dụ về Deployment và ReplicaSet:

Trong ví dụ sau, một Deployment mới tạo ra ReplicaSet A, sau đó tạo ra 3 Pod, với mỗi Pod Template được cấu hình để chạy một container image nginx:1.20.2. Trong trường hợp này, ReplicaSet A được liên kết với nginx:1.20.2 đại diện cho một trạng thái của Deployment. Trạng thái cụ thể này được ghi lại là Bản sửa đổi (Revision) 1.

Theo thời gian, chúng ta cần cập nhật ứng dụng được quản lý bởi đối tượng Deployment. Giả sử chúng ta muốn thay đổi Pod Template và cập nhật ảnh container từ nginx:1.20.2 lên nginx:1.21.5. Deployment sẽ kích hoạt một ReplicaSet B mới cho phiên bản ảnh container mới 1.21.5 và sự liên kết này đại diện cho trạng thái mới được ghi lại của Deployment, Revision 2 (Bản sửa đổi 2). Quá trình chuyển đổi liền mạch giữa hai ReplicaSet, từ ReplicaSet A với ba Pod phiên bản 1.20.2 sang ReplicaSet B mới với ba Pod phiên bản 1.21.5, hay từ Revision 1 sang Revision 2, được gọi là cập nhật rolling update của Deployment.

Một vài điểm cần lưu ý thêm về cập nhật rolling update:

Deployment theo dõi cả ReplicaSet A và ReplicaSet B cho đến khi tất cả các Pod mong muốn của ReplicaSet B (thường là tất cả Pod) đang chạy và ổn định. Khi đó, Deployment sẽ loại bỏ các Pod cũ từ ReplicaSet A theo cách được kiểm soát (rolling update) để đảm bảo tính khả dụng cao của ứng dụng.
Cập nhật rolling update là chiến lược mặc định của Deployment và nó giúp giảm thiểu thời gian chết (downtime) của ứng dụng trong suốt quá trình cập nhật.

Deployments (2)

Rolling update (cập nhật luân phiên) được kích hoạt khi chúng ta cập nhật các thuộc tính cụ thể của Pod Template trong Deployment. Trong khi các thay đổi có chủ đích như cập nhật image container, cổng container (container port), volume và điểm gắn kết (mount) sẽ kích hoạt một Revision (Bản sửa đổi) mới, các hoạt động khác có bản chất động, ví dụ như mở rộng quy mô hoặc thêm label cho Deployment, không kích hoạt rolling update, do đó không làm thay đổi số Revision.

Khi rolling update đã hoàn tất, Deployment sẽ hiển thị cả ReplicaSet A và ReplicaSet B, trong đó A được mở rộng xuống 0 (zero) Pod và B được mở rộng lên 3 Pods. Đây là cách Deployment ghi lại các cấu hình trạng thái trước đó của nó dưới dạng các Revision (Bản sửa đổi).

Một khi ReplicaSet B và 3 Pods phiên bản 1.21.5 của nó đã sẵn sàng, Deployment bắt đầu quản lý chúng một cách chủ động. Tuy nhiên, Deployment vẫn giữ lại cấu hình các trạng thái trước đó được lưu dưới dạng Revision (bản sửa đổi), đóng vai trò then chốt trong khả năng rollback (khôi phục) của Deployment – cho phép quay trở về trạng thái cấu hình được biết đến trước đó. Trong ví dụ của chúng ta, nếu hiệu suất của nginx:1.21.5 không đạt yêu cầu, Deployment có thể được rollback (khôi phục) về Revision trước đó, trong trường hợp này là từ Revision 2 quay lại Revision 1 đang chạy nginx:1.20.2.

DaemonSets

Đây là bản dịch tiếng Việt của đoạn văn trên về DaemonSet trong Kubernetes, kèm theo một số diễn giải thêm cho rõ về các khái niệm liên quan:

DaemonSet là các operator được thiết kế để quản lý các tác nhân (agent) trên node. Chúng giống với các operator ReplicaSet và Deployment khi quản lý việc tạo bản sao Pod và cập nhật ứng dụng, nhưng DaemonSet có một đặc điểm riêng: đảm bảo chỉ có một bản sao (replica) của Pod được đặt trên mỗi node, trên tất cả các node. Ngược lại, ReplicaSet và Deployment theo mặc định không kiểm soát việc lên lịch (scheduling) và bố trí (placement) nhiều bản sao Pod trên cùng một node.

Các loại tác vụ thông thường sử dụng DaemonSet:

Thu thập dữ liệu giám sát từ tất cả các node: DaemonSet đảm bảo một pod giám sát luôn chạy trên tất cả các node
Chạy các daemon lưu trữ, mạng hoặc proxy trên tất cả các node: Chẳng hạn, các daemon này giúp thiết lập mạng liên lạc giữa các pod trên các node khác nhau.
Các tác vụ quan trọng khác, cần đảm bảo chạy trên tất cả các node

Khả năng tự động hóa của DaemonSet:

Khi một node mới được thêm vào cụm, một Pod từ một DaemonSet nhất định sẽ tự động được đặt trên node đó. Quá trình này được điều khiển tự động bởi DaemonSet thay vì bởi Scheduler (bộ lên lịch) mặc định.
Khi bất kỳ một node nào bị lỗi hoặc bị xóa khỏi cụm, các Pod tương ứng được vận hành bởi DaemonSet cũng sẽ được dọn dẹp (garbage collected).
Nếu DaemonSet bị xóa, tất cả các bản sao Pod mà nó đã tạo cũng bị xóa theo.

Chú ý về scheduling đối với DaemonSet: Việc bố trí (placement) các DaemonSet Pod vẫn bị chi phối bởi các thuộc tính lên lịch, có thể giới hạn việc đặt Pod chỉ trên một tập hợp con của các node trong cụm. Điều này có thể đạt được với sự trợ giúp của các thuộc tính lên lịch Pod như nodeSelectors, các quy tắc node affinity (thân thiện node), taint và toleration. Các cơ chế này đảm bảo rằng Pod của DaemonSet chỉ được đặt trên các node cụ thể, chẳng hạn chỉ trên các node worker nếu được yêu cầu. Tuy nhiên, Scheduler mặc định có thể tiếp quản quá trình lên lịch nếu một tính năng tương ứng được kích hoạt, cho phép sử dụng các quy tắc node affinity.

Ví dụ về định nghĩa DaemonSet: Dưới đây là một ví dụ về bản khai báo định nghĩa đối tượng DaemonSet ở định dạng YAML:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-agent
  namespace: kube-system
  labels:
    k8s-app: fluentd-agent
spec:
  selector:
    matchLabels:
      k8s-app: fluentd-agent
  template:
    metadata:
      labels:
        k8s-app: fluentd-agent
    spec:
      containers:
      - name: fluentd-agent
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2

Services

Ứng dụng dạng container được triển khai trong cụm Kubernetes có thể cần kết nối đến các ứng dụng container khác, hoặc có thể cần phải truy cập được bởi các ứng dụng khác, hoặc thậm chí bởi các client bên ngoài. Điều này trở thành khó khăn bởi vì container không tự mở cổng (port) ra mạng của cụm, và nó cũng không thể tự được khám phá (discoverable). Một giải pháp đơn giản là ánh xạ cổng (port mapping) như được cung cấp bởi các máy chủ container thông thường. Tuy nhiên, do sự phức tạp của framework Kubernetes, việc ánh xạ cổng đơn giản như vậy lại không “đơn giản” tí nào. Giải pháp thực tế trong Kubernetes phức tạp hơn nhiều, với sự tham gia của tác nhân kube-proxy node, IP tables, các quy tắc định tuyến, máy chủ DNS của cụm; tất cả các thành phần này cùng nhau thực hiện một cơ chế cân bằng tải cấp vi mô (micro-load balancing) để mở cổng của container ra mạng lưới của cụm, thậm chí ra thế giới bên ngoài nếu cần. Cơ chế này được gọi là Service (Dịch vụ), và nó là phương thức được khuyến nghị để mở ứng dụng dạng container ra mạng Kubernetes. Lợi ích của Kubernetes Service trở nên rõ ràng hơn khi mở một ứng dụng với nhiều bản sao (replica), khi nhiều container chạy cùng một image cần mở cùng một cổng. Đây là tình huống mà việc ánh xạ cổng đơn giản của một máy chủ container sẽ không hoạt động, nhưng Service lại không gặp vấn đề gì khi triển khai một yêu cầu phức tạp như vậy.

[Note] Khóa học Kubernetes cơ bản (tiếng Việt) – Phần 2 – Chap 5 -> 8

Table of contents

Chapter 5. Installing Kubernetes

Chapter Overview

Learning Objectives

Kubernetes Configuration

Infrastructure for Kubernetes Installation

Installing Local Learning Clusters

Installing Production Clusters with Deployment Tools

Production Clusters from Certified Solutions Providers

Kubernetes on Windows

Chapter 6. Minikube – Installing Local Kubernetes Clusters

Chapter Overview

Learning Objectives

What Is Minikube?

Requirements for Running Minikube

Installing Minikube on Linux

Advanced Minikube Features (1)

Advanced Minikube Features (2)

Chap 7. Accessing Minikube

Accessing Minikube

Accessing Minikube: Command Line Interface (CLI)

Accessing Minikube: Web-based User Interface (Web UI)

Accessing Minikube: APIs

kubectl

Installing kubectl on Linux

kubectl Configuration File

Kubernetes Dashboard

APIs with ‘kubectl proxy’

APIs with Authentication

Chapter 8. Kubernetes Building Blocks

Kubernetes Object Model

Nodes

Namespaces

Pods

Labels

Label Selectors

ReplicationControllers

ReplicaSets (1)

ReplicaSets (2)

Deployments (1)

Deployments (2)

DaemonSets

Services