Mục tiêu: Từ client có thể conenct tới mạng VPC network thông qua VPN-server-Pritunl.

Phân hoạch địa chỉ IP

• VPN server:
• IP public: 103.56.156.114
• IP VPC: 10.20.1.47
• VM local
• IP VPC: 10.20.1.91

Yêu cầu: Client có thể connect tới VM local dải 10.20.1.91.

Các bước cài đặt trên VPN-server

apt-get update

apt-get -y upgrade

echo "deb http://repo.pritunl.com/stable/apt focal main" | sudo tee /etc/apt/sources.list.d/pritunl.list

echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.4.list

curl -fsSL https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add -

apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv E162F504A20CDF15827F718D4B7C549A058F8B6B

apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv 7568D9BB55FF9E5287D586017AE645C0CF8E292A

apt-get --assume-yes install pritunl mongodb-server

systemctl start pritunl mongodb

systemctl enable pritunl mongodb

Khi truy cập vào IP public thế này nghĩa là truy cập thành công

Sau đó dùng lệnh pritunl setup-key để lấy password default

Thực hiện thay đổi password trong giao diện

• Sau đó add organization và add user

Sau đó add server: Virtual network là dải IP tunnel

Sau đó attach Organization vào Server

Add route đến dải 10.20.1.0/24 (dải mạng VPC)

Sau đó chọn start server.

Thực hiện cấp file cho client

• Trong phần user chọn Get Two-Step Authentication Key để lấy Google Authentication Key.
• Trong phần user chọn Get Temporary Profile Link để lấy file config ovpn.

Thực hiện cài đặt Pritunl client

• Truy cập https://client.pritunl.com/#install để cài đặt.
• Sau khi cài đặt xong chạy lệnh pritunl-client-electron.

• Sau đó Import Profile file ovpn đã được tải về.
• Sau đó chọn connect: Phần enter pin thì nhập pin đã tạo khi tạo user, OTP thì sử dụng Google Authenticator.

Nhìn ip r đã thấy routing đến dải 10.20.1.0/24 thông qua 192.168.236.1 (chính là dải IP tunnel)

Docs:

• https://hocchudong.com/pritunl-vpn-phan-1-huong-dan-trien-khai-vpn-bang-pritunl-tren-ubuntu1804/
• https://hocchudong.com/pritunl-vpn-phan-2-huong-dan-cai-dat-pritunl-client-tren-linux/
• https://computingforgeeks.com/install-and-configure-pritunl-vpn-server-on-ubuntu/

Tôi sử dụng cert-manager để thực hiện quản lý các TLS Certificate. Ngoài việc hỗ trợ Let's Encryption, cert-manager còn hỗ trợ các tính năng như Self-Signed Certificate, CA, Vault. Để tìm hiểu thêm về cert-manager và các tính năng nâng cao bạn có thể truy cập vào document chính thức của cert-manager tại [1].

Cert-Manager quản lý các resource: Issuer (ClusterIssuer) , Certificates, CertificateRequest.

Hình sau đây mô tả mối quan hệ giữa Issuer, Certificate, Secret và cert-manager:

Yêu cầu:

- helm

- Nginx Ingress Controller

Thực hiện add helm repo cho cert-manager

helm repo add jetstack https://charts.jetstack.io
helm repo update

Cài đặt cert-manager bằng helm, sử dụng lệnh sau để install cert-manager:

helm install \
  --name cert-manager \
  --namespace cert-manager \
  --version v1.0.2 \
  jetstack/cert-manager \
  --set installCRDs=true

Kiểm tra các pod của cert-manager trên namespace cert-manager

Tạo ClusterIssuer phục vụ cho việc request tới ACME server để generate TLS Certificate

Bạn có thể sử dụng mẫu ClusterIssuer sau, ngoài ra ta cũng có thể sử dụng Issuer thay cho ClusterIssuer. Điểm khác nhau là với ClusterIssuer thì Issuer Cluster Wide tức là có thể sử dụng ở bất cứ namespace nào. Còn với Issuer chỉ tồn tại trong 1 namespace duy nhất.

Manifest tạo Cluster Issuer có tên sapd-issuer như sau

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: sapd-issuer
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: sapd@vccloud.vn
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource that will be used to store the account's private key.
      name: sapd-ssl
    # Add a single challenge solver, HTTP01 using nginx
    solvers:
    - http01:
        ingress:
          class: nginx

Lưu ý:

- Điền thông tin email

- Tên Secret lưu private key với ACME server

- Server URL. Lưu ý sử dụng acme staging cho test và production khi triển khai thật

Lưu lại manifest với tên file cluster-issuer.yml

Thực hiện tạo cluster-issuer bằng lệnh sau

kubectl apply -f cluster-issuer.yml

Kiểm tra ClusterIssuer đã được tạo

Khởi tạo 1 deployment Nginx để kiểm tra và expose qua service

kubectl create deploy --image nginx nginx
kubectl expose deploy nginx --port 80

Kiểm tra các resource vừa tạo

Ta sẽ cần sử dụng 1 domain cho service nginx vừa tạo ra. Tôi sẽ sử dụng domain ingress-1.k8slab.sapham.net và trỏ tới IP của Load Balancer là 45.124.94.24

Tip: Các bạn có thể trỏ wildcard domain vào địa chỉ IP của Load Balancer (Ingress)

Tạo ingress cho service nginx với domain trên. Sử dụng ingress manifest như sau

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-2
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "sapd-issuer"
spec:
  tls:
  - hosts:
    - ingress-1.k8slab.sapham.net
    secretName: ingress-1-ssl
  rules:
  - host: ingress-1.k8slab.sapham.net
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx
          servicePort: 80

Lưu ý:

- Sử dụng annotation để chỉ định cluster-issuer đã được tạo ở trên

- Khai báo host cho tls và rule: domain dùng để truy cập vào service

- Cert-manager sẽ lưu TLS Certificate cấp bởi Let's Encrypt vào Secret

Sau khi khởi tạo Ingress, ta sẽ thấy cert-manager khởi tạo Certificate, Secret để lưu trữ TLS Cert vừa được Generate.

Ta có thể kiểm tra thông tin Certificate vừa được khởi tạo bằng lệnh

kubectl describe cert ingress-1-ssl

Truy cập thử vào domain thông qua trình duyệt web

References:

[1] -  https://cert-manager.io/docs/

Ingress có nhiệm vụ giúp định tuyến (route) các request từ người dùng bên ngoài vào service được triển khai trong cụm Kubernetes. Thông thường, Ingress được sử dụng với mục đích routing tại layer 7 với các phương thức cơ bản như

- host-based routing: định tuyến dựa trên hostname truy cập của người dùng. Ví dụ request vào URL https://auth.example.com request sẽ được gửi tới Service Name production-auth. Với request vào URL https://api.example.com request sẽ được gửi tới Service Name production-api

- path-based routing: định tuyến dựa trên path của request. Ví dụ request vào URL https://api.example.com/user sẽ gửi tới Service Name production-user-api, request vào URL https://api.example.com/posts sẽ gửi tới Service Name production-post-api.

