در قسمت قبل آموزش کوبرنتیز، مراحل نصب kubectl، kubelet و kubeadm بصورت کامل شرح داده شد و روی همه نودهای کلاستر مراحل نصب انجام شد.
برای راه اندازی کلاستر کوبرنتیز تنها نصب نرم افزارها روی نودها کفایت نمی کند. در این مرحله باید master node راه اندازی (init) شود و worker node ها یکی یکی به آن متصل شوند.
به مجموعه کارهایی که در این قسمت انجام خواهیم داد، اصطلاحا بوت استرپ کردن کلاستر کوبرنتیز (Kubernetes cluster bootstrapping) می گویند.
systemctl status containerd systemctl status kubelet
قبل از bootstrap کردن کلاستر کوبرنتیز با اجرای دستورات بالا به ترتیب وضعیت containerd و kubelet را بررسی می کنیم.
containerd باید enabled و active(running) باشد.
kubelet باید enabled باشد ولی active نخواهد بود. kubelet بعد از kubeadm init اجرا خواهد شد.
On most modern Linux systems that use systemd (like Ubuntu, CentOS, Debian, RHEL), there are several possible service states.
When you run:
systemctl status <service-name>
You’ll mainly see two types of states:
These are the most common:
active (running) → Service is running properly
active (exited) → Ran successfully and exited (normal for one-shot services)
inactive (dead) → Not running
failed → Service crashed or failed to start
activating → In the process of starting
deactivating → In the process of stopping
So there are 6 common active states.
Check with:
systemctl is-enabled <service-name>
Possible results:
enabled → Starts at boot
disabled → Does not start at boot
static → Cannot be enabled manually (dependency only)
masked → Completely blocked from starting
indirect → Enabled via another service
generated → Created dynamically
transient → Temporary unit
So around 7 enablement states.
sudo systemctl enable <service-name> #Example (kubelet): sudo systemctl enable kubelet
Enabling does not start it right away.
To start it now:
sudo systemctl start <service-name>
Or both at once:
sudo systemctl enable --now <service-name>
Example:
sudo systemctl enable --now kubelet
سایر مواردی که باید چک شوند وضعیت SELinux و firewalld می باشند. SELinux باید Permissive باشد و firewalld باید inactive باشد.
getenforce systemctl status firewalld
برای راه اندازی و bootstrap کردن کلاستر کوبر از دستور kubeadm init استفاده می کنیم.
kubeadm init --apiserver-advertise-address=192.168.65.43 --pod-network-cidr=10.96.0.0/12 –-kubernetes-version=1.34.4
ممکن است Master Node ما دارای چند کارت شبکه باشد (این امر در بحث کلاستر کوبرنیتز و نودهای مستر مرسوم است)، در این صورت باید یکی از آنها را با وارد کردن IP در پارامتر apiserver-advertise-address مشخص کنیم. با این کار، Kubeapi روی همان IP هاست می شود.
ممکن است نودهای ما در ساب شبکه های مختلف قرار داشته باشند. در پارامتر pod-network-cidr باید رنج IP نودها را مشخص کنیم.
اگر نسخه Kubernetes را مشخص نکنیم، آخرین نسخه نصب می شود.
توجه: در محیط محصول همه imageها روی یک nexuse قرار می گیرند و کوبرنتیز از روی آن، image ها را لود می کند و imageها بصورت دستی نباید کپی شوند.
وقتی کامند kubeadm init اجرا می شود کارها/فازهای زیر انجام می شود:
preflight Run pre-flight checks certs Certificate generation /ca Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components /apiserver Generate the certificate for serving the Kubernetes API /apiserver-kubelet-client Generate the certificate for the API server to connect to kubelet /front-proxy-ca Generate the self-signed CA to provision identities for front proxy /front-proxy-client Generate the certificate for the front proxy client /etcd-ca Generate the self-signed CA to provision identities for etcd /etcd-server Generate the certificate for serving etcd /etcd-peer Generate the certificate for etcd nodes to communicate with each other /etcd-healthcheck-client Generate the certificate for liveness probes to healthcheck etcd /apiserver-etcd-client Generate the certificate the apiserver uses to access etcd /sa Generate a private key for signing service account tokens along with its public key kubeconfig Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file /admin Generate a kubeconfig file for the admin to use and for kubeadm itself /super-admin Generate a kubeconfig file for the super-admin /kubelet Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes /controller-manager Generate a kubeconfig file for the controller manager to use /scheduler Generate a kubeconfig file for the scheduler to use etcd Generate static Pod manifest file for local etcd /local Generate the static Pod manifest file for a local, single-node local etcd instance control-plane Generate all static Pod manifest files necessary to establish the control plane /apiserver Generates the kube-apiserver static Pod manifest /controller-manager Generates the kube-controller-manager static Pod manifest /scheduler Generates the kube-scheduler static Pod manifest kubelet-start Write kubelet settings and (re)start the kubelet wait-control-plane Wait for the control plane to start upload-config Upload the kubeadm and kubelet configuration to a ConfigMap /kubeadm Upload the kubeadm ClusterConfiguration to a ConfigMap /kubelet Upload the kubelet component config to a ConfigMap upload-certs Upload certificates to kubeadm-certs mark-control-plane Mark a node as a control-plane bootstrap-token Generates bootstrap tokens used to join a node to a cluster kubelet-finalize Updates settings relevant to the kubelet after TLS bootstrap /enable-client-cert-rotation Enable kubelet client certificate rotation addon Install required addons for passing conformance tests /coredns Install the CoreDNS addon to a Kubernetes cluster /kube-proxy Install the kube-proxy addon to a Kubernetes cluster show-join-command Show the join command for control-plane and worker node
Preflight: همه پیش نیازها چک می شود.
Certs: کار Certificate generation انجام می شود. در این مرحله کوبرنتیز برای خودش یک CA بالا می آورد و هرچقدر که certificate نیاز داشته باشد از CA دریافت می کند. در کلاستر کوبرنتیز همه ارتباطات بین اجزای کلاستر از جمله ارتباط بین kubectl و kubeapi و سایر ارتباطات داخل کلاستر بر پایه certificate انجام می شود یعنی علاوه بر اینکه ارتباط بین اجزا encrypt می شود، Authentication هم با certificate انجام می شود.
kubeconfig: فایلهای کانفیگ ایجاد می شود.به عنوان مثال تا ایجای کار kubelet در حالت اجرا نبود و قابلیت اجرا شدن نداشت چون فایل کانفیگی برای آن وجود نداشت. در این مرحله kubelet کانفیگ می شود و آماده اجراست.
etcd: در این مرحله static Pod مربوط به etcd کانفیگ می شود.
static pod ها، همه پادهایی هستند که برای بوت استرپ کردن و اجرای کلاستر کوبرنتیز نیاز می باشند مانند kubeapi, kubelet, etcd و ... . همانطور که قبلا هم گفته شد، کلاستر کوبرنتیز خود یک میکروسرویس می باشد که همه قسمت های آن در قالب Pod اجرا می شود.
control-plane: در این مرحله static Pod های kube-apiserver, kube-controller-manager و kube-scheduler کانفیگ می شوند.
kubelet-start: تنظیمات kubelet اعمال شده و start/restart می شود.
wait-control-plane: منتظر می ماند تا control plane اجرا شده و stable شود.
upload-config: در این مرحله کانفیگ kubeadm و kubelet روی ConfigMap بارگذاری می شود.
در کلاستر کوبرنتیز، Pod ها readonly هستند و در طول اجرا ویرایش نمی شوند. بعنوان مثال اگر یک پاد از connection string برای اتصال به پایگاه داده استفاده می کند ما نمی توانیم پاد را ویرایش کنیم و connection string آن را تغییر دهیم و به پایگاه داده جدید متصل کنیم. برای این منظور همه کانفیگ های مورد نیاز Pod ها در فایل ConfigMap نوشته می شوند. و در صورت نیاز، این فایل ConfigMap می باشد که تغییر می کند.
upload-certs: همه certificate های kubeadm بارگذاری می شوند.
mark-control-plane: نود فعلی بعنوان نود مستر (Control-Plane) تگ گذاری می شود.
bootstrap-token: توکن کلاستر کوبرنتیز ایجاد می شود. این توکن برای اتصال سایر نودها به کلاستر کوبرنتیز استفاده می شود.
kubelet-finalize: در این مرحله kubelet نهایی می شود.
addon: در این مرحله addon های دیگر مانند coredns و kube-proxy نصب می شوند.
show-join-command: در مرحله آخر، join-command نمایش داده می شود. cluster token هم داخل این کامند وجود دارد. سایر نودها برای اتصال به کلاستر، تنها کافی است که join-command را اجرا کنند.
#How to export/import images into containerd -------------------------------------- crictl images ls ctr -n k8s.io images import k8s-v1.35-all.tar ctr -n k8s.io images export scheduler.tar registry.k8s.io/kube-scheduler:v1.35.0
بعد از اجرای موفق دستور kubeadm init پوشه etc/kubernetes ساخته می شود. محتویات این پوشه را در زیر مشاهده می کنید:
-rw-------. 1 root root 5637 Feb 25 15:26 admin.conf -rw-------. 1 root root 5665 Feb 25 15:26 controller-manager.conf -rw-r--r--. 1 root root 91 Feb 19 04:11 kubelet-systemd.conf -rw-------. 1 root root 1965 Feb 25 15:28 kubelet.conf drwxr-xr-x. 2 root root 113 Feb 25 15:26 manifests drwxr-xr-x. 3 root root 4096 Feb 25 15:26 pki -rw-------. 1 root root 5609 Feb 25 15:26 scheduler.conf -rw-------. 1 root root 5661 Feb 25 15:26 super-admin.conf
در فایلهای با پسوند conf، همه کانفیگ های مورد نیاز اجزای کلاستر کوبرنتیز از جمله کانفیگ scheduler و kublet و نحوه اتصال آنها به kube api نوشته شده است. توجه داشته باشید همانطور که گفته شد همه ارتباطات کلاستر از طریق kube api صورت می گیرد و ارتباطات با استفاده از certificate هایی که CA تولید می کند، رمز میشوند.
حین اجرای دستور kubeadm init فرآیند اجرا بصورت کامل در ترمینال نمایش داده می شود. در صورت اجرای موفقیت آمیز دستور kubeadm init بخش پایانی زیر در ترمینال نمایش داده می شود. این بخش حاوی پیام های مهمی است که با هم آن را بررسی می کنیم.
Your Kubernetes control-plane has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config Alternatively, if you are the root user, you can run: export KUBECONFIG=/etc/kubernetes/admin.conf You should now deploy a pod network to the cluster. Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: https://kubernetes.io/docs/concepts/cluster-administration/addons/ Then you can join any number of worker nodes by running the following on each as root: kubeadm join 192.168.65.13:6443 --token 7m53p1.68r7728rdnu9fidg \ --discovery-token-ca-cert-hash sha256:2d341a0bcbe14f4f366b297ac8bd3f12be21c17883ef5d179f841c15009a57b7
خط 1: Kubernetes control-plane یا همان Master Node با موفقیت راه اندازی شد.
خط 3 تا 11: همه اطلاعات مربوط به کاربر ادمین کوبرنتیز در فایل admin.conf قرار گرفته است. این فایل یک فایل مهم است و هر شخصی که این فایل را داشته باشد می تواند بعنوان ادمین کوبرتیز باشد.
خط 5 تا 7 می گوید که اگر شما بعنوان ادمین کوبرنتیز هستید، یک پوشه مخفی با نام kube برای خودتان بسازید و فایل admin.conf را به آن کپی کنید و بعدا از این طریق آن را مورد استفاده قرار دهید.
در روش جایگزین، خط 11 می گوید که می توانید یک variable با نام KUBECONFIG تعریف کنید و مقدار آن را برابر با مسیر فایل admin.conf قرار دهید. هر کسی که این variable را داشته باشد می تواند به فایل admin.conf دسترسی داشته و بعنوان ادمین کوبرنتیز باشد.
با انتخاب و اجرای یکی از دو روش ذکر شده، حالا ما ادمین کلاستر هستیم و می توانیم با اجرای دستورات kubectl، کلاستر کوبرنتیز را مدیریت نماییم.
خط 13 تا 15: در بخش بعد توضیح داده خواهد شد.
خط 17 تا 20: حالا که کلاستر ما راه اندازی شد با اجرای دستور موجود در خط 19و20 روی یک نود worker می توانیم آن نود را به کلاستر متصل کنیم. به هر تعدادی که بخواهیم می توانیم نود worker به کلاستر کوبرنتیز خود اضافه کنیم.
kubeadm join 192.168.65.13:6443 --token 7m53p1.68r7728rdnu9fidg \ --discovery-token-ca-cert-hash sha256:2d341a0bcbe14f4f366b297ac8bd3f12be21c17883ef5d179f841c15009a57b7
توجه داشته باشید که اتصال اولیه worker nodeها به کلاستر توسط توکن انجام می شود. اما بعد از اتصال اولیه، certificate بین آنها و master node ردوبدل می شود و از این پس ارتباط بین آنها با certificate انجام می گیرد.
برای مشاهده لیست توکن ها می توانید از دستور زیر استفاده کنید:
kubeadm token list
این توکن ها مدت انقضایی در حدود 24 ساعت دارند و بعد از منقضی شدن نمی توان از آنها استفاده کرد.
برای تولید توکن جدید می توانید از دستور زیر استفاده کنید:
kubeadm token create --print-join-command
پارامتر print-join-command باعث می شود علاوه بر تولید توکن جدید، join-command مربوط به آن هم نمایش داده شود.
CNI: Container Network Interface
دستور زیر لیست همه Podها را نشان می دهد:
kubectl get po -A
بعد از اجرای kubeadm init و راه اندازی کلاستر کوبرنتیز، لیست پادها بصورت زیر می باشند:
[root@MASTER-01 kubernetes]# kubectl get po -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-7d764666f9-pwjgn 0/1 Pending 0 136m kube-system coredns-7d764666f9-qrqvv 0/1 Pending 0 135m kube-system etcd-master-01 1/1 Running 0 137m kube-system kube-apiserver-master-01 1/1 Running 0 137m kube-system kube-controller-manager-master-01 1/1 Running 0 137m kube-system kube-proxy-xp7vx 1/1 Running 0 136m kube-system kube-scheduler-master-01 1/1 Running 0 137m
etcd, kube-apiserver, kube-controller-manager, kube-proxy و kube-scheduler پادهای سیستمی هستند که روی نود مستر (Control-plane) اجرا می شوند و همانگونه که در ستون READY مشاهده می شود، همه آنها در حال اجرا می باشند. اما پاد coredns که دو نسخه از آن هم موجود می باشد می تواند روی master node یا روی worker node اجرا شود.
مانند container runtime، در زمینه Networking هم خود kubernetes، ابزاری را توسعه نداده است. در عوض یک اینترفیس (cni) ایجاد کرده است و هر ابزاری که این اینترفیس را پیاده سازی کند می تواند بعنوان مدیریت کننده شبکه کلاستر استفاده شود. لیستی از این ابزارها در سایت kubernetes در بخش Networking and Network Policy آورده شده است.
یکی از ابزارهای معرفی شده در این زمینه Calico می باشد. (برای محیط production بهتر است از Cilium بجای Calico استفاده شود.)
راهنمای کامل نصب کالیکو در سایت آن به آدرس زیر وجود دارد:
https://docs.tigera.io/calico/latest/getting-started/kubernetes/self-managed-onprem/onpremises
Download the Calico networking manifest for the Kubernetes API datastore.
curl https://raw.githubusercontent.com/projectcalico/calico/v3.31.4/manifests/calico.yaml -O
If you are using pod CIDR 192.168.0.0/16, skip to the next step. If you are using a different pod CIDR with kubeadm, no changes are required — Calico will automatically detect the CIDR based on the running configuration. For other platforms, make sure you uncomment the CALICO_IPV4POOL_CIDR variable in the manifest and set it to the same value as your chosen pod CIDR.
Customize the manifest as necessary.
Apply the manifest using the following command.
kubectl apply -f calico.yaml
طبق مستندات نصب کالیکو، ما فایل calico.yaml را دانلود می کنیم و مقدار CALICO_IPV4POOL_CIDR را برابر با مقداری که موقع kubeadm init وارد کرده بودیم قرار می دهیم.
# - name: CALICO_IPV4POOL_CIDR # value: "192.168.0.0/16"
تبدیل می شود به:
- name: CALICO_IPV4POOL_CIDR value: "10.96.0.0/12"
در گام بعدی می توانیم تغییرات دلخواه خود را در فایل calico.yaml بدهیم. به عنوان مثال می توانیم آدرس همه imageها را از مقدار اصلی به آدرس repository خود تغییر دهیم.
و در آخر با اجرای دستور زیر این فایل manifest را در کلاستر اعمال می کنیم:
kubectl apply -f calico.yaml
وقتی این دستور اجرا می شود، kubectl مقدار فایل manifest را تبدیل به json کرده و آن را با فراخوانی REST API به kubeapi می فرستد. kubeapi بعد از دریافت مقدار json آن را در دیتابیس ثبت می کند. سپس اگر نیاز هست پادی بالا بیاید، kubeapi به scheduler دستور بالا آمدن پاد را می دهد. scheduler مجددا از طریق kubeapi دستور میدهد به kubelet.
kubelet از طریق containerd اقدام به ساخت image می کند، سپس آن را تبدیل به Pod کرده و تحویل می دهد.
حالا مجددا با اجرای دستور kubectl get po -A لیست پادهای موجود در کلاستر را مشاهده می کنیم:
[root@MASTER-01 sources]# kubectl get po -A NAMESPACE NAME READY STATUS kube-system calico-kube-controllers-9dff488b-6kbvv 1/1 Running kube-system calico-node-dff24 1/1 Running kube-system calico-node-pbjmj 1/1 Running kube-system coredns-7d764666f9-pwjgn 1/1 Running kube-system coredns-7d764666f9-qrqvv 1/1 Running kube-system etcd-master-01 1/1 Running kube-system kube-apiserver-master-01 1/1 Running kube-system kube-controller-manager-master-01 1/1 Running kube-system kube-proxy-v6zgz 1/1 Running kube-system kube-proxy-xp7vx 1/1 Running kube-system kube-scheduler-master-01 1/1 Running
برای مشاهده وضعیت یک پاد می توانیم از دستور زیر استفاده کنیم:
kubectl describe po -n kube-system calico-node-dff24
پارامتر اول بعد از n- نام namespace و پارامتر بعدی نام پاد می باشد.
برای مشاهده وضعیت همه نودهای کلاستر از دستور زیر استفاده می کنیم:
kubectl get no
برای مشاهده اینکه هر پادی روی چه نودی اجرا شده، از دستور زیر استفاده می کنیم:
kubectl get po -A -o wide
https://kubernetes.io/docs/concepts/cluster-administration/addons/
https://www.tigera.io/tigera-products/calico/
https://docs.tigera.io/calico/latest/getting-started/kubernetes/self-managed-onprem/onpremises
