Mở Đầu
Trong thời đại công nghệ hiện nay, việc sử dụng Kubernetes để triển khai ứng dụng microservices ngày càng phổ biến. Tuy nhiên, không phải tất cả các ứng dụng chạy trên Kubernetes đều tự động đạt được độ sẵn sàng cao (High Availability) và khả năng chịu lỗi. Để đảm bảo tính sẵn sàng cao cho ứng dụng, chúng ta cần cấu hình một cách hợp lý và tùy chỉnh theo từng ứng dụng cụ thể.
Bài viết này sẽ đề cập đến các cấu hình quan trọng và thông số cần thiết để bảo vệ ứng dụng khỏi downtime và nâng cao tính sẵn sàng.
Chiến Lược Triển Khai (Deployment Strategy)
Chiến lược triển khai ứng dụng rất quan trọng trong việc kiểm soát cách thức triển khai và cập nhật ứng dụng trong Kubernetes. Hai chiến lược phổ biến nhất là Rolling Update và Recreate.
- Rolling Update: Cho phép cập nhật từng pod một cách tuần tự, đảm bảo rằng phiên bản cũ vẫn hoạt động trong suốt quá trình nâng cấp. Điều này giúp tránh downtime.
- Recreate: Tự động tắt tất cả các pod cũ trước khi triển khai phiên bản mới, phương thức này có thể gây ra downtime.
Có thể kết hợp các chiến lược kiểm thử như canary hoặc blue-green deployment để giảm thiểu rủi ro.
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
strategy:
type: RollingUpdate # Cấu hình chiến lược triển khai
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myapp-image:v2Khả Năng Kiểm Tra Sẵn Sàng (Readiness & Liveness)
Readiness Probe và Liveness Probe là hai loại kiểm tra tình trạng thiết yếu cho các pod trong Kubernetes. Chúng giúp đảm bảo dịch vụ luôn luôn trong trạng thái hoạt động ổn định.
- Readiness Probe: Xác định khi nào một container sẵn sàng nhận yêu cầu mới và ngăn chặn người dùng truy cập vào dịch vụ khi container chưa sẵn sàng, tránh lỗi HTTP Code 503.
- Liveness Probe: Kiểm tra xem container có đang hoạt động bình thường không. Nếu không, Kubernetes sẽ tự động khởi động lại pod.
yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp
spec:
containers:
- name: myapp-container
image: myapp-image
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 20Quản Lý Tài Nguyên (Resource Requests & Limits)
Requests và Limits cho phép bạn kiểm soát việc sử dụng tài nguyên của mỗi container, từ đó tối ưu hóa hiệu suất và tránh quá tải hệ thống.
- Requests: Tài nguyên tối thiểu mà container cần để hoạt động ổn định.
- Limits: Giới hạn tối đa tài nguyên mà container được phép sử dụng, giúp tránh tình trạng chiếm dụng quá mức.
yaml
apiVersion: v1
kind: Pod
metadata:
name: resource-demo
spec:
containers:
- name: resource-demo-container
image: nginx
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"Tự Động Mở Rộng Pod (Horizontal Pod Autoscaler - HPA)
HPA cho phép tự động tăng hoặc giảm số lượng pod dựa trên chỉ số như CPU, giúp dịch vụ tự động mở rộng khi có nhu cầu tải cao.
yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70Hook PostStart & PreStop
PostStart Hook thực hiện các hành động cần thiết ngay sau khi container khởi động, trong khi PreStop Hook đảm bảo quá trình tắt của container diễn ra êm ái, giúp tránh mất dữ liệu.
yaml
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]Ngân Sách Ngừng Hoạt Động Của Pod (Pod Disruption Budget - PDB)
PDB cho phép bạn thiết lập số lượng tối đa pod có thể ngừng hoạt động tại một thời điểm, đảm bảo dịch vụ vẫn hoạt động liên tục trong quá trình bảo trì.
yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: myapp-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: myappChống Tình Trạng Gom Pod (Pod Anti-Affinity)
Pod Anti-Affinity giúp phân tán các pod trên nhiều node, tránh tình trạng tất cả pod của một ứng dụng nằm trên cùng một node, giảm thiểu rủi ro ngừng hoạt động.
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: anti-affinity-demo
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- myapp
topologyKey: "kubernetes.io/hostname" # Yêu cầu các pod không nằm trên cùng 1 node
containers:
- name: nginx
image: nginxKết Luận
Bài viết đã chia sẻ những phương pháp và cấu hình quan trọng cần thiết để đảm bảo tính sẵn sàng cao cho ứng dụng trên Kubernetes, bao gồm:
- Chiến Lược Triển Khai
- Khả Năng Kiểm Tra Sẵn Sàng
- Quản Lý Tài Nguyên
- Tự Động Mở Rộng Pod
- Các Hook Tùy Chỉnh
- Ngân Sách Ngừng Hoạt Động
- Chống Tình Trạng Gom Pod
Bên cạnh đó, còn có nhiều yếu tố khác ảnh hưởng đến độ sẵn sàng của ứng dụng mà chúng ta cũng cần chú ý. Từ góc độ DevOps, việc cấu hình hợp lý các yếu tố trên đóng góp lớn vào tính khả dụng của ứng dụng. Hy vọng rằng bài viết này cung cấp giá trị cho bạn trong việc tối ưu hóa ứng dụng của mình!
Nếu thấy bài viết hữu ích, đừng quên Upvote và Follow để nhận thông báo về các bài viết tiếp theo nhé! Chúc bạn một ngày tốt lành!
Quảng Cáo
Nếu bạn gặp khó khăn trong lĩnh vực chuyên môn hay cần hỗ trợ về mặt hệ thống và DevOps tools, hãy liên hệ với mình để được trợ giúp và tư vấn thêm nhé! hoangviet.io.vn.
source: viblo
