CFSDN nhấn mạnh vào giá trị tạo ra nguồn mở và chúng tôi cam kết xây dựng nền tảng chia sẻ tài nguyên để mọi nhân viên CNTT có thể tìm thấy thế giới tuyệt vời của bạn tại đây.

Bài viết trên blog CFSDN này nói về cách Kubernetes triển khai khám phá dịch vụ. Nó được tác giả sưu tầm và biên soạn. Nếu bạn quan tâm đến bài viết này, hãy nhớ thích nó.

Hãy nói về khám phá dịch vụ Kubernetes. Trước hết, tiền đề chính là giao tiếp với máy chủ và giao tiếp giữa các máy chủ đều ổn, nghĩa là tất cả các Pod trong cùng một cụm Kubernetes đều có thể tương tác được. Điều này đạt được bằng các giải pháp cấp thấp hơn, bao gồm cầu docker0/CNI, chế độ Flannel vxlan/host-gw, v.v., những giải pháp này sẽ không được thảo luận trong bài viết này.

Với tiền đề là tất cả các Pod đều được kết nối với nhau, chúng ta có thể gọi các tài nguyên trên Pod bằng cách truy cập podIP Vậy thì cách khám phá dịch vụ còn bao xa? Mặt khác, IP của Pod không cố định. chúng tôi truy cập vào một nhóm phiên bản Pod Thường có nhu cầu cân bằng tải và đối tượng Service được sử dụng để giải quyết các vấn đề như vậy.

Giao tiếp nội cụm

Điểm cuối

Dịch vụ trước tiên giải quyết các nhu cầu liên lạc trong cụm. Đầu tiên chúng tôi viết một triển khai chung:

1. Phiên bản api: ứng dụng/v1 
2. loại: Triển khai 
3. siêu dữ liệu: 
4. tên: tên máy chủ 
5. đặc điểm kỹ thuật: 
6. bộ chọn: 
7. Nhãn phù hợp: 
8.   ứng dụng: tên máy chủ 
9. bản sao: 3 
10. bản mẫu: 
11. siêu dữ liệu: 
12.   nhãn: 
13.     ứng dụng: tên máy chủ 
14. đặc điểm kỹ thuật: 
15.   container: 
16.     - tên: tên máy chủ 
17.       hình ảnh: mirrorgooglecontainers/serve_hostname 
18.       cổng: 
19.         - containerPort: 9376 
20.           giao thức: TCP 

Những gì ứng dụng này làm là truy cập và trả về tên máy chủ của chính nó, đồng thời mỗi Pod được gắn nhãn tên máy chủ APP.

Sau đó, chúng tôi viết một Dịch vụ chung cho các nhóm này:

1. Phiên bản api: v1 
2. loại: Dịch vụ 
3. siêu dữ liệu: 
4. tên: tên máy chủ 
5. đặc điểm kỹ thuật: 
6. bộ chọn: 
7. ứng dụng: tên máy chủ 
8. cổng: 
9. - tên: mặc định 
10.   giao thức: TCP 
11.   cổng: 80 
12.   mục tiêuCổng: 9376 

Bạn có thể thấy rằng Dịch vụ chọn các Pod có nhãn tương ứng thông qua bộ chọn và các Pod được chọn này sẽ trở thành Điểm cuối. Chúng ta có thể thử:

1. ~/cloud/k8s kubectl lấy tên máy chủ ep 
2. TÊN        ĐIỂM CUỐI 
3. tên máy chủ 172.28.21.66:9376,172.28.29.52:9376,172.28.70.13:9376 

Khi một Pod gặp sự cố, không ở trạng thái chạy hoặc không sẵn sàngProbe, nó sẽ bị xóa khỏi danh sách Điểm cuối.

Cụm IP

Ở trên chúng ta có Dịch vụ và Điểm cuối và loại Dịch vụ được tạo mặc định là loại ClusterIP. Hãy kiểm tra Dịch vụ đã tạo trước đó:

1. ~ kubectl lấy tên máy chủ svc 
2. TÊN        LOẠI CỤM-IP CỔNG IP NGOÀI TUỔI 
3. tên máy chủ ClusterIP 10.212.8.127 80/TCP 8m2s 

