Serial blog Nhập môn Kubernetes
Nội dung
- Workload Resource
- Pod
- ReplicaSet
- Deployment
Workload Resource
Bài viết phần 5 này mình sẽ trình bày về Workloads resource.
Workload resource là loại resource sử dụng để khởi động container. Như đã nói lần trước thì có 8 loại:
Pod
Trong kubernetes thì Pod là là đơn vị nhỏ nhất. Pod được cấu thành từ 1 container hoặc nhiều container, chúng chia sẽ địa chỉ IP giữa các container với nhau. Nói cách khác, nếu chúng ta tạo một Pod chứa 2 container trở lên, thì các các container này sẽ đồng nhất với nhau địa chỉ IP. Chính vì vậy các container trong Pod sẽ trao đổi với nhau như trong môi trường local vậy. Ngoài ra các container trong cùng 1 Pod cũng chia sẽ với nhau vùng chứa gọi là Volume.
Link: https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/
Create Pod
Bây giờ chúng ta sẽ thực hiện create Pod đơn giản, các ví dụ ở phần này mình sử dụng minikube để thực hiện. Cách thiết lập môi trường minikube thì mình đã trình bày ở phần 2.
Đầu tiên chúng ta chuẩn bị 1 file pod_sample.yml. Pod này đơn giản chứa 1 container là nginx:1.12, mở port 80 cho container này.
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
spec:
containers:
- name: nginx-container
image: nginx:1.12
ports:
- containerPort: 80
Chạy lệnh để create pod
$ kubectl apply -f pod_sample.yml
pod "sample-pod" created
Kiểm tra Pod đã được khởi tạo ok chưa.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
sample-pod 1/1 Running 0 1m
Như ở trên thì mình có thể thấy là Pod đã run ok rồi, các bạn muốn lấy thông tin chi tiết hơn chút thì ta dùng lệnh option -o wide
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
sample-pod 1/1 Running 0 3m 172.17.0.4 minikube
Create Pod chứa 2 container
Chúng ta chuẩn bị file 2pod_sample.yml như bên dưới:
apiVersion: v1
kind: Pod
metadata:
name: sample-2pod
spec:
containers:
- name: nginx-container-112
image: nginx:1.12
ports:
- containerPort: 80
- name: nginx-container-113
image: nginx:1.13
ports:
- containerPort: 81
Để cho không bị xung đột với pod trước, chúng ta tạm thời xoá pod cũ đi
kubectl delete -f pod_sample.yml
Bây giờ chúng ta tạo Pod mới chứa 2 container, câu lệnh cũng tương tự.
# Create pod
$ kubectl apply -f 2pod_sample.yml
pod "sample-2pod" created
# Get list pods
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
sample-2pod 2/2 Running 0 3s
Ở trạng thái Running và READY là 2/2 thì có vẻ là OK rồi. Các bạn để ý một chút ở file 2pod_sample.yml mình đã cố ý gắn port cho conainer thứ 2 là port: 81. Lý do vì sao như vậy, chắc chắn là để tránh xung đột rồi. Vậy thì mình sửa về port 80 xem kết quả như thế nào nhé.
$ kubectl apply -f 2pod_sample.yml
pod "sample-2pod" created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
sample-2pod 1/2 Error 2 33s
$ kubectl logs sample-2pod nginx-container-113
2018/08/16 04:28:48 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
2018/08/16 04:28:48 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
2018/08/16 04:28:48 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
2018/08/16 04:28:48 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
2018/08/16 04:28:48 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
2018/08/16 04:28:48 [emerg] 1#1: still could not bind()
nginx: [emerg] still could not bind()
Như mình đã nói các container trong Pod sẽ chia sẽ không gian Network với nhau, ở đây mình dùng 2 container nginx có chung port: 80, hẳn là xảy ra xung đột rồi. :D
Login đến container
Để truy cập vào container ta dùng 「kubectl exec」
$ kubectl exec -it sample-pod /bin/bash
root@sample-pod:/#
ReplicaSet
ReplicaSet là loại resource dùng để tạo và duy trì số lượng Pod được chỉ định. Chẳng hạn như mình muốn tạo ra 5 Pod và muốn luôn duy trì số lượng này (nhằm đảm bảo ứng dụng hoặt động ổn định), mình sẽ sử dụng ReplicaSet, trong trường hợp vì lý do gì đó, một hoặc một vào pod bị sự cố. K8s sẽ tự động tái tạo lại đủ 5 Pod cho chúng ta.
Tạo một ReplicaSet
Chúng ta sẽ tạo thử một ReplicaSet đơn giản như file rs_sample.yml bên dưới. replicas: 3 nghĩa là tạo 3 Pod giống nhau, Pod được định nghĩa ở chổ spec.template. Trong ví dụ này thì Pod của chúng ta chỉ chứa 1 container là nginx:1.12
#rs_sample.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: sample-rs
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
containers:
- name: nginx-container
image: nginx:1.12
ports:
- containerPort: 80
Chạy lệnh để đăng ký resource đến Kubernetes Master
$ kubectl apply -f ./rs_sample.yml
replicaset.apps/sample-rs created
Bây giờ chúng ta kiểm ra ReplicaSet đã được tạo Ok chưa, có tạo 3 Pod cho chúng ta không.
$ kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
sample-rs 3 3 3 14m nginx-container nginx:1.12 app=sample-app
Tiếp theo thì kiếm tra số Pod được tạo ra, trạng thái như thế nào.
$ kubectl get pod -l app=sample-app -o wide
NAME READY STATUS RESTARTS AGE IP NODE
sample-rs-pdkcl 1/1 Running 0 16m 10.42.2.6 Node1
sample-rs-vwz57 1/1 Running 0 16m 10.42.1.6 Node2
sample-rs-znzkg 1/1 Running 0 16m 10.42.2.5 Node1
Như vậy là Ok rồi, các bạn có để ý ở item NODE không, do hiện tại mình đang chạy ở Cluster có 4 server sử dụng Rancher. Các bạn có thể tham khảo lại cách cấu trúc Kubernetes Cluster mình đã trình bày ở phần 3. Ở đây mình sử dụng 2 Nodes nên nó phân bổ Pods về cho 2 Nodes này. Trường hợp bạn đang dùng minikube thì chắc chắn là chỉ có 1 node duy nhất mà thôi.
Auto Healing
Ở ReplicaSet, trường hợp Node hay Pod gặp sự cố, ReplicaSet có cơ chế tự động khởi động lại Pod trên một Node khác, vì vậy làm giảm sự ảnh hưởng đến hệ thống. Một trong số những khái niệm cự kỳ quan trọng trong Kubernetes đó là "Auto Healing - tự động chữa bệnh".
Để kiểm chứng cơ chế auto healing thì ta thử xoá 1 Pod đi xem sao. Hiện tại chúng ta có 3 Pod như dưới đây, mọi người để ý NAME của nó nhé.
$ kubectl get pod -l app=sample-app -o wide
NAME READY STATUS RESTARTS AGE IP NODE
sample-rs-pdkcl 1/1 Running 0 47m 10.42.2.6 Node1
sample-rs-vwz57 1/1 Running 0 47m 10.42.1.6 Node2
sample-rs-znzkg 1/1 Running 0 47m 10.42.2.5 Node1
Xoá Pod
$ kubectl delete pods sample-rs-pdkcl
pod "sample-rs-pdkcl" deleted
Đã xoá xong rồi, nhưng bây giờ kiểm tra lại số lượng Pod chúng ta đang có là bao nhiêu.
$ kubectl get pod -l app=sample-app -o wide
NAME READY STATUS RESTARTS AGE IP NODE
sample-rs-4bwhw 1/1 Running 0 47m 10.42.2.6 Node1
sample-rs-vwz57 1/1 Running 0 47m 10.42.1.6 Node2
sample-rs-znzkg 1/1 Running 0 47m 10.42.2.5 Node1
Vẫn duy trì 3 Pod đúng chưa, để ý NAME thì thấy có 1 Pod đã khác tên. Vì cơ chế auto healing đã tự động tạo ra Pod mới khi một Pod bị xoá.
Sự tăng giảm Pod của ReplicaSet chúng ta cũng có thể confirm bằng lệnh "kubectl describe rs"
$ kubectl describe rs sample-rs
Name: sample-rs
Namespace: default
Selector: app=sample-app
Labels: app=sample-app
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"name":"sample-rs","namespace":"default"},"spec":{"replicas":3,"selector":{"ma...
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=sample-app
Containers:
nginx-container:
Image: nginx:1.12
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 58m replicaset-controller Created pod: sample-rs-znzkg
Normal SuccessfulCreate 58m replicaset-controller Created pod: sample-rs-pdkcl
Normal SuccessfulCreate 58m replicaset-controller Created pod: sample-rs-vwz57
Normal SuccessfulCreate 9m replicaset-controller Created pod: sample-rs-4bwhw
Link:https://medium.com/@jiamin_ning/build-your-first-kubernetes-service-with-replicaset-7c37d9be689c
Label
RepicaSet quản lý các Pod được tạo ra bằng cơ chế gắn nhãn cho từng Pod. Vì vậy chúng ta dễ dàng tìm kiếm những Pod có label giống nhau, dễ dàng cho việc điều chỉnh tăng giảm số lượng Pod.
Labe của Pod được chỉ định ở phần spec.selector
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
Chúng ta cũng để ý ở file rs_sample.yml phía trên. tại thiết lập spec.template.metadata.labels cũng được setting là "app:sample-app". Vì các Pod được tạo ra ở trạng thái được gắn label là "app:sample-app" nên replicas: 3 sẽ tạo ra 3 Pod giống nhau.
Chúng ta cần lưu ý spec.selector và spec.template.metadata.labels bắt buộc phải giống nhau, nếu không sẽ xảy ra lỗi.
Có nhiều bạn cũng sẽ đặt câu hỏi, bây giờ mình tạo 1 Pod riêng (không phải tạo trong RepicaSet Manifest) nhưng được gắn label cũng là "app:sample-app" thì điều gì xãy ra. Trong trường hợp lable bị duplicate, tức là chúng ta đang chỉ định tạo 3 Pod có label là "app:sample-app" nhưng tự nhiên ở đâu xuất hiện 1 Pod nữa cũng có nhãn như vậy. Lúc này ReplicaSet hiểu lầm là số lượng Pod đã tăng quá mức quy định, nó sẽ stop đi một Pod.
Test thử thôi!
#pod_sample.yml
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
labels:
app: sample-app
spec:
containers:
- name: nginx-container
image: nginx:1.13
ports:
- containerPort: 80
# create Pod
$ kubectl apply -f pod_sample.yml
pod/sample-pod created
Kiểm tra tình trạng các Pod như thế nào
$ kubectl get pods -L app
NAME READY STATUS RESTARTS AGE APP
sample-pod 0/1 Terminating 0 3s sample-app
sample-rs-4bwhw 1/1 Running 0 2h sample-app
sample-rs-vwz57 1/1 Running 0 3h sample-app
sample-rs-znzkg 1/1 Running 0 3h sample-app
Vài giây sau chúng ta kiểm tra lại lần nữa.
$ kubectl get pods -L app
NAME READY STATUS RESTARTS AGE APP
sample-rs-4bwhw 1/1 Running 0 2h sample-app
sample-rs-vwz57 1/1 Running 0 3h sample-app
sample-rs-znzkg 1/1 Running 0 3h sample-app
Pod chúng ta vừa tạo đã biến mất. Vậy thì cơ chế luôn giữ số lượng Pod được chỉ định đã xoá đi 1 Pod thừa. Trong trường hợp lần này là xoá đi Pod chúng ta vừa thêm vào, nhưng cũng có trường hợp nó xoá đi Pod đã tồn tại trước đó. Vì vậy chúng ta cần lưu ý việc đánh nhãn cho Pod.
Khi chúng ta quen với cách làm việc của Kubernetes thì Lable nên là duy nhất. Vì chúng ta có thể gắn nhiều lable cho cùng 1 container nên hãy quyết định quy tắc đặt lên lable như gợi ý sau:
labels:
env: dev
codename: system_a
role: web-front
Scaling Pod
Bây giờ chúng ta sẽ thực hiện thay đổi số lượng Pod bằng cách thay đổi setting của ReplicaSet.
Có 2 phương pháp:
- Edit file yaml config, chạy command "kubectl apply -f [FILENAME]"
- Thực hiện scale bằng cách chạy command kubectl scale
Cách thứ nhất thì như mình cũng đã nói ở phần trước rồi, thay đổi file YAML config, chạy command kubectl apply ... là sẽ update được resource. Lần này mình sẽ demo bằng kubectl scale. Nhưng Workload resource có thể thực hiện scale bằng kubectl scale chỉ có 4 loại Deployment, Job, ReplicaSet, ReplicationController.
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-rs 3 3 3 3h
$ kubectl scale rs sample-rs --replicas 5
replicaset.extensions/sample-rs scaled
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-rs 5 5 5 3h
$ kubectl get pods -l app=sample-app
NAME READY STATUS RESTARTS AGE
sample-rs-4bwhw 1/1 Running 0 3h
sample-rs-lz6x7 1/1 Running 0 44s
sample-rs-vwz57 1/1 Running 0 3h
sample-rs-z5l8b 1/1 Running 0 44s
sample-rs-znzkg 1/1 Running 0 3h
Deployment
Deployment là loại resource có khả năng thực hiện việc Roling update, Roll back vv bằng việc quản lý nhiều ReplicaSet.
Cơ chế đơn giản như sau:
- Tạo một ReplicaSet mới
- Dần dần tăng số lượng replica (số Pod) trên ReplicaSet mới
- Dần dần giảm số lượng replica (số Pod) trên ReplicaSet cũ
- Lặp lại bước 2,3
- ReplicaSet cũ sẽ lưu lại với replica: 0
Lúc thực hiện chuyển đổi qua ReplicaSet mới.
- Vừa có thể kiểm tra việc khởi động container hay tình trạng Helth check trên ReplicaSet mới.
- Vừa có thể chỉ định chi tiết số lượng Pod lúc di chuyển ReplicaSet
Kubernetes là công cụ được đề cử nhiều nhất về phương pháp khởi động container. Cho dù hệ thống có 1 container đi nữa, thì việc khởi động container sử dụng Deployment cũng rất được kỳ vọng.
Create Deployment
Việc đầu tiên thì chúng ta cũng chuẩn bị fiel YAML config deployment_sample.yml. Nó trông cũng không khác file config của ReplicaSet mấy.
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-deployment
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
containers:
- name: nginx-container
image: nginx:1.12
ports:
- containerPort: 80
Lần này khi create resource, chúng ta thêm option --record để lưu lại lịch sử lúc update.
$ kubectl apply -f deployment_sample.yml --record
deployment.apps/sample-deployment created
Lịch sử sẽ lưu lại trong metadata.annotations.kubernetes.io/change-cause của ReplicaSets, chúng ta có thể confirm như bên dưới. Thông số metadata.annotations.deployment.kubernetes.io/revision cũng cho ta biết số lần sửa đổi.
$ kubectl get rs -o yaml | head
apiVersion: v1
items:
- apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
annotations:
deployment.kubernetes.io/desired-replicas: "3"
deployment.kubernetes.io/max-replicas: "4"
deployment.kubernetes.io/revision: "1"
kubernetes.io/change-cause: kubectl apply --filename=deployment_sample.yml --record=true
Nhân đây cũng nói luôn, Command "Kubectl run" cũng có khả năng tạo ra một Deployment, chỉ có điểm khác nhau là nó gán lable mặc định là run: sample-deployment, nhưng vì khả năng xảy ra xung đột của nó thấp nên thỉnh thoảng chúng ta cần test một images nào đó thì cũng có thể sử dụng rất tiện lợi.
$ kubectl run sample-deployment --image nginx:1.12 --replicas 3 --port 80
deployment.apps/sample-deployment created
Chúng ta có thể kiểm tra lại thông tin Deployment, ReplicaSet, Pods vv
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
sample-deployment 3 3 3 3 2m
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-deployment-5f7c4b7b4 3 3 3 2m
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
sample-deployment-5f7c4b7b4-59rlm 1/1 Running 0 2m
sample-deployment-5f7c4b7b4-69bjd 1/1 Running 0 2m
sample-deployment-5f7c4b7b4-vzpqq 1/1 Running 0 2m
Bây giờ mình muốn thay đổi version nginx từ nginx:1.12 -> nginx:1.13 trong deployment vừa rồi. Chúng ta có command 「kubectl set image」.
$ kubectl set image deployment sample-deployment nginx-container=nginx:1.13
deployment.extensions/sample-deployment image updated
Sau khi update xong thì ReplicaSet đã được tạo mới, giống như hình phía trên mình đã trình bày về rolling update, thì bây giờ Pod đã được tạo lại, về cơ bản thì không ảnh hưởng gì đến service của chúng ta.
kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
sample-deployment 3 3 3 3 23m
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-deployment-86b68b4c5b 0 0 0 23m
sample-deployment-d5b55f699 3 3 3 16m
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
sample-deployment-d5b55f699-4zqw2 1/1 Running 0 15m
sample-deployment-d5b55f699-9xvrj 1/1 Running 0 16m
sample-deployment-d5b55f699-zgv5w 1/1 Running 0 16m
Lần này mình đã giới thiệu về mối quan hệ giữa Deployment, ReplicaSet, Pod. Cụ thể như hình bên dưới đây.
Điều kiện update Deployment (ReplcaSet được tạo ra)
Như mình đã trình bày, khi update Deployment thì ReplicaSet mới sẽ được tạo ra. Việc "Update" ở đây không bao gồm việc thay đổi số lương replica mà chính là việc thay đổi nội dung của Pod được tạo ra. Nói một cách chính xác hơn thì khi spec.template thay đổi thì sẽ tạo ra ReplicaSet mới, và thực hiện Rolling update.
Thực tế khi xem định nghĩa ReplicaSet, tại phần dưới spec.template tính toán giá trị hash và quản lý nó bằng label đã được gắn. Thêm nữa khi thực hiện cơ chế này, trong trường hợp chúng ta muốn quay về lại image cũ, bằng cách thủ công nếu chúng ta setting cùng giá trị hash, thì sẽ không sinh ra ReplicaSet mới, mà sử dụng lại ReplicaSet đã tồn tại trước đó.
$ kubectl get rs sample-deployment-d5b55f699 -o yaml
...
...
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
pod-template-hash: "816119255"
...
...
Trong ví dụ lần này vì chúng ta thay đổi image của Pod từ nginx:1.12 sang nginx 1.13 nên Pod Template Hash được tính toán lại và ReplicaSet được tạo mới.
Rollback Update
Ở Deployment có chức năng roolback. Thực chất của chức năng roolback đó chính là việc chuyển đổi ReplicaSet hiện tại đang sử dụng. ReplicaSet về cơ bản sau khi được chuển đổi vẫn tồn tại ở trạng thái replica: 0 như lưu history vậy. Vì vậy nó có thể tăng số lượng replica bằng việc tái sử dụng lại:
kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-deployment-86b68b4c5b 0 0 0 21h
sample-deployment-d5b55f699 3 3 3 21h
Để kiểm tra lịch sử update chúng ta sử dụng command 「kubectl rollout history」. Tại mục CHANGE-CAUSE, vì chung ta đã truyền option --record lúc create Deployment nên nó đã lưu lại, trường hợp không có option --record thì nó sẽ không hiển thị.
$ kubectl rollout history deployment sample-deployment
deployments "sample-deployment"
REVISION CHANGE-CAUSE
1 kubectl create --filename=deployment_sample.yml --record=true
2 kubectl set image deployment sample-deployment nginx-container=nginx:1.13
Khi thực hiện rollback, dĩ nhiên chúng ta có thể chỉ định việc muốn rollback đến revision nào bằng cách gán thêm parameter
# Trường hợp rollback về revision ngay trước đó
$ kubectl rollout undo deployment sample-deployment
deployment "sample-deployment" rolled back
# Trường hợp chỉ định revision cụ thể
$ kubectl rollout undo deployment sample-deployment --to-revision 1
deployment "sample-deployment" rolled back
Sau khi thực hiện rollback thì Pod đã được khởi động trên ReplicaSet cũ.
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-deployment-86b68b4c5b 3 3 3 22h
sample-deployment-d5b55f699 0 0 0 22h
Xem qua thì các bạn thấy cách rollback kiểu này có vẻ rất hay, tuy nhiên thực tế thì rất ít người dùng, lý do thay vì thực hiện rollback bằng command kubectl rollout thì chúng ta chỉnh sửa trực tiếp lên file YAML và chạy lệnh kubectl apply thì tốt hơn. Khi thay đổi spec.template về lại trạng thái trước khi update (nginx 1.12) thì Pod Template Hash cũng về lại giá trị ban đầu. Vì vậy Pod được khởi động trên ReplicaSet phù hợp, giống như lệnh kubectl rollout.
Deployment scaling
Cũng giống như ReplicaSets chúng ta có thể sử dụng 「kubectl scale」 hoặc 「kubectl apply -f」 để scaling.
Phương pháp update nâng cao
Trong bài viết lần này mình đã tập trung nói về phần update, thực tế để update thì chúng ta còn có một phương pháp đó là recreate. Liên quan đến update có rất nhiều paramater, chi tiết mình sẽ trình bày ở các phần sau.
