Hiển thị các bài đăng có nhãn Kubernetes. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn Kubernetes. Hiển thị tất cả bài đăng

25 tháng 6, 2019

Kiến trúc Kubernetes: Nodes

Kiến trúc Kubernetes: Nodes

Một node là một worker machine bên trong Kubernetes, trước đó còn được biết như là một minion. Một node có thể là một VM hoặc một physical machine, điều này phụ thuộc vào cluster. Mỗi node sẽ chứa các service cần thiết để chạy các pod và được quản lý bởi các master component. Các service trên một node bao gồm container runtime, kubeletkube-proxy.

Node Status

Status của một node bao gồm các thông tin sau:

  • Addresses
  • Conditions
  • Capacity và Allocatable
  • Info

Node status và các thông tin chi tiết khác về một node có thể được hiển thị bằng cách sử dụng lệnh sau:

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

Addresses

Cách sử dụng của các trường này sẽ khác nhau tùy thuộc vào cloud provider của bạn hoặc cấu hình vật lý:

  • HostName: hostname được ghi lại bởi kernel của node. Có thể được ghi đè qua tham số kubelet --hostname-override

  • ExternalIP: địa chỉ IP của node có thể được định tuyến ở bên ngoài cluster

  • InternalIP: địa chỉ IP của node chỉ có thể được định tuyến bên trong cluster

Conditions

Trường conditions mô tả trạng thái của tất cả các node Running. Ví dụ, conditions sẽ bao gồm:

Node Condition Mô tả
OutOfDisk True nếu node không có đủ bộ nhớ để tạo thêm các pod mới, ngược lại là False
Ready True nếu node tình trạng tốt và sẵn sàng chấp nhận thêm pod, False nếu node không tình trạng tốt và không chấp nhận thêm pod, Unknown nếu node controller không nghe thấy được tín hiệu từ node-monitor-grace-period cuối cùng (mặc định là 40 giây)
MemoryPressure True nếu bộ nhớ của node ở mức thấp, ngược lại là False
PIDPressure True nếu có quá nhiều process chạy trong node, ngược lại là False
DiskPressure True nếu dung lượng đĩa cứng thấp, ngược lại là False
NetworkUnavailable True nếu network của node không được cấu hình đúng, ngược lại là False

Node condition được khai báo như một đối tượng JSON. Ví dụ, response dưới đây mô tả tình trạng của node:

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

Nếu trạng thái của Ready condition vẫn là Unknown hoặc False lâu hơn pod-eviction-timeout, thì một tham số được truyền đến kube-controller-manager và tất cả các Pod trên node được lên lịch để xóa bởi Node Controller. pod-eviction-timeout mặc định là năm phút. Trong một vài trường hợp khi node không thể truy cập thì apiserver sẽ không thể giao tiếp với kubelet trên node. Quyết định xóa các pod không thể được truyền đạt đến kubelet cho đến khi giao tiếp với apiserver được tái lập. Trong lúc đó, các pod đã được lên lịch để xóa vẫn có thể tiếp tục chạy trên nod được phân vùng.

Trong các version Kubernetes trước 1.5, node controller sẽ force delete các pod không thể truy cập đến từ apiserver. Tuy nhiên, từ version 1.5 và các version cao hơn, node controller không force delete các pod cho đến khi nó xác nhận rằng chúng đã ngừng chạy trong cluster. Bạn có thể thấy các pod có thể đang chạy trên một node không thể truy cập được như đang trong trạng thái Terminating hoặc Unknown. Trong các trường hợp Kubernetes không thể suy đoán ra một node đã vĩnh viễn rời khỏi cluster thì người quản trị cluster có thể cần xóa node bằng cách thủ công. Việc xóa đối tượng node từ Kubernetes dẫn đến việc tất cả Pod đang chạy trên node bị xóa khỏi apiserver và giải phóng tên của chúng.

Trong version 1.12, tính năng TaintNodesByCondition trở thành beta vì vậy node lifecycle controller tự động tạo các taint đại diện cho condition. Tương tự scheduler bỏ qua các điều kiện khi quyết định một node, thay vào đó nó chú ý vào các tainttoleration của Pod.

Capacity và Allocatable

Mô tả các tài nguyên sẵn có trong node: CPU, memory, và số lượng tối đa pod có thể được scheduled vào node.

Các trường trong capacity block chỉ ra tổng số tài nguyên mà một Node sở hữu. Allocatable block chỉ ra lượng tài nguyên trên Node đang sẵn sàng được tiêu thụ bởi các Pod thông thường.

