Learn DevOps

Học K8s concepts

Hải Yến Trịnh's photo
Hải Yến Trịnh
·

20 min read

Table of contents

Tổng quan K8s

Quay lại trước đây

Deployment evolution

Tại sao K8s?

  • K8s cung cấp 1 framework để run distributed system resiliently.

K8s cung cấp:

  • Service discovery and load balancing: K8s có thể expose DNS name hoặc sử dụng IP address. Nếu traffic tới một container nhiều, K8s sẽ có thể load balance và distribute network traffic để deployment stable.

  • Storage orchestration: Cho phép tự động mount 1 storage system tùy ý.

  • Automated rollouts và rollbacks: Có thể mô tả desired state và K8s sẽ thay đổi trạng thái hiện tại để đạt được desired state.

  • Automatic bin packaging: Cho K8s biết bao nhiêu CPU và RAM mỗi container cần và K8s sẽ fit container vào nodes để best use of your resources.

  • Self-healing: K8s restart container nếu như chúng fail, thay thế container, kill containers không phản hồi với user-defined healthcheck, và không advertise chúng với clients cho tới khi chúng sẵn sàng

  • Secret and configuration management: L8s cho phép lưu trữ và quản lý dữ liệu nhạy cảm ví dụ như password, token,.. Bạn có thể deploy và update secrets và application configuration mà không cần phải rebuild lại container images, cũng không expose secrets trong stack configuration.

  • Batch execution: K8s có thể quản lý batch và CI workloads, thay thế các containers bị fail nếu cần thiết

  • Horizontal scaling: Scale application up và down với các câu lệnh đơn giản, với UI hoặc một cách tự động theo mức độ sử dụng CPU

  • IPv4/IPv6 dual-stack: Phân bổ IPv4 và IPv6 cho các Pods và Services

  • Designed for extensbility: Thêm features và K8s cluster mà không cần phải thay đổi upstream source code.

K8s components

Components of Kubernetes

Control panel components

  • kube-apiserver: K8s API server: frontend cho K8s control panel. kube-apiserver: implemtation của K8s API server, scale horizontally, có thể run nhiều instance kube-apiserver và balance traffic giữa các instance này

  • etcd: consistent and HA key value store, sử dụng như k8s backing store cho cluster data. Cần đảm bảo rằng có backup plan cho data khi sử dụng etcd làm backing store.

  • kube-scheduler: watches các pods mới tạo với assigned note, và chọn node để chạy pod. Các yếu tố quyết định scheduling: individual và collective resource requirements, hardware/software/policy constraints, affinity và anti-affinity specifications, data locality, inter-workload interference, và deadlines.

  • kube-controller-manager: Control plane component chạy controller processes. Theo logic, mỗi controller sẽ là 1 process riêng biệt, nhưng để giảm sự phức tạp sẽ được compiled vào thành 1 binary duy nhất và chạy trong 1 process. Có nhiều loại controller, 1 số ví dụ:

    • Node controller: noticing và responding khi nodes chết

    • Job controller: Watch job objects và represent one-off tasks, sau đó tạo pods để run các tasks

    • EndpointSlice controller: Populate EndpointSlice objects (cung cấp 1 link giữa Services và Pods)

    • ServiceAccount controller: tạo default ServiceAccounts cho các namespaces mới.

  • Cloud-controller-manager: embed cloud-specific logic. Cloud controller manager cho phép link cluster vài cloud provider's API, và separate các components interact với cloud platform với các components chỉ interact trong cluster. Các controller sau có thể có cloud provider dependencies:

    • Node controller: Checking cloud provider để xác định xem một node đã bị delete sau khi stop responding chưa

    • Route controller: Để set up các routes trong underlying cloud infrastructure

    • Service controller: Để tạo, update và delete cloud provider load balancers

Node components

  • kubelet: agent chạy trên mỗi node của cluster. Nó đảm bảo rằng containers đang được chạy trong một Pod. Kubelet dựa vào 1 set các PodSpecs đươc cung cấp thông qua nhiều cơ chế và đảm bảo rằng contrainers được mô tả trong các PodSpecs này đang chạy và healthy. kubelet không quản lý các container không tạo ra với K8s.

  • kube-proxy: Là một network proxy chạy trên mỗi node trong cluster, implementing K8s Service concept. kube-proxy maintains network rule trên mỗi node của cluster. Những network rule này cho phép network communication tới Pods từ network sessions trong hoặc ngoài cluster. kube-proxy sử dụng OS packet filtering layer nếu như có available. Nếu không có, kube-proxy sẽ tự forwards traffic.

  • Container runtime: component cho phép k8s chạy các containers một cách hiệu quả. Nhiệm vụ là quản lý execution và lifecycle của containers trong k8s env. K8s hỗ trợ containerd, cri-o, và tất cả các triển khai của K8s CRI (container runtime interface)