Chúng ta thấy rằng ClusterIP là 10.212.8.127 thì chúng ta có thể truy cập bất kỳ Pod nào trong danh sách Endpoint thông qua địa chỉ này trong cluster Kubernetes:

1. sh-4.2# cuộn tròn 10.212.8.127 
2. tên máy chủ-8548b869d7-9qk6b 
3. sh-4.2# cuộn tròn 10.212.8.127 
4. tên máy chủ-8548b869d7-wzksp 
5. sh-4.2# cuộn tròn 10.212.8.127 
6. tên máy chủ-8548b869d7-bvlw8 

Sau khi truy cập địa chỉ ClusterIP ba lần và trả về ba tên máy chủ khác nhau, chúng tôi nhận thấy rằng Dịch vụ chế độ ClusterIP đã tự động thực hiện cân bằng tải theo vòng tròn theo yêu cầu.

Đối với Serivice ở chế độ ClusterIP lúc này có bản ghi A là service-name.namespace-name.svc.cluster.local trỏ tới địa chỉ ClusterIP:

1. sh-4.2# nslookup hostnames.coops-dev.svc.cluster.địa phương 
2. Máy chủ: 10.212.0.2 
3. Địa chỉ: 10.212.0.2#53 
4.  
5. Tên: hostnames.coops-dev.svc.cluster.địa phương 
6. Địa chỉ: 10.212.8.127 

Tất nhiên chúng tôi nhận được hiệu ứng tương tự khi truy cập thông qua bản ghi A này:

1. sh-4.2# curl hostnames.coops-dev.svc.cluster.địa phương 
2. tên máy chủ-8548b869d7-wzksp 

Vậy bản ghi A của Pod là gì? Chúng ta có thể xem qua:

1. sh-4.2# nslookup 172.28.21.66  
2. 66.21.28.172.TRONG-addr.arpa tên = 172-28-21-66.hostnames.coops-dev.svc.cluster.địa phương. 

Dịch vụ không đầu

CluserIP của Dịch vụ được Kubernetes tự động gán theo mặc định. Tất nhiên, bạn cũng có thể tự thiết lập. Khi chúng ta đặt CluserIP thành Không, nó sẽ trở thành dịch vụ Headless.

Dịch vụ không đầu thường được sử dụng với StatefulSet. StatefulSet là một phương pháp điều phối vùng chứa cho các ứng dụng có trạng thái. Ý tưởng cốt lõi của nó là đặt cho Pod một tên số được chỉ định để Pod có mã nhận dạng mạng duy nhất không thay đổi. Trong trường hợp đó, việc sử dụng cân bằng tải CluserIP để truy cập Pod rõ ràng là không khả thi, bởi vì chúng tôi mong muốn truy cập trực tiếp vào chính Pod thông qua nhận dạng chứ không phải VIP ảo.

Tại thời điểm này, chúng ta thực sự có thể sử dụng DNS. Mỗi Pod sẽ có một bản ghi A pod-name.service-name.namespace-name.svc.cluster.local trỏ đến podIP. Chúng ta có thể truy cập trực tiếp vào Pod thông qua bản ghi A này.

Chúng ta hãy xem cách viết StatefulSet và Service tương ứng:

1. --- 
2. Phiên bản api: ứng dụng/v1 
3. loại: StatefulSet 
4. siêu dữ liệu: 
5. tên: tên máy chủ 
6. đặc điểm kỹ thuật: 
7. Tên dịch vụ: "tên máy chủ" 
8. bộ chọn: 
9. Nhãn phù hợp: 
10.   ứng dụng: tên máy chủ 
11. bản sao: 3 
12. bản mẫu: 
13. siêu dữ liệu: 
14.   nhãn: 
15.     ứng dụng: tên máy chủ 
16. đặc điểm kỹ thuật: 
17.   container: 
18.     - tên: tên máy chủ 
19.       hình ảnh: mirrorgooglecontainers/serve_hostname 
20.       cổng: 
21.         - containerPort: 9376 
22.           giao thức: TCP 
23.  
24. --- 
25. Phiên bản api: v1 
26. loại: Dịch vụ 
27. siêu dữ liệu: 
28. tên: tên máy chủ 
29. đặc điểm kỹ thuật: 
30. bộ chọn: 
31. ứng dụng: tên máy chủ 
32. clusterIP: Không có 
33. cổng: 
34. - tên: mặc định 
35.   giao thức: TCP 
36.   cổng: 80 
37.   mục tiêuCổng: 9376 

