קוברנטיס מאפשר לנו ליצור Virtual Network שפועל בכל הקלסטר שלנו, כל Pod בקלסטר מקבל כתובת IP ייחודית ויכול לתקשר עם כל pod אחר בקלסטר – גם במיקרה שהPod רץ בNode אחר.
לאחר מכן נריץ את הפקודה הבאה כדי לקבל רשימה של הPODS שלנו כולל כתובת הIP שלהם:
kubectl get pods -o wide
בשלב האחרון ננסה להריץ CURL מתוך הbusybox שלנו לכתובת הIP של הפודים האחרים שלנו, כאשר את ה00.00.00.00 אנו נחליף בכתובת הIP של הפוד אליו אתה רוצים לבצע את הCURL. הפקודה kubectl exec busybox בעצם מריצה את הcurl 00.00.00.00 בתוך POD הbusybox שלנו.
kubectl exec busybox -- curl 00.00.00.00
במידה והצלחנו לבצע CURL וקיבלנו את עמוד הדיפולט של Nginx זה בעצם מוכיח, שPODS יכולים לתקשר בניהם, גם אם הם ממוקמים בNodes אחר ושההתקנה של Flannel בוצעה בהצלחה.
לאפשר לקונטיינרים לתקשר בניהם כאשר הם נמצאים בNODES שונים
למנוע כפילות של כתובת IP זהה בין דוקרים שממוקמים בNODES שונים
כשמחליפים קונטיינר – הוא בדרכ יקבל כתובת IP חדשה שזה מצב שאנו לא תמיד מעוניינים בו.
היחידה הקטנה ביותר בקוברנטיס נקראת POD, הPOD יכול להכיל קונטיינר אחד או קבוצה של קונטיינרים. כל הקויינטנרים שנמצאים באותו POD יקבלו את אותה כתובת IP, וכל POD שממוקם בקלסטר יקבל כתובת IP ייחודית באותו IP SPACE.
כל הקונטיינרים יכולים לתקשר עם קונטיינרים אחרים ללא NAT.
כתובת הIP שהקונטיינר מזהה ככתובת IP ששייכת לו היא אותה כתובת IP שהקונטיינרים האחרים רואים כשייכת להם.
הNetwork Overlay אחראי על חלוקת כתובת הIP. הEtcd הוא Key-Value דאטאבייס לאובייקטים של קוברנטיס הKubelet הוא הסרביס של קוברנטיס שרץ על כל הנודים בקלסטר – גם במאסטר וגם בWORKERS.
קוברנטיס כולל רכיבים שונים שעובדים ביחד ומאפשרים את תפקודו של הקוברנטיס קלסטר. כדי לראות את כל הPODS שאחראים על תפקודו של הקוברנטיס שלנו נריץ את הפקודה הבאה:
kubectl get pods -n kube-system
כל POD שמופיע לנו הוא בעצם POD שמריץ בתוכו רכיב שקשור לקוברנטיס עצמו. הרכיבים העיקריים הם:
kube-apiserver זהו הAPI הראשי של קוברנטיס. הוא מבוסס REST. למשל הפקודה שהרצנו מקודם – kubectl get pods מבצעת למעשה פנייה לAPI.
etcd מנהל את נושא המידע – סטורג של הקלסטר. לא מדובר בסטורג' שמאחסן בתוכו את האתר את הקבצים שלנו למשל, מדובר בסטורג שמחזיק את הדאטא שקשור לכמה PODS רצים כרגע, NODES, איזה כתובת IP יש לכל אחד וכו – כל המידע שדרוש לקוברנטיס בשביל לנהל ולהחזיק את הקלסטר שלנו. במידה ויש לנו יותר מMASTER אחד, etcd ידאג שהדאטא הזה יהיה מסונכרן בין כל הMasters שלנו.
kube-controller-manager מאחד בתוכו רכיבים שונים לחבילה אחת. הוא מחזיק בתוכו את כל השירותים והספריות הדרושות לקוברנטיס. אם אנו מתייחסים ל jube-apiserver כפרונט של קוברנטיס, אזי ה kube-controller-manager הוא למעשה הבקאנד של קוברנטיס.
kube-scheduler אחראי על יצירת הPODS, מתי להריץ אותם, מתי לכבות אותם, באיזה Node עצמאי להריץ אותם וכו.
kube-proxy כל NODE זקוק לkube-proxy שלנו, הוא אחראי על התקשורת בין הNODES השונים על ידי הוספת כללי Firewall. כאשר POD בNODE X צריך לדבר עם POD שממוקם בNODE Y חייב להיות ROUTE וRULE שמאפשר את זה.
kubelet הAGENT שמריץ את הקונטיינרים שלנו בכל NODE. הוא בעצם המתווך בין הAPI של קוברנטיס לדוקר. (Docker במקרה שלנו, אגב קוברנטיס תומך לא רק בדוקר). הוא רץ כSERVICE ולא כPOD (כי הוא אחראי למעשה על הרצת הקונטיינר) ולכן הוא לא מופיע לנו ברשימת הPODS. כדי לראות אותו נריץ את הפקודה:
באחד המדריכים, יצרנו קוברנטיס קלסטר עם 3 Nodes, כל Node הוא בעצם שרת/מכונה שמריץ קונטיינרים (Pod).
לכל קוברנטיס קלסטר חייב להיות לפחות Node אחד שהוא יהיה הNode המנהל – הוא מריץ בתוכו את הKubernetes API ואת שאר כלי הניהול של קוברנטיס, שאר הNodes מכונים Workers.
Pods הוא היחידה הבסיסית ביותר של קוברנטיס. כל Pod מורכב מקונטיינר אחד או יותר (בדרכ יש קונטיינר אחד בכל POD אבל ניתן שיהיה יותר מקונטיינר אחד), כתובת IP בתוך הקוברנטיס קלסטר ואיחסון (Storage). כל Pod אחד או יותר יוצרים ביחד Node. קלסטר מורכב מNode אחד או יותר.
כשאנחנו מפעילים Pod, קוברנטיס בעצם מתזמן – Schedules Pod שיריץ אותו. הPod יריץ את כל הקונטיינטרים שם חלק מאותו Pod.
כדי ליצור POD, אנו משתמשים בקובץ YAML שמכיל את הפרטים של אותו POD. לדוגמא, אם נירצה ליצור POD שמריץ קונטיינר Nginx ניצור קובץ בשם ourtamlefilename.yaml לדוגמא עם הפרטים הבאים:
מכונה = Node לשם ההדגמה אנו ניצור kubernetes קלסטר שמורכב מ3 מכונות , 2 מכונות שיהיו הNODES ומכונה אחת שתהיה הNode Master שלנו. לשרת המסטר שלנו נקרא k8master , לשרת NODE הראשון נקרא k8node1 ולשני k8node2 ההפצה שבחרתי לעבוד איתה בהדגמה היא Ubuntu 18 LTS
בMASTER שלנו אנו נתקין: * Docker * Kubeadm * Kubelet * Kubectl * Control Plane
אחרי כמה דקות, נקבל פלט שמכיל את הפקודה אותה אני נצטרך להריץ אחכ בכל Node שלנו על מנת שהוא יוכל להצטרף לקלסטר. חשוב לשמור את הפקודה ואת הטוקן – כי בלעדיו לא תוכלו לצרף Nodes לCluster שלכם. במקרה שלי הפלט שהתקבל הוא
אחרי שהרצנו את הפקודה ב2 השרתים (ייתכן ותתבקשו להוסיף sudo) נריץ בשרת הMaster שלנו (k8master) שוב את הפקודה הבאה:
user@servername:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
servername1.serverdomain.com NotReady master 10m v1.12.7
servername2.serverdomain.com NotReady <none> 40s v1.12.7
servername3.serverdomain.com NotReady <none> 85s v1.12.7
ושימו לב שהפעם המסטר שלנו מזהה את 2 השרתים האחרים, כולם עדיין בסטטוס של NotReady.
השלב החמישי: הגדרות רשת עם Flannel
לקריאה מקדימה על networking בקוברנטיס:
בכל 3 המכונות (Nodes) – כולל מכונת הMaster שלנו נריץ את הפקודות הבאות
echo "net.bridge.bridge-nf-call-iptables=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
kubeadm הוא כלי שמאפשר אוטומציה של חלק גדול של יצירת קלסטר, בתכלס – הופך את העבודה שלנו ביצירת קלסטר להרבה יותר קלה.
מה זה kubelet?
kubelet הוא שירות (Agent) שרץ בכל קוניינר שקיים בכל Node שלנו, כל שרת שיריץ קונטיינר זקוק לשירות kubelet.
מה זה kubectl?
kubectl הוא כלי command line שמאפשר לנו לתקשר עם הקלסטר (Cluster) שלנו ולנהל אותו.
על מנת להתקין את השירותים הנל, נריץ את הפקודות הבאות: (אני בחרתי להתקין את גירסת 1.12.7-00 , בהתאם לצורך שלכם – ייתכן ואתם תירצו להתקין גירסה אחרת. שימו לב, במידה ותיבחרו להתקין גירסה מתקדמת יותר, עקבו אחרי ההוראות הנוספות בלינק הזה, הדבר העיקרי הוא שגירסאות מתקדמות יותר לא יעבדו טוב במידה ומוגדר לכם שטח SWAP במערכת ההפעלה, לכן יש קודם לבטל את הSWAP.)
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat << EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet=1.12.7-00 kubeadm=1.12.7-00 kubectl=1.12.7-00
sudo apt-mark hold kubelet kubeadm kubectl
ולאחר מכן נוודא שההתקנה הצליחה על ידי הפקודה הבאה:
תמיד רציתם ממשק GUI שתוכלו לנהל באמצעות את הדוקרים שלכם ואת Docker Swarm? אז תכירו את Portainer!
בעיקרון כמעט כל מה שאתם יכולים לעשות דרך הDocker Command Line אתם יכולים לעשות באמצעות Portainer והבונוס שPortainer בגירסה הקהילתית שלו הוא חינמי לחלוטין
Portainer למעשה הוא קונטיינר בעצמו, לכן ניצור לו קונטיינר שיוכל לרוץ עליו.
הדבר הראשון שנעשה הוא ליצור Volume לPortainer, נריץ את הפקודה:
בשורה הזאת אנו מגדירים לקונטיינר שלנו את הVolume הראשון שלו שהוא בעצם חיבור הSocket לשרת DOCKER שלנו.
-v /var/run/docker.sock:/var/run/docker.sock \
שימו לב לשורה הזאת
v portainer_data:/data portainer/portainer
שבה בעצם אנו מגדירים לקונטיינר לעשות שימוש בVolume שיצרנו בשבילו. את זה אנחנו עושים בשביל לוודא שהתוכן של הקונטיינר שלנו יהיה persistence. כמו כן, אנו חושפים את פורט 9000 בקונטיינר של Portainer לפורט 8080 במחשב שלנו (או בשרת DOCKER).
נריץ את הפקודה הבאה כדי לראות את הקונטיינרים שלנו
docker container ls
ניכנס לכתובת: http://localhost:8080 (במידה ואנו במחשב הפיתוח שלנו) או לכתובת הIP הציבורית של שרת הDocker שלנו ונקבל את המסך בו אנו צריכים להגדיר שם משתמש וסיסמא לפאנל של Portainer
בדוגמה שלנו אנו משתמשים בשרת לוקאלי, לכן נבחר באפשרות Local ונלחץ על Connect.
והרי לנו מסך הבית של Portainer שכבר מציג לנו את שרת הDocker הלוקלאי שלנו
נלחץ לדוגמה על שרת הדוקר הלוקאלי שלנו ונקבל מידע מהיר
כאן אנו רואים כמה קונטיינרים יש לנו בשרת, IMAGES, רשתות, Volumes ועוד. לחיצה על כל אחת מהאפשרות תוביל למידע ואפשרויות נוספות.
כדי ליצור קונטיינר חדש לדוגמה, נלחץ על Containers
ובמסך הבא נלחץ על Add Container
ומשם נוכל ליצור את הקונטיינר שלנו. ממליץ לכם לחקור את כל האפשרויות המדהימות שPortainer נותן לנו ליצירה וניהול. מדובר בלי נוח ומומלץ בחום!
SNS – הוא שירות שמנהל שליחת הודעות, לדוגמה הודעות SMS, מיילים וכו.
את הטריגרים אנחנו יכולים ליצור באמצעות הAWS Console וגם כמובן באמצעות הAWS Cli, בהתאם למה שנוח לנו ובהתאם למה שנכון למיקרה והם מאפשרים לנו בעצם לקבל התראות על פעולות שקרו בGit Repo שלנו.
על מנת שנוכל ליצור טריגר לSNS כדי לקבל התראות CodeCommit עלינו לעמוד בתנאים הבאים: 1. הריפו שלנו בCodeCommit חייב להיות ממוקם באותו Region של הSNS Topic שלנו. 2. חייב להיות לנו SNS Topic קיים, ואם אין, אז כמובן צריכים ליצור אותו.
לצורך ההדגמה, יצרתי בCodeCommit ריפו בשם "GitRepoWithTriggersDemo"
עכשיו ניצור SNS Topic אליו נחבר את הטריגר שלנו: ניכנס לAWS SNS ונלחץ על הכפתור Create Topic
נבחר שם לנושא שלנו, במיקרה שלי בחרתי את השם המקורי "MyDemoTopic", נגלול את המסך למטה ונלחץ על הכפתור הכתום "Create Topic"
אחרי שיצרנו את הSNS Topic, אנו צריכים לבחור את ה"מנויים" לנושא שלנו, "מנויים" הם אלו שיקבלו למעשה את ההודעות שאנו נפרסם בTopic. בדוגמה שלנו אנו נגדיר מנויים מסוג "דואר אלקטרוני", באותה מידה יכלנו כמובן להגדיר "SMS" אם היינו רוצים שהם יקבלו הודעת SMS. כדי להגדיר אותם נלחץ בתפריט הצדדי על Subscriptions ואז נלחץ על הלחצן "Create Subscription"
במסך הבא נבחר באפשרות Email ובEndPoint נזין את כתובת הדואר האלקטרוני אליה אנו רוצים שתישלח הודעה בכל פעם שנפרסם או ייתפרסם משהו בTopic שלנו.
עכשיו ניכנס בחזרה למסך הRepo שלנו בCodeCommit, נלחץ על Settings, נבחר את הטאב Triggers ונלחץ על Create Trigger
נבחר שם לטריגר החדש שלנו, אני בחרתי "NewBranch", נסמן את סוג האירוע (EVENT) שאנו מעוניינים שהטריגר שלנו יאזין לו, במקרה שלנו "Create Branch Or Tag". בסוג השירות אליו אנו מעוניינים שהטריגר שלנו ייתחבר נבחר "Amazon SNS" – ואז נבחר את הSNS Topic הרלוונטי – במקרה שלנו קראנו לו MyDepoTopic
נלחץ על Test Trigger וניגש לתיבת הדואל שהגדרנו בשלב הקודם (למנוי) ונוודא שקיבלנו הודעת מייל. ואכן קיבלנו הודעה.
נלחץ על לחצן "Create Trigger" כדי לשמור ולהפעיל את הטריגר החדש שיצרנו.
עכשיו, בכל פעם שניצור Branch חדש בריפו שלנו, כל מי שרשום לSNS Topic שמקשור לטריגר שלנו יקבל על כך הודעה.
קלי קלות!
מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!
הטריגרים בCodeCommit הם למעשה הייתרון המשמעותית ביותר לשימוש בCodeCommit לניהול הקוד שלנו לעומת שירותים כגון GitHub, GitLab, BitBucket וכו.
טריגרים מאפשרים לנו לבצע פעולות בצורה אוטומטיות כאשר קרה EVENT מסויים בקוד ריפו שלנו ולמעשה הם מופעלים בתגובה לאירועים שקורים בקוד שלנו. לדוגמה, כאשר מישהו דחף (GIT PUSH) שינויים לקוד, או כאשר נוצר(או נמחק) Branch (או (GIT TAG) חדש ועוד נוכל אנחנו והצוות שלנו או כל מי שנירצה לקבל על כך התראה.
דוגמאות:
* יצירת BRANCH חדש יכולה להפעיל טריגר SNS topic על מנת להודיע לכל האנשים הרלוונטיים בצוות שלנו שנוצר Branch חדש כדי שהחברים שלנו יידעו שכדאי להם לעשות git pull למחשב הפיתוח שלהם.
שירותים לדוגמה שהטריגרים יכולים להפעיל עבורנו:
* פונקציות למבדה (Lambada Functions) – וואו, כאן ניתן לעשות כבר דברים מדהימים! * SNS – AWS Simple Notification Service (שליחת הודעה בדואל, SMS וכו), אחד הייתרונות בחיבור לSNS הוא שזה מאפשר לנו להתחבר למעשה לכל השירותים אליהם SNS מתחבר כמו AWS SQS לדוגמה (Aws Simple Queue Service)