Addons

Addons sử dụng các K8s resources (DaemonSet, Deployment, etc) để implement cluster features. Bởi vì những addons này sử dụng cluster-level features, namespaced resources cho addons thuộc về kube-system namespace.

DNS

Trong khi những addons khác không phải là strictly required, thì tất cả các K8s cluster đều cần cluster DNS, bởi vì sẽ có rất nhiều examples phụ thuộc vào nó.

Cluster DNS là một DNS server, bổ sung cho DNS server(s) trong env, dùng để serve các DNS recors cho K8s services.

Web UI (Dashboard)

Cho phép người dùng quản lý và troubleshoot applications đang chạy trong cluster cũng như chính cluster.

Container resource monitoring

Records generic time-series metrics about containers in a central DB, and provides a UI for browsing that data.

Cluster-level logging

Chịu trách nhiệm lưu trữ container logs vào một log store trung tâm với search/browsing interface.

Network plugins

Là software components implement the CNI specification. Nó có trách nhiệm allocate IP address cho pods và cho phép chúng communicate với các pods khác trong cluster.

K8s API

Core của K8s control plane là API server. API server expose 1 HTTP API cho phép người dùng, và các thành phần khác của cluster, các external components giao tiếp với nhau.

Hầu hết các hành động có thể được thực thi bằng kubectl hoặc các tools như kubeadm. Tuy nhiên, bạn cũng có thể truy cập API trực tiếp bằng REST calls.

Nên xem xét sử dung client libs nếu đang viết 1 app sử dụng k8s API: https://kubernetes.io/docs/reference/using-api/client-libraries/

OpenAPI specification

OpenAPI v2

OpenAPI v3

API Discovery

/api và /apis endpoints.

Aggregated Discovery

Beta support cho aggredated discovery, publishing tất cả các resources supported bởi cluster thông qua 2 endpoints: /api và /apis.

Có thể access bằng các request vào endpoints với Accept header chỉ định aggregated discovery resource: Accept: application/json;v=v2beta1;g=apidiscovery.k8s.io;as=APIGroupDiscoveryList

API groups và versioning

  • Versioning được chia ở API level hơn là resource hay fielđ level

  • K8s implement API groups có thể enable hoặc disable.

API changes

Nếu bạn sử dụng beta API version, bạn sẽ cần chuyển sang stable API khi API graduaté.

API extension

K8s API có thể được extended theo 1 trong 2 cách:

K8s architecture

Components of Kubernetes

Nodes

K8s chạy workloads bằng cách đặt các containers vào Pods chạy trên các Nodes.

Mỗi nodes được quản lý bởi control plane và bao gồm services cần thiết để chạy Pods.

Các thành phần của một node bao gồm: kubelet, 1 container runtime và kube-proxy.

Management

Có 2 cách để node được add vào API server:

  • kubelet trên node self-register với control panel

  • Bạn add Node object manually

Sau khi tạo Node object, hoặc kubelet trên một node self-registers, control panel kiểm tra xem Node object có valid không. VD: Nếu bạn tạo Node từ json manifest sau:

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

K8s tạo ra Node object internally. K8s checks kubelet đã được register với API server có match với metadata.name file của Node không. Nếu node là healthy, thì có thể chạy đc Pod. Nếu không, node đó sẽ bị ignore khỏi các cluster activity cho đến khi nó healthy.

Node name uniqueness

  • Name định nghĩa 1 Node

  • 2 Node không thể có cùng 1 tên

  • K8s assume 1 instance sử dụng cùng tên sẽ có cùng state và attributes. ĐIều này sẽ dẫn tới inconsistencies nếu 1 instance được modified mà không đổi tên. Nếu node cần phải thay thế hoặc updated, node hiện tại cần phải được remove khỏi API server và add lại sau update.

Self- registration của nodes

Khikubelet tag --register-node là true (default), kubelet sẽ cố gắng register chính nó với AI server. Pattern này là pattern đc ưu tiên