Info

Thông tin chung về node như kernel version, Kubernetes version (kubeletkube-proxy version), Docker version (nếu sử dụng), tên của OS. Thông tin được thu thập bởi kubelet trong node.

Management

Không giống như podservice, một node vốn không được tạo ra bởi Kubernetes: nó được tạo bên ngoài bởi các cloud provider như GCE hoặc nó có sẵn trong nhóm các máy vật lý hoặc máy ảo của bạn. Vì vậy khi Kubernetes tạo một node, nó tạo một đối tượng đại diện cho node. Sau khi tạo, Kubernetes kiểm tra liệu node có hợp lệ hay không. Ví dụ, hãy thử tạo một node theo nội dung như sau:

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

Kubernetes tạo một node nội bộ (đại diện) và xác nhận node bằng cách kiểm tra tình trạng dựa trên trường metadata.name. Nếu node hợp lệ - tất cả service cần thiết đều chạy - nó sẽ đủ điều kiện để chạy một pod. Ngược lại, nó được bỏ qua trong bất kỳ hoạt động nào của cluster cho đến khi trở thành hợp lệ.

Hiện tại, có ba thành phần tương tác với Kubernetes node interface: node controller, kubeletkubectl.

Node Controller

Node controller là một master component quản lý nhiều khía cạnh khác nhau của các node.

Node controller có nhiều vai trò trong vòng đời của một node. Đầu tiên là việc gán CIDR block cho node khi nó được đăng ký (nếu CIDR assignment được bật).

Thứ hai là giữ danh sách các node nội bộ của node controller luôn cập nhật mới nhất theo danh sách các machine sẵn dùng của cloud provider. Khi chạy trong môi trường cloud, bất cứ khi nào một node trong tình trạng không tốt thì node controller sẽ hỏi cloud provider liệu VM cho node đó có sẵn dùng hay không. Nếu không, node controller xóa node đó khỏi danh sách các node của nó.

Thứ ba là theo dõi tình trạng của các node. Node controller chịu trách nhiệm cập nhật NodeReady condition của NodeStatus thành ConditionUnknown khi một node trở nên không thể truy cập đến (ví dụ như node bị down), và sau đó thu hồi tất cả pod khỏi node đó (sử dụng graceful termination) nếu node này tiếp tục không thể truy cập (timeout mặc định là 40s để khởi động báo cáo ConditionUnknown và 5 phút sau đó để khởi động quá trình thu hồi pod). Node controller liên tục kiểm tra trạng thái của mỗi node trong khoảng thời gian mỗi --node-monitor-period giây.

Trong các version Kubernetes trước 1.13, NodeStatus chính là tín hiệu theo dõi của node. Bắt đầu từ version 1.13, tính năng cho thuê node được giới thiệu là một tính năng alpha (NodeLease). Khi tính năng NodeLease được bật, mỗi node sẽ có một đối tượng Lease được liên kết trong namespace kube-node-lease, namespace được làm mới định kì; cả NodeStatusnode lease được coi như tín hiệu từ node. Các node lease được làm mới thường xuyên trong khi NodeStatus chỉ được báo cáo từ node đến master khi có các thay đổi hoặc đã đủ thời gian (mặc định là 1 phút, lâu hơn thời gian 40s timeout cho các node không thể truy cập). Vì node lease nhẹ hơn nhiều so với NodeStatus nên tính năng này làm cho tín hiệu của node trở nên rẻ hơn đáng kể từ cả hai khía cạnh là khả năng mở rộng và hiệu suất.

Từ version 1.4, node controller sẽ xem xét trạng thái của tất cả node trong cluster trước khi đưa ra quyết định thu hồi pod.

Trong nhiều trường hợp, node controller giới hạn tỉ lệ thu hồi thành --node-eviction-rate (mặc định là 0.1) mỗi giây, điều này nghĩa là nó sẽ không thu hồi pod từ hơn một node mỗi 10 giây.