Như trên, không có sự khác biệt giữa StatefulSet và triển khai. Có một trường bổ sung spec.serviceName. Chức năng của trường này là yêu cầu bộ điều khiển StatefulSet sử dụng Dịch vụ tên máy chủ trong quá trình xử lý logic để đảm bảo khả năng phân giải duy nhất của Pod.

Sau khi thực hiện áp dụng, bạn sẽ thấy Pod tương ứng được tạo sau một thời gian:

1. ~ kubectl lấy pod -w -l ứng dụng=tên máy chủ 
2. TÊN          TRẠNG THÁI SẴN SÀNG KHỞI ĐỘNG LẠI TUỔI 
3. hostnames-0 1/1 Đang chạy 0 9m54s 
4. hostnames-1 1/1 Đang chạy 0 9m28s 
5. hostnames-2 1/1 Đang chạy 0 9m24s 

Đúng như dự đoán, tên các Pod được đánh số tăng dần và không bị lặp lại. Đồng thời, quá trình tạo các Pod này cũng được thực hiện tuần tự theo số lượng. Chúng tôi biết rằng tên Pod được triển khai bằng triển khai sẽ được thêm cùng với tên replicaSet và một số ngẫu nhiên, số này sẽ tiếp tục thay đổi sau khi khởi động lại. Đối với Pod được triển khai bằng StatefulSet tại đây, mặc dù podIP vẫn sẽ thay đổi nhưng tên sẽ không bao giờ thay đổi. Dựa vào điều này, chúng ta có thể truy cập từng Pod thông qua một bản ghi DNS A cố định.

Vì vậy, tại thời điểm này, chúng ta hãy xem bản ghi A của Pod:

1. sh-4.2# nslookup hostnames-0.hostnames 
2. Máy chủ: 10.212.0.2 
3. Địa chỉ: 10.212.0.2#53 
4.  
5. Tên: hostnames-0.hostnames.coops-dev.svc.cluster.địa phương 
6. Địa chỉ: 172.28.3.57 
7.  
8. sh-4.2# nslookup hostnames-1.hostnames 
9. Máy chủ: 10.212.0.2 
10. Địa chỉ: 10.212.0.2#53 
11.  
12. Tên: hostnames-1.hostnames.coops-dev.svc.cluster.địa phương 
13. Địa chỉ: 172.28.29.31 
14.  
15. sh-4.2# nslookup hostnames-2.hostnames 
16. Máy chủ: 10.212.0.2 
17. Địa chỉ: 10.212.0.2#53 
18.  
19. Tên: hostnames-2.hostnames.coops-dev.svc.cluster.địa phương 
20. Địa chỉ: 172.28.23.31 

Phù hợp với suy luận trước đó, chúng ta có thể truy cập podIP thông qua bản ghi A pod-name.service-name.namespace-name.svc.cluster.local. Trong cùng một không gian tên, chúng ta có thể đơn giản hóa nó thành pod-name.service-name. .

Tại thời điểm này, bản ghi Dịch vụ là gì:

1. sh-4.2# nslookup tên máy chủ 
2. Máy chủ: 10.212.0.2 
3. Địa chỉ: 10.212.0.2#53 
4.  
5. Tên: hostnames.coops-dev.svc.cluster.địa phương 
6. Địa chỉ: 172.28.29.31 
7. Tên: hostnames.coops-dev.svc.cluster.địa phương 
8. Địa chỉ: 172.28.3.57 
9. Tên: hostnames.coops-dev.svc.cluster.địa phương 
10. Địa chỉ: 172.28.23.31 

Hóa ra đó là một nhóm podIP trong danh sách Điểm cuối, nghĩa là bạn vẫn có thể truy cập cân bằng tải vào Pod phụ trợ thông qua bản ghi service-name.namespace-name.svc.cluster.local A.

