Bài viết thuộc series “Service Mesh on Kubernetes”
Giới thiệu
Ở bài trước ta đã tìm hiểu cách cài đặt Istio lên Kubernetes. Ở bài này chúng ta sẽ cùng làm ví dụ đầu tiên với Istio.
Ứng dụng ta làm ở bài này bao gồm hai Services là Web App và Catalog.
Thay vì để chúng gọi nhau như bình thường thì ta sẽ nhúng Istio Sidecar Proxy (Data Plane) vào hai Services này để chúng gọi nhau thông qua Proxy, lúc này thì toàn bộ Request ra hoặc vào của hai Services đều được theo dõi bởi Istio Sidecar Proxy.
Chuẩn bị
Ta tải source code ở đây Istio In Action, toàn bộ ví dụ trong series này đều nằm trong source code trên.
Tiếp theo, ta tạo một namespace
tên là istio-action
cho toàn bộ ví dụ trong series.
kubectl create ns istio-action
Chuyển namespace
trên thành namespace
mặc định.
kubectl config set-context $(kubectl config current-context) --namespace=istio-action
Triển khai Catalog Service
Đầu tiên ta sẽ tạo Catalog Service, xem thử cấu hình của Catalog Service.
cat services/catalog/kubernetes/catalog.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: catalog
---
apiVersion: v1
kind: Service
metadata:
labels:
app: catalog
name: catalog
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 3000
selector:
app: catalog
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: catalog
version: v1
name: catalog
spec:
replicas: 1
selector:
matchLabels:
app: catalog
version: v1
template:
metadata:
labels:
app: catalog
version: v1
spec:
serviceAccountName: catalog
containers:
- env:
- name: KUBERNETES_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: istioinaction/catalog:latest
imagePullPolicy: IfNotPresent
name: catalog
ports:
- containerPort: 3000
name: http
protocol: TCP
securityContext:
privileged: false
Trước khi tạo Catalog Service ta sẽ nhúng thêm đoạn cấu hình của Istio Sidecar Proxy vào, có hai cách để làm như sau:
- Dùng câu lệnh
istioctl kube-inject
- Bật tự động nhúng
Nhúng Sidecar Proxy thủ công
Để nhúng Sidecar Proxy thủ công ta sẽ dùng câu lệnh istioctl
, thực hiện như sau.
istioctl kube-inject -f services/catalog/kubernetes/catalog.yaml
Ta sẽ thấy nó in ra kết quả rất dài, istioctl
sẽ thêm vào tệp tin cấu hình ban đầu thuộc tính initContainers
và một Container tên là istio-proxy
.
...
apiVersion: apps/v1
kind: Deployment
...
image: docker.io/istio/proxyv2:1.15.1
name: istio-proxy
ports:
- containerPort: 15090
name: http-envoy-prom
protocol: TCP
...
initContainers:
- args:
- istio-iptables
- -p
- "15001"
- -z
- "15006"
- -u
- "1337"
- -m
- REDIRECT
- -i
- '*'
- -x
- ""
- -b
- '*'
- -d
- 15090,15021,15020
- --log_output_level=default:info
image: docker.io/istio/proxyv2:1.15.1
name: istio-init
...
securityContext:
allowPrivilegeEscalation: false
capabilities:
add:
- NET_ADMIN
- NET_RAW
drop:
- ALL
Lưu ý: để cấu hình được Istio Sidecar Proxy thì Kubernetes Cluster phải có quyền NET_ADMIN và NET_RAW
Ta có thể dùng kube-inject
để sửa tệp tin Deployment như trên và triển khai nó lên Kubernetes, hoặc bật tự động nhúng như ở phần tiếp theo, mình gợi ý là các bạn nên làm theo cách thứ hai.
Nhúng Sidecar Proxy tự động
Để bật tự động nhúng cho Istio rất đơn giản, ta chỉ cần đánh label tên là istio-injection=enabled
vào namespace
mà ta cần.
Ví dụ ở bài này ta đang làm trên namespace
tên là istio-action
.
kubectl label namespace istio-action istio-injection=enabled
Bây giờ khi ta tạo Deployment thì Istio sẽ tự động nhúng Sidecar Proxy vào.
kubectl apply -f services/catalog/kubernetes/catalog.yaml
serviceaccount/catalog created
service/catalog created
deployment.apps/catalog created
Kiểm tra.
kubectl get pod
NAME READY STATUS RESTARTS AGE
catalog-5d8f997684-fjvf5 0/2 PodInitializing 0 4s
Nếu STATUS
chưa ở trạng thái Running
thì chờ một chút và gọi lại.
kubectl get pod
NAME READY STATUS RESTARTS AGE
catalog-5d8f997684-fjvf5 2/2 Running 0 61s
Nếu thấy STATUS
ở trạng thái Running
thì tất cả đã chạy xong, lúc này ta sẽ thấy ở trường READY
là 2/2
tương ứng với hai Container, một Container là ứng dụng Catalog của ta và Container còn lại là istio-proxy
Sidecar.
Kiểm tra thử Catalog Service của ta đang chạy với Istio Proxy thì có xử lý được Request hay không.
kubectl run -i -n default --rm --restart=Never dummy --image=curlimages/curl --command -- sh -c 'curl -s http://catalog.istio-action/items/1'
{
"id": 1,
"color": "amber",
"department": "Eyewear",
"name": "Elinor Glasses",
"price": "282.00"
}
Nếu thấy được kết quả JSON như trên thì ta đã chạy thành công 😁.
Triển khai Webapp Service
Tiếp theo ta tạo Webapp Service, xem thử cấu hình của Webapp Service.
cat services/webapp/kubernetes/webapp.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: webapp
---
apiVersion: v1
kind: Service
metadata:
labels:
app: webapp
name: webapp
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 8080
selector:
app: webapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: webapp
name: webapp
spec:
replicas: 1
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
serviceAccountName: webapp
containers:
- env:
- name: KUBERNETES_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: CATALOG_SERVICE_HOST
value: catalog.istio-action
- name: CATALOG_SERVICE_PORT
value: "80"
- name: FORUM_SERVICE_HOST
value: forum.istio-action
- name: FORUM_SERVICE_PORT
value: "80"
image: istioinaction/webapp:latest
imagePullPolicy: IfNotPresent
name: webapp
ports:
- containerPort: 8080
name: http
protocol: TCP
securityContext:
privileged: false
Triển khai
kubectl apply -f services/webapp/kubernetes/webapp.yaml
Đợi khi nó tạo xong và gọi thử vào Webapp Service.
kubectl run -i -n default --rm --restart=Never dummy --image=curlimages/curl --command -- sh -c 'curl -s http://webapp.istio-action/api/catalog/items/1'
Khi ta gọi vào Webapp Service thì nó sẽ gửi Request qua Catalog Service để lấy dữ liệu, để dễ hình dung thì các bạn truy cập vào Webapp Service ở trên trình duyệt, chạy câu lệnh port-forward
.
kubectl port-forward deploy/webapp 8080:8080
Mở trình duyệt và truy cập vào localhost:8080
, ta sẽ thấy giao diện như bên dưới.
Bây giờ thì tất cả các Request vào và ra khỏi Webapp Service và Catalog Service đều đi qua Istio Proxy.
Như ta đã nói ở bài đầu tiên thì việc này sẽ giúp Istio có thể kiểm soát và theo dõi được toàn bộ Request trong hệ thống, đây là tính năng của cái gọi là Service Mesh mà người ta vẫn hay nói.
Kết luận
Vậy là ta đã làm xong ví dụ đầu tiên với Istio, ở bài tiếp theo ta sẽ nói tiếp một vài tính năng quan trọng của Istio và cách để theo dõi các Request.
Tác giả @Quân Huỳnh
Nếu bài viết có gì sai hoặc cần cập nhật thì liên hệ Admin.
Tham gia nhóm chat của DevOps VN tại Telegram.
Kém tiếng Anh và cần nâng cao trình độ giao tiếp: Tại sao bạn học không hiệu quả?