Hành vi thu hồi thay đổi khi một node trong vùng khả dụng đã biết có tình trạng không tốt. Node controller kiểm tra tỉ lệ các node trong vùng tình trạng không tốt (NodeReady condition là ConditionUnknown hoặc ConditionFalse) ở trong cùng thời điểm. Nếu tỉ lệ các node trong tình trạng không tốt ít nhất là --unhealthy-zone-threshold (mặc định là 0.55) thì tỉ lệ thu hồi sẽ giảm xuống: nếu cluster nhỏ (ví dụ nhỏ hơn hoặc bằng --large-cluster-size-threshold node, mặc định 50) thì việc thu hồi bị dừng, mặt khác tỉ lệ thu hồi sẽ giảm xuống --secondary-node-eviction-rate (mặc định 0.01) mỗi giây. Lí do các chính sách này được triển khai trên mỗi vùng khả dụng là vì một vùng khả dụng có thể trở thành phân vùng từ master trong khi những các vùng còn lại vẫn được kết nối.

Từ version Kubernetes 1.6, NodeController cũng chịu trách nhiệm thu hồi các pod đang chạy trên node có các NoExecute taint, khi pod không tolerate các taint. Hơn nữa, vì là tính năng alpha nên mặc định nó bị disable, NodeContoller chịu trách nhiêm thêm các taint tương ứng với các vấn đề của node như node không thể truy cập hay không sẵn sàng (not ready).

Self-Registration

Khi flag kubelet --register-node được thiết lập là true (giá trị mặc định), kubelet sẽ cố gắng tự đăng ký với API server. Đây là mô hình được sử dụng bởi hầu hết các distro.

Để tự đăng ký, kubelet được khởi động với các option sau:

  • --kubeconfig - Đường dẫn đến các credential để tự xác thực đến apiserver.

  • --cloud-provider - cách giao tiếp với một cloud provider để đọc metadata của chính nó.

  • --register-node - tự động đăng ký với API server.

  • --register-with-taints - đăng ký node với dánh sách taint đã cung cấp (phân cách bằng dấu phảy <key>=<value>:<effect>). Không hoạt động nếu register-nodefalse.

  • --node-ip - địa chỉ IP của node.

  • --node-labels - nhãn của node khi đăng ký node trong cluster

  • --node-status-update-frequency - chỉ định tần suất kubelet gửi status của node đến master.

Khi Node authorization mode và NodeRestriction admission plugin được bật thì các kubelet chỉ được phép tạo và sửa đổi tài nguyên Node của riêng chúng

Manual Node Administration

Một quản trị viên cluster có thể tạo và sửa đổi các đối tượng node.

Nếu quản trị viên muốn tạo các đối tượng node theo cách thủ công thì cần thiết lập cờ kubelet--register-node=false.

Quản trị viên có thể sửa đổi các tài nguyên của node (kể cả thiết lập --register-node). Các sửa đổi bao gồm thiết lập các nhãn trên node và đánh dấu nó là unschedulable.

Nhãn của các node có thể được sử dụng kết hợp với các node selector trên các pod để điều khiển scheduling, ví dụ như ràng buộc một pod chỉ đủ điều kiện chạy trên một tập hợp con của các node.

Bằng cách đánh dấu một node là unschedulable sẽ ngăn chặn các pod mới được scheduled tới node đó, nhưng không áp dụng cho các pod đã tồn tại ở trên node. Việc này sẽ hữu ích vì nó như một bước chuẩn bị trước khi reboot node,... Ví dụ, để đánh dấu một node là unschedulable, ta cần chạy lệnh sau:

kubectl cordon $NODENAME

Node capacity

Capacity của một node (số lượng CPU và số lượng memory) là một thành phần của node. Thông thường, các node tự đăng ký và báo cáo capacity của chúng khi tạo node. Nếu bạn đang quản lý node theo cách thủ công thì bạn cần thiết lập node capacity khi thêm một node mới.

Kubernetes scheduler đảm bảo có đủ các tài nguyên cho tất cả pod trên một node. Nó kiểm tra tổng số request của các container trên node không lớn hơn node capacity. Điều này bao gồm tất cả container được khởi động bởi kubelet, nhưng không bao gồm các container được khởi động trực tiếp bới container runtime cũng như bất kỳ tiến trình nào chạy bên ngoài các container.

26 tháng 5, 2019

Giới thiệu về Kubernetes

Giới thiệu về Kubernetes (k8s)

Trong bài viết này, chúng ta sẽ cùng tìm hiểu Kubernetes (k8s) là gì, nó không phải là gì, nó giải quyết vấn đề gì, các thành phần kiến ​​trúc của nó, làm thế nào để chạy trên local và cuối cùng là một số lựa chọn thay thế trên thị trường.

Vậy Kubernetes là gì?

