Khi bạn bắt đầu tạo ngày càng nhiều dịch vụ Kubernetes, các tác vụ ban đầu đơn giản sẽ bắt đầu trở nên phức tạp hơn. Ví dụ: nhóm phát triển không thể tạo dịch vụ hoặc triển khai dưới cùng một tên. Nếu bạn có hàng nghìn nhóm, việc liệt kê chúng đơn giản sẽ tốn rất nhiều thời gian chứ đừng nói đến việc quản lý chúng đúng cách. Và đây chỉ là phần nổi của tảng băng chìm.
Hãy xem cách namespace giúp quản lý tài nguyên Kubernetes dễ dàng hơn. Vậy không gian tên là gì? Không gian tên có thể được coi là một cụm ảo trong cụm Kubernetes của bạn. Bạn có thể có nhiều không gian tên tách biệt với nhau trong một cụm Kubernetes. Họ thực sự có thể giúp bạn và nhóm của bạn về tổ chức, bảo mật và thậm chí cả hiệu suất hệ thống.
Trên hầu hết các bản phân phối Kubernetes, cụm xuất hiện ngay lập tức với một không gian tên được gọi là "mặc định". Thực tế có ba namespace mà Kubernetes xử lý: default, kube-system và kube-public. Hiện tại, Kube-public không được sử dụng thường xuyên.
Để nguyên không gian tên kube là một ý tưởng hay, đặc biệt là trên hệ thống được quản lý như Google Kubernetes Engine. Nó sử dụng không gian tên "mặc định" làm nơi tạo các dịch vụ và ứng dụng của bạn. Hoàn toàn không có gì đặc biệt về nó, ngoại trừ việc Kubernetes được cấu hình sẵn để sử dụng nó và bạn không thể xóa nó. Điều này rất tốt cho những hệ thống mới bắt đầu và có hiệu suất thấp, nhưng tôi không khuyên bạn nên sử dụng không gian tên mặc định trên các hệ thống sản xuất lớn. Trong trường hợp thứ hai, một nhóm phát triển có thể dễ dàng viết lại mã của người khác và phá vỡ công việc của nhóm khác mà không hề nhận ra.
Do đó, bạn nên tạo nhiều không gian tên và sử dụng chúng để phân chia dịch vụ của mình thành các đơn vị có thể quản lý được. Một không gian tên có thể được tạo bằng một lệnh duy nhất. Nếu bạn muốn tạo một namespace có tên test thì hãy sử dụng lệnh $ kubectl create namespace test hoặc đơn giản là tạo một file YAML và sử dụng nó như bất kỳ tài nguyên Kubernetes nào khác.
Bạn có thể xem tất cả các không gian tên bằng lệnh $ kubectl get namespace.
Sau khi hoàn tất, bạn sẽ thấy ba không gian tên tích hợp và một không gian tên mới có tên là "test". Hãy xem một tệp YAML đơn giản để tạo một nhóm. Bạn sẽ nhận thấy rằng không có đề cập đến không gian tên.
Nếu bạn sử dụng kubectl để chạy tệp này, nó sẽ tạo mô-đun mypod trong không gian tên hiện đang hoạt động. Đây sẽ là không gian tên mặc định cho đến khi bạn thay đổi nó. Có 2 cách để cho Kubernetes biết bạn muốn tạo tài nguyên trong không gian tên nào. Cách đầu tiên là sử dụng cờ không gian tên khi tạo tài nguyên.
Cách thứ hai là chỉ định vùng tên trong khai báo YAML.
Nếu bạn chỉ định một vùng tên trong YAML, tài nguyên sẽ luôn được tạo trong vùng tên đó. Nếu bạn cố gắng sử dụng một không gian tên khác trong khi sử dụng cờ không gian tên, lệnh sẽ thất bại. Bây giờ nếu bạn cố gắng tìm nhóm của mình, bạn sẽ không thể làm được điều đó.
Điều này xảy ra vì tất cả các lệnh được thực thi bên ngoài vùng tên hiện đang hoạt động. Để tìm nhóm của mình, bạn cần sử dụng cờ không gian tên, nhưng điều này nhanh chóng trở nên nhàm chán, đặc biệt nếu bạn là nhà phát triển trong một nhóm sử dụng không gian tên riêng và không muốn sử dụng cờ đó cho mỗi lệnh. Hãy xem chúng ta có thể khắc phục điều này như thế nào.
Ngay lập tức, không gian tên hoạt động của bạn được gọi là mặc định. Nếu bạn không chỉ định một namespace trong tài nguyên YAML thì tất cả các lệnh Kubernetes sẽ sử dụng namespace mặc định đang hoạt động này. Thật không may, việc cố gắng quản lý không gian tên đang hoạt động bằng kubectl có thể không thành công. Tuy nhiên, có một công cụ rất tốt tên là Kubens giúp quá trình này trở nên dễ dàng hơn nhiều. Khi chạy lệnh kubens, bạn sẽ thấy tất cả các vùng tên có vùng tên đang hoạt động được tô sáng.
Để chuyển namespace đang hoạt động sang namespace test, bạn chỉ cần chạy lệnh test $kubens. Sau đó, nếu bạn chạy lại lệnh $kubens, bạn sẽ thấy một không gian tên hoạt động mới hiện đã được phân bổ - test.
Điều này có nghĩa là bạn không cần cờ vùng tên để xem nhóm trong vùng tên thử nghiệm.
Bằng cách này, các không gian tên được ẩn với nhau nhưng không bị cô lập với nhau. Một dịch vụ trong một không gian tên có thể giao tiếp khá dễ dàng với một dịch vụ trong một không gian tên khác, điều này thường rất hữu ích. Khả năng giao tiếp trên các không gian tên khác nhau có nghĩa là dịch vụ của nhà phát triển của bạn có thể giao tiếp với dịch vụ của nhóm nhà phát triển khác trong một không gian tên khác.
Thông thường, khi ứng dụng của bạn muốn truy cập dịch vụ Kubernetes, bạn sử dụng dịch vụ khám phá DNS tích hợp và chỉ cần đặt tên cho ứng dụng của mình. Tuy nhiên, bằng cách đó, bạn có thể tạo một dịch vụ có cùng tên trong nhiều không gian tên, điều này không được chấp nhận.
May mắn thay, điều này có thể dễ dàng giải quyết bằng cách sử dụng dạng mở rộng của địa chỉ DNS. Các dịch vụ trong Kubernetes hiển thị điểm cuối của chúng bằng mẫu DNS chung. Nó trông giống như thế này:
Thông thường, bạn chỉ cần tên dịch vụ và DNS sẽ tự động xác định địa chỉ đầy đủ.
Tuy nhiên, nếu bạn cần truy cập một dịch vụ trong một không gian tên khác, bạn chỉ cần sử dụng tên dịch vụ cộng với tên không gian tên:
Ví dụ: nếu bạn muốn kết nối với cơ sở dữ liệu dịch vụ trong không gian tên thử nghiệm, bạn có thể sử dụng cơ sở dữ liệu địa chỉ cơ sở dữ liệu.test
Nếu bạn muốn kết nối với cơ sở dữ liệu dịch vụ trong không gian tên prod, bạn sử dụng cơ sở dữ liệu.prod.
Nếu bạn thực sự muốn cách ly và hạn chế quyền truy cập không gian tên, Kubernetes cho phép bạn thực hiện việc này bằng Chính sách mạng Kubernetes. Tôi sẽ nói về điều này trong tập tiếp theo.
Tôi thường được hỏi câu hỏi, tôi nên tạo bao nhiêu không gian tên và cho mục đích gì? Phần dữ liệu được quản lý là gì?
Nếu bạn tạo quá nhiều không gian tên, chúng sẽ cản trở bạn. Nếu có quá ít trong số chúng, bạn sẽ mất tất cả lợi ích của giải pháp đó. Tôi nghĩ có bốn giai đoạn chính mà mọi công ty đều phải trải qua khi tạo cơ cấu tổ chức của mình. Tùy thuộc vào giai đoạn phát triển của dự án hoặc công ty của bạn, bạn có thể muốn áp dụng chiến lược không gian tên phù hợp.
Hãy tưởng tượng rằng bạn là thành viên của một nhóm nhỏ đang phát triển 5-10 dịch vụ vi mô và bạn có thể dễ dàng tập hợp tất cả các nhà phát triển vào một phòng. Trong tình huống này, việc chạy tất cả các dịch vụ sản phẩm trong không gian tên mặc định là điều hợp lý. Tất nhiên, để linh hoạt hơn, bạn có thể sử dụng 2 namespace - riêng cho prod và dev. Và rất có thể, bạn kiểm tra quá trình phát triển của mình trên máy tính cục bộ bằng cách sử dụng thứ gì đó như Minikube.
Giả sử mọi thứ thay đổi và giờ đây bạn có một nhóm đang phát triển nhanh chóng, làm việc trên hơn 10 dịch vụ vi mô cùng một lúc. Sẽ có lúc cần phải sử dụng nhiều cụm hoặc không gian tên riêng biệt cho sản phẩm và nhà phát triển. Bạn có thể chia nhóm thành nhiều nhóm nhỏ để mỗi nhóm có microservice riêng và mỗi nhóm này có thể chọn không gian tên riêng để tạo điều kiện thuận lợi cho quá trình quản lý phát triển và phát hành phần mềm.
Khi mỗi thành viên trong nhóm hiểu rõ hơn về cách thức hoạt động của toàn bộ hệ thống, việc phối hợp mọi thay đổi với tất cả các nhà phát triển khác sẽ ngày càng trở nên khó khăn hơn. Việc cố gắng tạo toàn bộ ngăn xếp trên máy cục bộ của bạn ngày càng trở nên khó khăn hơn.
Ở các công ty lớn, các nhà phát triển thường không biết chính xác ai đang làm việc gì. Các nhóm giao tiếp bằng hợp đồng dịch vụ hoặc sử dụng công nghệ lưới dịch vụ, bổ sung thêm lớp trừu tượng qua mạng, chẳng hạn như công cụ cấu hình Istio. Đơn giản là không thể cố gắng chạy toàn bộ ngăn xếp cục bộ. Tôi thực sự khuyên bạn nên sử dụng nền tảng phân phối liên tục (CD) như Spinnaker trên Kubernetes. Vì vậy, sẽ đến lúc mọi lệnh chắc chắn cần có không gian tên riêng. Mỗi nhóm thậm chí có thể chọn nhiều không gian tên cho môi trường dev và môi trường prod.
Cuối cùng, có những công ty khởi nghiệp lớn trong đó một nhóm nhà phát triển thậm chí không biết về sự tồn tại của các nhóm khác. Một công ty như vậy thường có thể thuê các nhà phát triển bên thứ ba tương tác với nó thông qua các API được ghi chép rõ ràng. Mỗi nhóm như vậy chứa một số nhóm và một số dịch vụ vi mô. Trong trường hợp này, bạn cần sử dụng tất cả các công cụ mà tôi đã nói trước đó.
Các lập trình viên không nên triển khai các dịch vụ theo cách thủ công và không có quyền truy cập vào các vùng tên không liên quan đến họ. Ở giai đoạn này, nên có một số cụm để giảm “bán kính bùng nổ” của các ứng dụng được cấu hình kém, nhằm đơn giản hóa quy trình thanh toán và quản lý tài nguyên.
Do đó, việc tổ chức của bạn sử dụng hợp lý các không gian tên cho phép bạn làm cho Kubernetes trở nên dễ quản lý, kiểm soát, an toàn và linh hoạt hơn.
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com