iptables

Ít nhiều chúng ta đều biết rằng Dịch vụ trong Kubernetes hoạt động dựa trên kube-proxy và iptables. Sau khi Dịch vụ được tạo, kube-proxy có thể nhận biết nó và sẽ tạo các quy tắc iptables tương ứng trên máy chủ cho mục đích này.

Lấy Dịch vụ chế độ CluserIP làm ví dụ, trước tiên nó sẽ tạo quy tắc KUBE-SERVICES làm mục nhập:

1. -A KUBE-SERVICES -d 10.212.8.127/32 -p tcp -m bình luận --comment "mặc định/tên máy chủ: IP cụm" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3 

Ý nghĩa của bản ghi này là: tất cả địa chỉ đích của CluserIP này sẽ được chuyển sang chuỗi iptables KUBE-SVC để xử lý.

Vậy hãy cùng xem chuỗi KUBE-SVC là gì:

1. -A KUBE-SVC-NWV5X2332I4OT4T3 -m bình luận --comment "mặc định/tên máy chủ:" -m thống kê --chế độ ngẫu nhiên --xác suất 0,33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ 
2. -A KUBE-SVC-NWV5X2332I4OT4T3 -m bình luận --comment "mặc định/tên máy chủ:" -m thống kê --chế độ ngẫu nhiên --xác suất 0,50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3 
3. -A KUBE-SVC-NWV5X2332I4OT4T3 -m bình luận --comment "mặc định/tên máy chủ:" -j KUBE-SEP-57KPRZ3JQVENLNBR 

Bộ quy tắc này thực sự được sử dụng để cân bằng tải. Chúng tôi thấy rằng --probability là 1/3, 1/2 và 1 theo thứ tự vì các quy tắc iptables được khớp từ trên xuống dưới, nên việc thiết lập các giá trị này có thể đảm bảo rằng mỗi quy tắc. các trận đấu chuỗi có xác suất đến như nhau. Sau khi xử lý logic cân bằng tải, các yêu cầu lần lượt được chuyển tiếp đến ba quy tắc khác:

1. -A KUBE-SEP-57KPRZ3JQVENLNBR -s 172.28.21.66/32 -m bình luận --comment "mặc định/tên máy chủ:" -j MARK --set-xmark 0x00004000/0x00004000  
2. -A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m bình luận --comment "mặc định/tên máy chủ:" -m tcp -j DNAT --đến đích 172.28.21.66:9376 
3.  
4. -A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 172.28.29.52/32 -m bình luận --comment "mặc định/tên máy chủ:" -j MARK --set-xmark 0x00004000/0x00004000  
5. -A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m bình luận --comment "mặc định/tên máy chủ:" -m tcp -j DNAT --đến đích 172.28.29.52:9376 
6.  
7. -A KUBE-SEP-X3P2623AGDH6CDF3 -s 172.28.70.13/32 -m bình luận --comment "mặc định/tên máy chủ:" -j MARK --set-xmark 0x00004000/0x00004000  
8. -A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m bình luận --comment "mặc định/tên máy chủ:" -m tcp -j DNAT --đến đích 172.28.70.13:9376 

Bạn có thể thấy rằng chuỗi KUBE-SEP có ba quy tắc DNAT và cờ 0x00004000 được đặt trước DNAT. Quy tắc DNAT là thay đổi địa chỉ đích và cổng của yêu cầu thành podIP và cổng được chỉ định bởi --to-destination trước PREROUTING, tức là trước khi việc định tuyến có hiệu lực. Bằng cách này, yêu cầu truy cập CluserIP 10.212.8.127 ban đầu của chúng tôi sẽ được cân bằng tải cho từng Pod.

Vậy tôi nên làm gì nếu pod được khởi động lại và podIP thay đổi? Đương nhiên, kube-proxy chịu trách nhiệm giám sát các thay đổi của pod cũng như cập nhật và duy trì các quy tắc iptables.

Đối với dịch vụ không có đầu, chúng tôi truy cập trực tiếp vào Pod thông qua bản ghi A cố định, vì vậy đương nhiên các quy tắc iptables này là không cần thiết.

