Để hiểu rõ hơn về câu hỏi này, đáng để nhắc lại những điều cơ bản Các thành phần Kubernetes.
Về cơ bản chúng ta có thể chia cụm thành:
- Nút chính: Mặt phẳng điều khiển, chịu trách nhiệm đưa ra các quyết định toàn cầu về cụm
- Worker Node(s) - chịu trách nhiệm chạy các nhóm bằng cách cung cấp môi trường thời gian chạy Kubernetes.
Chúng ta hãy xem các thành phần của phần "Nút" (công nhân):
kubelet
Một đại lý chạy trên mỗi nút trong cụm. Nó đảm bảo rằng hộp đựng đang chạy trong một vỏ.
Kubelet lấy một bộ PodSpec được cung cấp thông qua các cơ chế khác nhau và đảm bảo rằng các vùng chứa được mô tả trong các PodSpec đó đang chạy và khỏe mạnh. Kubelet không quản lý các thùng chứa không được tạo bởi Kubernetes.
kube-proxy
kube-proxy là một proxy mạng chạy trên mỗi nút trong cụm của bạn, triển khai một phần của Kubernetes Dịch vụ Ý tưởng.
kube-proxy duy trì các quy tắc mạng trên các nút. Các quy tắc mạng này cho phép giao tiếp mạng với các Nhóm của bạn từ các phiên mạng bên trong hoặc bên ngoài cụm của bạn.
kube-proxy sử dụng lớp lọc gói hệ điều hành nếu có và nó khả dụng. Mặt khác, kube-proxy tự chuyển tiếp lưu lượng truy cập.
thời gian chạy vùng chứa
Thời gian chạy vùng chứa là phần mềm chịu trách nhiệm chạy các vùng chứa.
Kubernetes hỗ trợ một số thời gian chạy vùng chứa: docker, chứa đựng, CRI-Ovà bất kỳ triển khai nào của Kubernetes CRI (Giao diện thời gian chạy vùng chứa).
Như kubelet và Container runtime là hai thành phần chính chịu trách nhiệm chạy pod và thiết lập kết nối với Control Plane, chúng phải được cài đặt trực tiếp trên hệ điều hành của nút. Nó cũng có nghĩa là cho kubelet nó phải có chứng chỉ TLS mà bạn đã đề cập trong câu hỏi của mình để đảm bảo kết nối an toàn với Mặt phẳng điều khiển. Thế còn kube-proxy?
Nó có thể được cài đặt theo hai cách trong quá trình cung cấp cụm - trực tiếp trên hệ điều hành của nút (ví dụ: cách này được sử dụng trong Kubernetes Con đường khó khăn) hoặc dưới dạng DaemonSet (kubeadm).
Khi nào kube-proxy Là cài đặt trực tiếp nó cũng sẽ có một cách riêng biệt chứng chỉ TLS được tạo, giống như kubelet.
Cách thứ hai, là "DeamonSet" được đề cập trong câu hỏi của bạn. Có nghĩa là, thay vì chạy dưới dạng OS deamon trực tiếp trên nút, nó sẽ được cấu hình thông qua DeamonSet triển khai và nó sẽ chạy dưới dạng nhóm trên mọi nút. Ưu điểm so với chạy trực tiếp trên hệ điều hành:
- Sử dụng các tính năng của DeamonSet, chúng tôi đảm bảo rằng trong trường hợp xảy ra lỗi, nhóm này sẽ tự động được tạo lại trên nút
- ít can thiệp trực tiếp hơn vào hệ điều hành nút - thay vì tạo chứng chỉ TLS cặp mới, chúng tôi sẽ chỉ sử dụng ServiceAccount
Trả lời câu hỏi của bạn:
Điều gì đặc biệt ở đây về Daemonsets liên quan đến xác thực?
Để hiểu rõ hơn chúng ta có thể xem xét sâu hơn về kube-proxy được định cấu hình qua DaemonSets bằng cách sử dụng cụm được cung cấp với kubeadm. Dựa trên Tài liệu Kubernetes:
Một ServiceAccount cho kube-proxy được tạo ra trong hệ thống kube không gian tên; sau đó kube-proxy được triển khai dưới dạng DaemonSet:
- Thông tin đăng nhập (
ca.crt và mã thông báo) đến mặt phẳng điều khiển đến từ ServiceAccount
- Vị trí (URL) của máy chủ API đến từ Bản đồ cấu hình
- Các
kube-proxy ServiceAccount bị ràng buộc với các đặc quyền trong hệ thống: nút-proxier CụmVai trò
Có ba điểm. Trước tiên hãy kiểm tra cái đầu tiên:
Thông tin xác thực - bí mật
Nhận tên tài khoản dịch vụ từ định nghĩa nhóm:
kubectl get daemonset kube-proxy -n kube-system -o yaml
...
tài khoản dịch vụ: kube-proxy
serviceAccountName: kube-proxy
...
Như, có thể thấy, nó có được chỉ định một Tài khoản dịch vụ gọi điện kube-proxy:
Hãy kiểm tra nó:
kubectl get sa kube-proxy -n kube-system -o yaml
Đầu ra:
phiên bản api: v1
loại: ServiceAccount
metadata:
tạoDấu thời gian: "2021-08-16T14:14:56Z"
tên: kube-proxy
không gian tên: hệ thống kube
resourceVersion: "259"
người dùng: (UID)
bí mật:
- tên: kube-proxy-token-2qhph
Như có thể thấy, chúng ta đang đề cập đến bí mật có tên kube-proxy-token-2qhph:
kubectl lấy bí mật kube-proxy-token-2qhph -n kube-system -o yaml
Đầu ra:
phiên bản api: v1
dữ liệu:
ca.crt: (ĐÃ MÃ HÓA CA BASE64 CỦA APISERVER)
không gian tên: (NAMESPACE BASE64 ĐƯỢC MÃ HÓA)
mã thông báo: (BEARER TOKEN BASE64 ĐƯỢC MÃ HÓA)
loại: Bí mật
metadata:
chú thích:
kubernetes.io/service-account.name: kube-proxy
kubernetes.io/service-account.uid: ...
tạoDấu thời gian: "2021-08-16T14:14:56Z"
tên: kube-proxy-token-2qhph
không gian tên: hệ thống kube
resourceVersion: "256"
người dùng: (UID)
gõ: kubernetes.io/service-account-token
Bí mật này chứa đựng:
Bí mật đã tạo chứa CA công khai của máy chủ API và Mã thông báo web JSON (JWT) đã ký.
Chúng tôi đang sử dụng mã thông báo mang "JSON Web Token" này để xác minh các yêu cầu:
Tài khoản dịch vụ là trình xác thực được bật tự động sử dụng mã thông báo mang đã ký để xác minh yêu cầu.
JWT đã ký có thể được sử dụng làm mã thông báo mang để xác thực là tài khoản dịch vụ đã cho. Nhìn thấy ở trên để biết cách mã thông báo được bao gồm trong một yêu cầu. Thông thường, những bí mật này được gắn vào các nhóm để truy cập trong cụm vào máy chủ API, nhưng cũng có thể được sử dụng từ bên ngoài cụm.
Để biết thêm thông tin về mã thông báo bootstrap, tôi khuyên bạn nên đọc các tài liệu Kubernetes sau: Xác thực bằng Bootstrap Tokens, mã thông báo kubeadm và Kubernetes RBAC 101: Xác thực.
Bản đồ cấu hình
Bằng cách làm theo các bước tương tự như để lấy tên ServiceAccount, chúng ta sẽ nhận được tên ConfigMap được gắn vào kube-proxy nhóm:
kubectl get daemonset kube-proxy -n kube-system -o yaml
...
khối lượng:
- bản đồ cấu hình:
chế độ mặc định: 420
tên: kube-proxy
...
Bây giờ, hãy lấy định nghĩa ConfigMap:
kubectl get cm kube-proxy -n kube-system -o yaml
kubeconfig.conf: |-
phiên bản api: v1
loại: Cấu hình
cụm:
- cụm:
cơ quan cấp chứng chỉ: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
máy chủ: https://10.230.0.12:6443
tên: mặc định
bối cảnh:
- bối cảnh:
cụm: mặc định
không gian tên: mặc định
người dùng: mặc định
tên: mặc định
bối cảnh hiện tại: mặc định
người dùng:
- tên: mặc định
người dùng:
tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
Địa chỉ IP này ở bên dưới người phục vụ: là địa chỉ API vậy kube-proxy biết nó và có thể giao tiếp với nó.
Ngoài ra còn có tài liệu tham khảo đến xe đẩy và mã thông báo được gắn từ kube-proxy-token-2qhph bí mật.
CụmVai trò
Hãy kiểm tra ClusterRole đã đề cập trước đó - hệ thống: nút-proxier:
kubectl mô tả hệ thống clusterrole:node-proxier
Tên: hệ thống: nút-proxier
Nhãn: kubernetes.io/bootstrapping=rbac-defaults
Chú thích: rbac.authorization.kubernetes.io/autoupdate: true
Quy tắc chính sách:
Tài nguyên URL phi tài nguyên Tên tài nguyên Động từ
--------- ----------------- -------------- -----
sự kiện [] [] [tạo cập nhật bản vá]
event.events.k8s.io [] [] [tạo cập nhật bản vá]
các nút [] [] [lấy danh sách xem]
điểm cuối [] [] [xem danh sách]
dịch vụ [] [] [danh sách xem]
endpointslices.Discovery.k8s.io [] [] [xem danh sách]
Chúng tôi có thể rằng vai trò này có thể liệt kê và xem các điểm cuối của nút, enpoint, dịch vụ, v.v ...
Bằng cách mô tả ClusterRoleBinding kubeadm:nút-proxier chúng ta có thể khẳng định vai trò đó hệ thống: nút-proxier được sử dụng bởi kube-proxy Tài khoản dịch vụ:
kubectl mô tả liên kết cụm vai trò kubeadm:node-proxier
Tên: kubeadm:node-proxier
Nhãn: <không có>
Chú thích: <không có>
Vai trò:
Loại: ClusterRole
Tên: hệ thống: nút-proxier
Đối tượng:
Loại Tên Không gian tên
---- ---- ---------
ServiceAccount kube-proxy kube-system
Để biết thêm chi tiết, tôi khuyên bạn nên đọc kubeadm chi tiết thực hiện.
Trả lời câu hỏi thứ hai của bạn:
Điểm đằng sau là gì "Vì bản thân kubelet được tải trên mỗi nút và đủ để bắt đầu các dịch vụ cơ sở" ?
Nó chỉ có nghĩa là nút đã thiết lập kết nối với Mặt phẳng điều khiển (như kubelet là thành phần chịu trách nhiệm về điều đó), vì vậy Mặt phẳng điều khiển có thể bắt đầu lập lịch trình kube-proxy pod trên nút bằng cách sử dụng thời gian chạy bộ chứa được xác định trước.