Để có thể self-registration, kubelet được start với các options:

  • --kubeconfig - Path dẫn tới credentials để authenticate với API servcer.

  • --cloud-provider Cách để nói chuyện với cloud provider để đọc metadata.

  • --register-node Tự động register với API server

  • --register-with-taints Register node với given list of taint (comma seperated key=value:effect). No-of if register-node is false

  • --node-ip Optional comma-separated list IP cho node. Bạn chỉ có thể chỉ định 1 address cho mỗi family. Nếu không chỉ định argument này, kubelet sử dụng IPv4 default của node, nếu có; nếu node không có IPv4 thì kubelet sẽ sử dụng IPv6 default của node.

  • --node-labels Labels để add vào khi register node vào cluster

  • --node-status-update-frequency Specify how often kubelet posts node status to the API server.

Khi node authorization mode và NodeRestriction admission plugin được enable, kubelets chỉ được authorized để tạo/modify their own Node resource.

Manual Node administration

Bạn có thể tạo và chỉnh sửa Node object bằng cách sử dụng kubectl.

Nếu muốn chỉnh sửa Node object manually, set kubelet flag --register-node=false

Bạn có thể chỉnh sửa Node objects mà không quan tâm tới setting của --register-node. Ví dụ, bạn có thể set label trên 1 existing Node hoặc mark nó là unschedulable.

Bạn có thể sử dụng labels trên Node cùng với node selectors on Pods để control scheduling. Ví dụ, bạn có thể constrain một Pod chỉ eligible to run on a subset các available nodes.

Đánh dấu 1 node là unschedulable ngăn scheduler đặt các pods mới trên Node đó nhưng không ảnh hưởng tới các Pods hiện tại trên Node. Điều này sẽ có thể được dùng như bước chuẩn bị trước khi reboot 1 node hay các maintenace khác.

Để có thể đánh dấu 1 node là unschedulable, chạy:

kubectl cordon $NODENAME

Node status

Một Node status bao gồm các thông tin sau:

  • Address

  • Conditions

  • Capacity và Allocation

  • Info

Để xem:

kubectl describe node <insert-node-name-here>

Node heartbeats

Giúp cluster xác định availability của mỗi node, và take action khi node failure xảy ra.

Có 2 loại:

  • Update vào .status của 1 Node

  • Lease objects trong kube-node-lease namespace. Mỗi node có 1 Lease object đi kèm.

Node controller

Là k8s control plane component giúp quản lý nhiều aspect của 1 node.

Node controller có nhiều roles trong vòng đời của node. Đầu tiên là assigning CIDR block cho node khi nó được registered (nếu CIDR assignment được bật)

Thứ hai, nó sẽ giữ node controller's internal list các nodes up to date với cloud provider list các available machines. Khi chạy trên cloud env,và 1 node unhealthy, node controller hỏi cloud provider xem 1 VM cho node đó còn available. Nếu không, node controller xóa node khỏi list of nodes của nó.

Thứ ba, là monitoring nodes' health. Node controller sẽ có trách nhiệm:

  • Trong TH một node trở thành unreachable, update Ready condition trong Node's .status field. Trong TH này node controller sets Ready thành Unknown

  • Nếu nodes vẫn tiếp tục unreachable, trigger API-intitiated eviction cho tất cả các Pods trên unreachable node. Theo mặc định, node controller đợi 5 mins từ lúc đánh dấu 1 node là unknown cho tới khi submit eviction request đầu tiên.

Mặc định, node controller kiểm tra state mỗi node 5s/lần. Khoảng thời gian này có thể thay đổi bằng --node-monitor-period flag trên kube-controller-manager components.

Rate limits on evictions

Trong nhiều TH, node controller giới hạn eviction rate vào --node-eviction-rate (default 0.1) mỗi giây, có nghĩa là nó sẽ không evict pods from more than 1 node per 10 seconds.