iptables tương đối dễ hiểu nhưng trên thực tế hiệu suất của nó không tốt. Như bạn có thể tưởng tượng, khi chúng ta có số lượng Pod lớn thì hàng nghìn iptables Rules sẽ được tạo ra và được làm mới liên tục, điều này sẽ chiếm rất nhiều tài nguyên CPU trên máy chủ. Một giải pháp hiệu quả là dịch vụ dựa trên chế độ IPVS không cần đặt quy tắc iptables cho mỗi Pod. Thay vào đó, các quy tắc này được đặt ở trạng thái kernel, giúp giảm đáng kể chi phí duy trì các quy tắc này.

Giao tiếp giữa các cụm

Quyền truy cập bên ngoài vào Dịch vụ

Ở trên, chúng ta đã nói về cách các yêu cầu được truyền đạt trong cụm Kubernetes, chủ yếu dựa trên các bản ghi DNS do kube-dns tạo và các quy tắc iptables được duy trì bởi kube-proxy. Tất cả thông tin này được áp dụng trong cụm, vì vậy đương nhiên chúng tôi không thể truy cập một Dịch vụ hoặc Pod cụ thể từ bên ngoài cụm.

Ngoài chế độ CluserIP mặc định, Service còn cung cấp nhiều chế độ khác, chẳng hạn như chế độ nodePort, được sử dụng để giải quyết vấn đề này.

1. Phiên bản api: v1 
2. loại: Dịch vụ 
3. siêu dữ liệu: 
4. tên: tên máy chủ 
5. đặc điểm kỹ thuật: 
6. bộ chọn: 
7. ứng dụng: tên máy chủ 
8. loại: NodePort 
9. cổng: 
10. - nodePort: 8477 
11.   giao thức: TCP 
12.   cổng: 80 
13.   mục tiêuCổng: 9376 

Chúng tôi đã viết một Dịch vụ ở chế độ NodePort và đặt NodePort thành 8477, có nghĩa là chúng tôi có thể truy cập Dịch vụ tên máy chủ thông qua cổng 8477 của bất kỳ máy chủ nào.

1. sh-4.2# cuộn tròn 10.1.6.25:8477 
2. tên máy chủ-8548b869d7-j5lj9 
3. sh-4.2# cuộn tròn 10.1.6.25:8477 
4. tên máy chủ-8548b869d7-66vnv 
5. sh-4.2# cuộn tròn 10.1.6.25:8477 
6. tên máy chủ-8548b869d7-szz4f 

Chúng tôi ngẫu nhiên tìm thấy một địa chỉ Node để truy cập và nhận được cùng một công thức trả về.

Vậy quy tắc iptables của nó hoạt động như thế nào vào lúc này:

1. -A CUBE-NODEPORTS -p tcp -m bình luận --comment "mặc định/tên máy chủ: nodePort" -m tcp --dport 8477 -j KUBE-SVC-67RL4FN6JRUPOJYM 

kube-proxy tạo ra các quy tắc iptables ở trên trên mỗi máy chủ. Cổng được chỉ định thông qua --dport. Các yêu cầu truy cập vào cổng sẽ chuyển sang chuỗi KUBE-SVC và công thức Dịch vụ CluserIP trước đó. bước này không khác gì truy cập Dịch vụ CluserIP.

Tuy nhiên, cần lưu ý rằng khi yêu cầu rời khỏi máy chủ hiện tại và được gửi đến các Nút khác, thao tác SNAT sẽ được thực hiện trên đó:

1. -Một bình luận của KUBE-POSROUTING -m --comment "lưu lượng dịch vụ kubernetes yêu cầu SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE 

Bạn có thể thấy rằng quy tắc định tuyến sau này thực hiện SNAT đối với yêu cầu sắp rời khỏi máy chủ. Điều kiện phán đoán là nó mang cờ 0x4000, là cờ được mang bởi DNAT trước đó, do đó đánh giá rằng yêu cầu được chuyển tiếp từ đó. Dịch vụ, không phải là một yêu cầu thông thường.