Để bắt đầu hiểu tính hữu dụng của Kubernetes, trước tiên chúng ta phải hiểu hai khái niệm: hạ tầng bất biếncontainer. Hạ tầng bất biến là khái niệm mà các máy chủ không bao giờ được sửa đổi sau khi đã triển khai. Ý tưởng là nếu cần phải thay đổi một cái gì đó, thì nó không bao giờ được sửa đổi trực tiếp trên máy chủ, thay vào đó một máy chủ mới được xây dựng từ một base-image với tất cả các thay đổi cần thiết để chúng ta có thể thay thế máy chủ cũ bằng máy chủ mới mà không cần bất kỳ sửa đổi thêm nào. Container là một cách để đóng gói code của bạn, runtime, các system tool, các thư viện hệ thống và cấu hình để nó có thể được vận chuyển dưới dạng thực thi độc lập và nhẹ. Ý tưởng là ứng dụng của bạn sẽ hoạt động giống nhau ở mọi nơi, mọi lúc (ví dụ Ubuntu hoặc Windows). Điều đáng nói là container hóa không phải là một khái niệm mới, nó chỉ thực sự được phổ biến với sự phát triển của microservice và Docker.

Bây giờ chúng ta đã hiểu hai khái niệm đó, vậy Kubernetes là gì? Tôi sẽ định nghĩa nó như là container hoặc một nền tảng microservice điều phối computing, network và quản lý công việc cho chúng ta. Kubernetes mở rộng các cách ta scale ứng dụng được đóng gói, vì vậy chúng ta có thể nhận được tất cả những lợi ích của một kiến trúc hạ tầng bất biến

Từ Kubernetes có ý nghĩa gì, đó là một từ trong tiếng Hy Lạp, có nghĩa là người lái xe hoặc phi công và K8S là một từ viết tắt bằng cách thay thế 8 chữ cái "ubernete" bằng số "8".

Kubernetes cung cấp những gì?

K8s cung cấp một số tính năng chính giúp quy mô ứng dụng được đóng gói của bạn hoạt động hiệu quả.

  • Horizontal scaling - dễ dàng scale-up ứng dụng từ command-line hoặc từ giao diện UI

  • Tự động tráo đổi và rollback - theo dõi tình trạng của ứng dụng của bạn để đảm bảo tất cả các instance không bị lỗi cùng lúc. Nếu có sự cố, k8s sẽ tự động rollback thay đổi.

  • Service discovery và load balancing - Các container sẽ có IP riêng và bạn có thể đặt một tập hợp các container phía sau một tên miền DNS duy nhất để cân bằng tải.

  • Storage orchestration - tự động mount local, public-cloud hoặc một network storage.

  • Quản lý Secret và Cấu hình - Tạo và cập nhật các secret và cấu hình mà không cần phải build lại image của bạn.

  • Tự phục hồi - Khởi động lại các container khi không thành công, thay thế và lập lịch lại các container khi các node ngừng hoạt động, kill các container không đáp ứng được health-check do người dùng định nghĩa và không chúng phục vụ client cho đến khi chúng thực sự sẵn sàng.

  • Batch execution - Quản lý batch và tích hợp liên tục lượng công việc. Nó cũng đảm bảo việc thay thế các container bị lỗi

  • Tự động đóng gói - k8s đủ thông minh để lên lịch cho các container dựa trên yêu cầu tài nguyên và các ràng buộc khác.

Như bạn có thể thấy, Kubernetes cung cấp cho chúng ta rất nhiều thứ. Nó cho phép ta khởi chạy một cơ sở hạ tầng bất biến thực sự, nơi mà ứng dụng container của chúng ta có thể bị kill và tự phục hồi, container mới này có quyền truy cập vào tất cả các volume, secret, các cấu hình,... nó cần, tất cả đều là tự động.

Điều khoản và định nghĩa cơ bản của Kubernetes

Để bắt đầu hiểu cách sử dụng k8s, trước tiên chúng ta phải hiểu các đối tượng trong API. Có các đối tượng k8s cơ bản và một vài higher-level abstraction được gọi là các Controller.

Các đối tượng cơ bản

  • Pod - một nhóm gồm một hoặc nhiều container

  • Service - chuyển tiếp các request đến một nhóm các Pod

  • Volume - một thư mục có thể truy cập vào các container trong một Pod

  • Namespace - cho phép chúng ta tách cluster để dành riêng cho mục đích nhất định, ví dụ như một dự án hoặc một team phát triển

