Ngày 55 - State và Ingress trong Kubernetes
Trong bài viết cuối cùng về Kubernetes, chúng ta sẽ xem xét State và Ingress và các ứng dụng có trạng thái
Nội dung
- 90 Ngày DevOps 🚀
- Ngày 1 - Giới thiệu
- Ngày 2 - Trách nhiệm của kỹ sư DevOps
- Ngày 3 - Vòng đời DevOps - Tập trung vào ứng dụng
- Ngày 4 - DevOps & Agile
- Ngày 5 - Kế hoạch > Viết mã > Xây dựng > Kiểm thử > Phát hành > Triển khai > Vận hành > Giám sát >
- Ngày 6 - DevOps - Những câu chuyện thực tế
- Ngày 7 - Bức tranh toàn cảnh: DevOps & Học một ngôn ngữ lập trình
- Ngày 8 - Thiết lập môi trường DevOps cho Go & Hello World
- Ngày 9 - Giải thích mã Hello World
- Ngày 10 - Không gian làm việc của Go
- Ngày 11 - Biến, hằng số & kiểu dữ liệu
- Ngày 12 - Nhận thông tin đầu vào sử dụng con trỏ và chương trình hoàn thiện
- Ngày 13 - Tweet tiến trình của bạn với ứng dụng mới của chúng ta
- Ngày 14 - Bức tranh lớn: DevOps và Linux
- Ngày 15 - Các lệnh Linux cho DevOps (thực tế là tất cả mọi người)
- Ngày 16 - Quản lý Hệ thống Linux, Hệ thống Tệp & Lưu trữ
- Ngày 17 - Text Editors - nano vs vim
- Ngày 18 - SSH & máy chủ web (LAMP)
- Ngày 19 - Tự động hóa các tác vụ với các tập lệnh bash
- Ngày 20 - Thiết lập máy trạm phát triển - những điều tuyệt vời
- Ngày 21 - Bức tranh toàn cảnh: DevOps và Mạng máy tính
- Ngày 22 - Mô hình 7 Lớp OSI
- Ngày 23 - Giao thức mạng
- Ngày 24 - Tự Động Hóa Thiết Lập Mạng
- Ngày 25 - Lập trình Python trong tự động hóa mạng
- Ngày 26 - Xây dựng Lab
- Ngày 27 - Thực hành với Python
- Ngày 28 - Bức tranh toàn cảnh: DevOps & The Cloud
- Ngày 29 - Kiến thức cơ bản về Microsoft Azure
- Ngày 30 - Mô hình bảo mật Microsoft Azure
- Ngày 31 - Mô hình Điện toán Microsoft Azure
- Ngày 32 - Mô hình lưu trữ và cơ sở dữ liệu Microsoft Azure
- Ngày 33 - Mô hình Mạng Microsoft Azure + Quản lý Azure
- Ngày 34 - Thực hành với Microsoft Azure
- Ngày 35 - Bức tranh toàn cảnh: Git - Quản lý phiên bản
- Ngày 36 - Cài đặt & Cấu hình Git
- Ngày 37 - Giới thiệu về Git
- Ngày 38 - Staging & Changing
- Ngày 39 - Xem, unstaging, loại bỏ & khôi phục
- Ngày 40 - Mạng xã hội dành cho code
- Ngày 41 - Quy trình làm việc với mã nguồn mở
- Ngày 42 - Bức tranh toàn cảnh: Containers
- Ngày 43 - Docker là gì & Cài đặt
- Ngày 44 - Docker image & Thực hành với Docker Desktop
- Ngày 45 - Phân tích một Docker Image
- Ngày 46 - Docker Compose
- Ngày 47 - Docker Networking & Security
- Ngày 48 - Các lựa chọn thay thế cho Docker
- Ngày 49 - Bức tranh toàn cảnh: Kubernetes
- Ngày 50 - Chọn nền tảng chạy Kubernetes
- Ngày 51 - Triển khai Kubernetes cluster đầu tiên
- Ngày 52 - Thiết lập Kubernetes cluster đa node
- Ngày 53 - Tổng quan về Rancher - Thực hành
- Ngày 54 - Triển khai ứng dụng Kubernetes
- Ngày 55 - State và Ingress trong Kubernetes
- Ngày 56 - Bức tranh toàn cảnh: Cơ sở hạ tầng dưới dạng mã (IaC)
- Ngày 57 - Giới thiệu về Terraform
- Ngày 58 - Ngôn ngữ cấu hình HashiCorp (HCL)
- Ngày 59 - Tạo máy ảo với Terraform và biến
- Ngày 60 - Docker Containers, Provisioners & Modules
- Ngày 61 - Kubernetes & Đa môi trường
- Ngày 62 - Kiểm thử, Công cụ và Các phương pháp thay thế
- Ngày 63 - Bức tranh toàn cảnh: Quản lý cấu hình
- Ngày 64 - Ansible: Bắt đầu
- Ngày 65 - Ansible Playbooks
- Ngày 66 - Tiếp tục với Ansible Playbooks...
- Ngày 67 - Sử dụng Role & Triển khai Loadbalancer
- Ngày 68 - Tags, Variables, Inventory & Database Server config
- Ngày 69 - Tất cả những thứ còn lại của Ansible - Automation Controller, AWX, Vault
- Ngày 70 - Bức tranh toàn cảnh: CI/CD Pipelines
- Ngày 71 - Jenkins là gì?
- Ngày 72 - Làm quen với Jenkins
- Ngày 73 - Xây dựng Jenkins pipeline
- Ngày 74 - Hello World - Jenkinsfile App Pipeline
- Ngày 75 - Tổng quan về GitHub Actions
- Ngày 76 - Tổng quan về ArgoCD
- Ngày 77 - Bức tranh toàn cảnh: Giám sát
- Ngày 78 - Thực hành với công cụ giám sát
- Ngày 79 - Bức tranh toàn cảnh: Quản lý log
- Ngày 80 - ELK Stack
- Ngày 81 - Fluentd & FluentBit
- Ngày 82 - EFK Stack
- Ngày 83 - Trực quan hóa dữ liệu - Grafana
- Ngày 84 - Bức tranh toàn cảnh: Quản lý dữ liệu
- Ngày 85 - Dịch vụ dữ liệu
- Ngày 86 - Sao lưu tất cả các nền tảng
- Ngày 87 - Thực hành với sao lưu & phục hồi
- Ngày 88 - Sao lưu theo hướng tập trung vào ứng dụng
- Ngày 89 - Khôi phục thảm họa (DR)
- Ngày 90 - Dữ liệu & ứng dụng: Tính di động
Nội dung khoá học
- 90 Ngày DevOps 🚀
- Ngày 1 - Giới thiệu
- Ngày 2 - Trách nhiệm của kỹ sư DevOps
- Ngày 3 - Vòng đời DevOps - Tập trung vào ứng dụng
- Ngày 4 - DevOps & Agile
- Ngày 5 - Kế hoạch > Viết mã > Xây dựng > Kiểm thử > Phát hành > Triển khai > Vận hành > Giám sát >
- Ngày 6 - DevOps - Những câu chuyện thực tế
- Ngày 7 - Bức tranh toàn cảnh: DevOps & Học một ngôn ngữ lập trình
- Ngày 8 - Thiết lập môi trường DevOps cho Go & Hello World
- Ngày 9 - Giải thích mã Hello World
- Ngày 10 - Không gian làm việc của Go
- Ngày 11 - Biến, hằng số & kiểu dữ liệu
- Ngày 12 - Nhận thông tin đầu vào sử dụng con trỏ và chương trình hoàn thiện
- Ngày 13 - Tweet tiến trình của bạn với ứng dụng mới của chúng ta
- Ngày 14 - Bức tranh lớn: DevOps và Linux
- Ngày 15 - Các lệnh Linux cho DevOps (thực tế là tất cả mọi người)
- Ngày 16 - Quản lý Hệ thống Linux, Hệ thống Tệp & Lưu trữ
- Ngày 17 - Text Editors - nano vs vim
- Ngày 18 - SSH & máy chủ web (LAMP)
- Ngày 19 - Tự động hóa các tác vụ với các tập lệnh bash
- Ngày 20 - Thiết lập máy trạm phát triển - những điều tuyệt vời
- Ngày 21 - Bức tranh toàn cảnh: DevOps và Mạng máy tính
- Ngày 22 - Mô hình 7 Lớp OSI
- Ngày 23 - Giao thức mạng
- Ngày 24 - Tự Động Hóa Thiết Lập Mạng
- Ngày 25 - Lập trình Python trong tự động hóa mạng
- Ngày 26 - Xây dựng Lab
- Ngày 27 - Thực hành với Python
- Ngày 28 - Bức tranh toàn cảnh: DevOps & The Cloud
- Ngày 29 - Kiến thức cơ bản về Microsoft Azure
- Ngày 30 - Mô hình bảo mật Microsoft Azure
- Ngày 31 - Mô hình Điện toán Microsoft Azure
- Ngày 32 - Mô hình lưu trữ và cơ sở dữ liệu Microsoft Azure
- Ngày 33 - Mô hình Mạng Microsoft Azure + Quản lý Azure
- Ngày 34 - Thực hành với Microsoft Azure
- Ngày 35 - Bức tranh toàn cảnh: Git - Quản lý phiên bản
- Ngày 36 - Cài đặt & Cấu hình Git
- Ngày 37 - Giới thiệu về Git
- Ngày 38 - Staging & Changing
- Ngày 39 - Xem, unstaging, loại bỏ & khôi phục
- Ngày 40 - Mạng xã hội dành cho code
- Ngày 41 - Quy trình làm việc với mã nguồn mở
- Ngày 42 - Bức tranh toàn cảnh: Containers
- Ngày 43 - Docker là gì & Cài đặt
- Ngày 44 - Docker image & Thực hành với Docker Desktop
- Ngày 45 - Phân tích một Docker Image
- Ngày 46 - Docker Compose
- Ngày 47 - Docker Networking & Security
- Ngày 48 - Các lựa chọn thay thế cho Docker
- Ngày 49 - Bức tranh toàn cảnh: Kubernetes
- Ngày 50 - Chọn nền tảng chạy Kubernetes
- Ngày 51 - Triển khai Kubernetes cluster đầu tiên
- Ngày 52 - Thiết lập Kubernetes cluster đa node
- Ngày 53 - Tổng quan về Rancher - Thực hành
- Ngày 54 - Triển khai ứng dụng Kubernetes
- Ngày 55 - State và Ingress trong Kubernetes
- Ngày 56 - Bức tranh toàn cảnh: Cơ sở hạ tầng dưới dạng mã (IaC)
- Ngày 57 - Giới thiệu về Terraform
- Ngày 58 - Ngôn ngữ cấu hình HashiCorp (HCL)
- Ngày 59 - Tạo máy ảo với Terraform và biến
- Ngày 60 - Docker Containers, Provisioners & Modules
- Ngày 61 - Kubernetes & Đa môi trường
- Ngày 62 - Kiểm thử, Công cụ và Các phương pháp thay thế
- Ngày 63 - Bức tranh toàn cảnh: Quản lý cấu hình
- Ngày 64 - Ansible: Bắt đầu
- Ngày 65 - Ansible Playbooks
- Ngày 66 - Tiếp tục với Ansible Playbooks...
- Ngày 67 - Sử dụng Role & Triển khai Loadbalancer
- Ngày 68 - Tags, Variables, Inventory & Database Server config
- Ngày 69 - Tất cả những thứ còn lại của Ansible - Automation Controller, AWX, Vault
- Ngày 70 - Bức tranh toàn cảnh: CI/CD Pipelines
- Ngày 71 - Jenkins là gì?
- Ngày 72 - Làm quen với Jenkins
- Ngày 73 - Xây dựng Jenkins pipeline
- Ngày 74 - Hello World - Jenkinsfile App Pipeline
- Ngày 75 - Tổng quan về GitHub Actions
- Ngày 76 - Tổng quan về ArgoCD
- Ngày 77 - Bức tranh toàn cảnh: Giám sát
- Ngày 78 - Thực hành với công cụ giám sát
- Ngày 79 - Bức tranh toàn cảnh: Quản lý log
- Ngày 80 - ELK Stack
- Ngày 81 - Fluentd & FluentBit
- Ngày 82 - EFK Stack
- Ngày 83 - Trực quan hóa dữ liệu - Grafana
- Ngày 84 - Bức tranh toàn cảnh: Quản lý dữ liệu
- Ngày 85 - Dịch vụ dữ liệu
- Ngày 86 - Sao lưu tất cả các nền tảng
- Ngày 87 - Thực hành với sao lưu & phục hồi
- Ngày 88 - Sao lưu theo hướng tập trung vào ứng dụng
- Ngày 89 - Khôi phục thảm họa (DR)
- Ngày 90 - Dữ liệu & ứng dụng: Tính di động
Mục lục
- State và Ingress trong Kubernetes
- Ứng dụng có trạng thái
- Deployment với StatefulSet
- Persistant Volumes | Claims | StorageClass
- Persistent Volume
- Persistent Volume Claim
- ConfigMaps | Secrets
- StorageClass
- Tổng kết
- Cấu hình StorageClass
- Chơi game | Ý tôi là truy cập vào ứng dụng siêu quan trọng của chúng ta
- Tìm hiểu về Ingress
- Ingress là gì?
- Khi nào bạn cần ingress?
- Cấu hình Ingress với Minikube
- Tài liệu tham khảo
State và Ingress trong Kubernetes
Trong bài viết cuối cùng về Kubernetes, chúng ta sẽ xem xét State và Ingress.
Mọi thứ chúng ta đã nói cho tới nay là về phi trạng thái (stateless), phi trạng thái có nghĩa rằng các ứng dụng của chúng ta không quan tâm tới mạng nào đang được sử dụng và không cần bất cứ bộ lưu trữ vĩnh viễn nào. Trong khi các ứng dụng có trạng thái ví dụ như cơ sở dữ liệu, để các ứng dụng như vậy hoạt động chính xác, bạn sẽ cần đảm bảo rằng các pods có thể liên lạc với nhau thông qua một định danh duy nhất không thay đổi (hostnames, IPs,...) Ví dụ về các ứng dụng có trạng thái bao gồm các MySQL clusters, Redis, Kafka, MongoDB và các ứng dụng khác. Về cơ bản, bất kỳ ứng dụng nào lưu trữ dữ liệu.
Ứng dụng có trạng thái
StatefulSets đại diện cho một tập hợp các pods có định danh duy nhất, không đổ và hostnames ổn định mà Kubernetes sẽ duy trì bất kể chúng được lập lịch chạy ở đâu. Thông tin trạng thái và dữ liệu có khả năng phục hồi khác cho bất kỳ Stateful Set Pod cụ thể nào được duy trì trong persistent disk storage (bộ lưu trữ đĩa) được liên kết với StatefulSet.
Deployment với StatefulSet
- Việc tạo ra các bản sao của ứng dụng có trạng thái khó khăn hơn.
- Việc tạo ra các bản sau của các pods trong một deployment (ứng dụng phi trạng thái) là giống hệt nhau và có thể hoán đổi.
- Tạo ra các pods theo thứ tự ngẫu nhiên với các giá trị băm ngẫu nhiên.
- Một Service cân bằng tải cho bất kỳ pod nào.
Khi nói đến StatefulSets hoặc ứng dụng có trạng thái, những điều trên trở nên khó khăn hơn.
- Không thể tạo hoặc xoá cùng một lúc.
- Không thể được truy cập một cách ngẫu nhiên.
- Các bản sao của pods không giống hệt nhau.
Bạn có thể thấy một số thứ trong demo của chúng ta ngay sau đây về việc mỗi pods có một định danh riêng. Với ứng dụng phi trạng thái, bạn sẽ thấy các tên ngẫu nhiên, ví dụ: app-7469bbb6d7-9mhxd
trong khi ứng dụng có trạng thái sẽ được sắp xếp nghiêm chỉnh hơn với mongo-0
và khi được mở rộng quy mô, nó sẽ ạo một pod mới có tên là mongo-1
.
Các pods này được tạo từ cùng một cấu hình, nhưng chúng không thể hoán đổi cho nhau. Mỗi nhóm StatefulSet có một mã định danh cố định trong mọi lần lập lịch lại. Điều này là cần thiết bởi vì khi chúng ta yêu cầu các workloads có trạng thái ví dụ như cơ sở dữ liệu nơi chúng ta có các yêu cầu ghi và đọc, chúng ta không thể có hai pods cùng ghi một lúc mà không biết về việc này vì chúng sẽ khiến dữ liệu mất đi tính nhất quán. Chúng ta cần đảm bảo rằng chỉ một trong số các pods của chúng ta ghi vào cơ sở dữ liệu tại bất kỳ thời điểm nào, tuy nhiên, chúng ta có thể có nhiều pods đọc dữ liệu đó.
Mỗi pod trong StatefulSet sẽ có quyền truy cập vào persistent volume và một bản sao của cơ sở dữ liệu để đọc từ đó, và nó sẽ được cập nhật liên tự từ bản gốc. Một điều thú vị khác cần lưu ý là mỗi pod cũng sẽ lưu trữ trạng thái pod của nó trong persistent volume này, nếu sau đó mongo-0
bị chết thì một pod mới sẽ được cung cấp và nó sẽ tiếp quản trạng thái pod được lưu trong bộ lưu trữ.
TLDR; StatefulSets vs Deployments
- Tên nhóm có thể được dự đoán =
mongo-0
- DNS cố định
- Định danh pod - giữ nguyên State, giữ nguyên Role
- Tạo ra các bản sao của các ứng dụng có trạng thái rất phức tạp
- Có rất nhiều việc bạn phải làm:
- Định cấu hình cho các bản sao và đồng bộ hoá dữ liệu
- Tạo các bộ nhớ được chia sẻ
- Quản lý & sao lưu
- Có rất nhiều việc bạn phải làm:
Persistant Volumes | Claims | StorageClass
Làm cách nào để duy trì dữ liệu trong Kubernetes?
Chúng ta đã đề cập ở trên nhắc tới ứng dụng có trạng thái, chúng ta phải lưu trữ trạng thái ở đâu đó và đây là lúc cần có volume (một ổ đĩa), Kubernetes không cup cấp tính bền vững.
Chúng ta yêu cầu lớp lưu trữ không phụ thuộc vào vòng đời của pod. Bộ lưu trữ này phải luôn có sẵn và truy cập được từ tất cả các Kubernetes nodes. Bộ lưu trữ cũng phải nằm ngoài Kubernetes cluster để có thể tồn tại độc lập ngay cả khi Kubernetes cluster gặp sự cố.
Persistent Volume
- Một tài nguyên của cluster (như CPU và RAM) để lưu trữ dữ liệu
- Được tạo thông qua một tệp YAML
- Cần lưu trữ vật lý thực tế (Network-attached storage - NAS)
- Tích hợp từ bên ngoài vào Kubernetes cluster của bạn
- Bạn có thể có nhiều loại lưu trữ khi sử dụng các kho lưu trữ của mình
- PVs không được chia theo các namespaces
- Local storage khả dụng nhưng sẽ rành riêng cho một node trong cluster
- Cơ sở dữ liệu yêu cầu tính bền vững nên sử dụng lưu trữ từ xa (NAS)
Persistent Volume Claim
Một persistent volume có thể sẵn có và đảm bảo tính sẵn sàng nhưng nếu nó không được claim bởi một ứng dụng, nó sẽ không được sử dụng.
- Được tạo thông qua một tệp YAML
- Persistent Volume Claim được sử dụng trong cấu hình pod (thuộc tính volumes)
- PVCs ở trong cùng một namespace với pod
- Volume được mount vào pod
- Pods có thể có nhiều kiểu volume type khác nhau (ConfigMap, Secret, PVC)
Một cách khác để nghĩ về PVs và PVCs như sau: PVs được tạo bởi Kubernetes Admin PVCs được tạo bởi người dùng hoặc nhà phát triển ứng dụng
Cũng có 2 loại volumes khác mà chúng ta sẽ không đi vào chi tiết nhưng có được đề cập đến:
ConfigMaps | Secrets
- Tệp cấu hình cho pod của bạn.
- Tệp certificate cho pod của bạn.
StorageClass
- Được tạo thông qua tệp YAML
- Cung cấp Persistent Volumes một cách linh hoạt khi PVC yêu cầu nó
- Mỗi storage backend có provisioner của nó
- Storage bacned được định nghĩa bằng YAML (thông qua thuộc tính provisioner)
- Trìu tượng hoá các nhà cung cấp lưu trữ ở dưới
- Xác định các thông số cho lưu trữ đó
Tổng kết
Trong bài viết ngày hôm qua, chúng ta đã được hướng dẫn cách tạo ứng dụng phi trạng thái, ở đây chúng ta sẽ làm điều tương tự nhưng sẽ triển khai workload có trạng thái sử dụng minikube cluster của mình.
Một bản tóm tắt về các lệnh minikube mà chúng ta sẽ sử dụng để có các chứ năng và các addons để sử dụng persistence là
minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p mc-demo --Kubernetes-version=1.21.2
Lệnh này sử dụng CSI-hostpath-driver, thứ cung cấp cho chúng ta storageclass, thứ mà tôi sẽ trình bày sau.
Ứng dụng được xây dựng xong sẽ trông như sau:
Bạn có thể tìm thấy tệp cấu hình YAML cho ứng dụng này tại pacman-stateful-demo.yaml
Cấu hình StorageClass
Tuy nhiên, còn một bước nữa mà chúng ta nên chạy trước khi bắt đầu triển khai ứng dụng của mình và đó là đảm bảo storageclass của chúng ta (CSI-hostpath-sc) là lưu trữ mặc định của chúng ta. Trước tiên, chúng ta có thể kiểm tra điều này bằng cách chạy lệnh kubectl get storageclass
nhưng minikube cluster sẽ hiển thị standard storageclass là mặc định, vì vậy chúng ta phải thay đổi điều đó bằng các lệnh dưới đây.
Lệnh đầu tiên này sẽ đặt CSI-hostpath-sc storageclass là mặc định.
kubectl patch storageclass csi-hostpath-sc -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
Lệnh này sẽ xoá chú thích mặc định khỏi standard StorageClass.
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
Chúng ta bắt đầu không có Pacman namespace trong cluster của mình kubectl get namespace
Chúng ta sau đó triểu khai tệp YAML của mình. kubectl create -f pacman-stateful-demo.yaml
bạn có thể thấy từ lệnh này, chúng ta đã tạo một số đối tượng trong Kubernetes cluster.
Giờ đây chúng ta đã có namespace mới được tạo.
Sao đó, như bạn có thể thấy trong ảnh tiếp theo và lệnh kubectl get all -n pacman
sẽ cho thấy có một số điều đang xảy ra trong namespace của mình. Chúng ta có các pods chạy frontend với NodeJS, chúng ta có mongo chạy backend cơ sở dữ liệu. Có các service cho Pacman và mongo truy cập vào. Chúng ta có một deployment cho Pacman và một statefulset cho mongo.
Chúng ta cũng có persistent volume và persistent volume claim, lệnh kubectl get pv
sẽ cung cấp cho chúng ta persistent volumes trong mọi namespaces và lệnh kubectl get pvc -n pacman
sẽ cung cấp cho chúng ta các persistent volume claims trong namespace pacman.
Chơi game | Ý tôi là truy cập vào ứng dụng siêu quan trọng của chúng ta
Vì chúng ta đang sử dụng Minikube và như đã đề cập trong ứng dụng phi trạng thái, chúng ta có một số trở ngại cần vượt qua khi truy cập ứng dụng của mình. Tuy nhiên, chúng ta có quyền truy cập vào ingress hoặc load balancer trong cluster của mình, service được thiết lập để tự động nhận IP từ đó có thể truy cập từ bên ngoài (bạn có thể thấy điều này ở trên trong hình ảnh chụp các thành phần trong Pacman namespace).
Đối với demo này, chúng ta sẽ sử dụng phương thức chuyển tiếp cổng để truy cập ứng dụng của mình. Bằng cách mở một terminal và chạy lệnh kubectl port-forward svc/pacman 9090:80 -n pacman
. Mở trình duyệt và giờ đây, chúng ta sẽ có quyền truy cập vào ứng dụng của mình. Nếu bạn đang chạy ứng dụng này trên AWS thì nó cũng sẽ báo vị trí trên đám mây cũng như máy chủ chạy pod của bạn trong Kubernetes, một lần nữa bạn có thể nhìn lại và thấy tên pod này trên những ảnh chụp màn hình của chúng ta ở trên.
Bây giờ chúng ta có thể chơi và ghi điểm số, sau đó nó sẽ được lưu trong cơ sở dữ liệu của chúng ta.
OK, thât tuyệt nếu chúng ta có thể có một điểm số cao nhưng điều gì sẽ xảy ra nếu chúng ta xoá pod mongo-0
? Bằng lệnh
kubectl delete pod mongo-0 -n pacman
tôi có thể xoá nó và nếu bạn vẫn ở trong ứng dụng, bạn sẽ thấy điểm số sẽ không khả dụng ít nhất trong vài giây.
Bây giờ, nếu tôi quay trở lại trò chơi của mình, tôi có thể tạo một trò chơi mới và xem điểm số cao nhất của mình. Tuy nhiên, cách duy nhất mà bạn có thể thực sự tin tôi là hãy tự mình thử và chia sẻ lên mạng xã hội về điểm số của mình!
Với việc triển khai, chúng ta có thể mở rộng quy mô ứng dụng này bằng cách sử dụng các lệnh trong phần trước nhưng nếu bạn muốn tổ chức một bữa tiệc Pacman siêu to khổng lồ, bạn có thể mở rộng quy mô bằng cách sử dụng lệnh
kubectl scale deployment pacman --replicas=10 -n pacman
Tìm hiểu về Ingress
Trước khi chúng ta kết thúc phần về Kubernetes, tôi cũng muốn đề cập đến một phần kiến thức lớn của Kubernetes, đó là ingress.
Ingress là gì?
Cho tới nay, với các ví dụ của chúng ta, chúng ta sử dụng port-forward (chuyển tiếp cổng) hoặc chúng ta sử dụng cách lệnh cụ thể trong minikube để có quyền truy cập vào các ứng dụng của mình, nhưng điều này sẽ không hoạt động trong môi trường sản xuất (production). Chúng ta sẽ muốn có một cách tốt hơn để truy cập các ứng dụng của mình trên quy mô lớn với nhiều người dùng.
Chúng ta cũng đã nói về NodePort là một tuỳ chọn, nhưng một lần nữa, điều này chỉ dành cho mục đích thử nghiệm.
Ingress cung cấp cho chúng ta một cách tốt hơn để expose ứng dụng của mình, điều này cho phép xác định các quy tắc định tuyến trong Kubernetes cluster của mình.
Đối với ingress, chúng ta sẽ tạo một yêu cầu chuyển tiếp tới internal service của ứng dụng.
Khi nào bạn cần ingress?
Nếu bạn đang sử dụng nhà cung cấp điện toán đám mây, một dịch vụ Kubernetes được quản lý rất có thể sẽ có tuỳ chọn ingress của họ hoặc họ sẽ cung cấp cho bạn tuỳ chọn cân bằng tải. Bạn không phải tự mình triển khai điều này, một trong những lợi ích của dịch vụ Kubernetes được quản lý.
Nếu bạn đang chạy cluster của mình thì bạn sẽ cần cấu hình một entrypoint If you are running your cluster then you will need to configure an entrypoint.
Cấu hình Ingress với Minikube
Trên clsuter đang chạy của tôi với tên gọi mc-demo, tôi có thể chạy lệnh sau để bật tính năng ingress trên cluster của mình.
minikube --profile='mc-demo' addons enable ingress
Nếu chúng ta kiểm tra các namespace bây giờ, bạn sẽ thấy rằng chúng ta có một namespace mới với tên ingress-nginx kubectl get ns
Bây giờ, chúng ta phải tạo cấu hình YAML cho ingress để truy cập dịch vụ pacman. Tôi đã thêm tệp này vào repository này pacman-ingress.yaml
Sau đó, chúng ta có thể tạo nó trong ingress namespace của chúng ta với lệnh
kubectl create -f Pacman-ingress.yaml
Sau đó, nếu chúng ta chạy kubectl get ingress -n Pacman
Sau đó, tôi được thông báo rằng vì chúng ta đang sử dụng minikube chạy trên WSL2 trong Windows nên chúng ta phải tạo minikube tunnel bằng cách sử dụng lệnh
minikube tunnel --profile=mc-demo
Nhưng tôi vẫn không thể truy cập vào 192.168.49.2 và chơi game Pacman của mình.
Nếu bất kỳ ai có hoặc có thể làm cho điều này hoạt động trên Windows và WSL, tôi sẽ rất biết ơn nếu bạn bổ sung vào phần này. Tôi cảm thấy bài viết này sẽ giúp xác định nguyên nhân có thể khiến ingress không hoạt động với WSL Configuring Ingress to run Minikube on WSL2 using Docker runtime
Tài liệu tham khảo
Nếu bạn có tài liệu MIỄN PHÍ mà bạn đã sử dụng thì vui lòng thêm chúng vào đây thông qua PR cho repository này và tôi sẽ sẵn lòng thêm chúng vào.
- Kubernetes StatefulSet simply explained
- Kubernetes Volumes explained
- Kubernetes Ingress Tutorial for Beginners
- Kubernetes Documentation
- TechWorld with Nana - Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]
- TechWorld with Nana - Kubernetes Crash Course for Absolute Beginners
- Kunal Kushwaha - Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!
Bài viết này kết thúc phần Kubernetes của chúng ta, có rất nhiều nội dung khác mà chúng ta có thể trình bày về Kubernetes và 7 ngày chỉ giúp chúng ta có được kiến thức cơ bản, mọi người có thể xem qua 100DaysOfKubernetes để có một cái nhìn đầy đủ hơn.
Tiếp theo, chúng ta sẽ xem xét đến Cơ sở hạ tầng dưới dạng mã (Infrastructure as Code - IaC) và tầm quan trọng của nó từ góc độ DevOps.
Hẹn gặp lại vào ngày 56.
Các bài viết là bản tiếng Việt của tài liệu 90DaysOfDevOps của Micheal Cade và có qua sửa đổi, bổ sung. Tất cả đều có license [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License][cc-by-nc-sa].