Lý do cần thực hiện SNAT rất đơn giản. Trước hết, đây là một yêu cầu bên ngoài chưa được Kubernetes xử lý. Nếu nó truy cập vào nút 1, quá trình cân bằng tải của nút 1 sẽ chuyển tiếp nó đến một Pod trên nút 2. không có vấn đề gì, và Pod này đã được xử lý. Sau đó trực tiếp quay trở lại máy khách bên ngoài, khi đó máy khách bên ngoài sẽ rất bối rối. Rõ ràng là nó đang truy cập vào nút 1, nhưng thực sự đó là nút 2 được trả về chính nó. , lỗi thường sẽ được báo cáo.

Chức năng của SNAT ngược lại với DNAT. Khi yêu cầu rời khỏi nút 1 và được gửi đến nút 2, địa chỉ nguồn sẽ được thay đổi thành địa chỉ của nút 1. Sau đó, khi Pod trên nút 2 quay trở lại, nó sẽ được trả về nút 1 và sau đó. node1 sẽ được trả lại cho máy khách.

1. khách hàng 
2.             | ^ 
3.             | | 
4.             trong | 
5. nút 2 <--- nút 1 
6. | ^ SNAT 
7. | |   ---> 
8. trong | 
9. điểm cuối 

Dịch vụ có hai cách khác để truy cập nó từ thế giới bên ngoài. Đối với dịch vụ chế độ LoadBalancer của đám mây công cộng, đám mây công cộng Kubernetes sẽ gọi CloudProvider để tạo dịch vụ cân bằng tải cho bạn trên đám mây công cộng và định cấu hình địa chỉ IP của Pod được ủy quyền cho dịch vụ cân bằng tải làm phụ trợ. Chế độ còn lại là chế độ Tên ngoài. Bạn có thể chỉ định tên miền truy cập bên ngoài mà bạn muốn trong spec.externalName, chẳng hạn như tên máy chủ.example.com, sau đó bạn truy cập tên miền và truy cập service-name.namespace-name.svc.cluser. local Hiệu quả là như nhau. Tại thời điểm này, bạn nên biết rằng kube-dns thực sự đã thêm bản ghi CNAME cho bạn.

xâm nhập

Có một loại Service tên là LoadBalancer Tuy nhiên, nếu mỗi Service được cấu hình với một dịch vụ cân bằng tải bên ngoài thì sẽ rất tốn kém và lãng phí. Nói chung, chúng tôi hy vọng có một bộ cân bằng tải toàn cầu chuyển tiếp đến các Dịch vụ khác nhau bằng cách truy cập các URL khác nhau. Đây là chức năng của Ingress có thể được coi là một Dịch vụ.

Ingress thực sự là một sự trừu tượng hóa của proxy ngược. Tôi tin rằng bạn đã cảm thấy rằng thứ này rất giống với Nginx. Trên thực tế, Ingress là một lớp trừu tượng và một trong các lớp triển khai của nó hỗ trợ Nginx.

Chúng ta có thể triển khai bộ điều khiển xâm nhập nginx:

1. $ kubectl áp dụng -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml 

Bắt buộc.yaml là bộ điều khiển xâm nhập được duy trì chính thức.

