"IP của service ra IP của pod" thì là cơ chế tạo endpoind, sẽ được tạo mỗi khi pod được tạo ra. Ví dụ em tạo một service cho 1 deployment gồm 3 pod, thì tương ứng sẽ có một endpoind cho service đó chứa 3 IP của 3 pod mà service này làm LB cho nó. Trong trường hợp 1 pod die và cần được tạo mới thì IP của Pod mới sẽ được update vào endpoint này.
Về vấn đề DNS thì đúng rồi. Và nó thường được dùng cho các service internal của k8s. Dễ thấy nhất là các stateful opensource như kiểu redis-cluster, postgres hay kafka chẳng hạn, thì nó thường kết nối với nhau qua service name. Cũng tương tự với các service mình phát triển mà cần kết nối tới opensource trên k8s thì cũng sử dụng cách như trên.
Hay quá anh Việt ơi!!! Theo dõi bài của anh mấy tháng nay. Thanks anh much!
PS: Thánh soi nay cho em soi một xíu nhé, hehe. Theo em biết thì kube-proxy có cái tên như thế là vì nhiệm vụ chính của nó là "proxy" cái service, từ IP của service ra IP của pod. Còn CoreDNS thì thì lưu bản ghi DNS cho cả service lẫn pod: Service abc thuộc namespace xyz sẽ có tên miền abc.xyz.svc.cluster.local, còn pod có IP 10.100.2.15 thuộc namespace xyz thì sẽ có tên miền 10-100-2-15.xyz.pod.cluster.local. Đúng không nhỉ?
bạn bit dùng git scm không,không hiểu sao hồi cái cpu cũ của mình upload code lên heroku trực tiếp không bị lỗi auth failed ,nay thay cpu mới thì nó báo lỗi này
Công ty mình cũng cho mấy bạn TTS vào thẳng làm dự án thật, deadline đàng hoàng. Đôi lúc cũng chỉ sợ mấy bạn ấy lại bảo là "TTS gì mà bắt làm như nhân viên chính thức thế !?".
đang đọc cuốn Kubenertes in Action ver 2 song song với series này thì khuyên các bạn nên cài kind: https://kind.sigs.k8s.io để có 1 cụm k8s cluster thông qua docker ngay trên 1 máy nhé :v đơn giản hơn cả minikube.
Mình ghi nhận ý kiến đóng góp của bạn, tuy nhiên mình nghĩ câu chuyện trên không xảy ra ở chỗ mình thì cũng sẽ xảy ra ở chỗ khác, cần 1 người NÓI RA để những người khác cùng rút kinh nghiệm. Cuối mỗi câu chuyện và cuối bài đều là những gợi ý để mọi người cải thiện bản thân nếu ở vào hoàn cảnh giống bài viết. Chính những ứng viên trong bài cũng được mình thẳng thắn góp ý với mong muốn các bạn ấy sẽ có 1 tương lai tốt đẹp hơn. Nếu nhà tuyển dụng nào cũng chỉ nghĩ được việc mình, chăm chăm việc tìm được ứng viên tốt rồi im lặng chẳng feedback gì thì chắc là việc nhiều bạn vẫn còn rơi vào các câu chuyện trên dài dài nữa.
THẢO LUẬN
Cảm ơn bạn đã chia sẻ.
@hoai1234 em để email ở đây để a gửi qua mail nhé
da cho em xin full mã code vs anh o!
mình k download file weight trên Drive qua link https://drive.google.com/uc?id=12ttln8zPOWrFCPLr4hChmxr4rxuHRRoz, mong tác giả góp ý ạ!
bài viết tuyệt vời quá a ơi, hi vọng a sớm có tinh thần để viết tiếp các phần tới
👏
@rockman88v Yesss!! Lót dép hóng bài mới nữa anh ơi! ^^
"IP của service ra IP của pod" thì là cơ chế tạo endpoind, sẽ được tạo mỗi khi pod được tạo ra. Ví dụ em tạo một service cho 1 deployment gồm 3 pod, thì tương ứng sẽ có một endpoind cho service đó chứa 3 IP của 3 pod mà service này làm LB cho nó. Trong trường hợp 1 pod die và cần được tạo mới thì IP của Pod mới sẽ được update vào endpoint này. Về vấn đề DNS thì đúng rồi. Và nó thường được dùng cho các service internal của k8s. Dễ thấy nhất là các stateful opensource như kiểu redis-cluster, postgres hay kafka chẳng hạn, thì nó thường kết nối với nhau qua service name. Cũng tương tự với các service mình phát triển mà cần kết nối tới opensource trên k8s thì cũng sử dụng cách như trên.
Hay
Hay quá anh Việt ơi!!! Theo dõi bài của anh mấy tháng nay. Thanks anh much! PS: Thánh soi nay cho em soi một xíu nhé, hehe. Theo em biết thì kube-proxy có cái tên như thế là vì nhiệm vụ chính của nó là "proxy" cái service, từ IP của service ra IP của pod. Còn CoreDNS thì thì lưu bản ghi DNS cho cả service lẫn pod: Service abc thuộc namespace xyz sẽ có tên miền abc.xyz.svc.cluster.local, còn pod có IP 10.100.2.15 thuộc namespace xyz thì sẽ có tên miền 10-100-2-15.xyz.pod.cluster.local. Đúng không nhỉ?
Anh ơi bài viết toàn P1 thế này chả bh thấy P2
(
Huhu, series hay nên cầu xin van nài a đừng drop phần 2 🤧
👋👋👋
bạn bit dùng git scm không,không hiểu sao hồi cái cpu cũ của mình upload code lên heroku trực tiếp không bị lỗi auth failed ,nay thay cpu mới thì nó báo lỗi này
Intro hay quá anh ơi
quá tuyệt bạn ơi
same here =))) chỉ thấy sợ các bạn ấy ngợp quá rồi nặng quá chứ ko bao h sợ không có gì học =)))
Công ty mình cũng cho mấy bạn TTS vào thẳng làm dự án thật, deadline đàng hoàng. Đôi lúc cũng chỉ sợ mấy bạn ấy lại bảo là "TTS gì mà bắt làm như nhân viên chính thức thế !?".
đang đọc cuốn Kubenertes in Action ver 2 song song với series này thì khuyên các bạn nên cài kind: https://kind.sigs.k8s.io để có 1 cụm k8s cluster thông qua docker ngay trên 1 máy nhé :v đơn giản hơn cả minikube.
Mình ghi nhận ý kiến đóng góp của bạn, tuy nhiên mình nghĩ câu chuyện trên không xảy ra ở chỗ mình thì cũng sẽ xảy ra ở chỗ khác, cần 1 người NÓI RA để những người khác cùng rút kinh nghiệm. Cuối mỗi câu chuyện và cuối bài đều là những gợi ý để mọi người cải thiện bản thân nếu ở vào hoàn cảnh giống bài viết. Chính những ứng viên trong bài cũng được mình thẳng thắn góp ý với mong muốn các bạn ấy sẽ có 1 tương lai tốt đẹp hơn. Nếu nhà tuyển dụng nào cũng chỉ nghĩ được việc mình, chăm chăm việc tìm được ứng viên tốt rồi im lặng chẳng feedback gì thì chắc là việc nhiều bạn vẫn còn rơi vào các câu chuyện trên dài dài nữa.
@trung.pham92 Đúng rồi, series này sẽ basic và chi tiết hơn series trước dành cho người mới