Chuỗi hội thảo trên web: Cái nhìn kỹ hơn về Kubernetes
Bài viết này bổ sung chuỗi hội thảo trên web về triển khai và quản lý dung lượng công việc được chứa trong cloud . Loạt bài này bao gồm các yếu tố cần thiết của containers , bao gồm quản lý vòng đời của containers , triển khai các ứng dụng đa containers , mở rộng dung lượng công việc và làm việc với Kubernetes. Nó cũng nêu bật các phương pháp hay nhất để chạy các ứng dụng trạng thái. Bài viết này bổ sung cho phần thứ tư trong loạt bài, Một cái nhìn cận cảnh hơn về Kubernetes .
Kubernetes là một công cụ điều phối containers open-souce để quản lý các ứng dụng được chứa trong containers . Trong hướng dẫn trước của loạt bài này , bạn đã cấu hình Kubernetes trên DigitalOcean. Bây giờ cụm đã được cài đặt và đang chạy, bạn có thể triển khai các ứng dụng được chứa trong đó.
Trong hướng dẫn này, bạn sẽ tìm hiểu cách các nguyên bản này hoạt động cùng nhau khi bạn triển khai Pod trong Kubernetes, hiển thị nó như một Dịch vụ và mở rộng quy mô nó thông qua Bộ điều khiển nhân bản.
Yêu cầu
Để hoàn thành hướng dẫn này, trước tiên bạn nên hoàn thành hướng dẫn trước trong loạt bài này, Bắt đầu với Kubernetes .
Bước 1 - Tìm hiểu Nguyên thủy của Kubernetes
Kubernetes tiết lộ một API mà khách hàng sử dụng để tạo, mở rộng quy mô và chấm dứt ứng dụng. Mỗi hoạt động nhắm vào một trong các đối tượng khác mà Kubernetes quản lý. Các đối tượng này tạo thành các khối xây dựng cơ bản của Kubernetes. Chúng là những cơ sở ban đầu để bạn quản lý các ứng dụng được container hóa.
Sau đây là tóm tắt về các đối tượng API chính của Kubernetes:
- Cluster : Group tài nguyên máy tính, lưu trữ và mạng.
- Nút : Server chạy trong cụm.
- Không gian tên : Phân vùng logic của một cụm.
- Pods : Đơn vị triển khai.
- Nhãn và Bộ chọn : Các cặp Khóa-Giá trị để xác định và khám phá dịch vụ.
- Dịch vụ : Bộ sưu tập các Pod thuộc cùng một ứng dụng.
- Replica Set : Đảm bảo tính khả dụng và khả năng mở rộng.
- Triển khai : Quản lý vòng đời ứng dụng.
Hãy xem xét những điều này chi tiết hơn.
Các nút chạy một cụm Kubernetes cũng được coi là các đối tượng. Chúng có thể được quản lý giống như bất kỳ đối tượng API nào khác của Kubernetes. Để cho phép phân tách hợp lý các ứng dụng, Kubernetes hỗ trợ tạo Không gian tên . Ví dụ: một tổ chức có thể phân vùng một cách hợp lý một cụm Kubernetes để chạy môi trường phát triển, thử nghiệm, dàn dựng và production . Mỗi môi trường có thể được đặt vào một Không gian tên riêng được quản lý độc lập. Kubernetes tiết lộ API của nó thông qua Master Node .
Mặc dù Kubernetes chạy các containers Docker, nhưng các containers này không thể được triển khai trực tiếp. Thay vào đó, các ứng dụng cần được đóng gói theo định dạng mà Kubernetes hiểu được. Định dạng này cho phép Kubernetes quản lý các ứng dụng được chứa trong containers một cách hiệu quả. Các ứng dụng này có thể chứa một hoặc nhiều containers cần hoạt động cùng nhau.
Đơn vị cơ bản của đóng gói và triển khai trong Kubernetes được gọi là Pod . Mỗi Pod có thể chứa một hoặc nhiều containers cần được quản lý cùng nhau. Ví dụ: containers web server (Nginx) và containers bộ nhớ cache (Redis) có thể được đóng gói cùng nhau dưới dạng Pod. Kubernetes coi tất cả các containers thuộc Pod như một đơn vị logic. Mỗi khi một Pod mới được tạo, nó dẫn đến việc tạo ra tất cả các containers được khai báo trong định nghĩa Pod. Tất cả các containers trong Pod đều có chung ngữ cảnh như địa chỉ IP, tên server và bộ nhớ. Chúng giao tiếp với nhau thông qua giao tiếp giữa các quá trình (IPC) chứ không phải là các cuộc gọi từ xa hoặc API REST.
Sau khi các containers được đóng gói và triển khai trên Kubernetes, chúng cần được hiển thị để truy cập bên trong và bên ngoài. Một số containers nhất định như database và bộ nhớ đệm không cần phải tiếp xúc với thế giới bên ngoài. Vì API và giao diện user web sẽ được truy cập trực tiếp bởi những người tiêu dùng và user cuối khác, nên chúng sẽ phải được công khai. Trong Kubernetes, containers được hiển thị bên trong hoặc bên ngoài dựa trên policy . Cơ chế này sẽ giảm thiểu rủi ro của việc để lộ dung lượng công việc nhạy cảm như database cho công chúng.
Các group trong Kubernetes được hiển thị thông qua Dịch vụ . Mỗi Dịch vụ được khai báo là một điểm cuối bên trong hoặc bên ngoài cùng với thông tin về cổng và giao thức. Người tiêu dùng nội bộ bao gồm các Pod khác và người tiêu dùng bên ngoài như ứng dụng client API dựa vào Dịch vụ Kubernetes để tương tác cơ bản. Dịch vụ hỗ trợ giao thức TCP và UDP.
Mỗi đối tượng trong Kubernetes, chẳng hạn như Pod hoặc Service, được liên kết với metadata bổ sung được gọi là Nhãn và Bộ chọn . Nhãn là các cặp khóa / giá trị được gắn vào một đối tượng Kubernetes. Các nhãn này xác định duy nhất một hoặc nhiều đối tượng API. Bộ chọn liên kết một đối tượng Kubernetes với một đối tượng khác. Ví dụ: một Bộ chọn được xác định trong Dịch vụ giúp Kubernetes tìm thấy tất cả các Group có Nhãn phù hợp với giá trị của Bộ chọn. Sự liên kết này cho phép khám phá động các đối tượng. Các đối tượng mới được tạo trong thời gian chạy với các Nhãn giống nhau sẽ được phát hiện ngay lập tức và được liên kết với các Bộ chọn tương ứng. Cơ chế khám phá dịch vụ này cho phép cấu hình động hiệu quả chẳng hạn như các hoạt động mở rộng và mở rộng quy mô.
Một trong những lợi thế của việc chuyển sang container là mở rộng quy mô nhanh chóng. Vì các containers có trọng lượng nhẹ khi so sánh với máy ảo nên bạn có thể mở rộng quy mô chúng trong vài giây. Để có một cài đặt có khả năng mở rộng và khả dụng cao, bạn cần triển khai nhiều version ứng dụng của bạn và đảm bảo số lượng version tối thiểu của ứng dụng này luôn chạy. Để giải quyết cấu hình này của các ứng dụng được chứa trong containers , Kubernetes đã giới thiệu khái niệm Bộ bản sao , được thiết kế để chạy một hoặc nhiều Group mọi lúc. Khi nhiều version của Group cần chạy trong một cụm, chúng được đóng gói dưới dạng Bộ bản sao. Kubernetes sẽ đảm bảo số lượng Group được xác định trong Bộ bản sao luôn ở chế độ đang chạy. Nếu một Pod bị kết thúc do sự cố phần cứng hoặc cấu hình, máy bay điều khiển Kubernetes sẽ ngay lập tức chạy một Pod khác.
Đối tượng Triển khai là sự kết hợp của Group và Bộ bản sao. Nguyên thủy này mang lại các khả năng giống như PaaS cho các ứng dụng Kubernetes. Nó cho phép bạn thực hiện nâng cấp luân phiên triển khai hiện có với thời gian chết tối thiểu. Việc triển khai cũng cho phép các mẫu như triển khai canary và triển khai xanh lam / xanh lá cây. Họ xử lý các phần thiết yếu của quản lý vòng đời ứng dụng (ALM) của các ứng dụng được đóng gói.
Bước 2 - Liệt kê các node và không gian tên Kubernetes
Giả sử bạn đã làm theo các bước để cài đặt Cụm Kubernetes trong DigitalOcean , hãy chạy các lệnh sau để liệt kê tất cả các Nút và Không gian tên có sẵn:
- kubectl get nodes
OutputNAME STATUS ROLES AGE VERSION spc3c97hei-master-1 Ready master 10m v1.8.7 spc3c97hei-worker-1 Ready <none> 4m v1.8.7 spc3c97hei-worker-2 Ready <none> 4m v1.8.7
- kubectl get namespaces
OutputNAME STATUS AGE default Active 11m kube-public Active 11m kube-system Active 11m stackpoint-system Active 4m
Khi không có Không gian tên nào được chỉ định, kubectl
nhắm đến Không gian tên mặc định.
Bây giờ hãy chạy một ứng dụng.
Bước 3– Tạo và triển khai một group
Các đối tượng Kubernetes được khai báo trong các file YAML và được gửi đến Kubernetes thông qua kubectl
CLI. Hãy xác định một Pod và triển khai nó.
Tạo một file YAML mới có tên là Simple-Pod.yaml
:
- nano Simple-Pod.yaml
Thêm mã sau để xác định một Pod với một containers dựa trên web server Nginx. Nó được hiển thị trên cổng 80
qua giao thức TCP. Chú ý rằng định nghĩa chứa name
nhãn và env
. Ta sẽ sử dụng các nhãn đó để xác định và cấu hình các Group cụ thể.
apiVersion: "v1" kind: Pod metadata: name: web-pod labels: name: web env: dev spec: containers: - name: myweb image: nginx ports: - containerPort: 80 name: http protocol: TCP
Chạy lệnh sau để tạo Pod.
- kubectl create -f Simple-Pod.yaml
Outputpod "web-pod" created
Hãy xác minh việc tạo ra Pod.
- kubectl get pods
OutputNAME READY STATUS RESTARTS AGE web-pod 1/1 Running 0 2m
Trong bước tiếp theo, ta sẽ làm cho Pod này có thể truy cập Internet công cộng.
Bước 4 - Hiển thị Pod thông qua một Dịch vụ
Các dịch vụ hiển thị một bộ Group bên trong hoặc bên ngoài. Hãy xác định một Dịch vụ làm cho pod Nginx có sẵn công khai. Ta sẽ giới thiệu Nginx thông qua NodePort, một sơ đồ giúp Pod có thể truy cập thông qua một cổng tùy ý được mở trên mỗi Node của cụm.
Tạo một file mới có tên Simple-Service.yaml
chứa mã này để xác định dịch vụ cho Nginx:
apiVersion: v1 kind: Service metadata: name: web-svc labels: name: web env: dev spec: selector: name: web type: NodePort ports: - port: 80 name: http targetPort: 80 protocol: TCP
Dịch vụ phát hiện tất cả các Group trong cùng một Không gian tên trùng với Nhãn có name: web
. Phần bộ chọn của file YAML xác định rõ ràng liên kết này.
Ta chỉ định rằng Dịch vụ thuộc loại NodePort thông qua khai báo kiểu: NodePort.
Sau đó, sử dụng kubectl để gửi nó vào cụm.
- kubectl create -f Simple-Service.yml
Bạn sẽ thấy kết quả này cho biết dịch vụ đã được tạo thành công:
Outputservice "web-svc" created
Hãy lấy cổng mà Pod có sẵn.
- kubectl get services
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.3.0.1 <none> 443/TCP 28m web-svc NodePort 10.3.0.143 <none> 80:32097/TCP 38s
Từ kết quả này, ta thấy rằng Dịch vụ khả dụng trên cổng 32097
. Hãy thử kết nối với một trong các node Công nhân.
Sử dụng Control panel DigitalOcean để lấy địa chỉ IP của một trong các node Công nhân.
Sử dụng lệnh curl
để thực hiện một yêu cầu HTTP đến một trong các node trên cổng 31930
.
- curl http://your_worker_1_ip_address:32097
Bạn sẽ thấy phản hồi có chứa trang chủ mặc định của Nginx:
Output<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ... Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
Bạn đã xác định một Pod và một Dịch vụ. Bây giờ ta hãy xem xét tỷ lệ với Bộ bản sao.
Bước 5 - Các group chia tỷ lệ thông qua Bộ bản sao
Bộ Bản sao đảm bảo ít nhất một số Group tối thiểu đang chạy trong cụm. Hãy xóa Pod hiện tại và tạo lại ba Pod thông qua Bộ bản sao.
Đầu tiên, xóa Pod hiện có.
- kubectl delete pod web-pod
Outputpod "web-pod" deleted
Bây giờ, hãy tạo một khai báo Replica Set mới. Định nghĩa của Replica Set giống hệt với một Pod. Sự khác biệt chính là nó chứa phần tử bản sao xác định số lượng Group cần chạy. Giống như Pod, nó cũng chứa Nhãn dưới dạng metadata giúp khám phá dịch vụ.
Tạo file Simple-RS.yml
và thêm mã này vào file :
apiVersion: apps/v1beta2 kind: ReplicaSet metadata: name: web-rs labels: name: web env: dev spec: replicas: 3 selector: matchLabels: name: web template: metadata: labels: name: web env: dev spec: containers: - name: myweb image: nginx ports: - containerPort: 80 name: http protocol: TCP
Lưu và đóng file .
Bây giờ hãy tạo Bộ bản sao:
- kubectl create -f Simple-RS.yml
Outputreplicaset "web-rs" created
Sau đó, kiểm tra số lượng Group :
- kubectl get pods
OutputNAME READY STATUS RESTARTS AGE web-rs-htb58 1/1 Running 0 38s web-rs-khtld 1/1 Running 0 38s web-rs-p5lzg 1/1 Running 0 38s
Khi ta truy cập Dịch vụ thông qua NodePort, yêu cầu sẽ được gửi đến một trong các Group do Bộ bản sao quản lý.
Hãy kiểm tra chức năng của Group bản sao bằng cách xóa một trong các Group và xem điều gì sẽ xảy ra:
- kubectl delete pod web-rs-p5lzg
Outputpod "web-rs-p5lzg" deleted
Nhìn lại vỏ:
- kubectl get pods
OutputNAME READY STATUS RESTARTS AGE web-rs-htb58 1/1 Running 0 2m web-rs-khtld 1/1 Running 0 2m web-rs-fqh2f 0/1 ContainerCreating 0 2s web-rs-p5lzg 1/1 Running 0 2m web-rs-p5lzg 0/1 Terminating 0 2m
Ngay sau khi Pod bị xóa, Kubernetes đã tạo một Pod khác đảm bảo duy trì số lượng mong muốn.
Bây giờ ta hãy xem xét Triển khai.
Bước 6 - Xử lý các Triển khai
Mặc dù bạn có thể triển khai containers dưới dạng Group và Bộ bản sao, Triển khai giúp nâng cấp và vá ứng dụng của bạn dễ dàng hơn. Bạn có thể nâng cấp Pod tại chỗ bằng cách sử dụng Triển khai, điều mà bạn không thể làm với Bộ bản sao. Điều này giúp bạn có thể triển khai version ứng dụng mới với thời gian chết tối thiểu. Chúng mang lại các khả năng giống như PaaS để quản lý ứng dụng.
Xóa Tập bản sao hiện có trước khi tạo Triển khai. Thao tác này cũng sẽ xóa các Group được liên kết:
- kubectl delete rs web-rs
Outputreplicaset "web-rs" deleted
Bây giờ hãy xác định một Triển khai mới. Tạo file Simple-Deployment.yaml
và thêm mã sau:
apiVersion: apps/v1beta2 kind: Deployment metadata: name: web-dep labels: name: web env: dev spec: replicas: 3 selector: matchLabels: name: web template: metadata: labels: name: web spec: containers: - name: myweb image: nginx ports: - containerPort: 80
Tạo một triển khai và xác minh việc tạo.
- kubectl create -f Simple-Deployment.yml
Outputdeployment "web-dep" created
Xem các triển khai:
- kubectl get deployments
OutputNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE web-dep 3 3 3 3 1m
Vì Triển khai dẫn đến việc tạo Group , sẽ có ba Group chạy theo khai báo bản sao trong file YAML.
- kubectl get pods
OutputNAME READY STATUS RESTARTS AGE web-dep-8594f5c765-5wmrb 1/1 Running 0 2m web-dep-8594f5c765-6cbsr 1/1 Running 0 2m web-dep-8594f5c765-sczf8 1/1 Running 0 2m
Dịch vụ ta đã tạo trước đó sẽ tiếp tục định tuyến các yêu cầu đến các Group được tạo bởi Triển khai. Đó là do các Nhãn chứa các giá trị giống như định nghĩa Pod ban đầu.
Làm sạch tài nguyên bằng cách xóa Triển khai và Dịch vụ.
- kubectl delete deployment web-dep
Outputdeployment "web-dep" deleted
- kubectl delete service web-svc
Outputservice "web-svc" deleted
Để biết thêm chi tiết về Triển khai, hãy tham khảo tài liệu Kubernetes .
Kết luận
Trong hướng dẫn này, bạn đã khám phá các khối xây dựng cơ bản của Kubernetes khi triển khai web server Nginx bằng Pod, Dịch vụ, Bộ bản sao và Triển khai.
Trong phần tiếp theo của loạt bài này, bạn sẽ học cách đóng gói, triển khai, mở rộng quy mô và quản lý một ứng dụng nhiều containers .
Các tin liên quan