1. loại: ConfigMap 
2. Phiên bản api: v1 
3. siêu dữ liệu: 
4. tên: cấu hình nginx 
5. không gian tên: ingress-nginx 
6. nhãn: 
7. ứng dụng.kubernetes.io/tên: ingress-nginx 
8. app.kubernetes.io/part-của: ingress-nginx 
9. --- 
10. apiVersion: phần mở rộng/v1beta1 
11. loại: Triển khai 
12. siêu dữ liệu: 
13. tên: nginx-ingress-controller 
14. không gian tên: ingress-nginx 
15. nhãn: 
16. ứng dụng.kubernetes.io/tên: ingress-nginx 
17. app.kubernetes.io/part-của: ingress-nginx 
18. đặc điểm kỹ thuật: 
19. bản sao: 1 
20. bộ chọn: 
21. Nhãn phù hợp: 
22.   ứng dụng.kubernetes.io/tên: ingress-nginx 
23.   app.kubernetes.io/part-của: ingress-nginx 
24. bản mẫu: 
25. siêu dữ liệu: 
26.   nhãn: 
27.     ứng dụng.kubernetes.io/tên: ingress-nginx 
28.     app.kubernetes.io/part-của: ingress-nginx 
29.   chú thích: 
30.     ... 
31. đặc điểm kỹ thuật: 
32.   serviceAccountName: nginx-ingress-serviceaccount 
33.   container: 
34.     - tên: nginx-ingress-controller 
35.       hình ảnh: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.20.0 
36.       các đối số: 
37.         - /nginx-ingress-controller 
38.         - --configmap=$(POD_NAMESPACE)/cấu hình nginx 
39.         - --publish-service=$(POD_NAMESPACE)/ingress-nginx 
40.         - --annotations-tiền tố=nginx.ingress.kubernetes.io 
41.       securityContext: 
42.         khả năng: 
43.           làm rơi: 
44.             - TẤT CẢ 
45.           thêm vào: 
46.             - DỊCH VỤ_BIND_MẠNG 
47.         # www-dữ liệu -> 33 
48.         chạyVới tư cách là người dùng: 33 
49.       môi trường: 
50.         - tên: TÊN POD 
51.           giá trịTừ: 
52.             trườngRef: 
53.               fieldPath: siêu dữ liệu.tên 
54.         - tên: POD_NAMESPACE 
55.         - tên:http 
56.           giá trịTừ: 
57.             trườngRef: 
58.               fieldPath: metadata.namespace 
59.       cổng: 
60.         - tên:http 
61.           containerCảng: 80 
62.         - tên: https 
63.           containerCảng: 443 

Tóm lại, chúng tôi đã xác định một Pod dựa trên hình ảnh bộ điều khiển nginx-ingress và bản thân Pod này là bộ điều khiển giám sát các thay đổi trong đối tượng Ingress và Dịch vụ phụ trợ proxy của nó.

Khi một đối tượng Ingress được tạo, bộ điều khiển nginx-ingress sẽ tạo tệp cấu hình Nginx (nginx.conf) dựa trên nội dung của đối tượng Ingress và khởi động dịch vụ Nginx tương ứng.

Khi đối tượng Ingress được cập nhật, bộ điều khiển nginx-ingress sẽ cập nhật tệp cấu hình này. Bộ điều khiển nginx-ingress-controller cũng triển khai cấu hình động của nginx ngược dòng thông qua giải pháp Nginx Lua.

Để cho phép thế giới bên ngoài truy cập Nginx này, chúng tôi phải tạo một Dịch vụ để nó hiển thị Nginx:

1. $ kubectl áp dụng -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/baremetal/service-nodeport.yaml 

Nội dung ở đây mô tả Dịch vụ loại NodePort:

1. Phiên bản api: v1 
2. loại: Dịch vụ 
3. siêu dữ liệu: 
4. tên: ingress-nginx 
5. không gian tên: ingress-nginx 
6. nhãn: 
7. ứng dụng.kubernetes.io/tên: ingress-nginx 
8. app.kubernetes.io/part-của: ingress-nginx 
9. đặc điểm kỹ thuật: 
10. loại: NodePort 
11. cổng: 
12. - tên:http 
13.   cổng: 80 
14.   mục tiêuCổng: 80 
15.   giao thức: TCP 
16. - tên: https 
17.   cổng: 443 
18.   mục tiêuCổng: 443 
19.   giao thức: TCP 
20. bộ chọn: 
21. ứng dụng.kubernetes.io/tên: ingress-nginx 
22. app.kubernetes.io/part-của: ingress-nginx 

Bạn có thể thấy rằng Dịch vụ này chỉ hiển thị cổng 80/443 của Nginx Pod. Sau đó, bạn có thể truy cập Nginx thông qua IP máy chủ và NodePort.

Tiếp theo, hãy xem các đối tượng Ingress thường được viết như thế nào. Chúng ta có thể tham khảo một ví dụ.