Hành động Node eviction thay đổi khi một node trong AZ trở thành unhealthy. Node controller kiểm tra số % node trên 1 zone là unhealthy at the same time:

  • Nếu unhealthy nodes ít nhất --unhealthy-zone-threshold (default 0.55) thì eviction rate giảm.

  • Nếu cluster nhỏ (Có nhỏ hơn hoặc bằng --large-cluster-size-threshold nodes (default 50), evictions sẽ dừng

    • Mặt khác, eviction rate sẽ giảm tới --secondary-node-eviction-rate (default 0.01)/s

Nguyên nhân các policy này được implement mỗi AZ là bởi vì 1 AZ có thể trở thành partioned from the control plane while the others remain connected. Nếu cluster không span multiple cloud provider AZ, cơ chế eviction sẽ khôn take per-zone unavailability into account.

Một nguyên nhân chính cho việc spreading node across AZ is so that the workload can be shifted to healthy zones khi cả 1 zones down. Do đó, nếu tất cả các node ỏa 1 zone là unhealthy, thì node controller sẽ evicts at the normal rate of --node-eviction-rate. Một corner case khác là khi tất cả các zones đều hoàn toàn unhealthy, node controller assumes rằng có problem với connectivity giữa control plane và nodes, và sẽ không thực hiện bất kỳ evictions nào.

Node controller cũng chịu trách nhiệm evicting pods chạy trên các nodes với NoExecute tains, trừ khi các pods tolerate that taint.

Node controller cũng add taints corresponding to node problems như node unreachable và not ready. Điều này sẽ có ý nghĩa là scheduler sẽ không đặt các Pods trên unhealthy nodes.

Resource capacity tracking

Node objects track các thông tin về Node's resource capacity: ví dụ, số lượng memory available và số lượng CPUs. Node self register sẽ report capacity trong quá trình register. Nếu add node manually, bạn sẽ cần set node's capacity information khi bạn add.

K8s scheduler giúp đảm bảo có đủ tài nguyên cho tất cả các Pods trong 1 node. Scheduler kiểm tra tổng số requests của tất cả các containers quản lý với kubelet.

Node toploigy

Nếu bạn enable TopologyManager feature gate, kubelet sẽ sử dụng các topology hints khi making resource assignment decisions.

Graceful node shutdown

  • Kubelet đảm bảo pods theo normal pod termination process trong quá trình node shutdown. Trong khi node shutdown, kubelet không nhận Pods mới (kể cả TH những Pods này đã được bound vào node).

  • Graceful shutdown feature depends on systemd vì nó tận dụng systemd inhibitor locks để delay node shutdown với 1 given duration.

  • Graceful shutdown controlled với GracefulNodeShutdown feature gate, mặc định enable trong 1.21.

  • Mặc định, cả 2 options shutdownGracePeriod và shutdownGracePeriodCriticalPods đều set là 0, do đó sẽ không activate tính năng graceful node shutdown. Để activate, 2 kubelet config settings cần phải được configure phù hợp và set thành non-zero values.

  • Khi systemd detects hoặc notifies node shutdown, kubelet sets a NotReady condition trên Node, với reason là "node is shutting down". kube-scheduler sẽ không schedule bất cứ Pods nào trên affected node; các third-party scheduler cũng theo logic tương tự.

  • kubelet cũng reject Pods trong phase PodAdmission nếu ongoing node shutdown được detected, vì vậy kể cả Pods với một tolerant node.kubernetes.io/not-ready:NoSchedule cũng không start ở đây

  • Cùng lúc đó khi kubelet đang set condition trên its Node thông qua API, the kubelet cũng bắt đầu terminating bất cứ Pods nào đang running locally.

  • Trong thời gian graceful shutdown, kubelet terminates pods trong 2 phase:

    • Terminate regular pods chạy trên node

    • Terminate critical pods chạy trên node

Graceful node shutdown được configured với 2 KubeletConfiguration options:

  • shutdownGracePeriod: chỉ định thời gian tổng thể mà node delay việc shutdown. Đây là tổng grace period cho pod termination của cả regular và critical pods.

  • shutdownGracePeriodCriticalPods : duration sử dụng để terminate critical pods trong khoảng node shutdown. Value này nên nhỏ hơn shutdownGracePeriod.

Pod Priority based graceful node shutdown

  • Graceful node shutdown sẽ tôn trọng PriorityClass for Pods, miễn là bạn enable tính tăng này cho cluster.

  • Tính năng này cho phép cluster admins explicitly định nghĩa order của pods trong lúc graceful node shutdown dựa trên priority classes.

kubelet config YAML:

shutdownGracePeriodByPodPriority:
  - priority: 100000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 180
  - priority: 1000
    shutdownGracePeriodSeconds: 120
  - priority: 0
    shutdownGracePeriodSeconds: 60
  • Metrics graceful_shutdown_start_time_seconds and graceful_shutdown_end_time_seconds are emitted under the kubelet subsystem to monitor node shutdowns

Non-graceful node shutdown handling

  • Node shutdown action có thể không được detected bởi kubelet's Node Shutdown Manager, có thể bởi vì command không trigger inhibitor locks mechanism hoặc bởi vì lỗi của user: có thể là ShutdownGracePeriod và ShutdownGracePeriodCriticalPods không được configure chính xác.

  • Khi một node shutdown không được detected bởi kubelet's Node Shutdown manager, pods là một phần của StatefulSet sẽ stuck ở trạng thái terminating và không thể chuyển sang running node mới. Nếu có volumes được sử dụng bởi Pods, thì VolumeAttachments sẽ không bị xóa khỏi original shutdown node (mà volumes sử dụng bởi các pods này sẽ không thể attach sang new running node).

  • Nếu original shutdown node comes up, pod sẽ bị xóa bởi kubelet và new pods sẽ được tạo ra trên running node khác. Nhưng nếu orginal shutdown node không come up, các pods này sẽ ở trạng thái terminating mãi mãi.

  • Để giảm thiểu tình trạng này, user có thể add tay taint node.kubernetes.io/out-of-service với effect là NoExecute hoặc NoSchedule cho Node marking it out-of-service. Nếu NodeOutOfServiceVolumeDetach feature gate được bật trên kube-controller-manager, và một Node được đánh dấu là out-of-service với taint này, các pods trên node sẽ bị cưỡng chế xóa nếu không có matching toleration trên đó và volume detach operations cho pod termining trên node se diễn ra ngay lập tức. Điều này cho phép Pods trên out-of-service node có thể recover nhanh chóng trên 1 node khác.

Trong non - graceful shutdown. Pods sẽ bị terminated trong 2 phases:

  • Force delete Pods không có matching out-of-service tolerations.

  • Ngay lập tức detach volume cho các pod này

Swap memory management

  • Để bật swap trên 1 node, NodeSwap feature gate cần phải được bật trên kubelet, và --fail-swap-on command flag hoặc failSwapOn configuration setting sẽ phải set là false.

  • user có thể configure memorySwap.swapBehavior để chỉ định cách node sẽ sử dụng tính năng swap memory. Ví dụ:

memorySwap:
  swapBehavior: UnlimitedSwap

  • UnlimitedSwap (default): K8s workloads có thể dùng nhiều swap memory theo yêu cầu, cho tới khi chạm system limit.

  • LimitedSwap: Utilization của swap memory bởi K8s workloads có limitation. Chỉ những Pods của Bustable QoS là được cho phép employ swap, những pods không phải là Burstable QoS classification sẽ không được utilizing swap memory.

Trước khi detailing the caculation của swap limit, cần phải định nghĩa các terms sau:

  • nodeTotalMemory: Tổng số lượng physical memory available trên node

  • totalPodsSwapAvailable: Tổng số lượng swap memory trên node available for use by Pods

  • containerMemoryRequest: Container's memory request.

Swap limitation được tính toán như sau:

(containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable

Swap được support chỉ trên cgroup v2, cgroup v1 không support.

Communication between Nodes and the Control Plane

Node to Control Plane

  • Hub - and - spoke API pattern. Tất cả việc sử dụng API từ các nodes đều terminate at API server.

  • Nodes cần phải được provision với public root certificate cho cluster để chúng có thể connect một cách an toàn với API server cùng với 1 valid client credentials.

  • Một approach tốt là client credentials cung cấp cho kubelet là in the form of a client certificate.

  • Pods muốn connect với API server có thể sử dụng service account để K8s sẽ tự động inject public root certificate và môt valid bearer token và pod khi nó được khởi tạo. kubernetes service (in default namespace) được configured với 1 virtual IP address được redirected (via kube-proxy) sang HTTPS endpoint on the API server.

  • Control panel components giao tiếp với API server thông qua secure port.

Control panel to node

Có 2 primary communication paths từ control plane (the API server) tới các nodes:

  • Từ API server tới kubelet process chạy trên mỗi node của cluster.

  • Từ API server tới bất kì node, pod hoặc service nào thông qua API server's proxy

API server to kubelet

Kết nối từ API server tới kubelet được sử dụng để:

  • Fetching logs cho pods

  • Attaching (thường thông qua kubectl) tới running pods

  • Providing kubelet's chức năng port-forwarding

Các connection này terminate ở kubelet's HTTPS endpoints.

Theo mặc định, API server không verify kubelet's serving certificate, điều này có thể dẫn tới man-in-the-middle attacks và không an toàn khi run ở ngoài public network.

Để verify connection này, sử dụng --kubelet-certificate-authority flag để provide API server với 1 root certificate bundle để sử dụng verify kubelet's serving certificate.

Nếu không thể làm như trên, thì sử dụng SSH tunneling giữa API server và kubelet nếu cần để tránh connect trên public network.

Cuối cùng, Kubelet authentication and/or authorization nên được bật để giữ an toàn cho kubelet API.

API server to nodes, pods, and services

  • mặc định là HTTP connections và không được authenticate hay encrypt. Có thể chạy HTTPS connection bằng các prefixing https: vào node, pod hoặc service name ở API URL, nhung nó sẽ không validate certificate cung cấp bởi HTTPS endpoint cũng như client credentials.

SSH Tunnels

K8s support ssh tunnels để bảo vệ control plane tới nodes communication path. Trong configuration này, API server khởi tạo 1 SSH tunnel tới mỗi node trong cluster và pass tất cả các traffic dẫn tới kubelet, node, pod hoặc service qua tunnel. Tunnel này sẽ đảm bảo rằng traffic không bị expose ra khỏi network.

Note: SSH tunnels đã bị depreciate -> nên dùng Konnectivity service

Konnectivity service

  • Một thay thế cho SSH Tunnel

  • Cung cấp TCP level proxy cho các kết nối từ control panel tới cluster.

Konnectivity bao gồm 2 phần:

  • Konnectivity server: ở control panel network

  • Konnectivity agent: nodes network

Konnectivity agent khởi tạo kết nối tới Konnectivity server và maintain network connections.

Sau khi enable Konnectivity service, tất cả các connection từ control panel tới nodes sẽ đi qua connection này

Controllers

Control loop: loop không bị terminate, regulates state của 1 system.

Trong k8s, controller là control loops sẽ watch state của cluster, sau đó tạo ra hoặc request những thay đổi cần thiết để đưa current state về gần với desired state.

Controller pattern

Control via API

  • Eg: Job controller: job chạy 1 Pod, có thể là nhiều pods để thực thi một tác vụ và sau đó stop.

  • Khi job controller thấy task mới nó sẽ đảm bảo rằng, ở đâu đó trong cluster, kuberlet trên 1 set các nodes đang chạy đúng số lượng pods để hoàn thành task. Job controller tự bản thân nó không chạy Pods hay container nào cả. Thay vào đó, Job controller bảo API server tạo hoặc remove pods.

  • Các thành phần khác trong control panel ứng xử theo thông tin mới, và tuần tự cho đến khi task done.

  • Sau khi tạo mới 1 job, desired state sẽ quy định trạng thái Job cần hoàn thành. Job controller sẽ khiên current state cho Job trở nên gần với desired state: Tạo các pods thực thi công việc.

  • Controller cũng update objects. VD: khi công việc đã hoàn thành thì Job controller sẽ update Job object và đánh dấu Finished

Direct control

Ngược lại với Job, một số controller sẽ thực hiện các thay đổi bên ngoài cluster.

VD: nếu sử dụng control loop để đảm bảo có đủ Nodes trong cluster,sau đó controller cần vài thứ bên ngoài cluster hiện tại để set up các node mới nếu cần.

Controller tương tác với external state để tìm kiếm desired state từ API server, sau đó giao tiếp trực tiếp với external system để đưa trạng thái current thành desired.

Một điểm quan trọng ở đây là controller tạo ra các thay đổi để mang tới trạng thái desired, sau đó reports current state ngược trở lại cluster's API server. Các control loops có thể observe các reported data này và thực hiện các hành động của chúng.

Design

  • K8s sử dụng nhiều controllers và mỗi controller quản lý 1 aspect của cluster state.

  • Controllers có thể fail, K8s được thiết kế để cho phép điều này

Ways of running controllers

  • K8s có các built-in controllers chạy bên trong kube-controller-manager. Những controller này cung cấp các core behavior quan trọng.

  • Deployment controller và Job controller là các ví dụ controller là 1 phần của K8s. K8s cho phép chạy 1 resilient control plane, để nếu 1 trong số các built;in controller fail, thì các phần khác của control plan sẽ đảm nhận công việc của nó.

  • Bạn có thể tìm thấy các controller chạy bên ngoài control plane, để extend k8s. Hoặc, nếu muốn, có thể tự viết 1 controller

  • Có thể run các controller tự viết như là 1 set các Pods, hoặc externally to K8s.

Leases

gfff

k8s