Trong môi trường microservices, một hệ thống sẽ bao gồm nhiều dịch vụ khác nhau. Do vậy việc sử dụng Ingress để định tuyến tại layer 7 và quản lý các request vào các service đơn giản hơn và linh hoạt hơn.

Ngoài tính năng cơ bản trên, Ingress Controller còn hỗ trợ nhiều tính năng khác như Rate Limit, Authentication, CORS,... Việc hỗ trợ các tính năng này hoàn toàn phụ thuộc vào Ingress Controller mà bạn sử dụng. Hiện tại có rất nhiều các loại Ingress Controller khác nhau như: Nginx Ingress, Kong Ingress, Traefik, Haproxy Ingress, Voyager, Contour, Istio, Ambassador, Gloo, Skipper. Bạn có thể tham khảo thêm tại [1]

Trong bài này tôi sẽ cài đặt  Nginx Ingress Controller bằng helm và một vài thiết lập Ingress  cơ bản.

Thông thường, tôi sẽ cài đặt Ingress Controller ở mode DaemonSet. Lúc này các Ingress Controller cụ thể là Nginx sẽ chạy trên toàn bộ worker nodes. Ta có thể sử dụng Load Balancer để phân tải xuống các Nginx trên các worker node. Điều này giúp ta dễ dàng mở rộng hệ thống khi số lượng request lớn lên. Khi ta thêm các worker node, Nginx Ingress Controller cũng được scale tương ứng.

Mô hình lý tưởng là User -> L4LB -> L7LB -> Service mô tả như sau

Khi cài đặt Nginx Ingress Controller, ta thường tạo Service resource cho Ingress. Trên hạ tầng các nhà cung cấp Cloud sẽ khởi tạo Load Balancer và tự động cấu hình forward request port 80 và 443 vào các Nginx Ingress Controller.

Tôi sẽ sử dụng Cluster Kubernetes tạo sẵn trên hệ thống BizFly Cloud để cài đặt.

Yêu cầu cài đặt helm version 2 hoặc 3.

Thêm repo helm của nginx-ingress

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm repo update

Install Nginx Ingress bằng 1 lệnh duy nhất

helm install --name nginx ingress-nginx/ingress-nginx --set controller.kind=DaemonSet

Kiểm tra các pod của nginx-controller

Load Balancer đang được khởi tạo

Sau khi Load Balancer khởi tạo thành công, ta có thể kiểm tra địa chỉ IP External (Public IP) của Load Balancer để truy cập

Truy cập thử vào Load Balancer

Kiểm tra Load Balancer trên Dashboard BizFly Cloud

Load Balancer được tạo ra với 2 Listener trên port 80 và 443 tương ứng với Nhóm Server như hình sau

Như vậy ta đã cài đặt xong Nginx Ingress Controller ở mode DaemonSet và sử dụng Load Balancer tự động cân tải cho các Nginx process trên các Node worker.

Trong bài tiếp theo, tôi sẽ hướng dẫn một số cấu hình cơ bản cho Nginx Ingress .

References:

[1] - https://medium.com/flant-com/comparing-ingress-controllers-for-kubernetes-9b397483b46b

Giới thiệu

Như đã nói trong bài viết trước, các pods (capsule) được tạo K8S tạo trên Virtual Kubelet không sử dụng mạng của K8S mà sử dụng mạng của Neutron với project được khai báo biến môi trường.

Thế nên, những pod (capsule) đó hoàn toàn có thể kết nối mạng với các VM được tạo bởi Openstack.