1. apiVersion: phần mở rộng/v1beta1 
2. loại: Ingress 
3. siêu dữ liệu: 
4. tên: cafe-ingress 
5. đặc điểm kỹ thuật: 
6. tls: 
7. - máy chủ: 
8. - cafe.example.com 
9. secretName: cafe-secret 
10. quy tắc: 
11. - máy chủ: cafe.example.com 
12. http: 
13.   đường dẫn: 
14.   - đường dẫn: /tea 
15.     phần sau: 
16.       serviceName: tea-svc 
17.       dịch vụCổng: 80 
18.   - đường dẫn: /coffee 
19.     phần sau: 
20.       serviceName: coffee-svc 
21.       dịch vụCổng: 80 

Ingress này chỉ ra rằng tên miền tổng thể của chúng tôi là cafe.example.com. Chúng tôi hy vọng có thể truy cập Dịch vụ trà-svc thông qua cafe.example.com/tea và Dịch vụ cà phê-svc thông qua cafe.example.com/coffee. Ở đây chúng tôi viết các quy tắc chuyển tiếp thông qua trường khóa spec.rules.

Chúng ta có thể xem chi tiết về đối tượng Ingress:

1. $ kubectl lấy dữ liệu nhập 
2. TÊN           MÁY CHỦ ĐỊA CHỈ CỔNG TUỔI 
3. cafe-ingress cafe.example.com 80, 443 2 giờ 
4.  
5. $ kubectl mô tả ingress cafe-ingress 
6. Tên: cafe-ingress 
7. Không gian tên:        mặc định 
8. Địa chỉ: 
9. Mặc định phần sau:  mặc định-http-backend:80 () 
10. TLS: 
11. cafe-secret chấm dứt cafe.example.com 
12. Quy tắc: 
13. Đường dẫn lưu trữ Backend 
14. ---- ---- -------- 
15. cafe.example.com 
16.                 /tea tea-svc:80 () 
17.                 /coffee coffee-svc:80 () 
18. Chú thích: 
19. Sự kiện: 
20. Loại Lý do Tuổi   Từ                      Tin nhắn 
21. ---- ------ ---- ---- ------- 
22. Bình thường  TẠO NÊN  4m nginx-ingress-controller Ingress mặc định/cafe-ingress 

Chúng tôi đã đề cập trước đó rằng chúng tôi đã tiết lộ nginx-ingress thông qua NodePort và tại thời điểm này, cấu hình Ingress của chúng tôi hy vọng có thể truy cập Pod phụ trợ thông qua cafe.example.com, vì vậy trước tiên, tên miền cafe.example.com phải được trỏ đến Trên bất kỳ IP máy chủ nào :nodePort, yêu cầu đến nginx-ingress và sau đó được chuyển tiếp đến từng Dịch vụ phụ trợ. Tất nhiên, có nhiều cách để phát hiện nginx-ingress, bao gồm NodePort, LoadBalancer, HostNetwork, v.v.

Cuối cùng hãy thử yêu cầu:

1. $ curl cafe.example.com/coffee 
2. Máy chủ tên: cà phê-7dbb5795f6-vglbv 
3. $ curl cafe.example.com/tea 
4. Máy chủ tên: trà-7d57856c44-lwbnp 

Bạn có thể thấy rằng bộ điều khiển Nginx Ingress đã chuyển tiếp thành công yêu cầu đến Dịch vụ phụ trợ tương ứng cho chúng tôi. Và khi yêu cầu không khớp với bất kỳ quy tắc xâm nhập nào, tất nhiên chúng ta sẽ nhận được 404.

Cho đến nay, chúng ta đã nói xong về cách mạng container Kubernetes triển khai khám phá dịch vụ và khám phá dịch vụ là vấn đề cốt lõi trong kiến ​​trúc microservice. Nếu vấn đề này được giải quyết thì việc sử dụng Kubernetes để triển khai kiến ​​trúc microservice sẽ được hơn một nửa.

Địa chỉ gốc: https://fredal.xin/kubertnetes-discovery.

Cuối cùng, bài viết về cách Kubernetes triển khai khám phá dịch vụ kết thúc ở đây. Nếu bạn muốn biết thêm về cách Kubernetes triển khai khám phá dịch vụ, vui lòng tìm kiếm các bài viết về CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng tất cả các bạn sẽ ủng hộ blog của tôi trong tương lai! .