Higher-Level Abstractions

  • ReplicaSet - đảm bảo rằng số lượng Pod chúng ta muốn là những gì đang chạy.

  • Deployment - cung cấp các tham số cập nhật cho các PodReplicaSet

  • StatefulSet - đối tượng được sử dụng để quản lý các ứng dụng có trạng thái như các cơ sở dữ liệu.

  • DaemonSet - đảm bảo rằng tất cả hoặc một số node worker chạy một bản sao của một Pod. Điều này rất hữu ích cho các ứng dụng daemon như fluentd.

  • Job - tạo một hoặc nhiều Pod và thực thi một hoặc nhiều tác vụ nhất định, sau đó xóa các Pod.

Kiến trúc & Thành phần Kubernetes

Một k8s cluster được tạo thành từ một node Master. Node Master này có nhiệm vụ expose API, lên lịch triển khai và quản lý cluster nói chung. Các node Worker chịu trách nhiệm về container-runtime (giống như Docker hoặc rkt), cùng với một agent để giao tiếp với Master.

Các thành phần Master:

  • Kube-apiserver - expose API.

  • Etcd - Một key-value store lưu trữ tất cả dữ liệu cluster.

  • Kube-scheduler - lập lịch các pod mới trên các node worker

  • Kube-controller-manager - khởi chạy các controller

  • Cloud-controller-manager - giao tiếp với các clould-provider

Những thành phần này tạo nên một node Master. Etcd có thể được chạy trên cùng một server như một node Master hoặc trên một cluster chuyên dụng.

Các thành phần node:

  • Kubelet - Một tác nhân đảm bảo các container đang chạy trong một pod.

  • Kube-proxy - tuân theo các network-rule và thực hiện chuyển tiếp.

  • Container Runtime - Chịu trách nhiệm chạy container.

Dưới đây là một sơ đồ kiến ​​trúc cơ bản.

Hình 1

Cách cài đặt Kubernetes

Cài đặt k8s local rất đơn giản và dễ hiểu. Bạn sẽ phải cần hai công cụ sau: KubectlMinikube.

  • Kubectl - một CLI được sử dụng để tương tác với cluster.

  • Minikube - đây là file binary giúp triển khai một k8s cluster local trên máy phát triển.

Với hai công cụ này, bạn có thể bắt đầu triển khai các ứng dụng đã được container hóa của mình lên k8s cluster local chỉ trong vòng vài phút. Đối với một cluster-production đáp ứng tính sẵn sàng cao, bạn có thể sử dụng các công cụ như Kops, EKS, đây là service được cung cấp bởi AWS hoặc như GKE được cung cấp bởi Google.

Kubernetes sẽ không làm cho bạn những việc gì?

  • Nó không giới hạn loại ứng dụng bạn có thể triển khai. Nó cho phép bất kỳ loại ứng dụng được viết bằng bất kỳ ngôn ngữ lập trình nào. Miễn là nó được đặt trong một container.

  • Nó không thay thế các công cụ giống như Jenkins vì vậy nó sẽ không build ứng dụng của bạn cho bạn.

  • Nó không phải là một middleware nên nó sẽ không thực hiện các tác vụ mà middleware thực hiện như các message-bus hoặc caching quen thuộc.

  • Không quan tâm giải pháp ghi log nào được sử dụng. Hãy thiết lập ứng dụng của bạn ghi log ra stdout, và sau đó bạn có thể thu thập những log bạn muốn.

  • Không quan tâm về ngôn ngữ cấu hình của bạn (ví dụ: json).

K8s không quan tâm đến những điều này chỉ đơn giản là nó cho phép chúng ta xây dựng ứng dụng theo cách chúng ta muốn, phơi bày và thu thập bất kỳ loại thông tin nào theo cách chúng ta muốn.

Các đối thủ cạnh tranh Kubernetes

Có các công cụ khác tương tự như k8s. Ví dụ: có Docker Compose cho staging nhưng không thích hợp cho production hoặc Nomad cho phép chúng ta quản lý cluster và lên lịch nhưng nó không giải quyết được nhu cầu quản lý và giám sát cấu hình, secret của chúng ta, Netflix chỉ mở mã nguồn nền tảng điều phối (orchestration) của họ được gọi là Titus do đó không có đủ người sử dụng nó trong production, ngoại trừ Netflix. Nhìn chung, k8s cung cấp các tính năng tốt nhất hiện có với các dự án bổ trợ của bên thứ 3 để mở rộng chức năng của nó.

view raw Kubernetes.md hosted with ❤ by GitHub
z_img_001.png
view raw z_img_001.png hosted with ❤ by GitHub