Thế nhưng như ta đã biết, ta cũng cần phải có node kubernetes master để schedule vào VK. Vậy trong trường hợp ta muốn sử dụng hệ thống mà pod vừa được tạo trên node K8S, vừa được tạo trên VK (node Compute Openstack), ta sẽ cần thêm hỗ trợ từ Kuryr-Kubernetes (https://docs.openstack.org/kuryr-kubernetes/latest/)

Kuryr-Kubernetes

Kuryr-kubernetes cho phép cụm K8S sử dụng mạng của Neutron, từ đó các pod có thể thông mạng với VM và các capsule.

Cài đặt: https://docs.openstack.org/kuryr-kubernetes/latest/installation/index.html

Để thử nghiệm ta labs sử dụng mô hình như sau:

Mô hình

Mô tả:

VM/Pod gắn vào mạng nào thì sử dụng mạng đó.

VM/Pod đứng cùng hàng dọc với node nào thì được tạo trên node đó.

Nét liền là mạng vật lý.

Nét đứt là mạng tạo bởi neutron.

Các trường hợp labs

Ta có sử dụng 4 trường hợp kết nối sau:

• VM (node2) và pod_VK(node1)

• pod_VK(node1) và pod_VK(node2)

• pod_kubelet và VM

• pod_VK và pod_kubelợp

Kết nối 2 pod VK trên 2 node compute khác nhau

Ta triển khai 2 pod_VK trên 2 node compute.

Pod_VK được tạo bởi containerd chứ không phải docker thế nên cần cri-tools để truy cập được vào pod.

cri-tools: https://github.com/kubernetes-sigs/cri-tools

Đồng thời từ node pod ở node này ta ping thử sang pod ở node còn lại

root@worker1:~# crictl -r unix:///var/run/containerd/containerd.sock ps
CONTAINER           IMAGE               CREATED             STATE               NAME                                                                      ATTEMPT             POD ID
ca91b2afea795       nginx:1.14.2        31 minutes ago      Running             capsule-default-nginx-deployment-virtual-admin-77cf5845f5-mq59d-zeta-11   0                   e9ba6b9769a3a
root@worker1:~# crictl -r unix:///var/run/containerd/containerd.sock exec -it ca91b2afea795 sh
# ping ^C
# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.10.10.56  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::f816:3eff:fea7:cd10  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:a7:cd:10  txqueuelen 1000  (Ethernet)
        RX packets 16305  bytes 27046669 (25.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9296  bytes 634907 (620.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ping 10.10.10.27
PING 10.10.10.27 (10.10.10.27) 56(84) bytes of data.
64 bytes from 10.10.10.27: icmp_seq=1 ttl=64 time=16.5 ms
64 bytes from 10.10.10.27: icmp_seq=2 ttl=64 time=1.38 ms
64 bytes from 10.10.10.27: icmp_seq=3 ttl=64 time=1.98 ms
64 bytes from 10.10.10.27: icmp_seq=4 ttl=64 time=1.03 ms
^C
--- 10.10.10.27 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.038/5.245/16.573/6.549 ms

root@worker2:~# crictl -r unix:///var/run/containerd/containerd.sock ps
CONTAINER           IMAGE               CREATED             STATE               NAME                                                                      ATTEMPT             POD ID
7a296ffcf7ee6       nginx:1.14.2        41 minutes ago      Running             capsule-default-nginx-deployment-virtual-slef-77cf5845f5-kmrg8-theta-20   0                   2e9d3b1ffe1df
root@worker2:~# crictl -r unix:///var/run/containerd/containerd.sock exec -it 7a296ffcf7ee6 sh
# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.10.10.27  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::f816:3eff:feba:2965  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:ba:29:65  txqueuelen 1000  (Ethernet)
        RX packets 17151  bytes 27108767 (25.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9415  bytes 643452 (628.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ping 10.10.10.56
PING 10.10.10.56 (10.10.10.56) 56(84) bytes of data.
64 bytes from 10.10.10.56: icmp_seq=1 ttl=64 time=2.60 ms
64 bytes from 10.10.10.56: icmp_seq=2 ttl=64 time=1.01 ms
64 bytes from 10.10.10.56: icmp_seq=3 ttl=64 time=0.985 ms
64 bytes from 10.10.10.56: icmp_seq=4 ttl=64 time=1.16 ms
c^C
--- 10.10.10.56 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.985/1.442/2.607/0.676 ms
#

Ta có thể thấy cả 2 chiều đều thông mạng với nhau.

Kết nối giữa pod VK và VM trên 2 node compute khác nhau

Ta sang node compute2 console vào VM vừa tạo và ping thử đến pod ở node compute1.

root@worker2:~# virsh console instance-00000006
Connected to domain instance-00000006
Escape character is ^]

login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
selfservice-instance2c login: cirros
Password:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
$ ping 10.10.10.56
PING 10.10.10.56 (10.10.10.56): 56 data bytes
64 bytes from 10.10.10.56: seq=0 ttl=64 time=3.432 ms
64 bytes from 10.10.10.56: seq=1 ttl=64 time=0.831 ms
64 bytes from 10.10.10.56: seq=2 ttl=64 time=1.151 ms
64 bytes from 10.10.10.56: seq=3 ttl=64 time=1.970 ms
^C
--- 10.10.10.56 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.831/1.846/3.432 ms
$ ifconfig
eth0      Link encap:Ethernet  HWaddr FA:16:3E:D2:28:E5  
          inet addr:10.10.10.245  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::f816:3eff:fed2:28e5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:276 errors:0 dropped:0 overruns:0 frame:0
          TX packets:139 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:23530 (22.9 KiB)  TX bytes:13196 (12.8 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

$

Ở pod trong node compute1 ta cũng ping thử lại với VM ở node compute2

# ping 10.10.10.245
PING 10.10.10.245 (10.10.10.245) 56(84) bytes of data.
64 bytes from 10.10.10.245: icmp_seq=1 ttl=64 time=2.16 ms
64 bytes from 10.10.10.245: icmp_seq=2 ttl=64 time=0.965 ms
64 bytes from 10.10.10.245: icmp_seq=3 ttl=64 time=1.14 ms
64 bytes from 10.10.10.245: icmp_seq=4 ttl=64 time=1.93 ms
^C
--- 10.10.10.245 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.965/1.552/2.167/0.510 ms
# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.10.10.56  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::f816:3eff:fea7:cd10  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:a7:cd:10  txqueuelen 1000  (Ethernet)
        RX packets 16331  bytes 27048713 (25.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9322  bytes 636951 (622.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Ta có thể thấy giữa VM và pod cũng thông mạng với nhau.

Kết nối giữa pod-kubelet và VM

Với kuryr-kubernetes, ta có thể cho pod sử dụng cùng mạng với mạng được tạo bởi openstack neutron.

Ta thử ping đến pod từ VM

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether fa:16:3e:5c:0e:b1 brd ff:ff:ff:ff:ff:ff
    inet 10.1.3.117/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe5c:eb1/64 scope link
       valid_lft forever preferred_lft forever
$ ping 10.1.2.67
PING 10.1.2.67 (10.1.2.67): 56 data bytes
64 bytes from 10.1.2.67: seq=0 ttl=64 time=4.967 ms
64 bytes from 10.1.2.67: seq=1 ttl=64 time=1.675 ms
64 bytes from 10.1.2.67: seq=2 ttl=64 time=1.086 ms
64 bytes from 10.1.2.67: seq=3 ttl=64 time=2.049 ms
^C
--- 10.1.2.67 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.086/2.444/4.967 ms

Ta tạo 1 pod mới sử dụng image cirros

root@k8s-master:~# kubectl get pod -o wide
NAME                                             READY   STATUS    RESTARTS   AGE     IP            NODE              NOMINATED NODE   READINESS GATES
cirros-deployment-worker-75ffdf847-vrds7         1/1     Running   0          3m58s   10.1.2.87     k8s-worker        <none>           <none>
nginx-deployment-virtual-slef-77cf5845f5-kmrg8   1/1     Running   0          3h24m   10.10.10.27   virtual-kubelet   <none>           <none>
nginx-deployment-worker-57d9684bf8-gsfth         1/1     Running   0          50m     10.1.2.67     k8s-worker        <none>           <none>

Ta truy cập vào pod và ping thử lại VM

root@k8s-master:~# kubectl exec -it cirros-deployment-worker-75ffdf847-vrds7  sh
/ # ping 10.1.3.117
PING 10.1.3.117 (10.1.3.117): 56 data bytes
64 bytes from 10.1.3.117: seq=0 ttl=64 time=2.982 ms
64 bytes from 10.1.3.117: seq=1 ttl=64 time=1.540 ms
64 bytes from 10.1.3.117: seq=2 ttl=64 time=1.011 ms
64 bytes from 10.1.3.117: seq=3 ttl=64 time=0.827 ms
^C
--- 10.1.3.117 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.827/1.590/2.982 ms
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue qlen 1000
    link/ether fa:16:3e:86:63:29 brd ff:ff:ff:ff:ff:ff
    inet 10.1.2.87/16 scope global eth0
       valid_lft forever preferred_lft forever
/ #

Ta có thể thấy pod tạo bơi kubelet và VM thông với nhau.

Kết nối giữa pod tạo bởi kubelet và virtual kubelet

Ta tạo 1 pod (VK) trên dải mạng của cho pod của kubernetes

root@k8s-master:~# kubectl get pod -o wide
NAME                                              READY   STATUS    RESTARTS   AGE     IP            NODE              NOMINATED NODE   READINESS GATES
cirros-deployment-worker-75ffdf847-vrds7          1/1     Running   0          29m     10.1.2.87     k8s-worker        <none>           <none>
nginx-deployment-virtual-admin-77cf5845f5-5dg2v   1/1     Running   0          9m55s   10.1.1.173    virtual-kubelet   <none>           <none>
nginx-deployment-virtual-slef-77cf5845f5-kmrg8    1/1     Running   0          3h50m   10.10.10.27   virtual-kubelet   <none>           <none>
nginx-deployment-worker-57d9684bf8-gsfth          1/1     Running   0          76m     10.1.2.67     k8s-worker        <none>           <none>

Ta truy cập vào node compute2, truy cập vào pod

# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.1.1.173  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::f816:3eff:fec1:1b68  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c1:1b:68  txqueuelen 1000  (Ethernet)
        RX packets 10399  bytes 16046109 (15.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6207  bytes 446993 (436.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ping 10.1.2.87
PING 10.1.2.87 (10.1.2.87) 56(84) bytes of data.
64 bytes from 10.1.2.87: icmp_seq=1 ttl=64 time=3.71 ms
64 bytes from 10.1.2.87: icmp_seq=2 ttl=64 time=1.25 ms
64 bytes from 10.1.2.87: icmp_seq=3 ttl=64 time=0.795 ms
64 bytes from 10.1.2.87: icmp_seq=4 ttl=64 time=1.21 ms
^C
--- 10.1.2.87 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3017ms
rtt min/avg/max/mdev = 0.795/1.743/3.710/1.150 ms
#
# ping 10.1.2.67
PING 10.1.2.67 (10.1.2.67) 56(84) bytes of data.
64 bytes from 10.1.2.67: icmp_seq=1 ttl=64 time=1.62 ms
64 bytes from 10.1.2.67: icmp_seq=2 ttl=64 time=1.03 ms
64 bytes from 10.1.2.67: icmp_seq=3 ttl=64 time=1.63 ms
64 bytes from 10.1.2.67: icmp_seq=4 ttl=64 time=1.52 ms
^C
--- 10.1.2.67 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.032/1.454/1.635/0.252 ms
#

Ta có thấy được từ pod tạo bởi (VK) cũng thông mạng đến pod tạo bởi kubelet thường.

Openstack Loadbalancer được tạo khi expose service

Như sơ đồ ở trên, ta thấy rằng k có pod/VM nào sử dụng dải service, dải đó dành riêng cho những loadbalancer (Openstack Octavia) dùng cho service của Kubernetes.

Khi ta expose service

root@k8s-master:~# kubectl get pod -o wide
NAME                                              READY   STATUS    RESTARTS   AGE    IP            NODE              NOMINATED NODE   READINESS GATES
cirros-deployment-worker-75ffdf847-vrds7          1/1     Running   0          43m    10.1.2.87     k8s-worker        <none>           <none>
nginx-deployment-virtual-admin-77cf5845f5-5dg2v   1/1     Running   0          23m    10.1.1.173    virtual-kubelet   <none>           <none>
nginx-deployment-virtual-slef-77cf5845f5-kmrg8    1/1     Running   0          4h3m   10.10.10.27   virtual-kubelet   <none>           <none>
nginx-deployment-worker-57d9684bf8-gsfth          1/1     Running   0          89m    10.1.2.67     k8s-worker        <none>           <none>
root@k8s-master:~# kubectl expose deployment nginx-deployment-
nginx-deployment-virtual-admin  nginx-deployment-virtual-slef   nginx-deployment-worker
root@k8s-master:~# kubectl expose deployment nginx-deployment-worker
service/nginx-deployment-worker exposed
root@k8s-master:~# kubectl get svc
NAME                             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes                       ClusterIP   10.2.0.1       <none>        443/TCP   4h44m
nginx-deployment-virtual-admin   ClusterIP   10.2.154.91    <none>        80/TCP    24s
nginx-deployment-worker          ClusterIP   10.2.182.210   <none>        80/TCP    3s
root@k8s-master:~# kubectl edit svc nginx-deployment-worker
service/nginx-deployment-worker edited
root@k8s-master:~# kubectl edit svc nginx-deployment-virtual-admin
service/nginx-deployment-virtual-admin edited
root@k8s-master:~# kubectl get svc
NAME                             TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes                       ClusterIP      10.2.0.1       <none>        443/TCP        4h48m
nginx-deployment-virtual-admin   LoadBalancer   10.2.154.91    <pending>     80:31012/TCP   4m22s
nginx-deployment-worker          LoadBalancer   10.2.182.210   <pending>     80:30066/TCP   4m1s

Loadbalancer được tạo và gọi đến

[root@controller ~(kubernetes)]$ openstack loadbalancer list
+--------------------------------------+----------------------------------------+----------------------------------+--------------+---------------------+----------+
| id                                   | name                                   | project_id                       | vip_address  | provisioning_status | provider |
+--------------------------------------+----------------------------------------+----------------------------------+--------------+---------------------+----------+
| 96be6376-3eed-4822-a3e1-9deba4b37918 | kube-system/kube-dns                   | 623f7793c0974c50a932c4e6b7145b95 | 10.2.0.10    | PENDING_CREATE      | amphora  |
| 879c7bd0-43d5-41c3-9868-c9cfd5168687 | default/nginx-deployment-virtual-admin | 623f7793c0974c50a932c4e6b7145b95 | 10.2.154.91  | ACTIVE              | amphora  |
| 8733211d-9c49-40e5-8952-180aa7621bde | default/nginx-deployment-worker        | 623f7793c0974c50a932c4e6b7145b95 | 10.2.182.210 | PENDING_UPDATE      | amphora  |
+--------------------------------------+----------------------------------------+----------------------------------+--------------+---------------------+----------+
[root@controller ~(kubernetes)]$ curl 10.2.154.91
^Ccu


[root@controller ~(kubernetes)]$ cu
^C
[root@controller ~(kubernetes)]$ curl 10.2.154.91
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
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>
[root@controller ~(kubernetes)]$ curl 10.2.182.210
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
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>

Kết luận

Vậy với Openstack Zun và Kuryr-Kubernetes, ta có thể có 1 hệ thống Cloud Openstack kết hợp với K8S và cả Nodeless

Giới thiệu

Virutal kubelet (VK) là triển khai mã nguồn mở của Kubernetes Kubelet làm 1 Kubelet nhằm mục đích kết nối Kubernetes đến các APIs khác.

Mô hình:

Vì Virtual Kubelet không thực sự là 1 node kubelet thế nên các containers/pod sẽ được tạo thực tế ở trên các cloud providers khác cung cấp dịch vụ.

Các providers đang hỗ trợ:

Admiralty Multi-Cluster Scheduler
Alibaba Cloud Elastic Container Instance (ECI)
AWS Fargate
Azure Batch
Azure Container Instances (ACI)
Elotl Kip
Kubernetes Container Runtime Interface (CRI)
Huawei Cloud Container Instance (CCI)
HashiCorp Nomad
OpenStack Zun
Tencent Games Tensile Kube

Ở đây chúng ta sẽ sử dụng openstack zun

Cài đặt

Để cài đăt, ta cần cài đặt Go và đặt biến môi trường GOPATH (tham khảo tại): https://www.linode.com/docs/development/go/install-go-on-ubuntu/

Tải VK về từ github: https://github.com/virtual-kubelet/openstack-zun.git

Truy cập đến thư mục: ~/openstack-zun/cmd/virtual-kubelet#

Sau đó build: go build main.go

đổi tên main -> virtual-kubelet copy vào thư mục /usr/bin

Khởi chạy

Để khởi chạy ta cần xác thực qua keystone, ta cần những biến môi trường như sau:

export OS_DOMAIN_ID=default
export OS_REGION_NAME=RegionOne
export OS_PROJECT_NAME=demo
export OS_IDENTITY_API_VERSION=3
export OS_AUTH_URL=http://10.0.2.15/identity/v3
export OS_USERNAME=demo
export OS_PASSWORD=password

P/s: đặt biến môi trường theo cài đặt của mình

Sau đó chạy lệnh virtual-kubelet

Kết quả:

root@k8s-master:~# kubectl get nodes
NAME              STATUS   ROLES    AGE    VERSION
k8s-master        Ready    master   122m   v1.13.3
k8s-worker        Ready    <none>   105m   v1.13.3
virtual-kubelet   Ready    agent    94m    v1.14.3

Triển khai pods trong VK:

Vì OpenStack virtual node được cấp 1 taint, thế nên cần toleration để triển khai pod đó:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  tolerations:
  - key: "virtual-kubelet.io/provider"
    operator: "Equal"
    value: "openstack"
    effect: "NoSchedule"
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

root@k8s-master:~# kubectl get pod -o wide
NAME                                        READY   STATUS        RESTARTS   AGE   IP           NODE              NOMINATED NODE   READINESS GATES
nginx-deployment-virtual-77cf5845f5-8h9tp   1/1     Running       0          14m   10.1.1.54    k8s-worker        <none>           <none>
nginx-deployment-worker-57d9684bf8-z7skz    1/1     Running       1          51m   10.1.1.191   k8s-worker        <none>           <none>

Check trên openstack:

openstack capsule list
+--------------------------------------+---------------------------------------------------+---------+------------+
| uuid                                 | name                                              | status  | addresses  |
+--------------------------------------+---------------------------------------------------+---------+------------+
| 4fe2d632-cb11-4596-b9a9-feebab10191f | default-nginx-deployment-virtual-77cf5845f5-npxcv | Running | 10.1.0.198 |
| 3ff4a995-67c0-416d-bced-78378c6f616e | kube-system-kube-proxy-4jt8p                      | Error   |            |
+--------------------------------------+---------------------------------------------------+---------+------------+

Chú ý, vì VK không sử dụng mạng của k8s tạo ra mà dụng mạng của neutron nên kube-proxy lỗi là điều bình thường.

Đối với Openstack Zun, có 2 khái niệm cần để ý đó là containers và capsule.
Capsule tương ứng với pod và containers tương ứng với containers

Như ta đã biết, Kubernetes sử dụng Horizontal Pod Autoscaler (HPA) để có thể scale số lượng pod.

Để có thể làm được điều đó, HPA sẽ thực hiện vòng loop để query những metrics hiện tại sau đó tính toán và thực viện công việc scale.

Nhưng có vấn đề đặt ra ở đây, đó là đôi khi những metrics thu về được lại chưa đủ để có thể thực hiện scale. Ví dụ sẽ được nói đến tiếp theo trong bài viết.

Để thực hiện điều này thì Kubernetes có thành phần được gọi metrics registry. Mục đích metrics registry là cung cấp giao diện để client có thể query metrics. Giao diện này gồm 3 thành phần là:

• Resource Metrics API
• Custom Metrics API
• External Metrics API

Vậy khi chúng ta muốn scale với Custom Metrics API, ta cần phải cung cấp backend cho nó. Backend này bao gồm 2 thành phần chính đó là Metric collector và Metric API server.

METRIC COLLECTOR  

Chúng ta sẽ lựa chọn Metric collector khá phổ biến: Prometheus

Để cho đơn giản,ở đây ta sẽ sử dụng Prometheus-operator thông qua Helm:

Repo prometheus-operator:

https://github.com/helm/charts/tree/master/stable/prometheus-operator

Prometheus-operator gồm nhiều thành phần, trong đó chủ yếu là Prometheus, Grafana (công cụ tạo dashboard), và các service monitor để lấy metrics từ kubernetes.

Câu lệnh:

helm install my-mon stable/prometheus-operator -f values.yaml

Trong đó values.yaml là file mình tự tạo với nội dung như sau:

serviceMonitorSelectorNilUsesHelmValues: false [1]

Việc này là cần thiết vì nó sẽ cho phép thu được những metrics khác ngoài những thành phần của Kubernetes.

Sau khi thực hiện xong, ta hoàn toàn có thể truy cập trang web đã được host lên:

Prometheus:

Grafana:

MQTT BROKER (VerneMQ)

Ta sẽ sử dụng VerneMQ làm MQTT Broker làm ví dụ

Tiếp tục sử dụng Helm để tải VerneMQ

Repo:

https://vernemq.github.io/docker-vernemq

Ta cần phải cấu hình VerneMQ 1 chút mới có thể chạy được không như Prometheus-operator.

Đầu tiên, ta cần pull verneMQ chart về:

helm pull vernemq/vernemq --untar true

Ta sẽ pull Chart về và giải nén, ta có thư mục vernemq

Truy cập file values.yaml trong thư mục, ta chỉnh sửa 1 số thông số như sau

Quan trọng

Vì helm sử dụng image 1.10.2 để tạo vernemq và image này bị lỗi thiếu thư viện, ta cần chỉnh config

image: 1.10.2 thành image: 1.10.2-1-alpine hoặc image: lastest để không gặp lỗi này

Sau đó:

serviceMonitor:
  create: true

Tạo ra service monitor để prometheus lấy được những metrics

Đồng thời ta cần phải thêm vào:

additionalEnv:
  - name: DOCKER_VERNEMQ_ALLOW_ANONYMOUS
    value: "on"
  - name: DOCKER_VERNEMQ_ACCEPT_EULA
    value: "yes"

  - name: DOCKER_VERNEMQ_ALLOW_ANONYMOUS
    value: "on"

Để bỏ qua bước xác thực khi truyền tin

  - name: DOCKER_VERNEMQ_ACCEPT_EULA
    value: "yes"

Chấp nhận điều khoản sử dụng của VerneMQ [2]

Ngoài ra, VerneMQ còn là 1 Stateful Cluster thế nên ta cần phải lệnh gọi để tách node khỏi cluster khi scale down.

Trong thư mục templates, ta truy cập file statefulset.yaml thêm nội dung:

lifecycle:
            preStop:
              exec:
                command: ["/bin/bash","-c","vmq-admin cluster leave node=VerneMQ@$HOSTNAME.myvernemq-headless.default.svc.cluster.local -k -i 1 -t 30"]

Sau khi cấu hình xong, ta sử dụng helm để triển khai:

helm install myVerneMQ . --set replicaCount=2 -f values.yaml

Sau khi triển khai xong, thì Prometheus cũng có thể lấy được metrics từ VerneMQ (VerneMQ có exporter mặc định khi được tạo ở port 8888) [3]

Để kiểm tra hoạt động monitor đúng, ta sẽ thử publish message đến

Ở đây ta sẽ sử dụng Python và thư viện paho-mqtt

paho-mqtt

MQTT version 3.1.1 client class

PyPI

Code python:

import paho.mqtt.client as paho
import timebroker="localhost"
port=1883def on_publish(client,userdata,mid):             #create function for callback
    print("Published message to topic","ecg/omniacare/devices")
    print("mid=", mid)
    passclient1 = paho.Client("control1")                           #create client objectclient1.on_publish = on_publish                          #assign function to callbackff = open("/home/mqtt_ecg.txt","r")
ss = ff.read()

x = 3000
while True:
    x += 1
    client1.connect(broker,port) #establish connection
    client1.loop_start() #start the loop
    ss2 = ss.replace("mario.rossi", "mario.rossi."+str(x).zfill(6))
    print("Publishing message to topic","ecg/omniacare/devices")
    res = client1.publish("/ecg/omniacare/devices/0X345000DFG",ss2,2,0)
    print("Post publishing message to topic","ecg/omniacare/devices",res)
    client1.loop_stop(force=True)
    client1.disconnect()
    time.sleep(5) # wait

time.sleep(5) để điều khiển tần suất bắn message

Ta sẽ tạo dashboard sử dụng grafana

Trong đó:

Total publish receive: sum(mqtt_publish_received)

Total publish receive per second: sum(irate(mqtt_publish_received{mqtt_version="4"}[1m]))

Publish receiver per second per node:
irate(mqtt_publish_received{mqtt_version="4"}[1m])

Ở đây, ta muốn cho VerneMQ scale theo số lượng message publish mỗi giây, nhưng lại không có metrics nào đáp ứng được nhu cầu của chúng ta cả.

Và như đã nói ở trên, chúng ta cần Metric collector và Metric API server, ta sẽ cần Metric API server. Ở đây chúng ta sử dụng Prometheus-adapter

METRIC API SERVER

repo :

https://github.com/helm/charts/tree/master/stable/prometheus-adapter

Tương tự như VerneMQ, ta cũng cần pull về cấu hình 1 số chỗ

Trong file values.yaml

# Url to access prometheus
prometheus:
  url: http://my-mon-prometheus-operator-prometheus.default.svc.cluster.local
  port: 9090

Ta trỏ đến prometheus operator

rules:
    - seriesQuery:
    '{namespace!="",__name__="mqtt_publish_received",mqtt_version="4"}'
      seriesFilters: []
      resources:
        template: <<.Resource>>
      metricsQuery: sum(irate(<<.Series>>{<<.LabelMatchers>>}[1m])) by (<<.GroupBy>>)

Ta tạo custom rule để biến metrics mqtt_publish_received trở thành tổng số message nhận được mỗi giây trên mỗi node sum(irate(<<.Series>>{<<.LabelMatchers>>}[1m])) by (<<.GroupBy>>)

Sau đó khởi tạo prometheus-adapter

helm install prom-adap . -f values.yaml

Tạo autoscale và kiểm tra

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: vernemq-autoscaler
spec:
  scaleTargetRef:
    # point the HPA at the sample application
    # you created above
    apiVersion: apps/v1
    kind: StatefulSet
    name: myvernemq
  # autoscale between 1 and 10 replicas
  minReplicas: 1
  maxReplicas: 10
  metrics:
  # use a "Pods" metric, which takes the average of the
  # given metric across all pods controlled by the autoscaling target
  - type: Pods
    pods:
      # use the metric that you used above: pods/http_requests
      metricName: mqtt_publish_received
      # target 500 milli-requests per second,
      # which is 1 request every two seconds
      targetAverageValue: 60m

Ban đầu khi không chạy stress test:

NAME                 REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
vernemq-autoscaler   StatefulSet/myvernemq   0/60m     1         10        1          3h49m


+----------------------------------------------------------------+-------+
|                              Node                              |Running|
+----------------------------------------------------------------+-------+
|VerneMQ@myvernemq-0.myvernemq-headless.default.svc.cluster.local| true  |

Khi tải tăng lên

+----------------------------------------------------------------+-------+
|                              Node                              |Running|
+----------------------------------------------------------------+-------+
|VerneMQ@myvernemq-0.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-1.myvernemq-headless.default.svc.cluster.local| true  |
+----------------------------------------------------------------+-------+

vernemq-autoscaler   StatefulSet/myvernemq   22m/60m   1         10        3          3h8m 
NAME                 REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE 
vernemq-autoscaler   StatefulSet/myvernemq   22m/60m   1         10        3          3h8m 

Tiếp tục tăng:

vernemq-autoscaler   StatefulSet/myvernemq   266m/60m   1         10        4          146m
NAME                 REFERENCE               TARGETS    MINPODS   MAXPODS   REPLICAS   AGE 
vernemq-autoscaler   StatefulSet/myvernemq   266m/60m   1         10        4          146m
NAME                 REFERENCE               TARGETS    MINPODS   MAXPODS   REPLICAS   AGE 
vernemq-autoscaler   StatefulSet/myvernemq   266m/60m   1         10        4          146m
NAME                 REFERENCE               TARGETS    MINPODS   MAXPODS   REPLICAS   AGE 
vernemq-autoscaler   StatefulSet/myvernemq   800m/60m   1         10        5          146m


+----------------------------------------------------------------+-------+
|                              Node                              |Running|
+----------------------------------------------------------------+-------+
|VerneMQ@myvernemq-0.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-1.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-2.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-3.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-4.myvernemq-headless.default.svc.cluster.local| true  |
+----------------------------------------------------------------+-------+

Sau cùng:

+----------------------------------------------------------------+-------+
|                              Node                              |Running|
+----------------------------------------------------------------+-------+
|VerneMQ@myvernemq-0.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-1.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-2.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-3.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-4.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-5.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-6.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-7.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-8.myvernemq-headless.default.svc.cluster.local| true  |
|VerneMQ@myvernemq-9.myvernemq-headless.default.svc.cluster.local| true  |
+----------------------------------------------------------------+-------+

NAME                 REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE 
vernemq-autoscaler   StatefulSet/myvernemq   11m/60m   1         10        10         154m 
NAME                 REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE 
vernemq-autoscaler   StatefulSet/myvernemq   22m/60m   1         10        10         154m 

Ta theo dõi vào TARGETS có thể thấy pod được scale khi request đến nhiều hơn, và scale vào khi ít request đi.

References:

[1] - https://github.com/helm/charts/tree/master/stable/prometheus-operator#prometheusioscrape

[2] - https://docs.vernemq.com/installation/accepting-the-vernemq-eula

[3] - https://docs.vernemq.com/monitoring/prometheus

Bản chất việc thiết lập ACL Public cho 1 Bucket cho phép public danh sách các object có trong bucket đó, nên khi người dùng thực hiện truy cập vào một file thì không thể truy cập được và thông báo như sau

Mặc dù Bucket này đã public như thiết lập sau

Do vậy, để có thể truy cập vào file trong bucket trên ta có 2 cách

- Thực hiện set public đối với toàn bộ file khi thực hiện upload

- Hoặc sử dụng bucket policy để thiết lập bucket.

Trong bài này, tôi sẽ sử dụng bucket policy để thiết lập public cho toàn bộ file trong bucket.

Để thực hiện điều này, ta sử dụng lệnh s3cmd. Xem thêm hướng dẫn cấu hình s3cmd tại [1].

Tạo file `policy.json` như sau

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"AddPerm",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::sapd-test-bucket-private/*"
      ]
    }
  ]
}

Với sapd-test-bucket-private đây là tên bucket của bạn, bạn cần thay thế tương ứng với bucket mà bạn muốn public toàn bộ file trong bucket đó.

Thiết lập policy cho bucket bằng lệnh sau

s3cmd setpolicy policy.json s3://sapd-test-bucket-private

Kiểm tra lại thông tin policy

sapd@sapd ~/WORK/VC/s3 $ s3cmd info s3://sapd-test-bucket-private
s3://sapd-test-bucket-private/ (bucket):
   Location:  hn
   Payer:     BucketOwner
   Expiration Rule: none
   Policy:    b'{\n  "Version":"2012-10-17",\n  "Statement":[{\n    "Sid":"AddPerm",\n        "Effect":"Allow",\n      "Principal": "*",\n      "Action":["s3:GetObject"],\n      "Resource":["arn:aws:s3:::sapd-test-bucket-private/*"\n      ]\n    }\n  ]\n}\n'
   CORS:      none
   ACL:       *anon*: READ
   ACL:       sapd@vccloud.vn: FULL_CONTROL
   URL:       http://sapd-test-bucket-private.ss-hn-1.vccloud.vn/

Thực hiện truy cập vào file trong bucket.

Tada

References:

[1] - https://support.bizflycloud.vn/knowledge-base/dung-client-tool-ket-noi-voi-simple-storage/

Cụm từ adm không còn quá xa lạ đối với những ai đã từng cài đặt Kubernetes bằng kubeadm. Hiện nay có rất nhiều tool lấy cảm hứng từ kubeadm để đặt tên cho tool cài đặt 1 hệ thống như vậy (ví dụ có cephadm).

Trong bài này mình sẽ giới thiệu việc cài đặt etcd cluster sử dụng công cụ etcdadm. Đây là một công cụ khá mới, giúp cho việc cài đặt 1 cụm etcd 1 cách dễ dàng hơn.

Để cài đặt etcdad, ta cần thực hiện build từ source code, do release của etcdadm không có build sẵn binary.

Lưu ý: Yêu cầu phải cài đặt golang trên máy. Hiện mình đang dùng bản go1.14.2

root@sapd-ubuntu3:~/etcdadm# go version
go version go1.14.2 linux/amd64

Clone source code etcdadm từ github

git clone https://github.com/kubernetes-sigs/etcdadm

Build binary

make etcdadm

Sau khi build được etcdadm, ta thực hiện copy file binary này lên các node dự định cài đặt etcd.

Trong bày này, mình sẽ cài đặt trên 3 node có địa chỉ IP lần lượt như sau

• 10.5.9.175
• 10.5.8.86
• 10.5.9.55

Thực hiện khởi tạo cluster, gõ lệnh ./etcdadm init trên 1 node. Output như sau:

root@sapd-ubuntu3:~/etcdadm# ./etcdadm init
INFO[0000] [install] Artifact not found in cache. Trying to fetch from upstream: https://github.com/coreos/etcd/releases/download 
INFO[0000] [install] Downloading & installing etcd https://github.com/coreos/etcd/releases/download from 3.3.8 to /var/cache/etcdadm/etcd/v3.3.8 
INFO[0000] [install] downloading etcd from https://github.com/coreos/etcd/releases/download/v3.3.8/etcd-v3.3.8-linux-amd64.tar.gz to /var/cache/etcdadm/etcd/v3.3.8/etcd-v3.3.8-linux-amd64.tar.gz 
######################################################################## 100.0% -#O#-  #   #                                                                 
INFO[0005] [install] extracting etcd archive /var/cache/etcdadm/etcd/v3.3.8/etcd-v3.3.8-linux-amd64.tar.gz to /tmp/etcd172607196 
INFO[0006] [install] verifying etcd 3.3.8 is installed in /opt/bin/ 
INFO[0006] [certificates] creating PKI assets           
INFO[0006] creating a self signed etcd CA certificate and key files 
[certificates] Generated ca certificate and key.
INFO[0006] creating a new server certificate and key files for etcd 
[certificates] Generated server certificate and key.
[certificates] server serving cert is signed for DNS names [sapd-ubuntu3] and IPs [10.5.9.55 127.0.0.1]
INFO[0006] creating a new certificate and key files for etcd peering 
[certificates] Generated peer certificate and key.
[certificates] peer serving cert is signed for DNS names [sapd-ubuntu3] and IPs [10.5.9.55]
INFO[0007] creating a new client certificate for the etcdctl 
[certificates] Generated etcdctl-etcd-client certificate and key.
INFO[0008] creating a new client certificate for the apiserver calling etcd 
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/etcd/pki"
INFO[0011] [health] Checking local etcd endpoint health 
INFO[0011] [health] Local etcd endpoint is healthy      
INFO[0011] To add another member to the cluster, copy the CA cert/key to its certificate dir and run: 
INFO[0011] 	etcdadm join https://10.5.9.55:2379         

Tới bước này etcdadm đã thực hiện việc generate PKI Certificate trên node 10.5.9.55 tại thực mục /etc/etcd/pki/

root@sapd-ubuntu3:~/etcdadm# ls -lah /etc/etcd/pki/
total 48K
drwxr-xr-x 2 root root 4.0K May  2 22:09 .
drwxr-xr-x 3 root root 4.0K May  2 22:09 ..
-rw-r--r-- 1 root root 1.1K May  2 22:09 apiserver-etcd-client.crt
-rw------- 1 root root 1.7K May  2 22:09 apiserver-etcd-client.key
-rw-r--r-- 1 root root 1009 May  2 22:09 ca.crt
-rw------- 1 root root 1.7K May  2 22:09 ca.key
-rw-r--r-- 1 root root 1.1K May  2 22:09 etcdctl-etcd-client.crt
-rw------- 1 root root 1.7K May  2 22:09 etcdctl-etcd-client.key
-rw-r--r-- 1 root root 1.1K May  2 22:09 peer.crt
-rw------- 1 root root 1.7K May  2 22:09 peer.key
-rw-r--r-- 1 root root 1.1K May  2 22:09 server.crt
-rw------- 1 root root 1.7K May  2 22:09 server.key

Để các node khác có thể join vào cụm etcd này, ta cần thực hiện copy toàn certificate và key của CA tại thư mục này sang các node member còn lại:

rsync -avR /etc/etcd/pki/ca.* root@10.5.9.175:/
rsync -avR /etc/etcd/pki/ca.* root@10.5.8.86:/

Thực hiện join 2 node còn lại

./etcdadm join https://10.5.9.55:2379  

Kiểm tra danh sách member bằng etcdctl

root@sapd-ubuntu3:~/etcdadm/etcd-v3.3.8-linux-amd64# ./etcdctl --cert-file /etc/etcd/pki/etcdctl-etcd-client.crt --key-file /etc/etcd/pki/etcdctl-etcd-client.key --ca-file /etc/etcd/pki/ca.crt --endpoints https://10.5.9.55:2379 member  list
223f95c9dff0b55: name=sapd-ubuntu-2 peerURLs=https://10.5.8.86:2380 clientURLs=https://10.5.8.86:2379 isLeader=false
983953b13a9e0a4: name=sapd-ubuntu-1 peerURLs=https://10.5.9.175:2380 clientURLs=https://10.5.9.175:2379 isLeader=false
b627deeadb65a889: name=sapd-ubuntu3 peerURLs=https://10.5.9.55:2380 clientURLs=https://10.5.9.55:2379 isLeader=true

1. Giới thiệu

- Có rất nhiều công cụ dùng để thu thập các metrics của HOST và VM như Collectd, Stats, Telegraf, Promethus, Diamond,...
- Mình sử dụng công cụ Diamond để thu thập các metrics của HOST và các VM chạy trên HOST đó. Diamond được viết bằng Python, vì vậy ta có thể dễ dàng sửa đổi code, cũng như code thêm 1 số plugin #. Tham khảo source code diamond:
https://github.com/python-diamond/Diamond

- Bài này mình sẽ giới thiệu về việc sử dụng:

• Diammond để thu thập disk size và disk partitions size.
• InfluxDB để lưu trữ dữ liệu các metrics.
• Grafana để generate dữ liệu thành các biểu đồ tiện theo dõi.

2. Diamond

- Diamond có plugin LibvirtKVMCollector để thu thập các metrics của VM như CPU, Memory,... Tuy vậy, nếu bạn muốn thu thập disk size và disk partitions size của VM thì Diamond chưa hỗ trợ.
Vì vậy, ta cần code thêm plugin để có thu thập disk size và disk partitions size.
- Thư viện libivrt không hỗ trợ lấy disk size và disk partitions size của VM, nên ta phải dùng thư viện bên thứ 3 là libguestFS (http://libguestfs.org/ ).
Kết hợp 2 thư viện libivirt và libguestfs, ta có thể thu thập metrics disk size và disk partitions size của tất cả các VM đang chạy trên HOST tương đối dễ dàng.
- Ví dụ code lấy disk size và disk partitions size:

#!/usr/bin/python3

import libvirt
import guestfs

# Get disks and disk partitions size of of domain
def get_disks_and_parts_size (conn, dom_name):
    # Connect to domain "dom_name"
    dom1 = conn.lookupByName(dom_name)
    if dom1 == None:
        print('Failed to find the domain '+dom_name)
        exit(1)

    # All new Python code should pass python_return_dict=True
    # to the constructor.  It indicates that your program wants
    # to receive Python dicts for methods in the API that return
    # hashtables.
    g = guestfs.GuestFS(python_return_dict=True)

    # Attach the disk image read-only to libguestfs.
    g.add_libvirt_dom(dom=dom1, readonly=True)

    # Run the libguestfs back-end.
    g.launch()

    # Get disks total size of VM
    disks = g.list_devices()    # ['/dev/sda', '/dev/sdb']
    disks_total_size = {}   # {'/dev/sda': 41126400, '/dev/sdb': 21474836480}
                            # unit is byte

    for disk in disks:
        size_of_disk_total = g.blockdev_getsize64(disk)
        disks_total_size[disk] = size_of_disk_total

    # Get disk partitions size of VM
    partitions_size = []    # [ ['/dev/sda1', '2058100', '988608', '1053108', '49%', '/sysroot'] ; 
                            #   ['/dev/sda15', '106858', '3668', '103190', '4%', '/sysroot'] ]
                            # unit is KiB
    partitions = g.list_partitions()

    for partition in partitions:
        try:
            g.mount_ro(partition, "/")
        except RuntimeError:
            continue
        df_list = g.df()
        df_list_line = df_list.splitlines()
        partition_size = df_list_line[5].split()
        partitions_size.append(partition_size)

3. InfluxDB và Grafana

- Sau khi Diamond thu thập được disk size và disk partitions size, ta sẽ gửi các metrics đó đến InflubDB. Cuối cùng ta dùng Grafana để generate các dữ liệu đó và được biểu đồ, hình dưới minh họa các biểu đồ về disk size và disk partitions size:

• Bandwidth
• IOPS
• Latency

Tool: Flexible I/O Tester(fio)

Cài đặt: sudo apt-get install fio trên Ubuntu hoặc sudo yum install fio -y trên Centos/RHEL

Kiểm tra tốc độ ghi: sudo fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=2 --runtime=240 --group_reporting

Câu lệnh này sẽ kiểm tra tốc độ ghi, tên file : randwrite, kích cỡ: 512MB, chạy 4 jobs và 2 process  (tổng cộng 4GB)

Ta thấy bandwidth và IOPS: write: IOPS=6315, BW=24.7MiB/s (25.9MB/s)(1024MiB/41507msec)

Kiểm tra tốc độ đọc: sudo fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=4 --runtime=240 --group_reporting Đọc file ngẫu nhiên tổng cộng 2GB

Ta thấy bandwidth và IOPS: read: IOPS=4173, BW=16.3MiB/s (17.1MB/s)(2048MiB/125615msec)

Kiểm tra tốc độ đọc ghi: sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 tổng cộng 4 GB

Ta thấy bandwidth và IOPS: read: IOPS=2275, BW=9104KiB/s (9322kB/s)(3070MiB/345321msec) và write: IOPS=760, BW=3042KiB/s (3115kB/s)(1026MiB/345321msec)

Kiểm tra tốc độ ghi đọc tuần tự

Command: dd
Đọc: dd if=/dev/zero of=/tmp/laptop.bin bs=1G count=1 oflag=direct Ghi 1 file 1GB
Ghi: dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync Đọc 1 file 1GB
Kiểm tra latency(thời gian thao tác đến lúc hoàn thành): dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync ghi 512byte 1000 lần

ví dụ:

Kiểm tra độ trễ

Tool: ioping

Cài đặt: sudo apt-get install ioping
Câu lệnh: ioping -c "n" Trong đó n là số request

Ví dụ: n = 10

Trong đó 529,5 us = 0,5295 ms

Giám sát các Disk

Tool: iostat, htop

Cài đặt: sudo apt-get install sysstat

• Theo dõi report từ boot: iostat
• Theo dõi liên tục mỗi n giây: iostat "n"
• Theo dõi n lần, mỗi lần cách m giây: iostat m n

Ví dụ:

Trong đó các thông số: avg-cpu: trung bình các cpu

3 giá trị về % CPU

• %user: phần trăm CPU được sử dụng khi chạy các ứng dụng ở user level (tất cả những gì không thuộc về kernel)
• %system: phần trăm CPU được sử dụng khi chạy ở system level (kernel)
• %nice: tương tự %user nhưng với nice priority.

3 giá trị về % thời gian

• %iowait: phần trăm thời gian mà CPU(s) rảnh  khi hệ thống thực hiện disk I/O request.
• %idle: phần trăm thời gian mà CPU(s) rảnh và hệ thống không thực hiện disk I/O request.
• %steal: phần trăm thời gian dành cho chờ đợi của CPU hoặc CPU ảo trong khi bộ ảo hóa đang phục vụ một bộ xử lý ảo khác.

6 giá trị về device:

• Device: tên device, ở đây là "sda". Một device có 1 hay nhiều partition. (dùng iostat -pd sda để hiển thị thông số cho từng partition trong sda)
• tps: transfer per second. Mỗi  transfer là một I/O request đến device. Nhiều logical request có thể được hợp lại thành 1 I/O request đến device =>  một transfer không có kích thước cố định.
• kB_read/s: số kilobytes đọc từ device
• kB_read: tổng số kilobytes đọc từ device  = kB_read/s * interval (s)
• k B_wrtn/s: số kilobytes ghi vào device
• kB_wrtn: tổng số kilobytes ghi  từ device  = kB_read/s * interval (s)

Đánh giá

- IOPS: Càng cao càng tốt

-Lantency: Càng thấp càng tốt

- Bandwidth: Càng cao càng tốt