הגדרת Service
מסוג ClusterIP
בתוך Kubernetes
selector שבוחר פודים לפי תווית. בדוגמה שני פודים זהים, server1 ו-server2, נושאים את התווית payment-api-pod. בכל פוד initContainer כותב את שם הפוד ל-index.html בתיקייה משותפת, ושרת nginx מציג אותו.kubectl apply -f . יוצר את הפודים והשירות. kubectl describe service מראה type ברירת מחדל ClusterIP, את ה-selector ואת ה-endpoints, כלומר ה-IP הפנימיים של שני הפודים בפורט 80. ה-service נרשם גם ב-DNS של ה-cluster.test-server ונכנסים אליו אינטראקטיבית. לפוד הזה אין את התווית, אז ה-service לא ישלח אליו תקשורת.curl לשם ה-service בפורט 80 החזיר server1. אחרי kubectl delete pod של הפוד הראשון אותה פנייה הגיעה לפוד השני, והלקוח לא הרגיש בכלום.kubectl apply -f . מיישם את כל הקבצים בתיקייה, ואם אין שינוי כותב unchanged. הרצה חוזרת גם יוצרת מחדש אובייקט שחסר.kubectl get pods, kubectl get service, kubectl describe service <name>.kubectl run test-server ואז כניסה אינטראקטיבית עם bin/bash.פרקי ההרצאה: הגדרת Service מסוג ClusterIP בתוך Kubernetes
תמלול ההרצאה: הגדרת Service מסוג ClusterIP בתוך Kubernetes
הטקסט המלא של הדקות הראשונות בהרצאה «הגדרת Service מסוג ClusterIP בתוך Kubernetes» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם. היום אנחנו נגדיר load balancer ב-cluster של Kubernetes. בעולם של Kubernetes ה-load balancer נקרא service ויש לו שם ו-IP קבועים, וזאת לעומת הפודים שכל הזמן נופלים, קמים, ה-IP שלהם משתנים.
כמובן שבתוך הפוד, בתוך הקפסולה הזאת, בפנים רץ הקונטיינר עם השרת. אז השרתים האלו נופלים, קמים, ה-IP שלהם משתנים. כדי לא לשגע את היוזר המציאו ב-Kubernetes את המושג הזה שנקרא service.
הלקוחות מתחברים לשירות הזה בשם ו-IP קבועים ומאחורי הקלעים ה-kube-proxy, התוכנה הקטנה הזאת שרצה בתוך ה-worker nodes, ממפה את השירות לפוד מסוים. היא זאת שעושה את ה-routing ומעבירה את הפאקטים שמיועדים ל-service לפוד הנכון.
זה התפקיד של kube-proxy. בעולם של Kubernetes יש כמה סוגים של clusterים. בואו נתחיל מ-cluster IP, שזה cluster שלא חשוף כלפי חוץ.
הוא נועד לתקשורת בתוך ה-cluster, שנניח frontend יבקש משהו מה-backend, הכול בתוך אותו cluster. פשוט ה-frontend יפנה ל-backend דרך שם של service, וה-service הזה ממפה את הפאקטים ושולח את הפאקטים לפודים הנכונים.
למעשה ה-service הזה, יש לו כתובת IP אך ורק ברשת הפנימית של הפודים. אין לו IP חיצוני ברמת ה-node הפיזי, השרת הפיזי. בואו נקים cluster כזה.
אני אעשה פה שני פודים ו-service. הפוד הראשון, נקרא לו payment pod server אחד. הפוד השני יהיה זהה, רק השם שלו יהיה payment pod server שתיים.
חוץ מזה הם יהיו זהים לחלוטין ואני מדביק להם את אותו ה-label, payment API pod. התווית הזאת היא זאת שתעזור לי בתוך ה-service לזהות לאיזה פודים אנחנו שולחים את התקשורת.
אתם רואים פה בתוך ה-YAML של ה-service שלי יש selector שבוחר את הפודים לפי התווית הזאת. אז שוב, ה-selector הולך לפי התווית, והתווית הזאת מודבקת על הפודים שלי, וככה ה-service יודע לאיזה פוד בדיוק להעביר את התקשורת.
שימו לב כמה שהוא פשוט. אובייקט מסוג service, זה השם שלו. זה הולך להיות גם השם שלו בתוך DNS. לפי השם הזה פונים אליו הלקוחות. לדוגמה frontend ישלח בקשה לשם הזה בפורט שמונים לקבל איזשהו שירות וזה יעבור לפורט שמונים בתוך הפוד שיש לו את התווית הזאת.
אז עוד הפעם, זה אובייקט מסוג service. זה השם שלו שיופיע גם ב-DNS. השירות הזה ישלח את הפאקטים לפודים שעונים ל-selector הזה. זאת התווית שאני חייב להדביק על הפודים שלי.
הנה פה אני מדביק אותה ברמת ה-metadata של