https://virgool.io/feed/@rafiee مشاور زیرساخت. موسس سایت آموزشی DockerMe.ir fa 2026-06-16 06:36:08 https://files.virgool.io/upload/users/4319/avatar/wwlN89.jpeg?height=120&width=120 https://virgool.io/@rafiee https://virgool.io/@rafiee/%D9%86%D8%B5%D8%A8-%DA%A9%D9%84%D8%A7%D8%B3%D8%AA%D8%B1-%D8%A8%D8%A7-rancher-%D9%82%D8%B3%D9%85%D8%AA-%D9%86%D9%88%D8%B2%D8%AF%D9%87%D9%85-k8rir0jl7otr توی این قسمت میریم به سراغ اینکه بررسی کنیم چطوری می‌تونیم یه کلاستر کوبرنتیز رو با استفاده از rancher ستاپ کنیم و بیاریم بالا.RKEخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.RANCHERراه‌اندازی یک کلاستر Kubernetes با RKE:ابزارRancher Kubernetes Engine (RKE) یک توزیع Kubernetes تایید شده از طرف CNCF است که کاملاً درون کانتینرهای Docker اجرا می‌شود. این توزیع روی سرورهای فیزیکی و مجازی کار می‌کند. RKE مشکل پیچیدگی نصب، که یک مشکل رایج در جامعه Kubernetes است، را حل می‌کند. با RKE، نصب و پیاده‌سازی Kubernetes هم ساده‌تر و هم به راحتی قابل اتوماسیون است و کاملاً مستقل از سیستم‌عامل و پلتفرمی است که شما استفاده می‌کنید. به شرطی که بتوانید یک نسخه پشتیبانی‌شده از Docker را اجرا کنید، می‌توانید Kubernetes را با RKE راه‌اندازی و اجرا کنید. این روش خیلی برای جاهایی که می‌خواهیم تعداد زیادی کلاستر کوبرنتیز ایجاد و نگهداری کنیم مناسبه. خیلی می‌تونیم باهاش به راحتی چندین کلاستر رو به صورت توصیفی ایجاد کنیم.RKEپیشنیازهاابزار RKE بر روی تقریباً هر سیستم‌عامل لینوکس با نصب Docker اجرا می‌شود.کاربر SSH که برای دسترسی به نودها استفاده می‌شود باید عضو گروه docker بر روی نود باشد:usermod -aG docker <user_name>در نودهای ورکر، باید swap غیرفعال شود.تنظیمات sysctl که باید اعمال شود:net.bridge.bridge-nf-call-iptables=1نرم‌افزارهای موردنیاز که باید نصب کنیم:ابزار OpenSSH: برای ورود به هر نود از طریق SSH، باید OpenSSH نسخه 7.0 یا بالاتر بر روی هر نود نصب باشد و باید AllowTcpForwarding داخل کانفیگ فعال باشه.ابزار Docker: تو RKE هر نسخه Kubernetes از نسخه‌های مختلف Docker پشتیبانی می‌کند. یادداشت‌های انتشار Kubernetes شامل لیست فعلی نسخه‌های Docker معتبر است. البته خود رنچر بهتون اسکریپت می‌ده که باهاش داکر رو همون نسخه‌ای که لازم دارید رو نصب کنید.# Get a script to install a specific Docker version, such as 27.5.1. curl https://releases.rancher.com/install-docker/27.5.1.sh | sh # Install a specific version of Docker which docker || https://releases.rancher.com/install-docker/27.5.1.shالزامات سخت‌افزاری برای نودها دارای نقش ورکر بیشتر بستگی به workload شما دارد. حداقل برای اجرای اجزای نود Kubernetes نیاز به 1 CPU (هسته) و 1 گیگابایت حافظه دارید. البته این مقدار حداقل است و بعد از نصب حتما به مشکل می‌خورید باهاش و برای تست نصب و کانفیگ‌ها مناسب است.برای CPU و حافظه، توصیه می‌شود که کامپوننت‌های مختلف کلاستر Kubernetes (etcd، controlplane و worker) بر روی نودها مختلف میزبانی شوند تا بتوانند به‌طور جداگانه از یکدیگر مقیاس‌بندی شوند.برای اطلاعات دقیق‌تر از پورت‌هایی که نیاز داریم روی هرکدام از نودها باز باشد، میتونید به اینجا مراجعه کنید همچنین میتونید به روش دو بلاگ پست قبلی سرورهای کلاستر رو توی فایروال همدیگه باز کنید.ابتدا با کامند زیر RKE رو نصب می‌کنیم. معمولا ما یه ماشین داریم که با استفاده از آن کلاسترهای خودمون رو نصب و کانفیگ می‌کنیم. به هر حال باید جایی RKE رو نصب کنید که به سرورهای دیگه‌ی شما دسترسی داشته باشد.wget https://github.com/rancher/rke/releases/download/v1.7.3/rke_linux-amd64 chmod +x rke_linux-amd64 mv rke_linux-amd64 rke sudo mv rke /usr/local/binدر قدم بعدی میتونید با استفاده از اسکریپت‌های زیر لیستی از ایمیج‌های موردنیاز رو بگیرید اونها رو ذخیره و load کنید:# download rancher-images.txt list: wget https://github.com/rancher/rancher/releases/download/v2.10.3-alpha2/rancher-images.txt # download rancher-save-images script: wget https://github.com/rancher/rancher/releases/download/v2.10.3-alpha2/rancher-save-images.sh # download rancher-load-images script: wget https://github.com/rancher/rancher/releases/download/v2.10.3-alpha2/rancher-load-images.shبا استفاده از کامند زیر میتونید لیستی از نسخه‌هایی از کوبرنتیز که RKE پشتیبانی می‌کند و ایمیج‌های اونها رو دریافت کنید:# list all kubernetes version support rke config --list-version --all # Create a list of all images for one version rke config --list-version --system-images > rancher-images.txt # Create a list of all images for all version rke config --list-version --all --system-images > rancher-images.txtایمیج‌ها رو توی سرور خودتون ذخیره کنید، برای این‌کار اسکریپت rancher-save-images.sh را با دسترسی اجرا، ران کنید:chmod +x rancher-save-images.sh ./rancher-save-images.sh --image-list ./rancher-images.txtتو این مرحله نیازه که صبور باشید تا ایمیج‌ها داکر دریافت بشه، تو ایران صبر ایوب هم جزو نیازمندی‌های نصب هست. بعد از انجام این مرحله توی دایرکتوری شما فایل rancher-images.tar.gz ایجاد می‌شود. این فایل حاوی تمام ایمیج‌های مورد نیاز کلاستر کوبرنتیز می‌باشد.اگه میخواید تمام ایمیج‌های ورژن‌های مختلف رو دریافت کنید میتونید از کامند زیر استفاده کنید:# get and save image list rke config --list-version --all --system-images > rancher-images.txt# download all images ./rancher-save-images.sh --image-list ./rancher-images.txtتوی قدم بعدی ایمیج‌هایی که دریافت کردیم رو push می‌کنیم توی رجیستری private که داریم تا بتونیم از روی سرور‌ها اونو دریافت کنیم و ایمیج‌ها رو load کنیم. این کار تو ایران خیلی توصیه می‌شه. چون معمولا ما مشکل گرفتن ایمیج‌ها رو داریم با این کار یه بار می‌گیرم و هر جایی که لازم داشته باشیم ازش استفاده می‌کنیم.بعد از اینکه ایمیج‌ها در سرور قرار گرفت به رجیستری خودتون لاگین کنید:docker login https://registry.mecan.irاین اسکریپت ایمیج‌ها رو براتون تگ می‌زنه و پوش می‌کنه تو رجیستری که بهش دادید. واقعا کار رو با همین دو تا اسکریپت خیلی خیلی راحت کرده. اول دسترسی اجرایی بهش بدید و بعد اجراش کنید:chmod +x rancher-load-images.sh ./rancher-load-images.sh --image-list ./rancher-images.txt --registry registry.mecan.irداکر رو هم روی تمام سرورها نصب داشته باشید، برای این کار میتونید از این داکیومنت استفاده کنید. فقط دقت کنید بهتره که از نسخه‌هایی که گفته استفاده کنید تا مشکلی پیش نیاد و با ساختاری که داره کاملا کامپتیبل باشه.بعد از اینکه داکر رو نصب و کانفیگ کردید با استفاده از کامندهای زیر گروه داکر رو ایجاد کنید و یوزرتون (همونی که باهاش ssh می‌خواهید بزنید) رو بهش اضافه کنید:sudo groupadd docker sudo usermod -aG docker $USERیبار log-out و log-in کنید که عضویت یوزرتون در گروه re-evaluate بشه.ایجاد کانفیگ RKE:برای ایجاد کانفیگ RKE ما دو روش داریم. اول اینکه با دستور rke همانند زیر کانفیگ رو به صورت تعاملی باهاش بسازیم. که توصیه می‌کنم یه بار انجام بدید و بررسی کنید که باهاش آشنا بشید.rke config --name cluster.ymlمسیر دوم اینکه خودمون کانفیگ فایل رو بسازیم که در ادامه نمونه‌ی آن رو مشاهده می‌کنید. از اینجا هم می‌تونید اون رو دانلود کنید. فایلی با نام cluster.yml به شکل زیر ایجاد کنید:cat <<EOF >> cluster.yml nodes: - address: "192.168.200.11" port: 8090 role: - "etcd" - "controlplane" - "worker" user: root hostname_override: "master1" docker_socket: /var/run/docker.sock - address: "192.168.200.12" port: 8090 role: - "etcd" - "controlplane" - "worker" user: root hostname_override: "master2" docker_socket: /var/run/docker.sock - address: "192.168.200.13" port: 8090 role: - "etcd" - "controlplane" - "worker" user: root hostname_override: "master3" docker_socket: /var/run/docker.sock - address: "192.168.200.14" port: 8090 role: - "worker" user: root hostname_override: "worker1" docker_socket: /var/run/docker.sock - address: "192.168.200.15" port: 8090 role: - "worker" user: root hostname_override: "worker2" docker_socket: /var/run/docker.sock - address: "192.168.200.16" port: 8090 role: - "worker" user: root hostname_override: "worker3" docker_socket: /var/run/docker.sock# If set to true, RKE will not fail when unsupported Docker versionignore_docker_version: true# The Kubernetes version used. The default versions of Kubernetes are tied to specific versions of the system images.kubernetes_version: "v1.31.5-rancher1-1"# Set the name of the Kubernetes clustercluster_name: "MeCan"# List of registry credentialsprivate_registries: - url: registry.mecan.ir user: MeCan password: XXXXXXXXXXX is_default: trueservices: etcd: snapshot: true backup_config: interval_hours: 4 retention: 10 kube-api: audit_log: enabled: true configuration: max_age: 6 max_backup: 6 max_size: 110 path: /var/log/kube-audit/audit-log.json format: json policy: apiVersion: audit.k8s.io/v1 # This is required. kind: Policy omitStages: - "RequestReceived" rules: - level: RequestResponse resources: - group: "" resources: ["pods"] service_cluster_ip_range: 10.43.0.0/16 service_node_port_range: 30000-32767 always_pull_images: true kube-controller: cluster_cidr: 10.42.0.0/16 kubelet: cluster_domain: cluster.local extra_args: max-pods: 250 feature-gates: RotateKubeletServerCertificate=truenetwork: plugin: calicoauthentication: strategy: x509 sans: - "192.168.200.10" - "192.168.200.11" - "192.168.200.12" - "192.168.200.13" - "master.kube.mecan.ir" - "vip.kube.mecan.ir" - "master1.kube.mecan.ir" - "master2.kube.mecan.ir" - "master3.kube.mecan.ir" - "master" - "master1" - "master2" - "master3"authorization: mode: rbac# Specify monitoring provider (metrics-server)monitoring: provider: metrics-server # Available as of v1.1.0 update_strategy: strategy: RollingUpdate rollingUpdate: maxUnavailable: 8 EOFنهایتا با استفاده از کامند RKE کلاستر رو بالا میاریم. فقط حتما قبلش از دسترسی ssh به سرورهایی که معرفی کردید اطمینان کسب کنید.rke up --config ./cluster.ymlذخیره فایل‌های مهم:فایل‌های ذکر شده در زیر برای نگهداری، رفع اشکال و ارتقا کلاستر شما ضروری هستند.یک نسخه از فایل‌های زیر را در مکان امنی ذخیره کنید:فایل cluster.yml: فایل پیکربندی کلاستر RKE.فایل kube_config_rancher-cluster.yml: فایل Kubeconfig برای کلاستر، این فایل حاوی اطلاعات احراز هویت برای دسترسی کامل به کلاستر ایجاد شده است.فایل rancher-cluster.rkestate: فایل وضعیت کلاستر Kubernetes، این فایل حاوی وضعیت فعلی کلاستر است که شامل پیکربندی RKE و سرتیفیکیت‌ها می‌باشد. این فایل در ادامه‌ی مسیر که بخواهید کلاستر رو تغییر بدید ضروری است و از روی اون تشخیص می‌ده که کلاستر در چه وضعیتی قرار دارد.نکته: فایل وضعیت کلاستر Kubernetes فقط زمانی ایجاد می‌شود که از RKE نسخه v0.2.0 یا بالاتر استفاده کنید.مشخصات کلاستر ایجاد شده:خب دیگه یه کلاستر مالتی نود با استفاده از RKE ستاپ کردیم بد نیست یه مروری کنیم که این کلاستر ما چه مشخصاتی دارد:نسخه‌ی کوبرنتیر ما v1.31.5-rancher1-1 است.از calico برای cni استفاده کردیم.برای authorization از rbac داریم استفاده می‌کنیم.از etcd به صورت روزانه بکاپ می‌گیرم.۶ تا نود داریم که سه تا مستر و etcd و ورکر و سه تای دیگه تنها ورکر هستند.برای certificate آدرس‌هایی که داریم رو به عنوان SAN معرفی کردیم.برای IP پادها و سرویس‌ها از رنج‌های 10.42.0.0/16 و 10.43.0.0/16 استفاده کردیم.لاگ audit کوبرنتیز رو فعال کردیم.برای تمام ایمیج‌ها از رجیستری خودمون استفاده کردیم که مشخصاتش رو تو کانفیگ گذاشتیم.اسم کلاستر رو MeCan گذاشتیم.برای اتصال به نودها از پورت ssh غیر پیش‌فرض استفاده کردیم.برای اتصال به نودها از کاربر root استفاده کردیم.هاست نیم نودها رو هم بهش دادیم.تو این مستند هم به صورت کامل این مسیر به همراه اضافه و کم کردن نود و به روزرسانی کلاستر وجود داره که پیشنهاد می‌کنم حتما بهش سر بزنید.توی بلاگ پست‌های بعدی مطالب مربوط به کوبرنتیز رو ادامه میدیم و بیشتر با هم یاد می‌گیریم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sun, 09 Mar 2025 18:15:08 +0330 https://virgool.io/@rafiee/%D9%86%D8%B5%D8%A8-%DA%A9%D9%84%D8%A7%D8%B3%D8%AA%D8%B1-%D8%A8%D8%A7-kubespray-%D9%82%D8%B3%D9%85%D8%AA-%D9%87%D8%AC%D8%AF%D9%87%D9%85-d99ik58zyo7c توی این قسمت میریم سراغ اینکه بررسی کنیم چطوری می‌تونیم یه کلاستر کوبرنتیز رو با استفاده از kubespray ستاپ کنیم و بیاریم بالا. روشی که می‌تونیم باهاش کلاستر پروداکش رو ستاپ و نگهداری کنیم.kubesprayخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.Kubesprayتوی این بلاگ پست میریم به سراغ بررسی یه ابزار بسیار قدرتمند به اسم kubespray و یاد می‌گیریم که چجوری میتونیم باهاش یه کلاستر کوبرنتیز رو نصب کنیم. البته ابزار نمی‌شه بهش گفت. در حقیقت یه انسیبل خیلی بزرگ و کارا هست که می‌تونیم باهاش کوبرنتیز رو به با مدل‌های مختلفی نصب و کانفیگ کنیم.کیوب‌اسپری در واقع یه کلاس درس تمام عیار برای انسیبل هست، این پروژه انسیبلی هست که به کمک اون میتونیم روی بسترهای مختلف کلاستر کوبرنتیز رو نصب کنیم و آپدیت و ... که نیاز داریم رو به صورت automated انجام بدیم.ابزار kubeadm دانش حوزه‌ای درباره مدیریت چرخه حیات کلاستر کوبرنتیز را فراهم می‌کند؛ از جمله پیکربندی‌های خودمیزبان (self-hosted layouts)، خدمات کشف پویا (dynamic discovery services) و موارد دیگر. اگر این ابزار در دنیای جدید «اپراتورها» قرار می‌گرفت، ممکن بود به‌عنوان Kubernetes cluster operator نام‌گذاری شود.از سوی دیگر، Kubespray وظایف عمومی مدیریت پیکربندی را از دنیای «اپراتورهای سیستم‌عامل» و Ansible انجام می‌دهد، علاوه بر اینکه بخشی از فرایند اولیه ایجاد کلاستر کوبرنتیز (به‌همراه پلاگین‌های شبکه) و راه‌اندازی control plane را بر عهده دارد.ابزار Kubespray از نسخه v2.3 به بعد شروع به استفاده درونی از kubeadm برای ایجاد خوشه کرده است تا از دانش حوزه‌ای مدیریت چرخه حیات آن بهره ببرد و وظایف عمومی پیکربندی سیستم‌عامل را از آن جدا کند.پیش‌نیازها و نکات:توی قدم اول باید پروژه رو با تگ مشخص اون ورژنی که میخوایم clone کنیم، دقت کنید که برنچ master رو نگیرید و حتما از ورژن‌های استیبل استفاده کنید. اگر از برنچ master استفاده کنید استیبل نیست و آخرین نسخه هست که معمولا با خطاهای زیادی مواجهه می‌شید.kubespray Releaseبرای مثال از قسمت Tags گزینه v2.27.0 را انتخاب می‌کنیم و در این برنچ فایلی با نام requirements.txt وجود دارد به شکل زیر:requirementsدر این فایل ورژن انسیبلی که نیاز داریم نوشته شده که در اینجا مثلا 9.13.0 هست، همچنین ورژن سایر پکیج‌هایی که نیاز دارید در venv مربوطه نصب کنیم نوشته شده. این طوری تمام اون نیازمندی که برای نصب و کانفیگ توسط kubespray داریم رو همون نسخه‌ که نیاز داره رو نصب می‌کنیم. حتما توصیه می‌کنم که از virtual env استفاده کنیم که اگر نسخه‌ی دیگه‌ای داریم اونها رو خراب نکنه.نیازمندی دیگری که داریم این هست که در حالت عادی سرورهامون باید دسترسی به اینترنت برای دریافت ایمیج‌های داکر و باینری‌های که نیاز داره رو داشته باشند مگر اینکه بخوایم از روش‌های نصب برای محیط‌های آفلاین استفاده کنیم. اگر بخواهیم این کار رو کنیم باید سرورهای ما دسترسی به ریپوهای آفلاین داشته باشه.با توجه به مشکلاتی که تو دریافت پکیج‌ها و ایمیج‌ها تو ایران داریم توصیه می‌کنم یه Nexus بالای دست کلاستر کوبرنتیز خودمون داشته باشیم تا همه‌ی پکیج‌ها و ایمیج‌هایی که لازم داره رو از اون بگیره.نیازمندی بعدی این هست که سرورهامون رو کانفیگ کنیم که IPv4 forwarding بر روی اونها به صورت مجاز باشد، همچنین اگه از IPv6 برای سرویس‌ها و پادهاتون استفاده می‌کنید اون هم باید allowed کنید.نکته مهم دیگه اینکه این پروژه انسیبل فایروال شما رو مدیریت نمیکنه و خودتون بایستی که تنظیماتی که لازم دارید رو انجام بدید که در این مورد توی پست قبلی یه روشی پیشنهادی رو توضیح دادیم.دقت کنید که اگر انسیبل رو با کاربری غیر از root ران می‌کنید بایستی دسترسی‌های لازم رو بهش بدید و فلگ become رو ست کنید حتما و کامندتون رو با b- بزنید.حداقل برای نود مستر 1500MB و برای ورکر 1024MB رم نیاز هست که معمولا اگر برای پروداکشن بخوایم استفاده کنیم اعداد خیلی بیشتر از اینهاست و بسته به اپلیکیشن و نیازمندی که داریم متفاوت هست.پس کیوب‌اسپری رو کلون میکنیم :)git clone -b release-2.27 https://github.com/kubernetes-sigs/kubespray.gitبهتره که یه environment پایتونی ایجاد کنیم و مواردیکه توی requirements.txt هست رو توی اون نصب کنیم:VENVDIR=kubespray-venv KUBESPRAYDIR=kubespray apt install python3.10-venv python3 -m venv $VENVDIR source $VENVDIR/bin/activate cd $KUBESPRAYDIR# Install requirements package pip install -U -r requirements.txtیه کپی از فایل سمپلی که توی inventory پروژه هست می‌گیریم تا تغییراتی که لازم داریم رو توش انجام بدیم:# Copy inventory/sample as inventory/MeCan cp -rfp inventory/sample inventory/MeCanتوی این فایل سرورها به سه تا گروه زیر تقسیم میشن:گروه kube_node: لیست همه نودهای کلاستر توی این قسمت قرار میگیره.گروه kube_control_plane: این قسمت لیست سرورهایی هست که کامپوننت‌های نودهای مستر یا control plane روی اونها بالا میاد یعنی api-server و scheduler و controller manager.گروه etcd: توی این قسمت هم لیست نودهایی که روی اونها etcd بالا میاد رو میذاریم که برای پروداکشن حداقل باید سه تا باشن.# This inventory describe a HA typology with stacked etcd (== same nodes as control plane) # and 3 worker nodes # See https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html # for tips on building your # inventory # Configure 'ip' variable to bind kubernetes services on a different ip than the default iface # We should set etcd_member_name for etcd cluster. The node that are not etcd members do not need to set the value, # or can set the empty string value.node1 ansible_host=192.168.200.11 node2 ansible_host=192.168.200.12 node3 ansible_host=192.168.200.13 node4 ansible_host=192.168.200.14 node5 ansible_host=192.168.200.15 node6 ansible_host=192.168.200.16 [kube_control_plane]node1 node2 node3[etcd:children]kube_control_plane[kube_node]node1 node2 node3 node4 node5 node6بعد از اینکه inventory رو درست کردیم حالا میرسه زمان استفاده از playbookهای پروژه، اینجا میتونید یه لیستی از تگ های انسیبلی که این پروژه داره ببینید.برای مثال کامند زیر فقط تسک های مربوط به DNS configuration رو انجام میده و بقیه موارد رو اسکیپ میکنه:ansible-playbook -i inventory/MeCan/hosts.ini cluster.yml --tags preinstall,facts --skip-tags=download,bootstrap-osیا مثلا با استفاده از کامند زیر میتونید DNS resolver ip رو از روی نودهای کلاستر و مسیر etc/resolv.conf/ پاک کنید:ansible-playbook -i inventory/MeCan/hosts.ini -e dns_mode='none' cluster.yml --tags resolvconfشناخت انسیبل کیوب‌اسپری مهمه، مخصوصا اینکه بدونید تگی که دارید استفاده می‌کنید یا skipش می‌کنید چه کاری رو انجام میده. دستور زیر ایمیج‌های مورد نظر رو به صورت locally آماده میکنه، بدون اینکه نصب یا آپگریدی رو انجام بده:ansible-playbook -i inventory/MeCan/hosts.ini cluster.yml \ -e download_run_once=true -e download_localhost=true \ --tags download --skip-tags upload,upgradeکانفیگ group_vars/all/all.yml :توی قدم بعدی باید یه سری وریبل‌هارو تنظیم کنیم که توی فایل group_vars/all/all.ymlهستن.برای کانفیگ لودبالانسری که برای api-server ها گذاشتیم به شکل زیر عمل می‌کنیم:## External LB example configapiserver_loadbalancer_domain_name: "vip.kubespray.mecan.ir" loadbalancer_apiserver: address: 192.168.200.10 port: 6443همچنین برای لودبالانسر داخلی می‌تونیم از این کانفیگ استفاده کنیم:## Internal loadbalancers for apiservers loadbalancer_apiserver_localhost: true # valid options are "nginx" or "haproxy" loadbalancer_apiserver_type: nginxاگه میخواید که http_proxy ست کنید برای آپدیت پکیج‌ها و گرفتن ایمیج‌ها میتونید موارد زیر رو اضافه کنید:http_proxy: "PROXY_ADDRESS:PROXY_PORT" https_proxy: "PROXY_ADDRESS:PROXY_PORT" # https_proxy_cert_file: ""به مسیر roles/kubespray-defaults/defaults/main.yml هم مراجعه کنید قبل از اینکه تغییری رو در no_proxy ایجاد کنید. حتما لازمه که کانفیگ درستی برای NO_PROXY تنظیم کنید که درخواست‌هایی که نیاز نیست از روی پروکسی عبور نکنه.# no_proxy: "10.233.0.0/18,10.233.64.0/18"همچنین گزینه زیر رو هم true کنید تا cache رو به درستی انجام بده و همینطور گزینه های بعدی برای دیپلوی کردن container engine و مسیر فایل sysctl:download_container: true # Set false if you want to deploy container engine manually. deploy_container_engine: true sysctl_file_path: "/etc/sysctl.d/99-sysctl.conf"کانفیگ وریبل‌های مرتبط با containerd:توی قدم بعدی بایستی که تغییراتی رو در وریبل‌های مسیر group_vars/all/containerd.yml ایجاد کنیم و رجیستری های میرور خودمون رو برای container runtime که داریم استفاده می‌کنیم یعنی containerd ست کنیم:# Registries defined within containerd.containerd_registries_mirrors: - prefix: docker.io mirrors: - host: https://hub.mecan.ir capabilities: ["pull", "resolve"] - prefix: registry.k8s.io mirrors: - host: https://k8s.mecan.ir capabilities: ["pull", "resolve"] - prefix: quay.io mirrors: - host: https://quay.mecan.ir capabilities: ["pull", "resolve"]کانفیگ وریبل‌های مرتبط با etcd:در گام بعدی باید وریبل‌های مرتبط با etcd رو ست کنیم که اینجا هم میتونید داکیومنتش رو ببینید، برای مشخص کردن مسیر دایرکتوری که دیتای etcd در آن ذخیره می‌شود داریم:etcd_data_dir: /var/lib/etcdبرای مشخص کردن کانتینر ران‌تایم ‌مون داریم:## docker for docker, crio for cri-o and containerd for containerd.## Additionally you can set this to kubeadm if you want to install etcd using kubeadm## Kubeadm etcd deployment is experimental and only available for new deployments## If this is not set, container manager will be inherited from the Kubespray defaults## and not from k8s_cluster/k8s-cluster.yml, which might not be what you want.## Also this makes possible to use different container manager for etcd nodes.container_manager: containerdو ستینگ برای نحوه دیپلوی شدن etcd که روی kubeadm میذاریم:# It is possible to deploy etcd with three methods. To change the default deployment method (host), use the etcd_deployment_type variable. Possible values are host, kubeadm, and docker.etcd_deployment_type: kubeadmاگه میخواید که پورتی رو برای متریک‌های etcd مشخص کنید به شکل زیر عمل می‌کنیم:etcd_metrics_port: 2381و برای url ش هم اگه میخوای که overrideش کنیم به شکل زیر عمل میکنیم:etcd_listen_metrics_urls: "http://0.0.0.0:2381"کانفیگ وریبل‌های مرتبط با addons:توی گام بعدی میریم سراغ انجام کانفیگ‌های مرتبط با addon هایی که میخوایم اضافه کنیم به کلاستر در مسیر group_vars/k8s_cluster/addons.yml:هلم رو enable می‌کنیم و بعدی برای متریک سرور کانفیگ رو انجام میدیم:helm_enabled: true # Metrics Server deployment metrics_server_enabled: true metrics_server_container_port: 10250 metrics_server_kubelet_insecure_tls: true metrics_server_metric_resolution: 15s metrics_server_kubelet_preferred_address_types: "InternalIP,ExternalIP,Hostname" metrics_server_host_network: false metrics_server_replicas: 1اگر بخواهید می‌تونید مابقی اد‌آن‌های کوبرنتیز رو هم با استفاده از این کانفیگ انجام بدید. من معمولا مابقی ادآن‌ها رو خودم با Helm و Argo می‌زنم و از اینجا استفاده نمی‌کنم.کانفیگ وریبل‌های مرتبط با k8s-cluster:در قدم بعدی به سراغ فایل group_vars/k8s_cluster/k8s-cluster.yml می‌رویم. می‌تونیم بگیم که این فایل مهم‌ترین وریبل‌ها رو داخل خودش داره و کلا کلاسترمون با استفاده از این وریبل‌ها کانفیگ می‌شه.اگه میخواید که ورژن دیگه‌ای از کوبرنتیز رو داشته باشید مثلا یه نسخه بتا میتونید به شکل زیر وریبل رو تغییر بدید:kube_version: v1.31.4پلاگین نتورک رو مشخص می‌کنیم بعدش که هم میتونید برای cloud ست‌ش کنید و مواردی مثل cilium, calico, kube-ovn, weave or flannel:kube_network_plugin: calicoبرای تنظیمات مربوط به شبکه داخلی و نتورک سرویس‌ها و پادها داریم:# Kubernetes internal network for services, unused block of space. kube_service_addresses: 10.233.0.0/18# internal network. When used, it will assign IP # addresses from this range to individual pods. # This network must be unused in your network infrastructure! kube_pods_subnet: 10.233.64.0/18مود kube-proxy رو هم اینجا مشخص می‌کنیم که ما اینجا از iptables استفاه می‌کنیم:# Can be ipvs, iptables kube_proxy_mode: iptablesکانفیگ بعدی که اضافه می‌کنیم مربوط به این هست که پادها به صورت graceful و در چه زمانی خاموش بشن:# Graceful Node Shutdown (Kubernetes >= 1.21.0), see https://kubernetes.io/blog/2021/04/21/graceful-node-shutdown-beta/# kubelet_shutdown_grace_period had to be greater than kubelet_shutdown_grace_period_critical_pods to allow# non-critical podsa to also terminate gracefullykubelet_shutdown_grace_period: 60skubelet_shutdown_grace_period_critical_pods: 20sکانتینر ران‌تایم رو هم مشخص می‌کنیم که برای ما containerd هست:## docker for docker, crio for cri-o and containerd for containerd. ## Default: containerd container_manager: containerdخوبه که پالیسی گرفتن ایمیج‌ها رو هم عوض کنیم که در صورتیکه موجود بود دیگه دوباره ایمیج رو pull نکنه:k8s_image_pull_policy: IfNotPresentلاگ رو هم true می‌کنیم که ‌لاگ audit رو هم بتونیم داشته باشیم:kubernetes_audit: trueتوی k8s_cluster هم گزینه زیر رو فعال می‌کنیم تا یه کپی از کیوب کانفیگ رو به هاست اضافه کنه:kubeconfig_localhost: trueخوبه که این فضای رزرو رو هم برای kube daemons مشخص کنید:kube_reserved: true## Uncomment to override default values## The following two items need to be set when kube_reserved is truekube_reserved_cgroups_for_service_slice: kube.slicekube_reserved_cgroups: "/{{ kube_reserved_cgroups_for_service_slice }}"kube_memory_reserved: 256Mikube_cpu_reserved: 100mkube_ephemeral_storage_reserved: 2Gikube_pid_reserved: "1000"# Reservation for master hostskube_master_memory_reserved: 512Mikube_master_cpu_reserved: 200mkube_master_ephemeral_storage_reserved: 2Gikube_master_pid_reserved: "1000"همینطور رزرو منابع برای سیستم‌عامل:system_reserved: true## Uncomment to override default values## The following two items need to be set when system_reserved is truesystem_reserved_cgroups_for_service_slice: system.slicesystem_reserved_cgroups: "/{{ system_reserved_cgroups_for_service_slice }}"system_memory_reserved: 512Misystem_cpu_reserved: 500msystem_ephemeral_storage_reserved: 2Gi## Reservation for master hostssystem_master_memory_reserved: 256Misystem_master_cpu_reserved: 250msystem_master_ephemeral_storage_reserved: 2Giآدرس های تکمیلی که می توانند در کلیدهای kubernetes ssl اضافه شوند. اگر این آدرس‌ها رو به درستی تنظیم نکنیم ممکنه خطای x509 بگیریم و نتونیم با certificate که ساخته شده ارتباط بگیرم.## That can be useful for example to setup a keepalived virtual IPsupplementary_addresses_in_ssl_keys: - 192.168.200.10 - 192.168.200.11 - 192.168.200.12 - 192.168.200.13 - vip.kube.mecan.ir - master1 - master2 - master3 - master1.kube.mecan.ir - master2.kube.mecan.ir - master3.kube.mecan.irمیتونیم ورژن tls هم که ساپورت کنه رو هم تعیین کنیم که گزینه‌های مختلفی مثل VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 رو داریم:tls_min_version: "VersionTLS12"یا مثلا براش تعیین کنیم که به صورت خودکار در زمان‌های مشخصی در هر ماه سرتیفیکیت‌های control-plane رو renew کنه:auto_renew_certificates: true# First Monday of each monthauto_renew_certificates_systemd_calendar: "Mon *-*-1,2,3,4,5,6,7 03:{{ groups['kube_control_plane'].index(inventory_hostname) }}0:00"برای آپگرید سیستم ‌هم گزینه‌های زیر رو ست می‌کنیم:system_upgrade: truesystem_upgrade_reboot: neverکانفیگ‌های مربوط به Calico:توی فایل group_vars/k8s_cluster/k8s-net-calico.yml هم وریبل‌های مربوط به calico رو کانفیگ ‌می‌کنیم:# * can-reach=DESTINATION# * interface=INTERFACE-REGEX# see https://docs.projectcalico.org/reference/node/configurationcalico_ip_auto_method: "interface=eth.*"calico_ip6_auto_method: "interface=eth.*"مود اضافه کردن rule های iptables رو هم میتو‌نیم مشخص کنیم:calico_felix_chaininsertmode: Insertبرای فعال کردن wireguard که ترافیک calico رو رمزگذاری کنه داریم:calico_wireguard_enabled: trueهمچنین خوبه که liveness و readiness پراب رو هم ست کنیم:calico_node_livenessprobe_timeout: 10calico_node_readinessprobe_timeout: 30تقریبا چیزهایی که لازم بود و خیلی کاربردی بود رو کانفیگ کردیم. مابقی وریبل‌ها هم اگر نیاز داشتید می‌تونید کانفیگ کنید.ران کردن playbookها! :توی بلاگ پست قبلی هم توضیح دادیم، پورت‌های لازم رو بین نودها باید باز کنید و یا اینکه میتونید مثل روش زیر نودهای کلاستر رو توی فایروال همدیگه کلا باز کنید:iptables -A INPUT -s 192.168.200.10/32 -j ACCEPT -m comment --comment "The Trusted lb server"iptables -A INPUT -s 192.168.200.11/32 -j ACCEPT -m comment --comment "The Trusted master1 server"iptables -A INPUT -s 192.168.200.12/32 -j ACCEPT -m comment --comment "The Trusted master2 server"iptables -A INPUT -s 192.168.200.13/32 -j ACCEPT -m comment --comment "The Trusted master3 server"iptables -A INPUT -s 192.168.200.14/32 -j ACCEPT -m comment --comment "The Trusted worker1 server"iptables -A INPUT -s 192.168.200.15/32 -j ACCEPT -m comment --comment "The Trusted worker2 server"iptables -A INPUT -s 192.168.200.16/32 -j ACCEPT -m comment --comment "The Trusted worker3 server"iptables -A INPUT -s 10.233.0.0/18 -j ACCEPT -m comment --comment "Kubernetes internal network for services"iptables -A INPUT -s 10.233.64.0/18 -j ACCEPT -m comment --comment "Kubernetes internal network for pod"اول با کامند زیر ایمیج ‌های لازم رو دانلود می‌کنیم:# download tag: Fetching container images to a delegate host# The option `--become` is required, as for example writing SSL keys in /etc/,# installing packages and interacting with various systemd daemons.# Without --become the playbook will fail to run!ansible-playbook -i inventory/MeCan/inventory.ini cluster.yml --tags=downloadبعد از اینکه ایمیج‌ها آماده شد، playbook کلاستر رو با دسترسی root ران ‌می‌کنیم:# The option `--become` is required, as for example writing SSL keys in /etc/,# installing packages and interacting with various systemd daemons.# Without --become the playbook will fail to run!ansible-playbook -i inventory/MeCan/hosts.yaml --become --become-user=root cluster.ymlبعد از این مرحله‌ با توجه به سرعت ارتباطی که با سرورها دارید و اینترنتی که در اختیار دارید یه زمانی طول می‌کشه تا کلاستر شما نصب و کانفیگ بشه.دسترسی به کلاستر و انجام Smoke test:از یکی از نود‌های مستر فایل kubeconfig رو بر میداریم و برای دسترسی به کلاستر به عنوان ادمین از روی لپ‌تاپ خودمون فایل رو با دسترسی‌ها لازم در مسیر مشخص به شکل زیر قرار می‌دیم:sudo chown -R $USERNAME:$USERNAME /etc/kubernetes/admin.conf cat /etc/kubernetes/admin.conf > ~/.kube/configبرای اینکه بتونیم با این کانفیگ به کلاستر وصل شیم نیازه که آی پی داخلی و پرایوت که توی کانفیگ هست رو عوض کنیم و به آی پی external مربوط به api-server تغییر دهیم.بررسی کنیم که آیا متریک سرور به درستی اضافه شده به کلاستر:kubectl top nodesنتورک کلاستر رو تست کنیم که ببینیم پادهامون اینترنت دارن یا نه:kubectl run test-pod-1 -it --rm --image busybox -- ping google.comیه دیپلویمنت nginx هم با لیبل app=nginx میاریم بالا و تست می‌کنیم:kubectl create deployment nginx --image=nginx kubectl get pods -l app=nginxپورت فوروارد رو انجام می‌دیم و اکسس به اپلیکیشن رو چک می‌کنیم:POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath="{.items[0].metadata.name}")kubectl port-forward $POD_NAME 8080:80لاگ پادمون رو چک می‌کنیم:kubectl logs $POD_NAMEیه کامندم توش اجرا می‌کنیم:kubectl exec -ti $POD_NAME -- nginx -vحالا وقتشه که یه سرویس بیاریم بالا که بدون پورت فروارد هم بتونیم ببینیم این پادمون رو، اینجا برای تست از نوع nodeport یه سرویس ایجاد می‌کنیم:kubectl expose deployment nginx --port 80 --type NodePortفایروالم چک می‌کنیم که باز باشه اون پورت و یه کرل بهش می‌زنیم :NODE_PORT=$(kubectl get svc nginx \ --output=jsonpath='{range .spec.ports[0]}{.nodePort}')curl -I http://${EXTERNAL_IP}:${NODE_PORT}برای چک کردن DNS هم به شکل زیر عمل می‌کنیم یه دیپلویمنت busybox میسازیم و پادهاش رو لیست می‌کنیم:kubectl run busybox --image=busybox --command -- sleep 3600kubectl get pods -l run=busyboxاسم پاد رو در میاریم و سرویس کوبرنتیز رو از توی پاد سعی می‌کنیم چک کنیم:POD_NAME=$(kubectl get pods -l run=busybox -o jsonpath="{.items[0].metadata.name}")kubectl exec -ti $POD_NAME -- nslookup kubernetesدر ادامه چک می‌کنیم که آیا DNS built-in کوبرنتیز بین namespaceهای مختلف هم به درستی کار میکنه یا نه؟ پس به namespace ایجاد می‌کنیم:kubectl create namespace devحالا یه دیپلویمنت nginx توی این namespace ایجاد می‌کنیم و پورتش رو اکسپوز می‌کنیم به بیرون بعدش از توی یه پاد دیگه توی namespace دیفالت سعی می‌کنیم بهش وصل شیم:kubectl create deployment nginx --image=nginx -n devkubectl expose deployment nginx --port 80 --type ClusterIP -n devkubectl run curly -it --rm --image curlimages/curl:7.70.0 -- /bin/shcurl --head http://nginx.dev:80میدونیم که موقعی که یه secret توی کوبرنتیز ایجاد می‌کنیم به صورت رمزگذاری شده در etcd ذخیره می‌شود نهایتا که اصطلاحا می‌گیم encryption at rest یعنی موقعیکه دیتا میره توی دیتابیس ذخیره میشه استیبل میشه میخواد استراحت کنه! اونجا رمزگذاری میشه، توی تست بعدی میاییم یه secret درست می‌کنیم و بعدش به یکی از نودهای کنترلر وصل می‌شیم و به کمک دستور etcdctl سعی می‌کنیم اون دیتا رو از دیتابیس بگیریم و ببینیم به چه صورت هست:kubectl create secret generic kubernetes-the-hard-way --from-literal="mykey=mydata"لاگین می‌کنیم به یکی از نودها که etcd روی اون هست، بعدش:sudo ETCDCTL_API=3 etcdctl get \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ /registry/secrets/default/kubernetes-the-hard-way | hexdump -C# sample output00000000 2f 72 65 67 69 73 74 72 79 2f 73 65 63 72 65 74 |/registry/secret|00000010 73 2f 64 65 66 61 75 6c 74 2f 6b 75 62 65 72 6e |s/default/kubern|00000020 65 74 65 73 2d 74 68 65 2d 68 61 72 64 2d 77 61 |etes-the-hard-wa|00000030 79 0a 6b 38 73 00 0a 0c 0a 02 76 31 12 06 53 65 |y.k8s.....v1..Se|00000040 63 72 65 74 12 db 01 0a bf 01 0a 17 6b 75 62 65 |cret........kube|00000050 72 6e 65 74 65 73 2d 74 68 65 2d 68 61 72 64 2d |rnetes-the-hard-|00000060 77 61 79 12 00 1a 07 64 65 66 61 75 6c 74 22 00 |way....default".|00000070 2a 24 36 32 34 62 32 62 37 62 2d 33 62 30 35 2d |*$624b2b7b-3b05-|00000080 34 38 66 35 2d 61 62 33 38 2d 31 64 39 39 63 36 |48f5-ab38-1d99c6|00000090 33 37 33 33 63 65 32 00 38 00 42 08 08 94 a1 d3 |3733ce2.8.B.....|000000a0 b8 06 10 00 8a 01 62 0a 0e 6b 75 62 65 63 74 6c |......b..kubectl|000000b0 2d 63 72 65 61 74 65 12 06 55 70 64 61 74 65 1a |-create..Update.|000000c0 02 76 31 22 08 08 94 a1 d3 b8 06 10 00 32 08 46 |.v1".........2.F|000000d0 69 65 6c 64 73 56 31 3a 2e 0a 2c 7b 22 66 3a 64 |ieldsV1:..,{"f:d|000000e0 61 74 61 22 3a 7b 22 2e 22 3a 7b 7d 2c 22 66 3a |ata":{".":{},"f:|000000f0 6d 79 6b 65 79 22 3a 7b 7d 7d 2c 22 66 3a 74 79 |mykey":{}},"f:ty|00000100 70 65 22 3a 7b 7d 7d 42 00 12 0f 0a 05 6d 79 6b |pe":{}}B.....myk|00000110 65 79 12 06 6d 79 64 61 74 61 1a 06 4f 70 61 71 |ey..mydata..Opaq|00000120 75 65 1a 00 22 00 0a |ue.."..|00000127و می‌بینیم که دیتا به صورت رمزگذاری شده در دیتابیس هست.گام های بعدی رو به صورت لینک از داکیومنت‌هایی که توی گیتهاب قرار دادیم براتون میذارم اگه دوست داشتید میتونید اونها رو هم انجام بدید.استفاده از Sonobuoy برای تست کلاستر به صورت e2e.کلاستر رو Scale کنیم و node بهش اضافه کنیم یا ازش کم کنیم.آپگرید کردن کلاستر کوبرنتیز.توی بلاگ پست‌های بعدی مطالب مربوط به کوبرنتیز رو ادامه میدیم و بیشتر با هم یاد می‌گیریم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Fri, 28 Feb 2025 14:36:00 +0330 https://virgool.io/@rafiee/install-kubernetes-cluster-iqkjepmsh1wa توی این قسمت میریم به سراغ اینکه بررسی کنیم چطوری می‌تونیم یه کلاستر کوبرنتیز رو با استفاده از kubeadm ستاپ کنیم و بیاریم بالا.Kubernetes installation with kubeadmخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.در این بلاگ پست، راهنمای گام‌به‌گام راه‌اندازی یک کلاستر Kubernetes با استفاده از Kubeadm را ارائه داده‌ام.kubeadmابزار Kubeadm ابزاری فوق‌العاده برای راه‌اندازی سریع یک کلاستر Kubernetes است. این ابزار، تمام کارهای سنگین مربوط به تنظیم مؤلفه‌های کلاستر Kubernetes را انجام می‌دهد و همچنین از بهترین شیوه‌های پیکربندی کلاستر پیروی می‌کند. به صورت اختصار kubernetes admin هست که کمک می‌کنه تا به راحتی کلاستر ستاپ کنیم. فقط تو ستاپ کمک نمی‌کنه بلکه در ادامه‌ی نگهداری کلاستر هم بهمون کمک می‌کنه. مثلا اگر بخواهیم نود اضافه کنیم یا به روز رسانی انجام بدیم کنار دستمون هست تا بتونیم به راحتی هر کاری که لازم است رو باهاش انجام بدیم.ابزار Kubeadm چیست؟خب Kubeadm ابزاری برای راه‌اندازی یک کلاستر Kubernetes حداقلی (minimum viable) بدون پیچیدگی فراوان است. همچنین Kubeadm با اجرای مجموعه‌ای از پیش‌نیازها و بررسی‌ها، اطمینان حاصل می‌کند که سرور، پیش‌نیازها و پیکربندی‌های لازم برای اجرای Kubernetes را دارد.این ابزار توسط کامیونیتی رسمی Kubernetes توسعه و نگهداری می‌شود. ابزارهای دیگری مانند Minikube و Kind نیز هستند که به‌صورت ساده‌تر و با نیازمندی سخت‌افزاری کمتر، کلاستر Kubernetes راه‌اندازی می‌کنند که توی این بلاگ پست در موردشون توضیح دادیم و اینجا هم می‌تونید بیشتر در موردشون بخونید ولی این ابزارها بیشتر برای تست اپلیکیشن‌ها روی Kubernetes مفید هستند و همواره تو استیج و آرمایشگاه‌ها از آنها استفاده می‌شود. اما kubeadm به ما این امکان رو می‌دهد که کلاستر در سطح پروداکشن ستاپ و نگهداری کنیم.اما اگر قصد دارید با مؤلفه‌های کلاستر عمیق‌تر آشنا شوید یا ابزارهایی که مرتبط با مدیریت کلاستر هستند را آزمایش کنید، Kubeadm بهترین انتخاب خواهد بود و میتونید برای ستاپ کردن یه کلاستر production ready ازش استفاده کنید.بررسی پیش‌نیازهای راه‌اندازی۱. سه تا نود دبیان برای مستر‌های کلاستر و سه تا نود دیگه هم برای ورکر نودها، همچنین می‌توانید بسته به نیازتان نودهای ورکر بیشتری داشته باشید. این مستند بر اساس سیستم‌عامل Debian آماده شده است. اما برای نصب و کار با کوبرنتیز شما محدودیتی روی دیسترو ندارید و فقط لینوکس باشه کافیه. البته که روی ویندوز هم می‌شه ولی خوب من لینوکس بلدم و اونجا آموزش می‌دم.۲. نود مستر باید حداقل ۲ vCPU و ۲ گیگابایت رم داشته باشد. نود ورکر می‌تونه کمتر از این هم داشته باشه ولی بهتره که همین مقدار باشه.۳. فرقی نمیکنه که ماشین‌ها توی شبکه داخلی باشند یا پابلیک، در هر صورت از اتصال نتورکی اونها به هم مطمئن شید. نودهای مستر و ورکر روی یه سری پورت مشخص با همدیگه صحبت می‌کنند. باید دستری به این پورت‌ها رو برای هم باز کنید.نصب یه سری tools اولیه روی نودهاخوبه که قبل از هر هرکاری سرورهامون رو آپدیت کنیم و hardening (مجموعه‌ کارهایی که امنیت سرور رو افزایش می‌دهد) و tuning (مجموعه‌ کارهایی که کارایی سرور را افزایش می‌دهد) اونها رو انجام بدیم، که معمولا این کار رو با انسیبل انجام میدن. بعدش یه سری ابزار اولیه رو به شکل زیر نصب می‌کنیم:apt install -y wget git vim bash-completion curl htop net-tools dnsutils \ atop sudo software-properties-common telnet axel jq iotop \ ca-certificates curl gnupg lsb-release apt-transport-https gpgتوی مرحله بعدی باید کانتینر ران‌تایم موردنظرمون رو نصب کنیم. لازمه که اینجا یادآوری کنم داکر کانتینر ران‌تایم نیست و خود داکر از کانتینر‌دی برای کانتینر ران‌تایم داره استفاده می‌کنه. در ادامه دستورات مربوط به نصب و کانفیگ Containerd رو براتون میذارم:ابتدا GPG key رسمی داکر را به شکل زیر به کلیدهای apt اضافه می‌کنیم.sudo mkdir -p /etc/apt/keyrings && sudo chmod -R 0755 /etc/apt/keyringscurl -fsSL "https://download.docker.com/linux/debian/gpg" | gpg --dearmor --yes -o /etc/apt/keyrings/docker.gpgاگه توی ایران هستید و این دستور کرل اذیت میکنه باید از یه طریق مطمئن اون کلید رو با روش‌هایی که هر ایرانی بلده، بردارید و توی اون مسیر قرار بدید یا یه جایی که بشه ازش گرفت برای خودتون بذارید صرفا برای مثال به این شکل میشه فرآیند بعدش:curl -fsSL "https://store.dockerme.ir/Software/docker.gpg" | gpg --dearmor --yes -o /etc/apt/keyrings/docker.gpgبعدشم مخزن داکر رو به لیست مخزن‌های apt اضافه کنید.chmod a+r /etc/apt/keyrings/docker.gpgecho "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian bullseye stable" > /etc/apt/sources.list.d/docker.list # Check docker repository cat /etc/apt/sources.list.d/docker.listاگه ایرانی هستی و میخوای از ریپوزیتوری‌هایی استفاده کنی که تحریم نباشه این مدلی میزنی برای مثال کامند این قسمت رو به جای روش بالا:echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://repo.mecan.ir/repository/debian-docker bookworm stable" > /etc/apt/sources.list.d/docker.list# Check docker repository cat /etc/apt/sources.list.d/docker.listنهایتا containrerd رو نصب می‌کنیم و سرویسش رو استارت می‌کنیم.sudo apt update # Install containerd service sudo apt install containerd.io # Start and enable Containerd service sudo systemctl enable containerd sudo systemctl restart containerd sudo systemctl status containerdبعدش کانفیگش رو انجام می‌دیم و درایور Cgroup رو عوض می‌کنیم.sudo mkdir -p /etc/containerdsudo containerd config default | sudo tee /etc/containerd/config.toml# Change Cgroup driver sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml# Check Cgroup driver sudo cat /etc/containerd/config.toml | grep SystemdCgroupsudo apt-get update# Restart Containerd service sudo systemctl restart containerd sudo systemctl status containerdمجدد اگه ایرانی هستی و نیاز داری برای containerd رجیستری میرور ست کنی اینجوریه👇🏼توی همون فایل config.toml که داره بعد از اینکه پترن پلاگین هارو دیدی مثل این:[plugins."io.containerd.grpc.v1.cri".registry.mirrors]زیرش موارد زیر رو اضافه می‌کنید برای مخزن های مختلف: [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://hub.mecan.ir"] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry.k8s.io"] endpoint = ["https://k8s.mecan.ir"] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."quay.io"] endpoint = ["https://quay.mecan.ir"] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."mirror.gcr.io"] endpoint = ["https://gcr.mecan.ir"]اگر هم نیاز دارید که http proxy ست کنید براش میتونید اینجوری انجامش بدید:# Check and create directory path DIR_PATH=/etc/systemd/system/containerd.service.d [ -d "${DIR_PATH}" ] || sudo mkdir "${DIR_PATH}"# Create config file cat <<EOF >${DIR_PATH}/http-proxy.conf [Service] Environment="HTTP_PROXY=http://HTTP_PROSY_DOMAIN:PORT" Environment="HTTPS_PROXY=http://HTTP_PROSY_DOMAIN:PORT" Environment="NO_PROXY=localhost,127.0.0.1,10.233.0.0/18,10.233.64.0/18,.mecan.ir" EOF# Check config file cat ${DIR_PATH}/http-proxy.confبعد از همه اینها هم یه ریلود و یه ری استارت لازمه تا چنج‌ کانفیگ‌هاتون اعمال شه و بریم مرحله بعدی:sudo systemctl daemon-reload sudo systemctl restart containerd sudo systemctl status containerdنصب و کانفیگ ابزارهای کوبرنتیز و پیش‌نیازهاشون روی تمام سرورهاازونجایی که kube-proxy برای کار کردن به پکت فیلترینگ نیاز داره و تو این مستند ما مودش رو iptables قرار می‌دیم، این متغیرهای کرنلی زیر رو هم بایستی ست کنید:cat >>/etc/sysctl.d/kubernetes.conf<<EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 EOF# apply new sysctl config sysctl --system >/dev/null 2>&1بعدش برای فعال کردن این فیچرهای ترافیک bridge ماژول br-netfilter رو لود می‌کنیم:modprobe br_netfilterبرای اینکه کوبرنتیز بتونه بهتر فیچرهای memory management که داره رو اجرایی کنه swap رو برمیداریم:# Disable swap in fstab file sed -i '/swap/d' /etc/fstab# off swap swapoff -aدر قدم بعدی میریم سراغ اضافه کردن مخزن‌ها و نهایتا نصب ابزارهای کوبرنتیز:ابتدا نصب چنتا ابزار لینوکسی که نیازمون میشه:sudo apt-get update # apt-transport-https may be a dummy package; if so, you can skip that package sudo apt-get install -y apt-transport-https ca-certificates curl gpgاضافه کردن کلید مخزن‌ها به apt:# If the directory `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below. # sudo mkdir -p -m 755 /etc/apt/keyringscurl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg# OR Download from Store.DockerMe.ir curl -fsSL https://repo.mecan.ir/repository/apt-kube/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg# Check gpg key sudo ls -alh /etc/apt/keyrings/kubernetes-apt-keyring.gpgاضافه کردن مخزن کوبرنتیز به لیست مخازن apt:# This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list# Check kubernetes repo cat /etc/apt/sources.list.d/kubernetes.list# Update your repository apt-get update -yمجدد اگه ایرانی هستی و نیاز داری که مخزن میرور ست کنی میشه یه چیزی شبیه این:# for kubernetes 1.30 echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://repo.mecan.ir/repository/apt-kube/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list# Update your repository cat /etc/apt/sources.list.d/kubernetes.list# Update your repository apt-get updateچک نهایی و نصب kubelet و kubectl و kubeadm :# check package version: apt-cache policy kubelet kubectl kubeadm# install kubernetes tools: sudo apt-get install -y kubelet kubeadm kubectl# check install versions: kubelet --version kubeadm version kubectl versionنکته مهم اینجا این هست که پکیج‌هایی که نصب می‌کنید رو hold کنید تا بعدا ناخواسته ورژن اونها رو عوض نکنید، مگر اینکه در حال آپدیت نود باشید و خودتون بدونید که دارید چیکار می‌کنید. اگر اونها رو hold نکنید و ریپوی جدید کوبرنتیز رو داشته باشید با هر آپدیت سیستم‌عامل نسخه‌ی جدید‌ترش نصب می‌شه که اگر حواستون نباشه اذیتتون می‌کنه.sudo apt-mark hold kubelet kubeadm kubectlسرویس kubelet رو enable و استارت می‌کنیم:systemctl enable kubelet systemctl start kubelet systemctl status kubeletکانفیگ crictl رو هم انجام میدیم که بتونیم در صورت نیاز از کامندش استفاده کنیم:cat << EOF > /etc/crictl.yaml runtime-endpoint: "unix:///run/containerd/containerd.sock" timeout: 0 debug: false EOF# Check config file cat /etc/crictl.yaml# check crictl command and mirror containerd registry crictl infoباید تو این قسمت میرور‌ها و کانفیگ‌هایی که قبلا برای کانتینردی انجام دادیم رو بتونیم ببینیم.نیازمندی‌های پورت در Kubeadmلطفاً به تصویر زیر مراجعه کنید و اطمینان حاصل کنید که همه این پورت‌ها برای کنترل‌پلین (مستر) و ورکرها باز هستند و اون‌ها رو در فایروال باز کنید. باید سرورهای شما دسترسی به این پورت‌ها روی هم‌دیگه داشته باشند.k8s portsیه کاری که میتونید بکنید این هست که نودهای کلاستر رو توی هم باز کنید! یعنی بر اساس ip توی فایروال دسترسی نودهای خود کلاستر رو به همدیگه اکسپت کنید به شکل زیر مثلا یه سری rule رو توی etc/iptables/rules.v4/ به صورت persist اضافه می‌کنیم. البته که با توجه به نکات امنیتی که رعایت می‌کنید ممکنه این کار برای شما مناسب نباشه. از این رو اگر فقط پورت‌ها رو هم باز کنید کافی هست. نکته‌ی دیگه این که این دسترسی‌ها رو تو تمام نودها باید ایجاد کنید.iptables -A INPUT -s ${master1_ip} -j ACCEPT -m comment --comment "The Trusted ${master1_name}" iptables -A INPUT -s ${master2_ip} -j ACCEPT -m comment --comment "The Trusted ${master2_name}" iptables -A INPUT -s ${master3_ip} -j ACCEPT -m comment --comment "The Trusted ${master3_name}" iptables -A INPUT -s ${worker1_ip} -j ACCEPT -m comment --comment "The Trusted ${worker1_name}" iptables -A INPUT -s ${worker2_ip} -j ACCEPT -m comment --comment "The Trusted ${worker2_name}"بالای سر api-server ها باید یه لودبالانسر بذاریم که تا زمان استفاده از کلاستر HA داشته باشیم، اینجا یه داکیومنت گذاشتم که میتونید با استفاده ازش این کار رو انجام بدید. چون می‌خواهیم کلاستر HA داشته باشیم و ۳ تا مستر داریم لازم داریم با استفاده از لودبالانسر همواره به مستر درست برسیم.خب حالا دیگه آماده شدیم تا کانفیگ kubeadm رو انجام بدیم و کلاستر رو ایجاد کنیم، ابتدا وریبل های زیر رو طبق کلاستر خودتون اضافه کنید:اول یه سری وریبل ست می‌کنیم که وقتی کانفیگ رو می‌سازیم همه چیز درست باشه. لازمه که مقادیر اینها رو با مقادیری که خودتون دارید عوض کنید.# set specific variables content vip_ip=192.168.200.10 master1_ip=192.168.200.11 master2_ip=192.168.200.12 master3_ip=192.168.200.13 domain_name=mecan.ir master1_name=master1 master2_name=master2 master3_name=master3 vip_api_name=vip.kubeadmو در مرحله بعدی دستورات زیر رو بزنید تا فایل کانفیگ kubeadm ایجاد شود:cat <<EOT >/opt/kubeadm_config.yml apiVersion: kubeadm.k8s.io/v1beta3 bootstrapTokens: - groups: - system:bootstrappers:kubeadm:default-node-token token: abcdef.0123456789abcdef ttl: 24h0m0s usages: - signing - authentication kind: InitConfiguration localAPIEndpoint: advertiseAddress: ${master1_ip} bindPort: 6443 nodeRegistration: criSocket: unix:///var/run/containerd/containerd.sock imagePullPolicy: IfNotPresent name: ${master1_name} taints: - effect: NoSchedule key: node-role.kubernetes.io/master --- apiServer: timeoutForControlPlane: 4m0s extraArgs: authorization-mode: "Node,RBAC" certSANs: - "${vip_ip}" - "${master1_ip}" - "${master2_ip}" - "${master3_ip}" - "${master1_name}" - "${master2_name}" - "${master3_name}" - "${vip_api_name}" - "${vip_api_name}.${domain_name}" - "${master1_name}.${domain_name}" - "${master2_name}.${domain_name}" - "${master3_name}.${domain_name}" apiVersion: kubeadm.k8s.io/v1beta3 certificatesDir: /etc/kubernetes/pki clusterName: kubernetes etcd: local: imageRepository: "quay.io/coreos" imageTag: "v3.5.9" dataDir: "/var/lib/etcd" serverCertSANs: - "${master1_ip}" - "${master2_ip}" - "${master3_ip}" - "${vip_ip}" - "${master1_name}" - "${master2_name}" - "${master3_name}" - "${vip_api_name}" - "${vip_api_name}.${domain_name}" - "${master1_name}.${domain_name}" - "${master2_name}.${domain_name}" - "${master3_name}.${domain_name}" peerCertSANs: - "${master1_ip}" - "${master2_ip}" - "${master3_ip}" - "${vip_ip}" - "${master1_name}" - "${master2_name}" - "${master3_name}" - "${vip_api_name}" - "${vip_api_name}.${domain_name}" - "${master1_name}.${domain_name}" - "${master2_name}.${domain_name}" - "${master3_name}.${domain_name}" imageRepository: registry.k8s.io kind: ClusterConfiguration kubernetesVersion: 1.30.5 controlPlaneEndpoint: "${vip_api_name}.${domain_name}:6443" networking: dnsDomain: cluster.local serviceSubnet: "10.233.0.0/18" podSubnet: "10.233.64.0/18" --- apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration cgroupDriver: systemd EOT# check kubeadm config file cat /opt/kubeadm_config.ymlفایل این کانفیگ رو می‌تونید از اینجا دانلود کنید.قبل از اینکه کلاستر رو ایجاد کنید خوبه که ایمیج‌هایی که لازم هست رو اول دریافت کنید. مخصوصا اگه توی ایران هستید و دریافت ایمیج‌ها ممکن اذیت کننده بشه، به این صورت میتونید لیست ایمیج‌ها رو بگیرید و اونها رو pull کنید:kubeadm config images list --config /opt/kubeadm_config.ymlkubeadm config images pull --config /opt/kubeadm_config.ymlنهایتا با زدن دستور زیر ایجاد اولیه کلاستر رو شروع می‌کنید:kubeadm init --config /opt/kubeadm_config.ymlابزار kubeadm ابتدا یه سری precheck هارو انجام میده تا مطمئن شه که سرور آماده ران کردن کوبرنتیز هست، این precheckها ممکنه یه سری وارنینگ بده و یا به یه سری ارور بخوره و exit کنه اما نهایتا اگه مشکلی نباشه کامپوننت‌های control plane رو نصب میکنه و نهایتا یه پیامی شبیه این رو بهمون نشون میده: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/configYou should now deploy a Pod network to the cluster.Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: /docs/concepts/cluster-administration/addons/You can now join any number of machines by running the following on each nodeas root: kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>با استفاده از دستورات زیر میتونید کانفیگ kubectl که روی مستر اول تون ایجاد شده رو بردارید و بعدش برای استفاده راحت تر حتما بهتون توصیه می‌کنم که bash-completion رو اضافه کنید و همچنین میتونید اینجا و اینجا چیزای خیلی خوبی برای برای حرفه‌ای تر کردن کامندلاین تون برای کار با کوبرنتیز پیدا کنید.calicoالان کلاستر شما نصب شده و با استفاده از دستور kubectl می‌تونید وضعیت اون رو چک کنید. اگر لیست کل پادها رو بگیرید می‌بینید که پادهای coredns تو حالت pending مونده که به دلیل نبود CNI هست. یکی از کارهایی که CNI برای ما انجام می‌‌ده اینه که به پادهای ما IP می‌ده. پادهای Coredns منتظر گرفتن IP هستند. پس بریم سراغ نصب CNI روی کلاستر کوبرنتیز که آماده کردیم.در ادامه میمونه نصب CNI و اضافه کردن باقی‌ نودها به کلاستر که به صورت زیر انجام‌شون میدیم:# install calico CNI: kubectl create -f https://docs.tigera.io/calico/latest/manifests/calico.yaml# check calico pods on kube-system namespace: kubectl -n kube-system get pod | grep calicoابتدا سرتیفیکیت های مستر اول رو به بقیه نودهای مستر هم کپی می‌کنیم:# copy certificate directory to localhost: scp -r adm-master1:/etc/kubernetes/pki .# copy certificate directory to master2 and master3: scp -r pki adm-master2:/etc/kubernetes/ scp -r pki adm-master3:/etc/kubernetes/دستور گرفتن کامند Join برای اضافه کردن نود بعدی به کلاستر رو هم در ادامه براتون میذارم، دقت کنید که اگر نود مستر میخواید اضافه کنید یه سوئیچ control-plane-- هم بهش اضافه کنید.# create join command: kubeadm token create --print-join-command# sample output: kubeadm join 37.32.9.196:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>دیگه تموم شد. می‌تونید از کلاستر کوبرنتیز که دارید استفاده کنید. تمام این مسیر رو هم می‌تونید اینجا بینید و داشته باشید.kubeadm errorاشکالات احتمالی در Kubeadmدر زیر، به برخی اشکالات رایجی که ممکن است حین راه‌اندازی با آن روبه‌رو شوید اشاره شده است:پادها با خطای کمبود رم و CPU مواجه می‌شوند: مطمئن شوید نود مستر حداقل ۲ vCPU و ۲ گیگابایت رم دارد.نودها نمی‌توانند به مستر متصل شوند: بررسی کنید در فایروال، همه پورت‌های مورد نیاز باز باشند و نودها بتوانند از طریق شبکه، به یکدیگر متصل شوند.پادهای Calico مرتب ری‌استارت می‌شوند: معمولاً اگر آدرس IP نودها با رنج IP پادها همپوشانی داشته باشد، Calico به مشکل برمی‌خورد. مطمئن شوید رنج IP نود و پاد یکسان نیست.خطاهای دیگر پاد: برای خطاهای پاد می‌توانید راهنمای عیب‌یابی پادها را ببینید.اگر CPU سرور مستر کمتر از ۲ هسته باشد، ممکن است خطای زیر را ببینید:[ERROR NumCPU]: the number of available CPUs 1 is less than the required 2اگر از پارامتر --apiserver-advertise-address با IP عمومی استفاده کنید، ممکن است کامپوننت‌های مستر با خطای زیر روبه‌رو شوند:timed out waiting for the conditionبرای رفع مشکل در IP عمومی، از پارامتر --control-plane-endpoint استفاده کنید.در صورتی که پس از ریست‌کردن مستر با دستور kubeadm reset، با یک توکن جدید قصد دارید نود ورکر را Join کنید و خطای زیر را بگیرید، با دستور kubeadm reset روی ورکر مشکل را حل کنید:[ERROR FileAvailable--etc-kubernetes-kubelet.conf]: /etc/kubernetes/kubelet.conf already exists [ERROR Port-10250]: Port 10250 is in use [ERROR FileAvailable--etc-kubernetes-pki-ca.crt]: /etc/kubernetes/pki/ca.crt already existsاین دستور برای پاک کردن کلاستر استفاده می‌شود. بهش دقت کنید و تنها در مواقعی که می‌خواهید کلاستر ایجاد شده رو پاک کنید ازش استفاده کنید. همه‌چیز رو پاک می‌کنه حواستون باشه.ابزار Kubeadm چگونه کار می‌کند؟زمانی که با دستور kubeadm init یک کلاستر Kubernetes را راه‌اندازی می‌کنید، مراحل زیر رخ می‌دهد:مرحله‌ی Preflight Checks: ابتدا بررسی می‌کند که پیش‌نیازهای سیستمی مهیا هستند و ایمیج‌های مورد نیاز از registry.k8s.io دانلود می‌شود.مرحله‌ی TLS Certificates: گواهی‌های لازم ایجاد شده و در مسیر /etc/kubernetes/pki/ ذخیره می‌شوند.مرحله‌ی Kubeconfig Files: فایل‌های kubeconfig برای مؤلفه‌های مختلف در مسیر /etc/kubernetes/ تولید می‌شوند.راه‌اندازی Kubelet: سرویس Kubelet شروع به کار می‌کند و پادهای استاتیک (Static Pods) برای مؤلفه‌های کنترل‌پلین را در /etc/kubernetes/manifests/ می‌سازد.اجرای مؤلفه‌های مستر: پادهای مستر (api-server، controller-manager و scheduler) بالا می‌آیند.نصب CoreDNS و Kubeproxy.ایجاد توکن: توکن راه‌اندازی (Bootstrap Token) برای نودهای ورکر تولید می‌شود تا به کنترل‌پلین متصل شوند.بدین ترتیب، همه پیکربندی‌های اصلی در مسیر /etc/kubernetes/ قرار می‌گیرد.چند سوال متداول:۱. چگونه از CA سفارشی در Kubeadm استفاده کنیم؟به‌صورت پیش‌فرض، kubeadm گواهی‌های CA مخصوص خود را ایجاد می‌کند. اما اگر بخواهید از CA سفارشی استفاده کنید، فایل‌های گواهی‌تان باید در مسیر /etc/kubernetes/pki/ قرار داشته باشند. وقتی kubeadm فایل‌های گواهی را در آنجا بیابد، دیگر آن‌ها را بازنویسی نخواهد کرد.۲. چگونه دستور Kubeadm Join را مجدداً تولید کنیم؟کافی است از دستور زیر استفاده کنید:kubeadm token create --print-join-commandدر این مطلب، نحوه نصب Kubernetes را به‌صورت قدم‌به‌قدم با Kubeadm یاد گرفتیم.برای یک مهندس DevOps، درک اجزای کلاستر Kubernetes اهمیت زیادی دارد. در حالی که بسیاری از شرکت‌ها از سرویس‌های مدیریت‌شده (Managed Kubernetes) استفاده می‌کنند، یادگیری مؤلفه‌های پایه‌ای و مبانی Kubernetes، ضروری است.راه‌اندازی Kubeadm برای یادگیری و تمرین مناسب است. همچنین قابلیت آزمایش روی VMهای لوکال را فراهم می‌کند تا همه تنظیمات کلاستر را بررسی کرده و نحوه عیب‌یابی مؤلفه‌های مختلف را بیاموزید.توی بلاگ پست‌های بعدی مطالب مربوط به کوبرنتیز رو ادامه میدیم و بیشتر با هم یاد می‌گیریم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sun, 23 Feb 2025 11:49:56 +0330 https://virgool.io/@rafiee/%D8%B3%DB%8C-%D8%A2%D8%B1-%D8%AF%DB%8C-%D9%88-%D8%A7%D9%8F%D9%BE%D8%B1%D8%A7%D8%AA%D9%88%D8%B1-%D9%82%D8%B3%D9%85%D8%AA-%D8%B4%D8%A7%D9%86%D8%B2%D8%AF%D9%87%D9%85-clvz7kaggum1 توی این قسمت میریم به سراغ اینکه بررسی کنیم چطوری می‌تونیم ریسورس‌های خودمون رو به صورت کاستوم شده توی کوبرنتیز تعریف کنیم و بعدش هم در مورد اُپراتورها توی کوبرنتیز توضیح می‌دیم.CRD & Operatorخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.CRDتعریف منابع سفارشی (Custom Resource Definitions - CRDs)در دنیای کوبرنتیز، انعطاف‌پذیری و قابلیت گسترش از اهمیت بالایی برخوردار است. کوبرنتیز یک API قدرتمند برای مدیریت منابعی مانند Pod، Deployment و Service ارائه می‌دهد. اما اگر بخواهید منابعی را مدیریت کنید که به‌صورت پیش‌فرض توسط کوبرنتیز پشتیبانی نمی‌شوند، چه باید کرد؟ اینجاست که CRDs وارد عمل می‌شوند.توی کوبرنتیز CRDها به شما این امکان را می‌دهند که منابع سفارشی خود را تعریف کرده و API کوبرنتیز را مطابق نیازهای خود گسترش دهید. در این مطلب، یک مثال عملی از کار با CRDها را بررسی می‌کنیم، جایی که یک کنترلر سفارشی ConfigMapها را بر اساس منابع سفارشی مدیریت می‌کند.چرا از CRDها استفاده کنیم؟توی کوبرنتیز CRDها بسیار قدرتمند هستند، زیرا به شما این امکان را می‌دهند که منابع مربوط به برنامه‌های خاص خود را به شیوه‌ای بومی (Native) در کوبرنتیز مدیریت کنید. دلایل استفاده از CRDها:انتزاع (Abstraction): با استفاده از CRDها می‌توانید منطق پیچیده را در منابع سفارشی پنهان کنید و مدیریت برنامه‌ها را ساده‌تر کنید و از امکانات کوبرنتیز برای مدیریت منابع خود استفاده کنید.یکپارچگی (Consistency): تعریف منابع سفارشی به شما کمک می‌کند تا برنامه‌های خود را در محیط‌های مختلف به‌صورت یکپارچه مدیریت کنید.خودکارسازی (Automation): CRDها امکان خودکارسازی را فراهم می‌کنند و به شما اجازه می‌دهند کنترلرهای سفارشی ایجاد کنید که وضعیت منابع را نظارت و اصلاح کنند.در ادامه این مبحث نحوه نصب یک منبع سفارشی در API کوبرنتیز از طریق ایجاد CustomResourceDefinition را بررسی می‌کنیم.مطالب این پست نیاز به نسخه سرور کوبرنتیز 1.16 یا بالاتر دارد. برای بررسی نسخه، از دستور زیر استفاده کنید:kubectl versionایجاد یک CustomResourceDefinitionوقتی یک CustomResourceDefinition (CRD) جدید ایجاد می‌کنید، API Server کوبرنتیز یک مسیر RESTful جدید برای هر نسخه‌ای که مشخص می‌کنید ایجاد می‌کند. منبع سفارشی ایجاد شده می‌تواند در محدوده فضای نام (Namespace) یا سراسری (Cluster-scoped) باشد. حذف فضای نام، تمام آبجکت‌های CRD داخل آن را نیز حذف می‌کند. اما خود CRDها غیرمحدوده‌ای (Non-namespaced) هستند.مثال:فایل زیر را در resourcedefinition.yaml ذخیره کنید:apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string replicas: type: integer scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab shortNames: - ctایجاد CRD:kubectl apply -f resourcedefinition.yamlیک مسیر API جدید مانند زیر ایجاد می‌شود:/apis/stable.example.com/v1/namespaces/*/crontabs/...ایجاد آبجکت‌های سفارشیپس از ایجاد CRD، می‌توانید آبجکت‌های سفارشی را ایجاد کنید. به‌عنوان مثال، فایل زیر را در my-crontab.yaml ذخیره کنید:apiVersion: "stable.example.com/v1" kind: CronTab metadata: name: my-new-cron-object spec: cronSpec: "* * * * */5" image: my-awesome-cron-imageایجاد آبجکت سفارشی:kubectl apply -f my-crontab.yamlمشاهده آبجکت‌های ایجاد شده:kubectl get crontabحذف یک CustomResourceDefinitionبرای حذف CRD و تمام آبحکت‌های مرتبط:kubectl delete -f resourcedefinition.yamlمشخص کردن ساختار اسکیما (Schema)با نسخه apiextensions.k8s.io/v1، تعریف یک اسکیما ساختاری (Structural Schema) برای CRD الزامی است. این اسکیما برای موارد زیر استفاده می‌شود:اعتبارسنجی داده‌های ورودی.جلوگیری از ذخیره فیلدهای ناشناخته (Pruning).مثال اسکیما ساختاری:type: object properties: spec: type: object properties: cronSpec: type: string image: type: stringکنترل حذف فیلدهای ناشناخته:type: object properties: json: x-kubernetes-preserve-unknown-fields: trueبررسی یک مثال دیگه:در این مثال، یک CRD ریسورسی به نام CustomConfigMap ایجاد خواهیم کرد. هر زمان که نمونه‌ای از این منبع ایجاد یا حذف شود، یک کنترلر سفارشی به ترتیب یک ConfigMap را ایجاد یا حذف می‌کند.CRDمراحل مثال عملی1. ایجاد Custom Resource Definition (CRD)ابتدا CRD خود را تعریف می‌کنیم. فایل زیر را به نام CCM_CRD.yaml ایجاد کنید:apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: customconfigmaps.anvesh.com spec: group: anvesh.com names: plural: customconfigmaps singular: customconfigmap kind: CustomConfigMap scope: Namespaced versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: my-own-property: type: stringسپس دستور زیر را اجرا کنید:kubectl apply -f CCM_CRD.yaml2. ایجاد Custom Resource (CR)یک نمونه از منبع سفارشی ایجاد کنید. فایل زیر را به نام CCM_CR.yaml ذخیره کنید:apiVersion: anvesh.com/v1 kind: CustomConfigMap metadata: name: my-custom-resource-instance spec: my-own-property: "example-value"و دستور زیر را اجرا کنید:kubectl apply -f CCM_CR.yaml3. نوشتن کنترلر سفارشییک فایل به نام custom_controller.py ایجاد کرده و محتوای زیر را در آن قرار دهید:from kubernetes import client, config, watch def create_configmap(namespace, name, data): core_v1_api = client.CoreV1Api() configmap = client.V1ConfigMap( metadata=client.V1ObjectMeta(namespace=namespace, name=name), data=data ) core_v1_api.create_namespaced_config_map(namespace=namespace, body=configmap) def delete_configmap(namespace, name): core_v1_api = client.CoreV1Api() core_v1_api.delete_namespaced_config_map(name=name, namespace=namespace) def main(): config.load_incluster_config() api_instance = client.CustomObjectsApi() group = "anvesh.com" version = "v1" namespace = "default" plural = "customconfigmaps" resource_version = "" while True: stream = watch.Watch().stream( api_instance.list_namespaced_custom_object, group, version, namespace, plural, resource_version=resource_version ) for event in stream: custom_resource = event['object'] event_type = event['type'] resource_name = custom_resource['metadata']['name'] resource_data = custom_resource.get('spec', {}) if event_type == "ADDED": create_configmap(namespace, resource_name, resource_data) elif event_type == "DELETED": delete_configmap(namespace, resource_name)4. ایجاد Docker Image برای کنترلریک فایل Dockerfile ایجاد کنید:FROM python:3.8 ADD custom_controller.py / RUN pip install kubernetes CMD ["python", "/custom_controller.py"]سپس تصویر را بسازید:docker build -t custom-controller:v1 .5. راه‌اندازی کنترلریک فایل به نام controller_deployment.yaml ایجاد کنید و محتوای زیر را در آن قرار دهید:apiVersion: apps/v1 kind: Deployment metadata: name: custom-controller spec: replicas: 1 selector: matchLabels: app: custom-controller template: metadata: labels: app: custom-controller spec: containers: - name: custom-controller image: custom-controller:v1دستور زیر را اجرا کنید:kubectl apply -f controller_deployment.yaml۱. بررسی کنید که کنترلر در حال اجرا باشد:kubectl get pods۲. بررسی کنید که ConfigMap ایجاد شده است:kubectl get configmaps۳. منبع سفارشی را ویرایش کنید:kubectl edit customconfigmaps my-custom-resource-instance۴. منبع سفارشی را حذف کنید و بررسی کنید که ConfigMap حذف شده است:kubectl delete customconfigmaps my-custom-resource-instanceدر این آموزش یاد گرفتید چگونه از CRDها برای گسترش API کوبرنتیز استفاده کنید. با ترکیب CRDها و کنترلرها می‌توانید کوبرنتیز را برای نیازهای خاص خود سفارشی کنید و قدرت بیشتری به فرآیند مدیریت کانتینرها بدهید.Kubernetes Operatorاپراتورهای کوبرنتیز چیستند؟اپراتور یک افزونه برای کوبرنتیز است که فرآیند استقرار یک برنامه را خودکار می‌کند. اپراتورها معمولاً شامل کنترلرها و Custom Resource Definitions (CRDs) هستند که به شما این امکان را می‌دهند نمونه‌های جدید برنامه‌ها را بدون نیاز به دانش عمیق از نیازها یا نحوه عملکرد آنها، به‌سرعت مستقر کنید.اپراتورها هدف اصلی مدیران انسانی را منعکس می‌کنند. استقرار دستی سیستم‌های پیچیده در یک کلاستر کوبرنتیز معمولاً نیازمند تلاش زیادی است، زیرا باید Pods، StatefulSets، Services، ConfigMaps و Volumes مورد نیاز برنامه را ایجاد و متصل کنید. اپراتورها به شما این امکان را می‌دهند که از انواع آبجکت‌های سفارشی مانند postgresql استفاده کنید تا پیکربندی زیرساخت کوبرنتیز به‌طور خودکار انجام شود.اپراتور با ارائه CRDs و کنترلرهای مرتبط، این قابلیت را فراهم می‌کند.برای مثال شما می‌خواهید دیتابیس از سرویس بدید. می‌تونید برای دیتابیس خود CRD و اپراتور تعریف کنید و تمام کانفیگ‌ها و الزامات مورد نیاز رو اونجا ایجاد کنید و هر زمان که درخواست ساخت کلاستر جدید دیتابیس بدید یه کلاستر کامل همانند کانفیگ‌هایی که لازم دارید می‌تونید ایجاد کنید.اپراتور کوبرنتیز در مقابل کنترلرمعماری کوبرنتیز شامل اجزا و مفاهیم متعددی است، اما یک ویژگی همه آنها را به هم مرتبط می‌کند: مدل حالت اعلامی (Declarative State Model) که با استفاده از حلقه‌های کنترلی (Control Loops) به‌طور خودکار اقدامات لازم را برای همسان‌سازی وضعیت واقعی کلاستر با وضعیت مطلوب شما انجام می‌دهد.کنترلرهای داخلی مانند Deployments و ReplicaSets، آبجکت‌های کلاستر شما را دنبال کرده و چرخه حیات وابسته‌های آنها را مدیریت می‌کنند. به‌عنوان مثال، وقتی یک آبجکت Deployment با ۳ کپی (Replica) ایجاد می‌کنید، کنترلر Deployment به‌طور خودکار یک ReplicaSet با سه Pod راه‌اندازی می‌کند و تمام تلاش خودش رو با استفاده از کنترلر رپلیکیشن انجام می‌دهد که همواره ۳ رپلیکا رو برای سرویس شما ایجاد کند.کنترلرها یک الگوی عمومی هستند که در سراسر کوبرنتیز استفاده می‌شوند و اغلب بخشی از اپراتورها هستند. اپراتورها کدی سفارشی را توصیف می‌کنند که برنامه‌های خاص را با کوبرنتیز ادغام می‌کند.چرا از اپراتورها استفاده کنیم؟1. تسهیل استقرار و نگهداری برنامه‌های پیچیدهاپراتورها آبجکت‌های موردنیاز برنامه را بر اساس پیکربندی منابع سفارشی شما فراهم می‌کنند. این امر به شما اجازه می‌دهد تا بدون نیاز به دانش عمیق در مورد آبجکت‌های کوبرنتیز، برنامه‌های جدید را مستقر کنید.2. مدیریت چرخه حیات برنامهاپراتورها معمولاً چرخه حیات کامل برنامه را شامل ارتقاها، پشتیبان‌گیری‌ها و ادغام‌های نظارتی مدیریت می‌کنند. اپراتور به جای شما برنامه را اجرا می‌کند و لایه‌هایی از خودکارسازی را اضافه می‌کند که به مدیران انسانی کمک می‌کند وظایف خسته‌کننده یا مستعد خطا را انجام دهند. مثل این می‌مونه که تمام کانفیگ‌ها و الزامات مورد نیاز رو یه بار سر حوصله و صبر و با دقت زیاد ایجاد کنید و هر زمان که نیاز داشتید به راحتی از آن‌ها استفاده کنید.3. ساده‌سازی استقرار پایگاه‌های دادهاپراتورها به‌طور چشمگیری فرآیند استقرار پایگاه‌های داده را در کوبرنتیز ساده می‌کنند، اما برای برنامه‌های ساده و بدون وضعیت (Stateless) مانند وب‌سرورها ضروری نیستند.4. استقرار در چندین کلاستراگر یک برنامه عمومی را در چندین کلاستر مستقر می‌کنید، اپراتورها بسیار مفید هستند. اما برای کدهای اختصاصی خود بهتر است از جایگزین‌هایی مانند Helm Chart استفاده کنید.مثال‌هایی از اپراتورهای کوبرنتیزPostgres Operator۱. اپراتور Postgresاین اپراتور به شما امکان می‌دهد با استفاده از یک مانیفست YAML ساده، یک نمونه از Postgres با ذخیره‌سازی پایدار و تنظیمات از پیش پیکربندی‌شده ایجاد کنید:apiVersion: acid.zalan.do/v1 kind: postgresql metadata: name: postgres-cluster spec: volume: size: 1Gi numberOfInstances: 3 users: demo-user: - superuser - createdb databases: demo-user: demo-db postgresql: version: "15"۲. اپراتور MySQLاپراتور MySQL فرآیند استقرار نمونه‌های MySQL را ساده می‌کند. با ایجاد آبجکت InnoDBCluster، اپراتور مدیریت پایگاه داده، کشف شبکه و مسیر‌یابی ترافیک را خودکار می‌کند.apiVersion: mysql.oracle.com/v2 kind: InnoDBCluster metadata: name: demo-db spec: secretName: mysql-creds tlsUseSelfSigned: true instances: 3 router: instances: 1۳. اپراتور Prometheusاین اپراتور استقرار و مدیریت Prometheus را که یک دیتابیس time series برای مانیتورینگ است، خودکار می‌کند.۴. اپراتور Istioاپراتور Istio مدیریت و پیکربندی سرویس مش را ساده می‌کند. با ایجاد یک آبجکت IstioOperator، می‌توانید تنظیمات سرویس مش را مدیریت کنید.چگونه یک اپراتور کوبرنتیز ایجاد کنیم؟اپراتورها را می‌توان با استفاده از هر زبان برنامه‌نویسی که با API کوبرنتیز تعامل دارد، ایجاد کرد. کتابخانه‌های رسمی برای زبان‌هایی مانند Go، Python، Java و Ruby موجود هستند.1. Operator Frameworkابزار Operator Framework یک کیت اوپن سورس است که به شما در نوشتن اپراتورهای پایدار کمک می‌کند. این ابزار شامل یک SDK است که فرآیند ساخت، آزمایش و بسته‌بندی اپراتورها را تسهیل می‌کند.2. Operator SDKموردی بعدی Operator SDK هست که یک ابزار توسعه اپراتور است که از زبان‌های زیر پشتیبانی می‌کند:Go:برای توسعه‌دهندگانی که به اکوسیستم Go تسلط دارند.Ansible:برای کاربرانی که با اتوماسیون Ansible آشنا هستند.Helm:برای ساخت اپراتورها بر اساس Helm Chart های موجود.دیدیم که اپراتورها قابلیت‌های خاص برنامه را به کوبرنتیز اضافه می‌کنند، اونها پیچیدگی استقرار برنامه‌های پیشرفته را کاهش داده و به کاربران اجازه می‌دهند روی پیکربندی برنامه تمرکز کنند همچنین ابزارهایی مانند Operator SDK و Helm فرآیند ایجاد اپراتورها را تسهیل می‌کنند.توی بلاگ پست‌های بعدی مطالب مربوط به کوبرنتیز رو ادامه میدیم و بیشتر با هم یاد می‌گیریم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 15 Feb 2025 13:56:49 +0330 https://virgool.io/@rafiee/%D9%BE%DA%A9%DB%8C%D8%AC-%D9%85%D9%86%DB%8C%D8%AC%D8%B1-%DA%A9%D9%88%D8%A8%D8%B1%D9%86%D8%AA%DB%8C%D8%B2-helm-%D9%82%D8%B3%D9%85%D8%AA-%D9%BE%D8%A7%D9%86%D8%B2%D8%AF%D9%87%D9%85-xceqwsxlwtdh توی این قسمت میریم به سراغ هلم (Helm) که یکی از پراستفاده‌ترین و کاربردی‌ترین ابزارهایی هست که در کنار کوبرنتیز میاد و ازش برای راه‌اندازی برنامه‌های مختلف استفاده می‌کنند. کلا با استفاده از Helm به راحتی می‌تونیم ابزارها و سرویس‌‌هایی که می‌خواهیم رو روی کوبرنتیز راه‌اندازی و مدیریت کنیم.Helmخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.Helmهلم (Helm):در دنیای پویا و مقیاس‌پذیر ارکستراسیون کانتینرها، Kubernetes به عنوان یک فناوری اساسی برای استقرار و مدیریت برنامه‌های کانتینری در مقیاس بزرگ ظهور کرده است. با این حال، مدیریت منابع Kubernetes با رشد اندازه و پیچیدگی برنامه‌ها می‌تواند چالش‌برانگیز شود. اینجاست که هلم (Helm)، مدیر بسته Kubernetes، با آوردن سادگی و کارایی به مدیریت برنامه‌های Kubernetes وارد عمل می‌شود. یکی از ویژگی‌های قدرتمند هلم، استفاده از چارت‌ها است. در این بخش به بررسی چارت‌های هلم، دلیل نیاز به آن‌ها در Kubernetes و نحوه استفاده موثر از آن‌ها می‌پردازیم.ابزار Kubernetes به استاندارد اصلی برای ارکستراسیون و استقرار کانتینرها تبدیل شده است. با افزایش پیچیدگی برنامه‌های Kubernetes، مدیریت دستی آن‌ها می‌تواند به یک کار دشوار تبدیل شود. در اینجا، هلم (Helm)، یک مدیر بسته برای Kubernetes، وارد عمل می‌شود.هلم (Helm) یک پکیج منیجر برای Kubernetes است که مدیریت، استقرار و به‌روزرسانی برنامه‌های اجراشده روی کلاستر Kubernetes شما را ساده‌تر می‌کند.هلم به شما کمک می‌کند برنامه‌های Kubernetes را با ارائه روشی برای تعریف، نصب و به‌روزرسانی برنامه‌های پیچیده Kubernetes مدیریت کنید. اگر بخوام یه مثال بزنم که به ذهن نزدیک بشه می‌تونیم پکیج‌ منیجر لینوکس رو مثال بزنیم. شما با استفاده از پکیج منیجر می‌تونید سرچ، نصب، کانفیگ و دیلیت کنید هر پکیجی رو که می‌خواهید اینجا هم با استفاده از Helm می‌تونید در مورد اپلیکیشن‌ها و سرویس‌های خودتون به این صورت رفتار کنید.Helmدر هسته‌ی اصلی، هلم از چارت‌ها استفاده می‌کند که بسته‌هایی از منابع از پیش پیکربندی‌شده Kubernetes هستند. این چارت‌ها برای تعریف، نصب و مدیریت برنامه‌های پیچیده Kubernetes استفاده می‌شوند.چارت‌های هلم می‌توانند هر چیزی را از یک برنامه وب ساده تا یک سیستم توزیع‌شده پیچیده تعریف کنند.هلم مدیریت برنامه‌های Kubernetes را با استفاده از چارت‌ها ساده می‌کند. چارت‌ها بسته‌هایی از منابع از پیش پیکربندی‌شده Kubernetes هستند. می‌توانید چارت‌های هلم را شبیه به قالب‌هایی برای برنامه‌های Kubernetes در نظر بگیرید که قابلیت سفارشی‌سازی بر اساس نیاز شما را دارند.Helm Workflowساختار چارت هلممدیریت بسته‌ها: نصب، به‌روزرسانی و مدیریت برنامه‌های Kubernetes.مدیریت نسخه‌ها: مدیریت نسخه‌های مختلف از برنامه‌ها.مدیریت پیکربندی‌ها: سفارشی‌سازی برنامه‌ها با فایل‌های مقادیر (Values Files).یک چارت هلم شامل چند فایل است که منابع Kubernetes را تعریف می‌کنند. این فایل‌ها شامل موارد زیر هستند:Chart.yaml:شامل متادیتا درباره‌ی چارت، مانند نام و نسخه آن.values.yaml:شامل مقادیر پیکربندی برای چارت. این مقادیر به ازای دیپلویمنت‌های مختلف می‌تواند متفاوت باشد که به ما این امکان رو می‌دهد که به راحتی سرویس‌ها و اپلیکیشن‌های خودمون رو در محیط‌های مختلف متفاوت راه‌اندازی و مدیریت کنیم.templates/:شامل قالب‌های منابع Kubernetes که برای ایجاد منابع واقعی در کلاستر استفاده می‌شوند. این مانیفست‌ها طوری ایجاد شدند که مقادیر آنها با استفاده از Value فایل‌ها تغییر می‌کنند.Helmچرا به چارت‌های هلم در Kubernetes نیاز داریم؟ساده‌سازی فرایند استقرارمانفیست‌های Kubernetes که در قالب YAML یا JSON نوشته می‌شوند، نحوه اجرای برنامه‌ها و تعامل آن‌ها با سایر سرویس‌ها را توصیف می‌کنند. با رشد برنامه‌ها، این مانفیست‌ها پیچیده‌تر و مدیریت آن‌ها دشوارتر می‌شود. چارت‌های هلم این پیچیدگی را با بسته‌بندی تمام جزئیات ضروری در یک بسته کاهش می‌دهند و استقرار را قابل مدیریت‌تر و کمتر مستعد خطا می‌کنند. به ما این امکان رو می‌دهند که بتونیم به صورت خودکار سرویس‌ها و اپلیکیشن‌هامون رو روی کلاستر پیاده‌سازی کنیم.کنترل نسخه و بازگشت به نسخه قبلیچارت‌های هلم از نسخه‌بندی پشتیبانی می‌کنند، که به توسعه‌دهندگان اجازه می‌دهد نسخه‌های مختلف استقرار برنامه‌ها و تغییرات پیکربندی را مدیریت کنند. این ویژگی امکان بازگشت آسان به نسخه‌های قبلی را در صورت بروز مشکل فراهم می‌کند و قابلیت اطمینان استقرار را افزایش می‌دهد. کلا قابلیت نسخه‌بندی خیلی به ما تو مدیریت سرویس‌ها و اپلیکیشن‌هامون کمک می‌کنه.قابلیت استفاده مجدد و اشتراک‌گذاریبا استفاده از چارت‌های هلم، پیکربندی‌های استقرار برنامه‌ها می‌توانند در پروژه‌ها یا تیم‌های مختلف مجدداً استفاده شوند، که این امر بهبود بهترین روش‌ها و صرفه‌جویی در زمان را ممکن می‌سازد. همچنین چارت‌ها را می‌توان از طریق مخازن چارت هلم به اشتراک گذاشت و همکاری و کارایی را افزایش داد.سفارشی‌سازی از طریق فایل values.yamlچارت‌های هلم از یک فایل values.yaml استفاده می‌کنند که امکان سفارشی‌سازی آسان استقرار را بدون تغییر در خود چارت فراهم می‌سازد. به این ترتیب، می‌توان از یک چارت برای استقرار برنامه‌ها در محیط‌های مختلف (develop و test و production) تنها با تغییر مقادیر استفاده کرد.Helmویژگی‌های هلماستقرار سریع و آسانبا استفاده از چارت‌های هلم، می‌توانید به سرعت برنامه‌های پیچیده Kubernetes را مستقر کنید و خیلی خوب این کار رو تکرار، قابل انتقال و بهبود بدید.مدیریت به‌روزرسانی‌ها و بازگشت‌هابه‌روزرسانی یک برنامه به نسخه جدید تنها با به‌روزرسانی چارت و اجرای دستور helm upgrade امکان‌پذیر است.اگر مشکلی پیش بیاید، می‌توانید به راحتی به نسخه قبلی با دستور helm rollback بازگردید.سفارشی‌سازی بالامی‌توانید مقادیر پیکربندی خود را در فایل values.yaml تعریف کنید.همچنین می‌توانید این مقادیر را در زمان نصب با دستور helm install بازنویسی کنید.مخزن چارت‌های از پیش ساخته‌شدههلم دارای مخزن مرکزی از چارت‌های آماده است که می‌توانید از آن‌ها برای استقرار سریع برنامه‌های محبوب مانند WordPress، MySQL و Prometheus استفاده کنید. artifacthub.io جایی هست که مخزن پابلیک برای helm chart هاست و می‌تونید چارت‌های پابلیک رو از اونجا بردارید و استفاده کنید. البته معمولا شرکت‌ها و سازمان‌ها برای خودشون ریپوزیتوری helm به صورت خصوصی و عمومی دارند.Helmکار با هلمگام ۱: نصب هلمابتدا باید هلم را روی سیستم خود نصب کنید. فایل‌های باینری هلم برای macOS، لینوکس و ویندوز در دسترس هستند.روی macOS:brew install helmروی لینوکس:curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bashروی ویندوز:فایل باینری هلم را از صفحه رسمی انتشارهای GitHub دانلود کرده و آن را به مسیر PATH خود اضافه کنید.تأیید نصب:helm versionگام ۲: اضافه کردن مخزن هلمهلم از مخازن برای توزیع چارت‌ها استفاده می‌کند. مخزن پیش‌فرض هلم https://charts.helm.sh/stable است.اضافه کردن مخزن Stable:helm repo add stable https://charts.helm.sh/stable helm repo updateلیست مخازن موجود:helm repo listگام ۳: جستجو برای چارت‌های هلممی‌توانید با استفاده از دستور helm search چارت‌های موجود در مخزن آرتی‌فک‌هاب را جستجو کنید.مثال: جستجوی چارت MySQL:helm search repo mysqlگام ۴: نصب یک چارت هلمبرای نصب یک چارت هلم از دستور helm install استفاده کنید. مثال:helm install [RELEASE_NAME] [CHART_NAME][RELEASE_NAME]:نام یکتایی که برای استقرار خود تعیین می‌کنید.[CHART_NAME]:نام چارت، می‌تواند از یک مخزن یا یک دایرکتوری محلی باشد.مثال: نصب چارت MySQL:helm install my-mysql stable/mysqlبررسی وضعیت انتشار:helm status my-mysqlلیست تمام انتشارها:helm listگام ۵: سفارشی‌سازی چارت‌های هلمهلم امکان سفارشی‌سازی چارت‌ها را با استفاده از فایل‌های مقادیر فراهم می‌کند. می‌توانید مقادیر پیش‌فرض یک چارت را تغییر دهید.دریافت مقادیر پیش‌فرض:helm show values stable/mysql > my-values.yamlویرایش فایل my-values.yaml برای سفارشی‌سازی تنظیمات.نصب چارت با استفاده از فایل مقادیر سفارشی:helm install my-mysql -f my-values.yaml stable/mysqlگام ۶: به‌روزرسانی انتشاربرای به‌روزرسانی یک انتشار، فایل مقادیر را تغییر داده و از دستور helm upgrade استفاده کنید.مثال:ویرایش فایل my-values.yaml.به‌روزرسانی انتشار:helm upgrade my-mysql -f my-values.yaml stable/mysqlگام ۷: حذف یک انتشاربرای حذف یک انتشار از دستور helm uninstall استفاده کنید.مثال: حذف انتشار MySQL:helm uninstall my-mysqlگام ۸: ایجاد چارت سفارشی هلمبرای ایجاد یک چارت سفارشی، از دستور helm create استفاده کنید. این دستور ساختار اولیه یک چارت را ایجاد می‌کند.ایجاد چارت جدید:helm create my-chartساختار ایجاد شده:my-chart/ ├── Chart.yaml ├── values.yaml ├── charts/ ├── templates/ └── templates/tests/اضافه کردن مانیفست‌های Kubernetes به پوشه templates/.گام ۹: استقرار چارت سفارشیبسته‌بندی چارت:helm package my-chartنصب چارت:helm install my-release my-chart-0.1.0.tgzگام ۱۰: هوک‌های هلمهوک‌های هلم امکان اجرای کارها در نقاط مشخصی از چرخه عمر انتشار را فراهم می‌کنند. به عنوان مثال، می‌توانید یک Job پیش از نصب ایجاد کنید.مثال هوک:apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}-pre-install" labels: app: "{{ .Release.Name }}" annotations: "helm.sh/hook": pre-install spec: template: spec: containers: - name: pre-install-job image: busybox command: ['sh', '-c', 'echo Hello from the pre-install hook!'] restartPolicy: Neverهلم ابزاری قدرتمند است که مدیریت برنامه‌های Kubernetes را ساده می‌کند. با استفاده از چارت‌های هلم می‌توانید به راحتی برنامه‌ها را مستقر، مدیریت و به‌روزرسانی کنید. این راهنما اصول پایه‌ای هلم را پوشش داد و شما را برای استفاده از قابلیت‌های پیشرفته‌تر آن آماده می‌کند.Helm Chartمثالی از یک چارت ساده هلم برای یک برنامه وب۱. ایجاد چارت جدیدابتدا یک دایرکتوری جدید برای چارت خود ایجاد کنید:mkdir my-web-app-chart cd my-web-app-chart۲. ایجاد فایل Chart.yamlیک فایل به نام Chart.yaml ایجاد کنید و محتویات زیر را اضافه کنید:apiVersion: v2 name: my-web-app description: A Helm chart for a simple web application version: 1.0.0این فایل متادیتای پایه‌ای درباره‌ی چارت، مانند نام، توضیحات و نسخه آن را تعریف می‌کند.۳. ایجاد فایل values.yamlیک فایل به نام values.yaml با محتویات زیر ایجاد کنید:replicaCount: 3 image: repository: my-web-app tag: latest pullPolicy: IfNotPresent service: name: my-web-app type: ClusterIP port: 80 ingress: enabled: falseاین فایل مقادیر پیکربندی برای چارت را تعریف می‌کند، از جمله تعداد نسخه‌ها (replicas)، تصویر Docker و تنظیمات سرویس.۴. تعریف Deploymentیک دایرکتوری به نام templates ایجاد کرده و یک فایل deployment.yaml در آن با محتویات زیر ایجاد کنید:apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Chart.Name }} spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: app: {{ .Chart.Name }} template: metadata: labels: app: {{ .Chart.Name }} spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" imagePullPolicy: {{ .Values.image.pullPolicy }} ports: - name: http containerPort: 80این فایل استقرار Kubernetes برای برنامه وب شما را تعریف می‌کند.۵. تعریف Serviceیک فایل دیگر به نام service.yaml در دایرکتوری templates ایجاد کنید و محتویات زیر را اضافه کنید:apiVersion: v1 kind: Service metadata: name: {{ .Values.service.name }} spec: type: {{ .Values.service.type }} ports: - port: {{ .Values.service.port }} targetPort: http selector: app: {{ .Chart.Name }}این فایل سرویس Kubernetes برای برنامه وب شما را تعریف می‌کند.۶. بسته‌بندی چارتچارت خود را با اجرای دستور زیر بسته‌بندی کنید:bashCopy codehelm package .این دستور فایل my-web-app-1.0.0.tgz را ایجاد می‌کند.۷. نصب چارتچارت را روی یک کلاستر Kubernetes با دستور زیر نصب کنید:bashCopy codehelm install my-release my-web-app-1.0.0.tgzتوی این بلاگ پست سعی کردیم یه مقدار به Helm آشنا بشیم و ویژگی‌های اون رو بشناسیم و کار باهاش رو یاد بگیریم.اگر هنوز از هلم استفاده نمی‌کنید، حتماً اونو امتحان کنید!تو ادامه‌ی مسیرمون بیشتر با موارد مربوط به کوبرنتیز آشنا میشیم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 08 Feb 2025 19:43:19 +0330 https://virgool.io/@rafiee/%D9%85%D8%A7%D9%84%D8%AA%DB%8C-%D8%AA%D9%86%D9%86%D8%B3%DB%8C-%D8%AF%D8%B1-%DA%A9%D9%88%D8%A8%D8%B1-%D9%82%D8%B3%D9%85%D8%AA-%DA%86%D9%87%D8%A7%D8%B1%D8%AF%D9%87%D9%85-skryihgngrnq تو قسمت چهاردهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم مالتی تننسی تا بررسی کنیم که اگر بخواهیم چند تیم یا مشتری رو روی کلاستر داشته باشیم با چه مواردی روبرو هستیم.Kubernetes Multi-tenancyخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.در دنیای مدیریت کانتینرها، یکی از رویکردهای مهم و رایج، به اشتراک‌گذاری کلاستر کوبرنتیز بین چندین تیم یا چندین مشتری است. این رویکرد که تحت عنوان چند-مستاجری (Multi-Tenancy) شناخته می‌شود، مزایایی همچون صرفه‌جویی در هزینه‌ها، ساده‌سازی مدیریت و بهره‌برداری بهتر از منابع را به همراه دارد. با این حال، چند-مستاجری چالش‌هایی نیز به همراه دارد؛ از جمله مسائل امنیتی، تضمین عدالت در توزیع منابع و مدیریت مشکلات ناشی از Noisy Neighbors و ... .انواع مالتی تننسی در کوبرنتیزMulti-tenancyچندین تیم (Multiple Teams):در این حالت، یک سازمان می‌تواند چندین تیم را بر روی یک کلاستر مشترک مستقر کند. هر تیم یک یا چند ورک‌لود دارد و ممکن است نیاز به برقراری ارتباط با یکدیگر و حتی کلاسترهای دیگر داشته باشند.اعضای تیم‌ها غالباً از طریق ابزارهایی مانند kubectl یا سیستم‌های GitOps به منابع کوبرنتیز دسترسی دارند. اینجا اعتماد نسبی بین تیم‌ها وجود دارد، اما همچنان باید از سیاست‌های کوبرنتیز همچونRBAC ، Quotas و Network Policies برای اطمینان از امنیت، مدیریت منصفانه و جداسازی نسبی استفاده شود.چندین مشتری (Multiple Customers):نوع دیگر مالتی تننسی زمانی است که یک ارائه‌دهنده‌ی سرویس SaaS چندین نمونه از سرویس خود را برای مشتریان مختلف بر روی یک کلاستر اجرا کند. در این حالت، مشتریان دسترسی مستقیمی به کلاستر ندارند و کوبرنتیز عملاً از دید آن‌ها پنهان است. هدف اصلی اینجا معمولاً بهینه‌سازی هزینه‌ها و تامین ایزوله‌سازی قوی بین ورک‌لودهای مشتریان مختلف است.Multi-tenancyروش‌های اعمال مالتی تننسی و ابزارهای مربوطه در کوبرنتیزمالتی تننسی در کوبرنتیز را می‌توان به روش‌های مختلفی پیاده‌سازی کرد و هر روش نیز مصالحه‌هایی در سطح امنیت، پیچیدگی، هزینه و میزان جداسازی ایجاد می‌کند. در ادامه به برخی از ابزارها و الگوهای رایج در این زمینه می‌پردازیم:کنترل دسترسی مبتنی بر نقش (RBAC):RBAC روشی استاندارد برای کنترل سطوح دسترسی در کوبرنتیز است. با استفاده از Roles و RoleBindings (در سطح Namespace) می‌توانید تعیین کنید که کدام کاربر یا سرویس‌اکانت به چه منابعی دسترسی دارد. در محیط چند-تیمی، RBAC ابزاری کلیدی برای محدود کردن دسترسی تیم‌ها به فضای نام (Namespace) مختص خود و جلوگیری از دخالت در منابع کلاستر سطح بالا (Cluster-Level) توسط کاربران غیرمجاز است.سهمیه‌ها (Resource Quotas):کوبرنتیز این امکان را می‌دهد که استفاده از منابعی همچون CPU، حافظه، یا حتی تعداد آبجکت‌ها (مثلاً تعداد Pod یا ConfigMap) را در هر Namespace محدود کنید. این قابلیت در محیط‌های چند-تیمی که هر تیم به API کوبرنتیز دسترسی دارد، اطمینان می‌دهد که یک تیم نتواند با ایجاد تعداد زیادی منبع، منابع کلاستر را اشغال کند و برای دیگران مشکل ایجاد نماید. سهمیه‌ها ابزاری مهم برای تضمین عدالت و جلوگیری از بروز مشکل «همسایه پرسروصدا» هستند. البته باید توجه داشت که سهمیه‌ها (Quotas) همه چیز را کنترل نمی‌کنند؛ برای مثال، روی ترافیک شبکه اثر مستقیم ندارند.جداسازی شبکه (Network Policies):با استفاده از Network Policy، می‌توان ارتباط بین پادها را کنترل و محدود کرد. در محیط‌های مالتی تننسی حساس، می‌توانید یک سیاست پیش‌فرض تعریف کنید که ارتباط بین پادها را مسدود نماید، و صرفاً ارتباط با سرویس DNS یا جریان‌های ارتباطی مجاز شده را فعال کنید. بدین ترتیب امنیت و جداسازی به مراتب افزایش خواهد یافت. به صورت پیش فرض تمام پاد‌ها داخل کلاستر کوبرنتیز به یکدیگر از طریق شبکه دسترسی دارند.جداسازی ذخیره‌سازی (Storage Isolation):ذخیره‌سازی در کوبرنتیز با استفاده از PersistentVolume و PersistentVolumeClaim مدیریت می‌شود. با تعریف StorageClassهای متفاوت برای هر مستاجر، می‌توانید به هر تیم یا مشتری فضای ذخیره‌سازی ویژه‌ای اختصاص دهید. اگر از یک StorageClass مشترک استفاده می‌کنید، توصیه می‌شود از سیاست Reclaim با مقدار Delete استفاده کنید تا پس از آزاد شدن منابع، دوباره در اختیار مستاجر دیگری قرار نگیرد و از خطرات امنیتی احتمالی جلوگیری شود.جداسازی در سطح نود (Node Isolation):با اختصاص دادن مجموعه‌ای از نودها به یک مستاجر خاص، می‌توان از مخلوط شدن پادهای مستاجران مختلف بر روی یک نود جلوگیری کرد. این کار ریسک حملات احتمالی و مشکلات Noisy Neighbors را کاهش می‌دهد. حتی اگر مهاجمی به یک نود نفوذ کند، تنها به پادها و حجم‌های ذخیره‌سازی همان مستاجر دسترسی خواهد داشت.چند-مستاجری در کوبرنتیز روشی قدرتمند برای بهینه‌سازی هزینه‌ها و بهره‌برداری مؤثر از منابع مشترک است. با این حال، نیازمند برنامه‌ریزی دقیق، انتخاب مناسب ابزارهای نظارتی و امنیتی، و پیاده‌سازی سیاست‌های کنترلی است. از RBAC و سهمیه‌ها گرفته تا Network Policy و Node Isolation، هر کدام بخشی از پازل مالتی تننسی در کوبرنتیز را کامل می‌کنند. با استفاده‌ی هوشمندانه از این ابزارها و الگوها، می‌توان به یک کلاستر اشتراکی امن، پایدار و عادلانه دست یافت که نیازهای چندین تیم یا چندین مشتری را به خوبی برآورده کند.Multi-tenancyداشتن چندین تیم یا مشتری که یک کلاستر Kubernetes را به‌طور مشترک استفاده می‌کنند از منظر هزینه منطقی به نظر می‌رسد، اما این کار برامون سربارهایی رو داره که باید بررسی کنیم که مثلا بهتره که چنتا کلاستر جداگانه بالا بیاریم یا روی یک کلاستر جداسازی و ایزوله‌سازی انجام بدیم.مطالبی که در ادامه توضیح میدهیم از این مقاله گرفته شده و سعی کردیم آزمایش‌هایی که انجام دادند رو اینجا توضیح بدیم.team environmentsبیشتر تیم‌ها کلاستر خود را بر اساس محیط‌ها (environment) پارتیشن‌بندی می‌کنند.برای مثال، ده تیم ممکن است هر کدام سه محیط (مثلاً dev ،test و prod) داشته باشند.اگر کلاستر را بر مبنای تیم و محیط تقسیم‌بندی کنید، در مجموع 30 بخش (slice) متمایز خواهید داشت.حالا اگر بخواهیم مقیاس را به 50 تیم گسترش دهیم چه می‌شود؟ در این صورت، 150 بخش به دست می‌آید (50 تیم × 3 محیط = 150).اما پیامدهای این تصمیم چیست؟تصور کنید می‌خواهید برای مدیریت ترافیک ورودی، یک Ingress Controller مستقر کنید.Ingress Controllerدو انتخاب اصلی دارید:یک Ingress Controller واحد برای تمام مستأجران.یک Ingress Controller اختصاصی برای هر مستأجر.یک Ingress Controller واحد در مقابل Ingress Controllerهای اختصاصیفرض کنید می‌خواهید از nginx-ingress controller استفاده کنید و request پیش‌فرض آن 100 میلی‌هسته (millicore) CPU و 90 مگابایت حافظه است.اگر تصمیم بگیرید برای هر مستأجر یک Ingress Controller اختصاصی مستقر کنید، برای 50 مستأجر به صورت زیر خواهد بود:CPU: 50 × 100 millicore = 5 vCPUMemory: 50 × 90MB = 4.5GBنزدیک‌ترین نمونه‌ی EC2 که با این مشخصات همخوانی دارد یک c6i.2xlarge با قیمت حدود 250 دلار در ماه است. اگر با اشتراک گذاشتن یک Ingress Controller بین 50 مستأجر مشکلی ندارید، هزینه‌ها تنها کسر کوچکی از این مقدار خواهد بود، چرا که فقط بابت 100 میلی‌هسته و 90MB حافظه می‌پردازید.اما آیا این واقع‌بینانه نیست زیرا ترافیک ورودی 50 مستأجر احتمالاً بیش از یک Ingress Controller واحد نیاز دارد و به طور متوسط ممکن است از مقدار 100mi و 90MB بیشتر مصرف کند. علاوه بر این، در سناریویی که چیزی خراب شود یا نیاز به ارتقا داشته باشد، همه‌ی مستأجران تحت تأثیر قرار می‌گیرند.از آنجا که Kubernetes برای soft multi-tenancy طراحی شده، ارزش دارد که پیکربندی‌های مختلف چندمستأجری را از نرم تا سخت بررسی کنیم.هزینه‌ها را برای سه پیکربندی با سطوح جداسازی افزایشی مقایسه کردند که در ادامه نتایج را بررسی می‌کنیم:Hierarchical Namespace controller for soft multi-tenancy.vCluster for isolating control planes.Karmada for managing a cluster per tenant (hard multi-tenancy).بیایید با Hierarchical Namespace Controller شروع کنیم.Hierarchical Namespace Controller (HNC):یک مؤلفه است که در کلاستز نصب می‌کنید و به شما اجازه می‌دهد Namespaceها را تو در تو (nested) ایجاد کنید.Hierarchical Namespace Controllerایده‌ی هوشمندانه پشت آن این است که همه Namespaceهای فرزند، منابع را از والد به ارث می‌برند و این تو در تو بودن می‌تواند بی‌نهایت ادامه یابد.به این ترتیب، اگر یک Role در Namespace والد ایجاد کنید، همان منبع در فرزندان هم در دسترس خواهد بود. در پشت صحنه، کنترلر تفاوت بین دو Namespace را محاسبه کرده و منابع را کپی می‌کند.بیایید یک مثال ببینیم.بعد از نصب کنترلر، می‌توانید یک Namespace ریشه به شکل زیر ایجاد کنید:$ kubectl create ns parentحالا می‌توانید یک نقش (Role) در Namespace والد با دستور زیر ایجاد کنید:$ kubectl -n parent create role test1 --verb=* --resource=podحالا یک اسکریپت برای ایجاد 50 Namespace فرزند بنویسید:#!/bin/bash for i in {1..50} do kubectl hns create "tenant-$i" -n parent doneاگر لیست Roleها را در هر یک از Namespaceهای فرزند بررسی کنید، می‌بینید که Role به آن‌ها منتقل شده است:$ kubectl get roles -n tenant-1 NAME CREATED AT test1 2024-02-29T20:16:05Zهمچنین می‌توانید رابطه بین Namespaceها و ساختار درختی آنها را ببینید:$ kubectl hns tree parent parent ├── [s] tenant-1 ├── [s] tenant-10 ├── [s] tenant-11 ├── [s] tenant-12 ├── [s] tenant-13 ├── [s] tenant-14 ├── [s] tenant-15 ├── [s] tenant-16 # truncated outputاما Namespaceهای تو در تو چگونه پیاده‌سازی شده‌اند؟نیم‌اسپیس‌های فرزند در واقع همان Namespaceهای معمولی Kubernetes هستند. می‌توانید با دستور زیر آن‌ها را فهرست کنید:$ kubectl get namespaces NAME STATUS default Active hnc-system Active kube-node-lease Active kube-public Active kube-system Active parent Active tenant-1 Active tenant-10 Active tenant-11 Active tenant-12 Active tenant-13 Active #...ارتباطات آن‌ها در Hierarchical Namespace Controller ذخیره شده و این کنترلر مسئول انتشار (propagate) منابع از والد به فرزند است.هزینه اجرای چنین اپراتوری پایین است: درخواست کنونی برای حافظه و CPU حدود 300MB حافظه و 100 میلی‌هسته CPU است. اما این روش محدودیت‌هایی دارد. در Kubernetes، منابعی مانند Pod و Deployment در سطح Namespace اعمال می‌شوند. اما بعضی منابع در سطح کل کلاستر global هستند، مانند ClusterRole ، ClusterRoleBinding ، Namespaceها ، PersistentVolumeها، CustomResourceDefinitionها (CRD) و غیره. اگر مستأجران بتوانند Persistent Volume مدیریت کنند، همه‌ی PVهای کلاستر را خواهند دید، نه فقط PVهای خودشان.این منابع گلوبال در کنترل پلین ذخیره می‌شوند. پس اگر بخواهیم برای هر مستأجر یک کنترل پلین مجزا داشته باشیم چه؟vCluster: the cost of isolated control planesشما می‌توانید به هر مستأجر یک کلاستر اختصاص دهید یا از یک روش سبک‌تر استفاده کنید: اجرای یک کنترل پلین به صورت یک پاد در کلاستر میزبان.مستأجران مستقیماً به این کنترل پلین (که در قالب پاد است) وصل شده و منابع خود را در آن ایجاد می‌کنند.vClusterبا این کار، کنترل پلین فقط متعلق به آن‌هاست و در نتیجه منابع گلوبال و مشکل contention و رقابت بر سر منابع حذف می‌شود.اما پاد کنترل پلین کجا اسکجول می‌شود اگر فقط یک کنترل پلین اجرا کنید؟کلاستر ویرچوآل یا vCluster این رویکرد را در پیش گرفت و راه‌حل مبتکرانه‌ای ارائه داد: یک کنترلر که منابع را از کنترل پلین مستأجر به کنترل پلین میزبان کپی می‌کند.هنگامی که یک Deployment در کنترل پلین مستأجر ایجاد می‌کنید، مشخصات پادهای حاصل به کنترل پلین میزبان کپی شده و در آنجا زمانبندی می‌شوند.vClusterمزایا و معایب:هر مستأجر یک کنترل پلین کامل دارد که انعطاف‌پذیری یک کلاستر واقعی را فراهم می‌کند.این کنترل پلین تنها برای ذخیره منابع در یک دیتابیس استفاده می‌شود.کنترلر می‌تواند طوری پیکربندی شود که فقط منابع خاصی را کپی کند.به عبارت دیگر، یک مکانیزم همگام‌سازی دقیق به شما اجازه می‌دهد گزینشی تعیین کنید کدام منابع از کلاستر مستأجر به خوشه میزبان منتقل شوند.فرآیند تست کردن این روش چیزی شبیه موارد زیر است:vcluster create test --set 'sync.persistentvolumes.enabled=true'وقتی nested cluster آماده شد، یک PersistentVolume را در فایل pv.yaml ذخیره کنید:apiVersion: v1 kind: PersistentVolume metadata: name: task-pv-volume labels: type: local spec: storageClassName: manual capacity: storage: 10Gi accessModes: - ReadWriteOnce hostPath: path: "/mnt/data"سپس آن را با دستور زیر اعمال کنید:$ kubectl apply -f pv.yaml persistentvolume/task-pv-volume createdاز کلاستر مستأجر خارج شوید و همه PVها را در خوشه میزبان ببینید:$ vcluster disconnect $ kubectl get pv NAME CAPACITY STATUS CLAIM pvc-6ced7d97-c0f4-4a82-a5f8-2337907fff0b 5Gi Bound vcluster-test/data-test-0 vcluster-task-pv-volume-x-vcluster-test-x-test 10Gi Availableدو PV داریم: یکی برای کنترل پلین و دیگری که تازه ساختیم.اگر همین آزمایش را برای مستأجر دوم تکرار کنیم چه می‌شود؟$ vcluster create test2 --set 'sync.persistentvolumes.enabled=true'دوباره همان pv.yaml را اعمال می‌کنیم (نام تکراری اما بدون مشکل):$ kubectl apply -f pv.yaml persistentvolume/task-pv-volume createdاز کلاستر خارج شده و PVها را در میزبان بررسی کنید:$ vcluster disconnect $ kubectl get pv NAME CAPACITY STATUS CLAIM pvc-131f1b41-7ed3-4175-a33d-080cdff41b44 5Gi Bound vcluster-test2/data-test2-0 pvc-6ced7d97-c0f4-4a82-a5f8-2337907fff0b 5Gi Bound vcluster-test/data-test-0 vcluster-task-pv-volume-x-vcluster-test-x-test 10Gi Available vcluster-task-pv-volume-x-vcluster-test2-x-test2 10Gi Availableهر مستأجر فقط یک PV را می‌بیند، اما کلاستر میزبان همه را می‌بیند!توجه کنید برای هر مستأجر ما یک پاد و یک PV داریم. حال برای اجرای یک خوشه برای 50 مستأجر به چه منابعی نیاز داریم؟یک خوشه با یک pool شامل نودی با 2GB RAM و 1 vCPU را در نظر بگیرید که یک نود دارد و Cluster Autoscaler هم روش نصب شده. سپس اسکریپت زیر را اگر اجرا کنید:#!/bin/bash for i in {1..50} do vcluster create "tenant-$i" --connect=false --upgrade doneکلاستر در نهایت روی 17 نود پایدار بر اساس تست‌های انجام شده استیبل می‌شود.از آنجایی که هر نود حدود 12 دلار در ماه هزینه دارد، مجموع حدود 204 دلار در ماه شد. همچنین 1 دلار در ماه برای حجم 10GB PV هزینه داریم. مجموع حدود 254 دلار در ماه یا تقریباً 5 دلار به ازای هر مستأجر در این حالت هزینه میبرد.اگر به دلایل قانونی نیاز به جداسازی ورک‌لود در کلاستر مجزا داشته باشید، چه؟یک گزینه دیگر داشتن یک خوشه اختصاصی برای هر مستأجر است.Hard multi-tenancy: dedicated clusters with Karmada:می‌توانید از Karmada برای مدیریت کلاستر مستأجران و استقرار ورک‌لودهای مشترک روی تمام کلاسترها استفاده کنید. معماری Karmada مشابه vCluster است:ابتدا، یک کنترل پلین مدیر (cluster manager) دارید که از چند کلاستر آگاه است.Karmadaمعمولاً آن را در یک کلاستر ویژه که ورک‌لودی اجرا نمی‌کند، مستقر می‌کنند.سپس Karmada از یک عامل (agent) استفاده می‌کند که دستورات را از کنترل پلین Karmada دریافت و به کلاستر محلی ارسال می‌کند.در نهایت چنین ترکیبی دارید:کنترل پلین Karmada می‌تواند ورک‌لود را روی همه کلاسترها اسکجول کند.هر کلاستر می‌تواند همچنان به صورت مستقل ورک‌لود اجرا کند.از میان تمام گزینه‌ها، این گران‌ترین حالت برای نگهداری و بهره‌برداری است.در آزمایش انجام شده 51 کلاستر (50 مستأجر و 1 مدیریت) با یک نود (1vCPU، 2GB) ساخته شده.همه کلاسترها منطقه‌ای (Regional) و بدون HA بودند و پلتفرم Akamai هزینه‌ای برای کنترل پلین‌ها دریافت نکرد. تنها هزینه، هزینه یک نود کاری (Worker) برای هر کلاستر بود.The total: 50$12=~$612/month or ~$12/tenant/month (the cost of the single node).Comparing multi-tenancy costs:سه گزینه‌ی چندمستأجری دارای سطوح جداسازی و هزینه‌های بسیار متفاوتی هستند. باید حواسمون باشه که مالتی تننسی رو باید برای تمام اعضای کلاستر در نظر بگیریم یعنی مانیتورینگ، لاگینگ، پایپلاین‌ها و غیره هم هستند.هزینه‌ها بسیار متفاوت است، اما توجه داشته باشید که همه گزینه‌های چندمستأجری مشابه هم نیستند.با استفاده از کلاسترهای جداگانه عملاً انتخابی ندارید: باید حداقل یک Ingress Controller اختصاصی به ازای هر خوشه داشته باشید — بنابراین گزینه‌های کمتری برای اشتراک و صرفه‌جویی در هزینه دارید.میزبانی چندین مستأجر در یک کلاستر Kubernetes مستلزم تعادل بین هزینه‌ها و جداسازی است.می‌توانید چندمستأجری نرم را با سربار کم انتخاب کنید، اما ریسک تأثیرگذاری یک مشکل روی همه‌ی مستأجران وجود دارد. یا می‌توانید جداسازی کامل را انتخاب کنید اما باید نصب، مدیریت و ارتقای کلاسترها را برای چندین تیم را بر عهده بگیرید. گزینه‌ی دیگر یک راه میانه است: یک خوشه مشترک با یک کنترل پلین اختصاصی برای هر مستأجر (مثل vCluster) که مقداری جداسازی همراه با هزینه‌های قابل مدیریت‌تر ارائه می‌دهد.در بلاگ پست‌های بعدی مسیرمون رو ادامه میدیم و بیشتر و بیشتر در مورد کوبرنتیز یاد می‌گیریم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 01 Feb 2025 11:50:42 +0330 https://virgool.io/@rafiee/%D8%AF%DB%8C%D8%B2%D8%A7%DB%8C%D9%86-%DA%A9%D9%84%D8%A7%D8%B3%D8%AA%D8%B1-%D9%82%D8%B3%D9%85%D8%AA-%D8%B3%DB%8C%D8%B2%D8%AF%D9%87%D9%85-vkhl4ztefprm تو قسمت سیزدهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم کنترل دسترسی تا اینکه ببینیم چجوری به کلاستر متصل میشیم و چه فرآیندی طی میشه.Cluster Designخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.طراحی کلاستر Kubernetes با قابلیت High Availability (HA)کوبرنتیز به عنوان یکی از محبوب‌ترین ابزارهای Orchestration کانتینرها شناخته می‌شود که مزایای بی‌شماری برای مقیاس‌پذیری، پایداری و خودبهبودی سیستم‌ها ارائه می‌دهد. با این حال، برای سازمان‌ها و کسب‌وکارهای مهم، قابلیت دسترسی بالا (High Availability) یک الزام اساسی محسوب می‌شود. در این مقاله، گزینه‌های مختلف برای طراحی یک کلاستر HA در کوبرنتیز بررسی و راه‌حل‌های عملی ارائه می‌شود.گزینه‌های طراحی کلاستر Kubernetes با HAدو مسیر اصلی برای طراحی کلاستر High Available در Kubernetes وجود دارد:توپولوژی Control Plane با etcd استک‌شده (Stacked etcd Topology)توپولوژی Control Plane با etcd خارجی (External etcd Topology)هر کدام از این گزینه‌ها مزایا و معایب خاص خود را دارند که باید با دقت بررسی شوند.1. توپولوژی Stacked etcdدر توپولوژی استک‌شده، سرویس ذخیره‌سازی توزیع‌شده etcd بر روی همان نودهایی که Control Plane کوبرنتیز اجرا می‌شود، قرار می‌گیرد.Stacked etcd topologyهر نود Control Plane، شامل سرویس‌های kube-apiserver، kube-scheduler و kube-controller-manager است.هر نود یک کپی محلی از etcd را اجرا می‌کند و تنها با kube-apiserver محلی خود ارتباط دارد.برای بارگذاری درخواست‌ها به kube-apiserver از یک لود بالانسر بیرونی استفاده می‌شود.مزایا:پیاده‌سازی ساده‌تر و مدیریت آسان‌تر نسبت به etcd خارجی.مناسب برای محیط‌هایی که منابع کمتری در اختیار دارند.معایب:وابستگی به Control Plane و etcd روی یک نود؛ اگر یک نود از دسترس خارج شود، هم etcd و هم Control Plane تحت تاثیر قرار می‌گیرد.نیاز به حداقل 3 نود Control Plane برای ایجاد یک ساختار HA پایدار.نکته: این توپولوژی به صورت پیش‌فرض در kubeadm اجرا می‌شود. متداول‌ترین روش پیاده‌سازی کوبرنتیز به صورت HA می‌باشد و معمولا از این روش استفاده می‌شود.2. توپولوژی External etcd:در این توپولوژی، سرویس etcd از نودهای Control Plane جدا شده و روی نودهای اختصاصی اجرا می‌شود:External etcd topologyهر نود Control Plane مانند توپولوژی استک‌شده سرویس‌های kube-apiserver، kube-scheduler و kube-controller-manager را اجرا می‌کند.نودهای etcd به صورت جداگانه اجرا شده و با kube-apiserver هر نود Control Plane ارتباط برقرار می‌کنند. یعنی apiserver با آنها ارتباط برقرار می‌کنه.مزایا:جداسازی Control Plane و etcd باعث کاهش وابستگی می‌شود.از بین رفتن یک نود Control Plane یا etcd تاثیر کمتری روی پایداری کلاستر دارد.معایب:نیاز به تعداد بیشتری از نودها (حداقل 3 نود Control Plane و 3 نود etcd).پیچیدگی بیشتر در پیاده‌سازی و نگهداری.معمولا جاهایی که دوست داریم نودهای مستر خودمون رو stateless کنیم از این ساختار استفاده می‌کنیم که باعث می‌شه بتونیم تنها کامپوننتی که state داره رو بیرون از نودهای مستر ستاپ کنیم. در اسکیل‌های بزرگ هم توجیه داره که این کار رو انجام بدیم. انتخاب تعداد کلاسترهای Kubernetes: چند کلاستر بهتر است یا یک کلاستر بزرگ؟اگر از Kubernetes به عنوان پلتفرم عملیاتی برای برنامه‌های خود استفاده می‌کنید، احتمالاً با پرسش‌هایی اساسی مواجه خواهید شد:چند کلاستر باید داشته باشیم؟کلاسترها چقدر بزرگ باشند؟چه چیزی باید در هر کلاستر قرار بگیرد؟در این مقاله به بررسی این پرسش‌ها می‌پردازیم و مزایا و معایب گزینه‌های مختلف را تحلیل می‌کنیم.Many Cluster vs Few Clusterتصویر بالا مزایا و معایب استفاده از هرکدوم از رویکردهای انتخاب تعداد بیشتر یا کمتری کلاستر رو نشون میده.به عنوان یک توسعه‌دهنده نرم‌افزار، معمولاً چندین برنامه را طراحی و اجرا می‌کنید. این برنامه‌ها ممکن است در محیط‌های مختلفی مانند dev و test و production اجرا شوند.این وضعیت به نوعی ماتریس برنامه‌ها و محیط‌ها منجر می‌شود. به عنوان مثال، اگر 3 برنامه و 3 محیط داشته باشید، در مجموع 9 نمونه برنامه (Application Instance) خواهید داشت.Application Instancesسوال اینجاست که:آیا همه نمونه‌های برنامه را در یک کلاستر واحد اجرا کنید؟یا برای هر نمونه از برنامه یک کلاستر جداگانه داشته باشید؟یا ترکیبی از این دو روش؟همه این گزینه‌ها قابل‌قبول هستند و Kubernetes محدودیتی برای این انتخاب‌ها ایجاد نمی‌کند!در ادامه، گزینه‌های موجود را بررسی می‌کنیم:یک کلاستر بزرگ و اشتراکیکلاسترهای کوچک تک‌منظورهکلاستر به ازای هر برنامهکلاستر به ازای هر محیطبه‌طور کلی، می‌توان گفت یک کلاستر زمانی "بزرگ‌تر" از کلاستر دیگر است که مجموع بیشتری از نودها و پادها را داشته باشد — برای مثال، کلاستری با ۱۰ نود و ۱۰۰ پاد از کلاستری با ۱ نود و ۱۰ پاد بزرگ‌تر است.cluster size۱. یک کلاستر بزرگ و اشتراکیدر این روش، تمام ورک‌لودها در یک کلاستر Kubernetes اجرا می‌شوند و از طریق Namespaceهای جداگانه از هم تفکیک می‌شوند.یک کلاستر بزرگ و اشتراکی✅ مزایا:استفاده بهینه از منابع: تنها یک نسخه از منابع مدیریتی مانند نودهای کنترل، لاگینگ، مانیتورینگ و ... نیاز است.کاهش هزینه‌ها: هزینه کمتری برای مدیریت کلاستر و زیرساخت‌ها پرداخت می‌شود.مدیریت ساده‌تر: به‌روزرسانی‌ها و تنظیمات کلاستر فقط یک بار انجام می‌شوند.❌ معایب:مشکل Single Point Of Failure: خرابی کلاستر کل بار کاری را متوقف می‌کند.نبود ایزوله‌سازی کامل: برنامه‌ها از منابع مشترک استفاده می‌کنند و ریسک امنیتی ایجاد می‌شود.مقیاس‌پذیری محدود: کلاسترهای Kubernetes نمی‌توانند به‌صورت بی‌نهایت بزرگ شوند.۲. کلاسترهای کوچک تک‌منظورهدر این روش، برای هر نمونه از برنامه یک کلاستر Kubernetes جداگانه اجرا می‌شود.کلاسترهای کوچک تک‌منظوره✅ مزایا:کاهش دامنه خرابی: خرابی هر کلاستر فقط روی بار کاری همان کلاستر تأثیر می‌گذارد.ایزوله‌سازی کامل: منابع سخت‌افزاری، شبکه و سرویس‌ها بین کلاسترها کاملاً جدا هستند.دسترسی محدودتر: تعداد افراد دارای دسترسی به هر کلاستر کمتر است.❌ معایب:مصرف غیربهینه منابع: هر کلاستر نیاز به نودهای مدیریتی و منابع اختصاصی دارد.هزینه بالا: اجرای چندین کلاستر هزینه بیشتری در پی دارد.مدیریت پیچیده‌تر: نیاز به فرآیندهای خودکار برای مدیریت به‌روزرسانی‌ها و تنظیمات چند کلاستر.۳. کلاستر به ازای هر برنامهدر این رویکرد، برای هر برنامه یک کلاستر جداگانه ایجاد می‌شود که تمام نمونه‌های برنامه (مانند نسخه Dev و Prod) در همان کلاستر اجرا می‌شوند.کلاستر به ازای هر برنامه✅ مزایا:سفارشی‌سازی کلاستر برای برنامه: هر کلاستر می‌تواند بر اساس نیازهای برنامه خاص، مانند نودهای GPU یا پلاگین‌های CNI، تنظیم شود.❌ معایب:اختلاط محیط‌ها: نسخه‌های Dev و Prod یک برنامه در همان کلاستر اجرا می‌شوند و خرابی نسخه توسعه می‌تواند نسخه تولید را تحت تأثیر قرار دهد.۴. کلاستر به ازای هر محیطدر این روش، به‌ازای هر محیط (مانند Dev، Test و Prod) یک کلاستر جداگانه ایجاد می‌شود که تمام برنامه‌های آن محیط در کلاستر مربوطه اجرا می‌شوند.کلاستر به ازای هر محیط✅ مزایا:ایزوله‌سازی محیط تولید: محیط تولید از مشکلات محیط‌های دیگر جداست و پایدارتر عمل می‌کند.سفارشی‌سازی محیط: می‌توان کلاسترها را بر اساس نیازهای هر محیط بهینه کرد.کنترل دسترسی به محیط تولید: می‌توان دسترسی به محیط تولید را محدود یا حتی حذف کرد.❌ معایب:نبود ایزوله‌سازی بین برنامه‌ها: برنامه‌های غیرمرتبط از منابع مشترک استفاده می‌کنند.عدم تمرکز نیازهای ویژه: اگر یک برنامه نیاز خاصی مانند GPU داشته باشد، تمام کلاسترها باید این نیاز را تأمین کنند.نتیجه‌گیریدر مجموع، می‌توانید از تعداد کمی کلاستر بزرگ یا تعداد زیادی کلاستر کوچک استفاده کنید. هرکدام از این روش‌ها مزایا و معایب خود را دارند.انتخاب بهترین رویکرد به نیازهای شما بستگی دارد:اگر به صرفه‌جویی در هزینه و مدیریت ساده‌تر اهمیت می‌دهید، یک کلاستر بزرگ گزینه مناسبی است.اگر ایزوله‌سازی و کاهش دامنه خرابی برایتان مهم است، استفاده از کلاسترهای کوچک‌تر بهتر خواهد بود.می‌توانید ترکیبی از این رویکردها را نیز استفاده کنید؛ برای مثال، می‌توانید دو کلاستر به ازای هر تیم داشته باشید: یک کلاستر برای توسعه و آزمایش و یک کلاستر برای تولید.با توجه به سناریوهای بالا، می‌توانید مناسب‌ترین ترکیب را برای کسب‌وکار خود انتخاب کنید.در بلاگ پست‌های بعدی مسیرمون رو ادامه میدیم و بیشتر و بیشتر در مورد کوبرنتیز یاد می‌گیریم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sun, 26 Jan 2025 00:23:34 +0330 https://virgool.io/@rafiee/%D9%87%D8%B4%D8%AA-%D8%B3%D8%A7%D9%84-%D9%BE%D8%B1-%D8%AA%D9%84%D8%A7%D8%B7%D9%85-%DA%A9%D9%86%D8%A7%D8%B1-%D8%AF%D8%A7%DA%A9%D8%B1%D9%85%DB%8C-ckwyqg0xxfwf سلام و درودامیدوارم که حال و اوضاع خوبی داشته باشید. تو این پست می‌خوام اتفاقات این ۸ سال گذشته داکرمی رو باهم مرور کنیم و یکم از حال و احوال این چند سال بگم. سایت قدیمی داکرمیاوایل سال ۹۶ بود که یک اتفاق هیجان‌انگیز و بزرگ توی زندگیم افتاد: آقا محمدعلی، پسرم، توی اردیبهشت‌ماه به دنیا اومد. حضوری که سال‌ها منتظرش بودیم و با اومدنش همه چیز تغییر کرد. از همون لحظه‌ای که وارد زندگی‌مون شد، دیگه هیچ‌چیز مثل قبل نبود. برنامه‌ریزی‌های سابق عملاً بی‌اثر شده بود، چون همه چیز به حال و هوای محمدعلی بستگی داشت. هر کاری که می‌خواستیم انجام بدیم، اول باید می‌دیدیم آیا با حضورش امکان‌پذیره یا نه. واقعیت اینه که وقتی یکی به خانواده اضافه می‌شه، حتی اگر کلی هم برای اومدنش برنامه‌ریزی کرده باشی، باز هم همه روندها رو عوض می‌کنه.یادم هست که در کارم داشتم پیشرفت می‌کردم، اما حضور محمدعلی باعث شده بود بخش زیادی از توجه و تمرکزم را به خودش اختصاص بدم. چیزی که دقیقاً خودم می‌خواستم! تعامل و وقت‌گذراندن با پسرم از همون اول برام خیلی جذاب بود و هنوز هم هست. تقریباً همون سال بود که یک گام بزرگ در کارم برداشتم؛ به نظر خودم، وجود محمدعلی و انرژی‌ای که از حضورش گرفتم، تأثیر زیادی در این پیشرفت داشت. سال ۹۶، حدوداً اواسط سال، سایت داکرمی رو راه‌اندازی کردم تا آموزش آنلاین رایگان و باکیفیت ارائه بدم. هدفی که مدت‌ها تو ذهنم بود ولی تا اون زمان انجامش نمی‌دادم.تولید محتوای فارسیوضعیت تولید محتوای فارسی:یادم هست اون زمان‌ها تولید محتوا خیلی رایج نبود. خیلی‌ها اصلاً سمتش نمی‌رفتند و محتوای فارسی ارزشمند خیلی کم بود. یکی از دوستان نزدیکم، آقا مرتضی باشسیز، که حالا دیگه همه می‌شناسند و کلی ازش یاد گرفته‌اند، تازه سایت آموزش لینوکس رایگان رو راه‌اندازی کرده بود و داشت اونجا محتوا می‌گذاشت. مرتضی همیشه در این مسیر برای من الهام‌بخش بوده و هست، و تأثیر زیادی روی کارهای من داشته. حدود یک سال و نیم تولید محتوای داکر رو تو سایت داکرمی انجام دادم. بعدش آقا محمدحسین، پسر دومم، به دنیا اومد. حضور محمدحسین دوباره نظم زندگی و مسیر کاری من رو دچار تلاطم کرد. با این حال، از اومدنش خیلی خوشحال بودیم و روزگار شیرینی داشتیم. تقریباً همون موقع‌ها بود که یواش‌یواش همه سازمان‌ها به سمت داکر می‌رفتند و صدای داکرمی هم به گوششون رسیده بود. یادمه سال ۹۸ پر از تجربه‌های پروژه‌های کوچک و بزرگ و تدریس‌های سازمانی داکر بود؛ تجربه‌هایی که همچنان ادامه دارند.حادثه‌ای که بعد از اون دیگه حالمون خوب نشددوران تاریکی که بعدش دیگه روشن نشدتو این سال‌ها با مشکلات و معضلات متعددی روبه‌رو شدم. از سال ۱۳۹۸ تا ۱۴۰۲، دوره‌ای بود که پر از اتفاقات سنگین و تلخ بود؛ اتفاقاتی که خیلی از شما هم درگیرش بودید. از قطع شدن‌های مکرر اینترنت گرفته تا سقوط هواپیمای اوکراینی، اعتراضات مختلف، اتفاقاتی که حال‌ و هوای هممون رو خراب کرد. افسردگی‌ای که کم‌وبیش همه رو درگیر خودش کرد. منی که داشتم مسیر خودم رو طی می‌کردم، این بار با مسائلی مواجه شدم که اصلاً تو حوزه اختیارات من نبود و نمی‌دونستم باید باهاشون چی کار کنم. خیلی اذیت شدم، طوری که شاید بشه گفت دو سال کامل رو از دست دادم. هیچ کاری نکردم، فقط تماشا کردم، غصه خوردم و سوختم.منی که نمی‌خواستم برم و تصمیم گرفته بودم بمونم، حالا با مشکلی روبه‌رو شده بودم که هیچ راه‌حلی براش نداشتم. به افسردگی عمیقی دچار شدم که اگر همسرم کنارم نبود و کمکم نمی‌کرد، شاید مسیر زندگیم کاملاً عوض می‌شد... شاید دیگه نبودم که ادامه بدم و همه چیز کلاً تمام می‌شد.فرصت آموزشی برابر برای همه فرصت آموزشی برابر برای همه در همین حوالی بود که با همان ایده اولیه داکرمی، یعنی فرصت آموزشی برابر برای همه، همکاری‌ام را با آروان شروع کردم. نتیجه این همکاری، پروژه موفق و دوست‌داشتنی آروان آکادمی شد؛ جایی که محتوای گران و ارزشمند دواپس با کیفیت بالا و به‌صورت رایگان در اختیار همه قرار گرفت. این آکادمی مثل یک کورسوی امید بود در دل تاریکی‌هایی که گرفتارش شده بودم. همین نور کوچک توانست حال من را عوض کند و کمک کرد که دوباره به مسیر اصلی خودم برگردم؛ مسیری که دوستش داشتم و برایش خیلی زحمت کشیده بودم. از پویا پیرحسین‌لو واقعاً ممنونم که از این پروژه حمایت کرد و کمک کرد آروان آکادمی جایی بشه که هر فردی، در هر نقطه‌ای از ایران، اگر بخواد رشد کنه و دواپس یاد بگیره، بتونه به اون دسترسی داشته باشه.شروعی دوبارهشروعی دوبارهبا حمایت همسرم و خانواده‌ام، حال و اوضاعم کم‌کم بهتر شده بود، و دوباره به یک تصمیم بزرگ رسیدم؛ تصمیمی که شاید پنج سال رهایش کرده بودم. این بار اما مصمم‌تر از همیشه بودم و جرأت انجامش را پیدا کردم. از ابتدای سال ۱۴۰۳ تصمیم گرفتم دیگر با هیچ شرکتی قرارداد کاری نبندم و فقط به مشاوره با چند شرکت بسنده کنم. تمام تمرکز و انرژی‌ام را روی داکرمی گذاشتم. امسال برای اولین بار به سمت کار تمام‌وقت برای خودم رفتم. دفتر گرفتم و چند همکار پرانرژی و جوان که کمک بزرگی به من کردند. حضور آن‌ها و ایده‌های تازه‌ای که از ذهن خلاق و پر انرژی‌ آنها می‌آمد، باعث شد نه‌تنها از حال و هوای قبلی فاصله بگیرم، بلکه تا اینجا با موفقیت جلو بیاییم.امروز روز قشنگی بود! بعد از ۸ سال، سایت جدید داکرمی را بالا آوردیم. این اتفاق برای من خیلی الهام‌بخش بود و مسیری که در آن هستم را زیباتر و انگیزه‌بخش‌تر کرد. هدف ما در داکرمی برای ۵ سال آینده اینه که بتونیم با انجام پروژه‌های مختلف، مسیر اصلی درآمدمان را بسازیم و در کنار آن، آموزش رایگان دواپس را ارائه بدیم تا همه بتونن این مسیر را طی کنند و متخصص شوند. اما ما فقط به آموزش بسنده نمی‌کنیم. می‌خواهیم کنار هم راه بیاییم (آموزش‌های راه‌بیا) و یاد بگیریم چطور پروژه‌های واقعی انجام بدهیم و رشد کنیم. این مسیری است که ما را نه‌تنها حرفه‌ای‌تر، بلکه قوی‌تر و به‌هم نزدیک‌تر خواهد کرد.اینجا لازمه که حتما از حمایت‌های دوست عزیزم حسین آیت تشکر کنم که همیشه تمام قد از من و ایده‌هایی که داشتم حمایت کرده و بهم مشورت‌های کارگشا داده. حسین مثل یک چراغ همیشه مسیر پیش روی من رو روشن کرده و راهنمای خیلی خوبی برای من بوده.در این مسیر جدید، در حال گفتگو با شرکت‌های مختلف هستیم تا بتوانیم حمایت آن‌ها را جذب کنیم و این مسیر جذاب را با قدرت بیشتری پیش ببریم. کلی ایده‌های جذاب و هیجان‌انگیز داریم که با سرمایه‌هایی که جذب می‌کنیم، می‌خواهیم آن‌ها را عملی کنیم. اما مهم‌ترین حمایت‌کننده این مسیر، شما هستید! اگر شما از ما حمایت کنید، قطعاً می‌تونیم رشد کنیم و به ایده‌هایی که داریم برسیم. بزرگ‌ترین حمایتی که می‌تونید انجام بدید، استفاده از محتوای تولیدی ما، ثبت نظرات ارزشمندتان و به اشتراک‌گذاری آن‌هاست. همین کارهای کوچک، تأثیری بزرگ در پیشرفت ما دارند.سایت جدید و کانال یوتوب داکرمی را ببینید و مثل همیشه نظرهایتان را با ما به اشتراک بگذارید. با کمک شما، می‌توانیم کنار هم آینده‌ای جذاب‌تر و بهتر بسازیم.با ما متخصص شوید. احمد رفیعی احمد رفیعی Sat, 18 Jan 2025 01:12:31 +0330 https://virgool.io/@rafiee/%DA%A9%D9%86%D8%AA%D8%B1%D9%84-%D8%AF%D8%B3%D8%AA%D8%B1%D8%B3%DB%8C-%D8%A8%D9%87-%DA%A9%D9%88%D8%A8%D8%B1-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D8%A7%D8%B2%D8%AF%D9%87%D9%85-mzuunvhfo8s4 تو قسمت دوازدهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم کنترل دسترسی تا اینکه ببینیم چجوری به کلاستر متصل میشیم و چه فرآیندی طی میشه.Kubernetes API access controlخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.Kubernetes API Control Accessکنترل دسترسی به API کوبرنتیزکنترل دسترسی به API کوبرنتیز از اهمیت ویژه‌ای برخوردار است، چرا که تضمین می‌کند تنها کاربران و برنامه‌های مجاز به منابع حساس دسترسی پیدا کنند. این فرآیند شامل مراحل احراز هویت، مجوزدهی، کنترل پذیرش و ممیزی است. در ادامه، هر مرحله با جزئیات بیشتر و به زبان ساده توضیح داده شده است.Kubernetes API Control Access Stepsهمانطور که در تصویر بالا میبینید کاربر برای دسترسی گرفتن به api کوبرنتیز از سه مرحله احراز هویت، مجوزدهی و کنترل پذیرش عبور می‌کند که در ادامه هر مورد را توضیح میدهیم.احراز هویت (Authentication)احراز هویت اولین مرحله از فرآیند کنترل دسترسی است که هدف آن شناسایی کاربر یا برنامه‌ای است که درخواست ارسال کرده است. پس از برقراری ارتباط امن TLS، درخواست HTTP به این مرحله وارد می‌شود.Kubernetes Authenticationادمین کلاستر یا اسکریپت ساخت کلاستر تنظیمات لازم را برای اجرای یک یا چند ماژول احراز هویت در api-server اعمال می‌کند. ورودی این مرحله، کل درخواست HTTP است، اما معمولاً فقط بخش‌هایی مثل هدرها یا گواهی‌نامه کلاینت بررسی می‌شوند.ماژول‌های احراز هویت شامل موارد زیر هستند:- گواهی‌نامه‌های کلاینت (Client Certificates): این گواهی‌ها برای شناسایی امن کلاینت‌ها استفاده می‌شوند.- رمز عبور و توکن‌های ساده: برای دسترسی سریع به منابع کاربرد دارند.- توکن‌های بوت‌استرپ: برای ارتباطات اولیه در کلاستر استفاده می‌شوند.- توکن‌های وب (JWT): این توکن‌ها معمولاً برای حساب‌های کاربری سرویس‌ها به کار می‌روند.در صورت پیکربندی چند ماژول احراز هویت، هر ماژول به ترتیب بررسی می‌شود تا یکی از آنها موفق به احراز هویت شود. اگر هیچ ماژولی نتواند درخواست را تایید کند، درخواست با کد وضعیت HTTP 401 رد می‌شود. به زبان ساده، اگر سیستم نتواند کاربر را شناسایی کند، به او اجازه ادامه کار نمی‌دهد. همان‌طور که بالاتر گفتم می‌تونیم چندین ماژول برای احراز هویت کاربر به صورت همزمان داشته باشیم. هم می‌تونیم وصلش کنیم به SSO خودمون هم با کلاینت سرتیفیکیت و توکن به افرادی دسترسی بدیم. کوبرنتیز یا بهتر بگیم api-server هم‌زمان همه‌ی آنها رو بررسی می‌کنه و اگر با یکی تونست تایید کنه به کاربر اجازه می‌ده که لاگین کنه.مجوزدهی (Authorization)بعد از احراز هویت، نوبت به مجوزدهی می‌رسد. در این مرحله، بررسی می‌شود که آیا کاربر مجاز به انجام عملی است که درخواست داده است یا خیر. درخواست باید شامل اطلاعات زیر باشد:- نام کاربری: کاربری که درخواست را ارسال کرده است.- عملیات: کاری که کاربر قصد انجام آن را دارد (مثلاً ایجاد یا حذف یک پاد).- منبع: آبجکت یا منبعی که قرار است عملیات روی آن انجام شود.authorization modesمجوزدهی در کوبرنتیز از طریق چندین ماژول انجام می‌شود که شامل موارد زیر هستند:- (مجوزدهی نود) Node Authorization: این روش برای مجوزدهی درخواست‌های ارسال شده توسط kubelet‌ها طراحی شده و به کاربران معمولی مربوط نمی‌شود.Node Authorization- (کنترل دسترسی مبتنی بر ویژگی) ABAC : در این روش، سیاست‌ها بر اساس ویژگی‌های کاربر یا درخواست تعریف می‌شوند. این روش قدیمی شده و به جای آن از RBAC استفاده می‌شه که در ادامه توضیح می‌دیم.ABAC- (کنترل دسترسی مبتنی بر نقش) RBAC : دسترسی‌ها بر اساس نقش‌هایی که به کاربران اختصاص داده شده است مدیریت می‌شوند. روش خیلی مرسوم و متداولی که سرویس‌های دیگه هم ازش استفاده می‌کنند. ما دسترسی‌ها رو به roleها می‌دیم و role ها رو به کاربرها و آدم‌ها متصل می‌کنیم. نقش اصلی کنترل دسترسی تو کوبرنتیز بر عهده‌ی RBAC هست و معمولا همه از آن استفاده می‌کنند.RBAC- روش Webhook: در این روش، درخواست‌ها به یک سرویس خارجی ارسال می‌شوند تا تایید شوند.Webhook- (همیشه مجاز) AlwaysAllow: تمامی درخواست‌ها را بدون بررسی تایید می‌کند (برای محیط‌های توسعه مناسب است). البته که همون محیط توسعه هم باید با دسترسی منطقی و درستی کار بکنه تا بتونه روی پروداکشن به خوبی استقرار پیدا کنه. کلا چیز خوبی نیست که همه چیز رو allow کنیم. بهتره با محیط تست و تمرین کنیم که قراره بعدا باهاش مواجه بشیم.- (همیشه رد)AlwaysDeny: تمامی درخواست‌ها را بدون بررسی رد می‌کند (برای محیط‌های بسیار امن مناسب است). اینم بگم که کاربردی نیست اونقدر بالاخره نیاز داریم که یکی یا چیزی با سیستم و سرویس‌ کار کنه. برای همین نه به اون بی نمکی قبلی و نه به این شوری این.کی تصمیم می‌گیره؟مدیر کلاستر مشخص می‌کند که کدام یک از این ماژول‌ها فعال باشند. اگر چند ماژول مجوزدهی فعال باشد، کوبرنتیز درخواست را به ترتیب به هر ماژول ارسال می‌کند. اگر یکی از ماژول‌ها درخواست را تایید کند، عملیات مجاز خواهد بود. در غیر این صورت، درخواست با کد وضعیت HTTP 403 رد می‌شود. دقت کنید یکی از اون چند تا اگر اوکی باشه اکسپت می‌کنه و درخواست رو اعمال می‌کنه. ممکنه موقعیتی پیش بیاد که یه درخواست با یکی از این ابزارها و سیستم‌ها اوکی باشه و با یکی دیگه نه ولی چون اجتماع آنها هست با هر کدوم که اوکی بشه روال می‌کنه و کوبرنتیز درخواست رو اوکی می‌کنه. این موضوع هم تو احراض هویت و هم تو اعمال دسترسی برقرار هست.پیکربندی حالت‌های مجوزدهیConfigure Authorization Modesبرای پیکربندی حالت‌های مجوزدهی در کوبرنتیز، فایل تنظیمات kube-apiserver.yaml را ویرایش کنید که معمولاً در مسیر /etc/kubernetes/manifests/ قرار دارد. در این فایل، حالت‌های مجوزدهی مورد نظر خود را به پرچم --authorization-mode اضافه کنید و حالت‌ها را با کاما جدا کنید.مثال:--authorization-mode=RBAC,Webhookپس از اعمال تغییرات، سرور API را ری‌استارت کنید تا تغییرات اعمال شوند.استفاده از چندین حالت مجوزدهیMultiple Authorization Modesکوبرنتیز این امکان را فراهم می‌کند که چندین حالت مجوزدهی به صورت همزمان فعال شوند. در این حالت، هر درخواست به ترتیب توسط تمامی حالت‌ها بررسی می‌شود تا یکی از آنها درخواست را تایید یا رد کند. اگر تمامی حالت‌ها درخواست را رد کنند، دسترسی داده نمی‌شود.کنترل پذیرش (Admission Control)کنترل پذیرش مرحله‌ای است که پس از مجوزدهی اجرا می‌شود. در این مرحله، درخواست‌ها ممکن است تغییر داده شوند یا رد شوند. ماژول‌های کنترل پذیرش به درخواست‌هایی که برای ایجاد، تغییر، حذف، یا اتصال به یک آبجکت هستند، پاسخ می‌دهند. اما به درخواست‌هایی که صرفاً برای خواندن اطلاعات هستند، توجهی نمی‌کنند.Admission Controlکنترل‌کننده‌های پذیرش به دو دسته تقسیم می‌شوند:- کنترل‌کننده‌های تغییر‌دهنده (Mutating Admission Controllers): این کنترل‌کننده‌ها درخواست‌ها را قبل از پردازش تغییر می‌دهند. به عنوان مثال، کنترل‌کننده ServiceAccount به صورت خودکار یک حساب کاربری سرویس پیش‌فرض به پاد اضافه می‌کند. با mutations ما می‌تونیم درخواست رو تغییر بدیم. مثلا اینکه دیفالت سرویس اکانت رو به پادها اضافه کنیم.- کنترل‌کننده‌های اعتبارسنجی (Validating Admission Controllers): این کنترل‌کننده‌ها درخواست‌ها را بررسی می‌کنند تا اطمینان حاصل شود که با قوانین تعیین شده مطابقت دارند.ممیزی (Auditing)ممیزی در کوبرنتیز ابزاری است که یک مجموعه زمانی از رویدادهای امنیتی را ثبت می‌کند. این رویدادها شامل فعالیت‌های کاربران، برنامه‌ها، و خود سیستم کنترل مرکزی می‌شوند. رکوردهای ممیزی اطلاعات مهمی مانند زمان، مکان، و نوع عملیات را مستند می‌کنند. به عبارت دیگه تمام عملکردی که داخل کوبرنتیز در جریان است رو می‌تونیم با استفاده از Audit لاگ کنیم و به زبان ساده Audit log کوبرنتیز رو داشته باشیم و درست کانفیگ کرده باشیم می‌تونیم تمام اتفاقاتی که تو کلاستر افتاده رو با جزئیات کامل بدونیم. برای همین خیلی نقش کلیدی و مهمی برای بررسی رخدادهای داخل کلاستر کوبرنتیز داره.به طور کلی، ممیزی به سوالات زیر پاسخ می‌دهد:چه اتفاقی افتاد؟چه زمانی اتفاق افتاد؟چه کسی آن را آغاز کرد؟بر روی چه چیزی انجام شد؟از کجا مشاهده شد؟از کجا آغاز شد؟به کجا رفت؟Kubernetes Auditingسطوح ممیزیکوبرنتیز چندین سطح برای ثبت رویدادها ارائه می‌دهد:سطح None: هیچ رویدادی ثبت نمی‌شود.سطح Metadata: فقط متادیتای درخواست (مانند کاربر درخواست‌کننده، زمان، منبع، و فعل) ثبت می‌شود.سطح Request: متادیتای رویداد به همراه بدنه درخواست ثبت می‌شود.سطح RequestResponse: متادیتای رویداد، بدنه درخواست، و بدنه پاسخ ثبت می‌شوند.هر کدوم از این سطوح رو می‌تونیم بر اساس فعلی (Create,Delete,Get,...) که انجام می‌شه و کسی که انجام می‌ده داخل آدیت لاگ داشته باشیم. به این نکته توجه کنید که تو کلاسترهای بزرگ حجم این لاگ خیلی می‌تونه زیاد بشه و اگر درست کانفیگ نشه حتی می‌تونه که api-serverها رو با مشکل مواجه کنه. برای همین باید دقیق بدونیم که برای کجا می‌خواهیم اون رو فعال کنیم و سطح آن رو هم کامل مشخص کنیم. مثلا افعال get,watch,list عموما زیاد مهم نیست که بدونیم کی انجام داده. در اکثر اوقات می‌تونی این افعال رو none بزاریم تا بتونیم حجم لاگ و میزان اون رو منطقی کاهش بدیم.کنترل دسترسی به API کوبرنتیز یک فرآیند چندمرحله‌ای است که امنیت و مدیریت دسترسی را تضمین می‌کند. با استفاده از احراز هویت، مجوزدهی، کنترل پذیرش، و ممیزی، می‌توان دسترسی به منابع کلاستر را به طور دقیق مدیریت کرد. این مراحل به مدیران امکان می‌دهند تا با اطمینان بیشتری منابع حساس را محافظت کنند و دسترسی‌ها را بر اساس نیازهای خاص تنظیم کنند.Kubernetes RBACکنترل دسترسی مبتنی بر نقش (RBAC) در کوبرنتیزکنترل دسترسی مبتنی بر نقش یا RBAC (Role-Based Access Control) یکی از کلیدی‌ترین ابزارهای امنیتی در کوبرنتیز است که اطمینان می‌دهد کاربران و ورک‌لودها فقط به منابعی دسترسی داشته باشند که برای اجرای وظایفشان نیاز دارند. این مکانیزم به مدیریت دقیق سطوح دسترسی کمک می‌کند و از دادن مجوزهای غیرضروری به کاربران جلوگیری می‌نماید.Kubernetes RBACمعرفی آبجکت‌های RBACدر RBAC چهار نوع آبجکت اصلی تعریف می‌شود:RoleClusterRoleRoleBindingClusterRoleBindingاین آبجکت‌ها را می‌توان مانند سایر منابع کوبرنتیز با ابزارهایی مانند kubectl مشاهده و ویرایش کرد.Role and RoleBindingآبجکت‌های Role و ClusterRole به عنوان مجموعه‌ای از قوانین دسترسی تعریف می‌شوند که اجازه‌ی دسترسی به منابع خاص را مشخص می‌کنند. توجه داشته باشید که مجوزهای RBAC فقط افزایشی هستند؛ یعنی امکان تعریف قانون «رد کردن دسترسی» وجود ندارد. این نکته‌‌ی خیلی مهمی است که باید بهش دقت کنیم. به زبان ساده با role و clusterrole ما داریم می‌گیم چه ریسورسی (مثلا پاد یا سرویس یا هرچی ) چه فعلی (مثلا ساختن یا پاک کردن یا ادیت کردن یا هر چی) رو داشته باشیم. اینجا فقط این دو تا رو داریم مشخص می‌کنیم.Role:یک Role همیشه مجوزهای دسترسی را فقط در فضای نام (Namespace) مشخص‌شده تنظیم می‌کند. به همین دلیل هنگام ایجاد Role باید حتماً فضای نام مربوط به آن را مشخص کنید.RBAC Roleمثال ایجاد یک Role در نیم‌اسپیس dev:apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"]در مثال فوق، Role مجوز مشاهده و لیست‌کردن Podها را در فضای نام dev فراهم می‌کند.Role and RoleBindingCluster Role:آبجکت ClusterRole برخلاف Role، به صورت غیرمربوط به فضای نام (Cluster-wide) تعریف می‌شود و می‌تواند دسترسی به منابع در کل کلاستر را کنترل کند.مثال تعریف یک ClusterRole:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: node-reader rules: - apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"]در اینجا، ClusterRole مجوز مشاهده و لیست کردن Nodeها را در سطح کل خوشه فراهم می‌کند.RoleBinding:آبجکت RoleBinding یک Role را به یک یا چند موضوع (Subjects) مانند کاربرها، گروه‌ها یا حساب‌های کاربری سرویس (ServiceAccounts) متصل می‌کند. ما تو رول تعریف کردیم چه ریسورسی رو چی کار بتونیم بکنیم و با رول بایندینگ اون رو به یه کاربر یا گروه یا سرویس‌ اکانت متصل می‌کنیم.RBAC Role Bindingآبجکت RoleBinding مجوزهای مربوط به Role را در فضای نام مشخصی به موضوعات (subject) می‌دهد. همچنین می‌تواند به ClusterRole اشاره کند و مجوزهای مربوط به ClusterRole را به یک فضای نام خاص محدود کند.نمونه RoleBinding:apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods-binding namespace: dev subjects: - kind: User name: mamad apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.ioدر مثال فوق، کاربر mamad می‌تواند Podها را در فضای نام dev بخواند.ClusterRoleBindingآبجکت ClusterRoleBinding دقیقاً مانند RoleBinding عمل می‌کند، اما مجوزهای ClusterRole را در کل کلاستر (Cluster-wide) به موضوعات مشخص‌شده اعطا می‌کند.ClusterRoleBindingمثال:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: node-reader-binding subjects: - kind: User name: admin apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: node-reader apiGroup: rbac.authorization.k8s.ioدر این مثال، کاربر admin مجوز مشاهده Nodeها در کل کلاستر را دریافت می‌کند.پس عملا اینجا ما با دو تا موضوع مواجه هستیم یکی در سطح یک namespace و یکی در سطح کل کلاستر که هر دو عملکرد یکسان هست ولی حوزه‌ی فعالیتشون باهم متفاوت است.ServiceAccountیک سرویس اکانت هویتی برای فرآیندهایی که در Podها اجرا می‌شوند فراهم می‌کند.ServiceAccountزمانی که به API Server کوبرنتیز احراز هویت می‌کنید، خود را به عنوان یک کاربر مشخص معرفی می‌کنید. با این حال، کوبرنتیز خودش دارای یک User API نیست و هویت کاربران معمولاً در یک سیستم خارجی مدیریت می‌شود.مثال تعریف ServiceAccount:apiVersion: v1 kind: ServiceAccount metadata: name: my-service-account namespace: devسپس می‌توانید این ServiceAccount را به یک Pod اختصاص دهید:apiVersion: v1 kind: Pod metadata: name: example-pod namespace: dev spec: serviceAccountName: my-service-account containers: - name: my-container image: my-imageدر اینجا، Pod با استفاده از my-service-account احراز هویت خواهد شد.کنترل دسترسی مبتنی بر نقش (RBAC) در کوبرنتیز یکی از مهم‌ترین ابزارهای مدیریت امنیتی است که به شما اجازه می‌دهد دسترسی‌های دقیقی برای کاربران و فرآیندهای مختلف تعریف کنید. با استفاده از Role، ClusterRole، RoleBinding و ClusterRoleBinding می‌توان سطوح دسترسی مناسب در نیم‌اسپیس یا در کل کلاستر ایجاد کرد.با طراحی مناسب RBAC می‌توانید به امنیت و کارایی بیشتر در مدیریت منابع کوبرنتیز دست پیدا کنید.در بلاگ پست‌های بعدی مسیرمون رو ادامه میدیم و بیشتر و بیشتر در مورد کوبرنتیز یاد می‌گیریم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 11 Jan 2025 10:35:42 +0330 https://virgool.io/@rafiee/%D8%A7%D9%88%D9%84%D9%88%DB%8C%D8%AA-%D9%BE%D8%A7%D8%AF-%D9%88-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D9%82%D8%B3%D9%85%D8%AA-%DB%8C%D8%A7%D8%B2%D8%AF%D9%87%D9%85-prwu2rdionpu تو قسمت یازدهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم تعیین اولویت برای پادها و بررسی می‌کنیم که امنیت در سطوح مختلف چطور برای کوبرنتیز تعریف میشه.Pod Priorityخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.priority and preemptionتوی کوبرنتیز، هر پاد نماینده مجموعه‌ای از کانتینرهای اجرایی است. گاهی تعداد منابع در دسترس (مثل CPU و RAM) برای اجرای همه پادها کافی نیست. در این شرایط، مفهوم اولویت پدیدار می‌شود تا اسکجولر تشخیص دهد کدام پادها مهم‌تر هستند یا باید در زمان ازدحام منابع، حتماً اجرا شوند.هنگامی که پادی با اولویت بالا در صف اسکجولینگ است اما منابع کافی برای اجرای آن وجود ندارد، اسکجولر سعی می‌کند با متوقف کردن یا حذف موقت پادهای کم‌اهمیت‌تر، منابع لازم را آزاد کند. به این فرآیند Preemption می‌گویند. با این کار، از منابع محدود موجود به شکلی هوشمندانه‌تر استفاده می‌شود و پادهایی که برای عملکرد کل سیستم یا اپلیکیشن حیاتی هستند، در اولویت قرار می‌گیرند. البته تمام این اولویت‌ها توسط ما ایجاد و مدیریت می‌شه و دست خودمون هست. نکته‌ی دیگه اینکه اسکجولر برای جانمایی پاد‌ها روی نودهای کلاستر یه صفی داره و بررسی می‌کنه که اگر توی صفش یه پاد با اولویت بالایی وجود داشته باشه و براش جا نباشه سعی می‌کنه با جابه‌جایی پادهای کم اهمیت فضا رو برای استقرار پاد با اولویت بالاتر فراهم کنه.پاد‌ها می‌توانند اولویت داشته باشند. اولویت نشان‌دهنده اهمیت یک پاد نسبت به سایر پادها است. اگر یک پاد نتواند Schedule شود، Scheduler تلاش می‌کند پادهای با اولویت پایین‌تر را برکنار (Preempt) کند تا شرایط برای زمان‌بندی پاد در حال انتظار فراهم گردد.pod priorityوقتی اولویت پاد فعال باشد، Scheduler پادهای در حال انتظار را بر اساس اولویت آن‌ها مرتب می‌کند و یک پاد در حال انتظار با اولویت بالاتر را در صف زمان‌بندی جلوتر از پادهای دیگر با اولویت کمتر قرار می‌دهد. به همین دلیل، اگر نیازمندی‌های زمان‌بندی یک پاد با اولویت بالا برآورده شوند، ممکن است این پاد زودتر از پادهای با اولویت پایین‌تر زمان‌بندی شود. اگر چنین پادی نتواند اسکجول شود، مثلا نودی که منابع کافی داشته باشه رو پیدا نکنه اسکجولر برای این پاد، آنگاه اسکجولر ادامه داده و سعی می‌کند سایر پادهای با اولویت پایین‌تر را جابه‌جا نماید.وقتی پادها ایجاد می‌شوند، ابتدا وارد یک صف شده و منتظر زمان‌بندی (Scheduling) می‌مانند. اسکجولر یکی از پادها را از صف انتخاب کرده و تلاش می‌کند آن را روی یک Node مستقر کند. اگر هیچ نودی یافت نشود که تمام نیازمندی‌های مشخص‌شده پاد را برآورده سازد، Preemption برای پاد در انتظار فعال می‌شود.در این سناریو، پادی که در انتظار زمان‌بندی است را پاد P بنامیم. منطق Preemption تلاش می‌کند یک نود بیابد که با حذف یک یا چند پاد با اولویت پایین‌تر نسبت به P، امکان زمان‌بندی P روی آن نود فراهم شود. اگر چنین نودی پیدا شود، یک یا چند پاد با اولویت پایین‌تر از روی آن نود خارج (evict) می‌شوند. پس از حذف این پادها، P می‌تواند روی آن گره زمان‌بندی شود.Priority and Priority Class:priority classدر کوبرنتیز PriorityClass یک آبجکت بدون فضای نام (non-namespaced) است که یک نگاشت از نام کلاس اولویت به مقدار عددی اولویت ایجاد می‌کند. نام این آبجکت در فیلد name مربوط به metadata آن مشخص می‌شود. مقدار اولویت در فیلد اجباری value تعیین می‌گردد. هر چه مقدار بالاتر باشد، اولویت بیشتر است. نام یک آبجکت PriorityClass باید یک نام زیردامنه‌ی معتبر DNS باشد و نباید با -system شروع شود.با استفاده از این ساختار ما مشخص می‌کنیم که اولویت پادهامون به چه صورت است که در زمان قرارگرفتن روی نود و بلند شدن از روی نود اولویت آنها مشخص شود. به صورت کلی پادها با اولویت بالا آخر از همه از روی نودها بلند می‌شوند و همواره اول از همه روی نودها قرار می‌گیرند. مثال بزنم براتون مثلا نود شما به کلاستر اضافه شده. خیلی مهمه که پادهای مربوط به نتورک و استوریج و این چنین موارد اول روی آن نود ایجاد و استقرار پیدا کنه تا بقیه پادها. چون مابقی پادها برای عملکرد درست خود به این پاد‌ها نیاز دارند.ابتدا Kubelet کلاس QoS و سپس مقدار اولویت پاد را برای حذف پادها در نظر می‌گیرد. این امر تنها زمانی اتفاق می‌افتد که در نودها کمبود منابع وجود داشته باشد.با این حال، منطق Preemption تنها زمانی فعال می‌شود که پادهای با اولویت بالا در صف زمان‌بندی (Scheduling Queue) باشند. در فرایند Preemption، زمان‌بند رتبه QoS پاد را نادیده می‌گیرد. در حالی که حذف مبتنی بر QoS بدون نیاز به صف زمان‌بندی، تنها به‌دلیل کمبود منابع انجام می‌شود.فرآیند Node-pressure eviction فرآیندی است که طی آن kubelet به‌صورت پیشگیرانه پادها را برای بازیابی منابع بر روی نودها خاتمه می‌دهد. منابع اون نود داره تموم می‌شه و با این شرایط عملکرد و کارایی اون نود هم با مشکل مواجه می‌شه برای همین برخی از پادها رو جابه جا می‌کنه تا بتونه روی اون نود فضا خالی کنه.مثلا kubelet منابعی مانند CPU، حافظه، فضای دیسک و inode سیستم فایل را در نودهای کلاستر شما پایش می‌کند. هنگامی که یک یا چند مورد از این منابع به سطح خاصی از مصرف برسند، kubelet می‌تواند به‌صورت پیشگیرانه یک یا چند پاد روی آن نود را از کار بیندازد تا منابع را بازیابی کرده و از بروز کمبود جلوگیری کند. به صورت نگاه بالا و از سمت اطاق فکر کوبرنتیز نگاه کنیم یه نود داره منابعش تموم می‌شه برای این که بتونه ادامه‌ی کارایی خودش رو داشته باشه پادهای با اولویت پایین‌تر رو جابه جا می‌کنه و روی نودهای دیگه بالا میاره تا عملکرد نود از بین نره.نکته دیگه اینکه kubelet تلاش می‌کند قبل از خاتمه دادن به پادهای کاربران نهایی، منابع سطح نود را بازیابی کند. برای مثال، زمانی که منابع دیسک محدود شده باشند، ابتدا ایمیج‌های بلااستفاده کانتینرها را حذف می‌کند.حذف از طریق API (API-initiated eviction) فرآیندی است که در آن شما با استفاده از Eviction API، یک آبجکت Eviction ایجاد می‌کنید که موجب خاتمه‌ی کنترل‌شده‌ی پاد می‌شود.شما می‌توانید با فراخوانی مستقیم Eviction API و استفاده از یک کلاینت kube-apiserver (مثلاً دستور kubectl drain) عمل حذف را درخواست کنید. این کار یک آبجکت Eviction ایجاد می‌کند که به سرور API دستور می‌دهد پاد را خاتمه دهد.Pod Disruption Budget (PDB):Pod Disruption Budgetیک Pod Disruption Budget (PDB) به شما امکان می‌دهد محدودیتی برای ایجاد اختلال در برنامه‌تان تعیین کنید، تا زمانی که پادهای آن برای دلایلی نظیر به‌روزرسانی‌ها یا عملیات نگهداری روتین بر روی نودهای کوبرنتیز نیاز به زمان‌بندی مجدد دارند، میزان اختلال را کنترل کنید.یک PDB تعداد پادهای یک برنامه تکرارشونده (replicated) را که می‌توانند همزمان تحت اختلال ارادی (voluntary disruption) قرار بگیرند، محدود می‌کند. برای مثال، یک برنامه مبتنی بر quorum مایل است که تعداد رپلیکاهای در حال اجرای خود هرگز کمتر از تعداد مورد نیاز برای حفظ کوآروم نشود.در کوبرنتیز، پادها ممکن است به دلایل مختلف از جمله به‌روزرسانی نودها، ارتقای نرم‌افزار، یا جابجایی بار کاری نیاز به حذف موقت یا جابجایی داشته باشند. برخی از این عملیات، داوطلبانه (voluntary) هستند؛ یعنی مدیر یا ابزارهای مدیریت کلاستر به‌طور ارادی پادها را از بین می‌برند یا جابه‌جا می‌کنند (برای مثال، با اجرای فرمان kubectl drain برای تعمیر نود).در کوبرنتیز PDBها به شما این امکان را می‌دهند که تضمین کنید هنگام انجام این تغییرات ارادی، فقط تعداد محدودی از پادهای برنامه کاهش می‌یابد. در واقع PDB کاری می‌کند که حتی در صورت انجام عملیات نگهداری یا ارتقا، سطح پایداری و در دسترس بودن برنامه حفظ شود. این خیلی نکته‌ی مهمی است. البته برای تعداد پاد چه بیشتر و چه کمتر از یه تعداد می‌تونیم این کار رو کنیم. این قابلیت به ما این امکان رو می‌ده که مدیریت بهتری روی کلاستر اپلیکیشن خودمون داشته باشیم و جلوگیری می‌کنه که اعضای اون کلاستر از یه تعدادی بیشتر و یا کمتر نشود.Bin Packing:زمان‌بند کوبرنتیز (kube-scheduler) را می‌توان طوری پیکربندی کرد که با استفاده از تابع اولویت RequestedToCapacityRatioResourceAllocation، منابع عادی و منابع توسعه‌یافته را به‌صورت Bin Packing بسته‌بندی کند. تابع‌های اولویت (Priority Functions) می‌توانند برای تنظیم دقیق و شخصی‌سازی رفتار زمان‌بند بر اساس نیازهای خاص استفاده شوند. به عبارتی طوری برنامه‌ریزی کند که منابع مشخصی از نودها مورد استفاده قرار بگیرد به گونه‌ای که یه نود خیلی خالی و یکی دیگه خیلی پر نباشه تا بتونه همواره یه تعداد معقولی از پادها رو دیپلوی کنه. در صورتی که نیاز باشه منابع بیشتری به یه پاد اختصاص پیدا کنه و یه جورایی منابع زیادی لازم باشه و هیچ نودی اون رو نداشته باشه کوبرنتیز با ری اسکجولینگ که انجام می‌ده برخی از پادها رو جابه جا می‌کنه تا این فضا رو برای اون پاد فراهم کنه.bin packingامنیت در کوبرنتیز: اهمیت لایه‌های زیرساخت و سیاست‌های امنیتیامنیت در کوبرنتیز مستلزم توجه همزمان به زیرساخت اجرا (مانند پابلیک کلاد، دیتاسنتر سازمانی، یا سرورهای co-located)، اجزای کلاستر کوبرنتیز و در نهایت اپلیکیشن‌هایی است که روی آن اجرا می‌شوند. اگر لایه‌ی زیربنایی، مثلاً محیط ابری، به درستی ایمن نشده باشد، هیچ تضمینی وجود ندارد که بخش‌های بالادستی که روی آن اجرا می‌شوند امن باقی بمانند. اغلب ارائه‌دهندگان سرویس ابری دستورالعمل‌هایی برای افزایش امنیت Workloadها در محیط خود ارائه می‌دهند تا مطمئن شوید که تنظیمات شبکه، دسترسی‌ها و سرویس‌های زیرساختی به درستی امن‌سازی شده‌اند.Kubernetes Securityدو حوزه اصلی برای تأمین امنیت کوبرنتیز عبارتند از:امن‌سازی اجزای کلاستر: این بخش شامل Control Plane و مؤلفه‌هایی مانند kube-apiserver، kube-scheduler، kube-controller-manager و غیره می‌شود. همچنین تنظیمات درست برای etcd (پایگاه داده کوبرنتیز) و Kubelet روی نودها، اطمینان از TLS در ارتباطات داخلی، RBAC و استفاده از Admission Controllerها برای محدودسازی پیکربندی‌های ناامن ضروری است.امن‌سازی اپلیکیشن‌ها: کانتینرها، ایمیج‌ها و کد درون آن‌ها، نحوه تعامل کانتینر با سیستم‌عامل میزبان و سایر کانتینرها و در نهایت شبکه کانتینری و مخازن ذخیره‌سازی همگی از لایه‌های امنیتی مهم هستند. بررسی مداوم ایمیج‌ها برای آسیب‌پذیری‌ها، استفاده از اسکنرهای امنیتی، به‌کارگیری حداقل دسترسی‌ها (Principle of Least Privilege) و به‌روزرسانی مستمر کتابخانه‌ها و پکیج‌ها از موارد کلیدی در ایمن‌سازی این لایه است.سیاست‌های امنیتی پاد در کوبرنتیزاز سیاست‌های امنیتی برای محدودسازی سطح دسترسی و پیکربندی پادها استفاده می‌شود. برای مثال:Privileged:حداقل محدودیت و حداکثر دسترسی را دارد که اگرچه انعطاف‌پذیری بیشتری می‌دهد، اما خطر بالاتری از نظر امنیتی دارد. کلا توصیه نمی‌شه که این طوری پیش بره. این نوع دسترسی می‌تونه برای ما دردسرهای زیادی ایجاد کنه.Baseline:اعمال حداقل محدودیت‌ها برای جلوگیری از افزایش سطح دسترسی شناخته‌شده، بدون ایجاد محدودیت‌های شدید.Restricted:سخت‌ترین سیاست‌ها را دنبال می‌کند و بر اساس بهترین شیوه‌های سخت‌سازی پادها عمل می‌کند. این حالت برای سرویس‌های حساس و محیط‌های تولیدی حیاتی است.این سیاست‌ها را می‌توان در حالت‌های مختلف مانند Enforce (اعمال اجباری و جلوگیری از ایجاد پاد نامطابق)، Audit (صرفاً ثبت وقایع بدون جلوگیری)، و Warn (هشدار به کاربر اما اجازه‌ی ساخت پاد) فعال کرد.جایگزین کردن PodSecurityPolicy با راهکارهای نوینتا پیش از نسخه‌های اخیر، PodSecurityPolicy (PSP) برای تعریف شرایط امنیتی پادها در سطح کلاستر استفاده می‌شد. اما از نسخه 1.21 این ویژگی منسوخ و در نسخه 1.25 حذف شده است. جایگزین این قابلیت، استفاده از Pod Security Admission است که سیاست‌های امنیتی را در سطح Namespaces اعمال می‌کند. همچنین می‌توانید از پلاگین‌های خیلی خوبی همانند Gatekeeper (مبتنی بر Open Policy Agent) استفاده کنید تا قوانین دلخواه امنیتی خود را با کنترل بیشتری اجرا نمایید.نکات تکمیلی و توصیه‌هااستفاده از شبکه ایمن: اطمینان حاصل کنید که Network Policies در کوبرنتیز فعال بوده و ارتباطات بین پادها، نودها و سرویس‌ها مطابق اصل حداقل دسترسی کنترل شده است. به صورت پیش‌فرض تمام پادها در تمام namespaceها به همدیگر دسترسی دارند. با نتورک پالیسی می‌تونیم به خوبی جلوی این دسترسی‌ها رو بگیریم و این پیش‌فرض رو تغییر بدیم. در ضمن می‌تونیم پادهای خودمون رو Protect کنیم.رمزنگاری و مدیریت کلیدها: استفاده از TLS برای ارتباطات داخلی، رمزنگاری داده‌های حساس در etcd، و مدیریت امن Secretها از طریق Key Management Service (KMS) یا Vault ضروری است. به صورت پیش‌فرض کلید‌ها و رمزها داخل کوبرنتیز encode هستند که با استفاده از این ابزارها می‌تونیم آنها رو encrypt کنیم.ثبت وقایع و پایش امنیتی: فعال‌سازی Auditing در kube-apiserver، استفاده از ابزارهای پایش و هشداردهی (مانند Prometheus و Alertmanager)، و بررسی مداوم لاگ‌ها می‌تواند از بروز حملات و نفوذهای احتمالی جلوگیری کند. با استفاده از Auditing ما به خوبی متوجه می‌شم که کی داره چی کار می‌کنه و این خیلی کمکمون می‌کنه که Forensics انجام بدیم و بررسی کنیم که چه اتفاقی افتاده که این مشکل رو برای ما ایجاد کرده. کلا دیتای خیلی مهمی رو در اختیار ما قرار می‌ده.مدیریت چرخه عمر ایمیج‌ها: تنها از ایمیج‌های رسمی و معتبر استفاده کرده، آن‌ها را اسکن و به‌روزرسانی کنید. بهتر است ریجستری خصوصی و امن داشته باشید تا از ورود ایمیج‌های مخرب جلوگیری شود و همواره ایمیج‌هایی که داریم استفاده می‌کنیم رو پاییش و بررسی کنیم و از بروز مشکلات احتمالی روی آنها جلوگیری کنیم.امنیت کوبرنتیز یک فرآیند چندلایه است: از تأمین امنیت زیرساخت ابری و اعمال کنترل‌های دسترسی RBAC در کنترل‌پلین، تا اجرای سیاست‌های امنیتی پاد، مدیریت ایمیج‌ها، تنظیم شبکه‌های کانتینری و جایگزین کردن PSP با مکانیسم‌های جدیدتر مانند Pod Security Admission. با رعایت این اصول و توصیه‌ها، می‌توانید محیط کوبرنتیز خود را در برابر تهدیدات مختلف مقاوم‌تر و مطمئن‌تر نمایید.در ادامه مسیر تو بلاگ پست‌های بعدی موارد مربوط به سطح دسترسی رو توی کوبرنتیز بررسی می‌کنیم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 04 Jan 2025 08:20:39 +0330 https://virgool.io/@rafiee/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%DA%A9%D8%A7%D9%85%D9%84-%D9%81%D8%B1%D8%A2%DB%8C%D9%86%D8%AF-%D9%BE%D8%A7%D8%AF-%D8%AA%D9%88-%D9%86%D9%88%D8%AF-%DA%A9%D9%88%D8%A8%D8%B1%D9%86%D8%AA%DB%8C%D8%B2-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%87%D9%85-ndv6gb2b1ppk تو قسمت دهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم فرآیند pod to node و دقیق تر بررسی می‌کنیم که چجوری اسکجولر تصمیم میگیره که هر کدوم از پادهای ما رو روی کدوم نود کوبرنتیز استقرار بده.Kubernetes pod to node processخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.مقدمه:قبل‌تر دیدیم که اسکجولر پادهایی که جدیدا درست شدن رو بررسی می‌کنه و برای هرپاد جدیدی که اسکجولر اونو بررسی میکنه، یک نود مناسب پیدا میکنه. در واقع اسکجولر مسئول پیدا کردن بهترین نود برای پاد هست تا روی اون نود ران بشه. اسکجولر این کار رو بر اساس قوانینی که قبلا توضیح دادیم انجام میده در ادامه یه مقدار بیشتر در مورد این فرآیند توضیح میدیم.راه‌های مختلفی برای انجام این فرآیند هست اما تمام راه حل هایی که توصیه شده هستند از Label و Selector ها استفاده می‌کنند برای آسان کردن این فرآیند.node selectorNode Selector Scenario:ساده‌ترین و توصیه‌شده‌ترین روش برای اعمال محدودیت انتخاب نود nodeSelector است.یک فیلد در PodSpec است که یک Map از جفت‌های کلید-مقدار (key-value) را مشخص می‌کند.برای اینکه یک پاد واجد شرایط اجرا روی یک نود باشد، نود باید تمام جفت‌های کلید-مقداری که در nodeSelector مشخص شده است را به عنوان برچسب (Label) داشته باشد (نود می‌تواند برچسب‌های اضافی دیگری نیز داشته باشد). رایج‌ترین استفاده از nodeSelector شامل یک جفت کلید-مقدار است.node selectorNode Name Scenario:استفاده از nodeName ساده‌ترین روش برای اعمال محدودیت انتخاب نود است، اما به دلیل محدودیت‌هایی که دارد معمولاً استفاده نمی‌شود. nodeName یک فیلد در PodSpec است. اگر این فیلد خالی نباشد، Scheduler پاد را نادیده می‌گیرد و kubelet در نود مشخص‌شده سعی می‌کند پاد را اجرا کند.بنابراین، اگر nodeName در PodSpec مشخص شده باشد، نسبت به روش‌های دیگر برای انتخاب نود اولویت دارد.Affinity and Anti-affinity Scenario:تا اینجا متوجه شدیم که اسکجولر میشینه حساب کتاب میکنه که مثلا پاد رو نفرسته جایی که منابع مورد نیازش وجود نداشته باشه و اگه یادتون باشه گفتیم که یه بار فیلترینگ انجام میده که ببینه اصلا روی کدوم نود ها میشه این پاد رو برد و بعدش فرآیند Scoring رو انجام میده که پیدا کنه حالا از بین اینهایی که میشه کدومش بهتر هستند برای این پاد. این مباحث رو تو قسمت اسکجولر توضیح دادم. آیا اینکه cpu و ram کافی برای اون پاد روی نود باشه کافیه؟ آیا ما میتونیم با جزئیات بیشتری از اسکجولر بخوایم که مقصد پاد رو مشخص کنه؟ مثلا میشه بگیم هرجا یه پاد از backend هست یه پاد از redis هم باشه؟ یا مثلا میتونیم بگیم که تا جای ممکن پادهای فلان سرویس رو پخششون کن که کنار هم توی یک نود نباشن؟Pod Affinityدیدیم که nodeSelector یک روش بسیار ساده برای محدود کردن پادها به نودهایی با برچسب‌های خاص فراهم می‌کند. ویژگی affinity/anti-affinity به طور قابل توجهی انواع محدودیت‌هایی که می‌توانید بیان کنید را گسترش می‌دهد.مفهوم affinity شامل دو نوع وابستگی است:Node Affinity (وابستگی به نود)Inter-Pod Affinity/Anti-Affinity (وابستگی/ضد وابستگی بین پادها)نوع اول یعنی Node Affinity از نظر مفهومی مشابه nodeSelector است و به شما اجازه می‌دهد که مشخص کنید پاد شما با توجه به برچسب‌های نود، روی کدام نودها واجد شرایط اجرا باشد.در حال حاضر دو نوع Node Affinity وجود دارد:1. RequiredDuringSchedulingIgnoredDuringExecutionاین نوع به این معناست که پاد فقط در زمان اسکجولینگ باید قوانین وابستگی را رعایت کند، اما در زمان اجرا نادیده گرفته می‌شود. یعنی وقتی که پاد دلیور شد روی نود اگر شرط دیگه برقرار نباشه مهم نیست و تنها در زمان اسکجول شدن مهمه که شرط برقرار باشه. دقت کنید اگر اسکجولر نتونه نود مورد نظر رو برای پاد پیدا کنه پاد در حالت pending باقی می‌مونه تا اسکجولر بتونه نود مورد نظر برای برقراری شرط رو پیدا کنه.2. PreferredDuringSchedulingIgnoredDuringExecutionاین نوع به Scheduler پیشنهاد می‌دهد که قوانین وابستگی را رعایت کند، اما تضمینی برای رعایت آن‌ها وجود ندارد. یه جورایی می‌گیم که بهتره که این پاد مثلا این طوری اسکجول بشه اما اگر شرایط برقرار نبود جای دیگه‌ای هم اومد بالا مشکلی نیست. یه جورایی می‌گیم بهش که ترجیح می‌دیم که این طوری پیش بره اما اگر نشد مشکلی نیست.بخش IgnoredDuringExecution در نام این قوانین نشان می‌دهد که مشابه nodeSelector، اگر در زمان اجرا برچسب‌های یک نود تغییر کنند به‌طوری که قوانین وابستگی دیگر رعایت نشوند، پاد همچنان به اجرای خود روی آن نود ادامه می‌دهد.مثلا ممکنه پادهایی داشته باشیم که میخوایم فقط روی نودهایی از کلاستر دیپلوی بشن که اونجا gpu هم وجود داشته باشه.required labelde affinityدر مثال بالا از required label استفاده شده بنابراین حتما پاد اگر دیپلوی بشه روی نودی که لیبل gpu=true داره، دیپلوی میشه.node affinity preferred labelsدر مثال بالا می‌بینیم که از Preferred labels استفاده شده، یعنی به نوعی ترجیح ما این هست که این پاد روی نودهایی بره که توی zone1 هستند و share اونها به صورت dedicated لیبل زده شده اما اگر به هردلیلی این اتفاق نیافتد کوبرنتیز از اینکه این پاد روی نود دیگری دیپلوی شود جلوگیری نمی‌کند.سینتکس جدید Node Affinity از عملگرهای زیر پشتیبانی می‌کند:In (در لیست بودن)این عملگر بررسی می‌کند که آیا مقدار برچسب نود در لیستی از مقادیر مشخص‌شده وجود دارد یا نه.مثال:key: "environment" operator: "In" values: ["production", "staging"]این تنظیم به پاد اجازه می‌دهد فقط روی نودهایی اجرا شود که مقدار برچسب environment برابر با production یا staging باشد.NotIn (در لیست نبودن)بررسی می‌کند که مقدار برچسب نود در لیستی از مقادیر مشخص‌شده نباشد.مثال:key: "environment" operator: "NotIn" values: ["development", "test"]این تنظیم به پاد اجازه می‌دهد روی نودهایی اجرا شود که مقدار برچسب environment برابر با development یا test نباشد.Exists (وجود داشتن)بررسی می‌کند که آیا برچسب مشخص‌شده روی نود وجود دارد یا خیر.مثال:key: "region" operator: "Exists"این تنظیم به پاد اجازه می‌دهد روی نودهایی اجرا شود که برچسب region داشته باشند (بدون توجه به مقدار آن).DoesNotExist (وجود نداشتن)بررسی می‌کند که آیا برچسب مشخص‌شده روی نود وجود ندارد.مثال:key: "region" operator: "DoesNotExist"این تنظیم به پاد اجازه می‌دهد فقط روی نودهایی اجرا شود که برچسب region نداشته باشند.Gt (بزرگ‌تر بودن)بررسی می‌کند که آیا مقدار برچسب نود بزرگ‌تر از مقدار مشخص‌شده است یا خیر.مثال:key: "cpu-count" operator: "Gt" values: ["4"]این تنظیم به پاد اجازه می‌دهد روی نودهایی اجرا شود که مقدار برچسب cpu-count بیشتر از 4 باشد.Lt (کوچک‌تر بودن)بررسی می‌کند که آیا مقدار برچسب نود کوچک‌تر از مقدار مشخص‌شده است یا خیر.مثال:key: "cpu-count" operator: "Lt" values: ["8"]این تنظیم به پاد اجازه می‌دهد روی نودهایی اجرا شود که مقدار برچسب cpu-count کمتر از 8 باشد.این عملگرها انعطاف‌پذیری بالایی در تعریف وابستگی‌ها و محدودیت‌های زمان‌بندی پادها فراهم می‌کنند. یه جورایی داره بهمون کمک می‌کنه و دستمون رو باز می‌گذاره که با این لیبل‌ها بازی کنیم تا بتونیم به خوبی چیزی که می‌خواهیم رو پیاده‌ کنیم.inter pod anti-affintyوابستگی (Affinity) و ضد وابستگی (Anti-Affinity) بین پادها به شما اجازه می‌دهد که مشخص کنید پادهای شما با توجه به برچسب‌های پادهایی که قبلاً روی یک نود اجرا می‌شدند (به جای برچسب‌های خود نود)، روی کدام نودها اجرا شوند.قوانین وابستگی و ضد وابستگی بین پادها به این شکل عمل می‌کنند:«این پاد باید (یا در مورد ضد وابستگی، نباید) در X اجرا شود، اگر X از قبل یک یا چند پاد را که قوانین Y را برآورده می‌کنند، اجرا کرده باشد.»در اینجا:X:یک دامنه توپولوژی است، مانند نود، رک، Cloud Provider Zone یا Region و موارد مشابه.Y:قانونی است که Kubernetes سعی می‌کند آن را برآورده کند.این قابلیت به شما کمک می‌کند زمان‌بندی پادها را با توجه به روابط و وابستگی‌های بین آن‌ها دقیق‌تر مدیریت کنید.وابستگی (Affinity) و ضد وابستگی (Anti-Affinity) بین پادها نیازمند پردازش قابل توجهی است که می‌تواند زمان‌بندی (اسکجولینگ) را در کلاسترهای بزرگ به طور قابل توجهی آهسته کند. استفاده از این ویژگی‌ها در کلاسترهایی با بیش از چند صد نود توصیه نمی‌شود. کلا توصیه اینه تا زمانی که مجبور نشدیم از این قابلیت‌ها استفاده نکنیم چون تو کوبرنتیزمون هزینه ایجاد می‌کنه. اما اگر بهش نیاز داشتیم حتما ازشون استفاده می‌کنیم که خیلی کمک می‌کنه که فرآیند اسکجولینگمون هوشمندانه‌تر باشه.ضد وابستگی پادها (Pod Anti-Affinity) نیازمند این است که نودها به طور مداوم برچسب‌گذاری شوند. به عبارت دیگر، تمام نودهای کلاستر باید دارای یک برچسب مناسب مطابق با topologyKey باشند. اگر برخی یا همه نودها فاقد برچسب topologyKey مشخص‌شده باشند، ممکن است رفتارهای غیرمنتظره‌ای رخ دهد. البته اگر از این قابلیت استفاده کنیم همچین نیازمندی خواهیم داشت.pod affinityدر مثال بالا می‌بینیم که میتونیم با استفاده از لیبل‌ها و pod affinity کانتینرهای backend و frontend رو در کنار هم دیپلوی کنیم. یا حتی میتونیم به شکلی روی نودهای کلاستر لیبل بزنیم و با استفاده ازین مفاهیم تنظیمات رو به شکلی انجام بدیم که این کانتینرها در یک رک توی دیتاسنتر در کنار هم باشند.inter pod affinityTaints و Tolerations:مفهوم دیگه ای که در کلاستر کوبرنتیز داریم Taints و Tolerations هست که با هم کار می‌کنند تا اطمینان حاصل شود که پادها روی نودهای نامناسب زمان‌بندی نمی‌شوند.taint and tolerationیک یا چند Taint به یک نود اعمال می‌شود؛ این کار نشان می‌دهد که نود نباید هیچ پادی را که تحمل (Toleration) آن Taint را ندارد، بپذیرد. از این قابلیت برای ارائه‌ی نود اختصاصی استفاده می‌کنیم. یا به عبارتی برای اینکه مدیریت کنیم که پاد‌های دیگه که نباید روی نودهای ما که taint دارند قرار نگیرند.تا الان مواردی که معرفی کردیم به این صورت بود که محدودیت‌ها رو از سمت پاد اعمال میکردیم حالا با استفاده از taint و toleration میتونیم از سمت نودهای کلاستر این محدودیت رو اعمال کنیم، مثلا یک نود کلاستر رو با taint مربوط به دیسک‌های پرسرعت و گرون قیمت‌تر مشخص می‌کنیم، اونوقت تنها پادهایی میتونن روی این نود بیان که toleration متناسب باهاش رو داشته باشند.taint and tolerationدر ادامه برخی از کاربردها و یوز کیس‌های taint و toleration رو بررسی می‌کنیم.1. Dedicated Nodes (نودهای اختصاصی):از Taints و Tolerations می‌توان برای اختصاص نودهای خاص به پادهای خاص استفاده کرد.مثال: شما می‌خواهید نودهای خاصی را فقط برای اجرای پادهای مربوط به یک تیم یا پروژه خاص استفاده کنید.پیاده‌سازی:نود را با یک Taint مشخص کنید:kubectl taint nodes <node-name> dedicated=teamA:NoScheduleپادهای تیم A باید با این Toleration تنظیم شوند:tolerations: - key: "dedicated" operator: "Equal" value: "teamA" effect: "NoSchedule"2. Nodes with Special Hardware (نودهای با سخت‌افزار خاص):برای نودهایی که سخت‌افزار خاصی مانند GPU یا SSD دارند، از Taints و Tolerations استفاده می‌شود تا فقط پادهایی که به این سخت‌افزار نیاز دارند روی این نودها اجرا شوند.مثال: نودهایی که کارت گرافیک دارند فقط برای پادهایی که نیاز به GPU دارند در دسترس باشند.پیاده‌سازی:Taint کردن نود:kubectl taint nodes <node-name> hardware=gpu:NoScheduleتعریف Toleration در پاد:tolerations: - key: "hardware" operator: "Equal" value: "gpu" effect: "NoSchedule"3. Taint Based Evictions (خروج اضطراری بر اساس Taint):برای مدیریت خودکار منابع و پایداری کلاستر، Taints می‌توانند در صورت وقوع شرایط خاص، خروج اضطراری پادها را اعمال کنند. بنا به دلایل مختلف یا ما یا خود کوبرنتیز نیاز داریم که یه نود رو خالی کنیم و دیگه پادی داخلش نباشه یا دیگه پادی روش اسکجول نشه.مثال: زمانی که یک نود در حال کمبود منابع است یا در حال خاموش شدن است، پادها به طور خودکار به نودهای دیگر منتقل شوند.پیاده‌سازی:Kubernetes به صورت خودکار Taints خاصی مانند node.kubernetes.io/memory-pressure یا node.kubernetes.io/disk-pressure را اعمال می‌کند.پادها می‌توانند Toleration برای این شرایط تعریف کنند:tolerations: - key: "node.kubernetes.io/memory-pressure" operator: "Exists" effect: "NoSchedule"این ویژگی‌ها انعطاف‌پذیری و کنترل دقیق‌تری روی اسکجولینگ و اجرای پادها در Kubernetes فراهم می‌کنند.همونطور که برای محدودیت‌های از سمت پاد سطوح مختلفی رو میتونستیم تعیین کنیم مثل required و preferred برای اعمال محدودیت از سمت نود هم میتونیم effect‌های مختلفی رو برای taint تعریف کنیم:NoSchedule:پاد بدون داشتن Toleration مطابق با Taint، روی نود مورد نظر اسکجول نمی‌شود.NoExecute:این حالت بلافاصله تمام پادهایی که Toleration مطابق با Taint ندارند را از نود خارج می‌کند.PreferNoSchedule:نسخه نرم‌تر NoSchedule است که در آن کنترلر تلاش می‌کند پاد را روی نود دارای Taint اسکجول نکند، اما این یک الزام سخت‌گیرانه نیست.pod to node processنکته‌ی بسیار مهم:بالاتر هم بهش اشاره کردیم این موارد باعث می‌شه که فرآيند اسکجولینگ کوبرنتیز دشوارتر و سنگین‌تر بشه و اصطلاحا داریم این مسیر ور دستکاری می‌کنیم و بهتره که تا جایی که بهش نیاز نداریم ازشون استفاده نکنیم. هر چی ساده‌تر باشه فرآيند راحت‌تر پیش می‌ره ولی هر زمان که بهش نیاز داشتیم می‌تونیم به خوبی از این قابلیت‌ها استفاده کنیم. در ادامه مسیر میریم سراغ ادامه مطالب کوبرنتیز و موارد مربوط به این بلاگ پست رو تکمیل می‌کنیم و مطالب کوبرنتیز رو ادامه میدیم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sun, 29 Dec 2024 20:10:45 +0330 https://virgool.io/@rafiee/kubernetes-prob-resource-management-hcenel34gjtl تو قسمت نهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم پراب و مدیریت منابع و ریکوئست و لیمیت رو بررسی می‌کنیم.Kubernetes Probeخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.kubernetes probesدر Kubernetes، پراب (Probe) مکانیزمی است که به kubelet کمک می‌کند تا وضعیت سلامت یک کانتینر را بررسی کند. به بیان ساده، پراب‌ها تست‌هایی هستند که به صورت دوره‌ای اجرا می‌شوند تا تشخیص دهند که آیا یک کانتینر:سالم است (Healthy): یعنی به درستی کار می‌کند.آماده است (Ready): یعنی می‌تواند درخواست‌های جدید را پردازش کند.مشکلی دارد (Unhealthy): یعنی به درستی پاسخ نمی‌دهد.این مکانیزم از طریق صدا زدن یک Handler که توسط کانتیر ایجاد شده، اتفاق می‌افتد.سه نوع هندلر وجود دارند که به اختصار اونها رو توضیح میدیم.ExecAction:یک کامند رو درون کانتینر اجرا میکنه و اگه با status code صفر از کامند خارج بشه اون رو موفقیت آمیز در نظر میگیره و وضعیت کانتینر رو سالم گزارش میکنه.TCPSocketAction:به یک پورت خاص پاد از طریق ip پاد متصل میشه و یک TCP Check رو انجام میده و درصورتیکه پورت باز باشه این تست رو موفق در نظر میگیره.HTTPGetAction:یک درخواست HTTP GET به ip پاد میزنه در پورت و path مشخص و در صورتیکه response کد بزرگتر مساوی ۲۰۰ و کمتر از ۴۰۰ باشد اون رو موفق در نظر میگیره.انواع پراب‌ها:probes workflow1. Liveness Probe:برای بررسی اینکه آیا کانتینر سالم است یا نه. اگر کانتینر سالم نباشد، kubelet می‌تواند آن را ری‌استارت کند.2. Readiness Probe:برای بررسی اینکه آیا کانتینر آماده ارائه خدمات است یا نه. اگر آماده نباشد، از لیست پادهای قابل دسترس (Endpoints) حذف می‌شود.3. Startup Probe:برای بررسی اینکه آیا کانتینر توانسته به درستی شروع به کار کند یا نه. این پراب معمولاً برای کانتینرهایی که زمان زیادی برای شروع نیاز دارند استفاده می‌شود.probesبا استفاده از این پراب‌ها و وضعیتی که از پادها برامون مشخص می‌کنند تصمیم میگیرم که در زمان لودبالانس ترافیک رو سمت کدوم پادها بفرستیم و کدوم پادها در دسترس هستند و میتونند به درستی سرویس بدهند.probes and loadbalancerپراب‌ها نقش مهمی در مدیریت خودکار کانتینرها و اطمینان از پایداری سیستم دارند.می‌تونیم تنظیمات مختلفی رو برای پراب‌ها در نظر بگیریم و پراب‌ها رو کانفیگ کنم که در ادامه چند مورد از اونها رو توضیح میدیم.initialDelaySeconds:تعداد ثانیه‌هایی که پس از شروع کانتینر صبر می‌شود تا پراب‌های startup، liveness یا readiness آغاز شوند. مقدار پیش‌فرض ۰ ثانیه است. حداقل مقدار مجاز ۰ است.periodSeconds:فاصله زمانی (بر حسب ثانیه) برای اجرای پراب رو با این متغیر نشان می‌دهیم یعنی هر چند ثانیه یکبار پراب مجدد اجرا شود و وضعیت چک شود. مقدار پیش‌فرض ۱۰ ثانیه است. حداقل مقدار مجاز ۱ است.timeoutSeconds:تعداد ثانیه‌هایی که پس از آن پراب تایم‌اوت می‌شود. یعنی اگه تا اون زمان پاسخ نگرفت دیگه منتظر پاسخ نمی‌مونه و دریافت نشده در نظر میگیره. مقدار پیش‌فرض ۱ ثانیه است. حداقل مقدار مجاز ۱ است.successThreshold:حداقل تعداد موفقیت‌های متوالی برای اینکه پراب پس از یک بار شکست، موفق در نظر گرفته شود. مقدار پیش‌فرض ۱ است. برای پراب‌های liveness و startup باید مقدار ۱ داشته باشد. حداقل مقدار مجاز ۱ است.failureThreshold:زمانی که یک پراب شکست بخورد، Kubernetes تعداد failureThreshold بار تلاش می‌کند پیش از اینکه تسلیم شود. تسلیم شدن در مورد liveness probe به معنای ری‌استارت کردن پاد است. در مورد readiness probe، پاد به عنوان آماده‌نبودن (Unready) علامت‌گذاری می‌شود. مقدار پیش‌فرض ۳ است. حداقل مقدار مجاز ۱ است.کوبرنتیز با استفاده از Prob‌ها می‌تونه از وضعیت پادها و سرویس‌های ما مطلع بشه و در جریان وضعیت آنها قرار می‌گیره که این خیلی خوبه. اگر برای پادهامون Prob قرار ندیم کوبرنتیز نمی‌دونه که اون پادها در چه وضعیتی قرار دارند و این اصلا چیز خوبی نیست. با استفاده از این موارد ما داریم به کوبرنتیز خودمون شعور بیشتر اضافه می‌کنیم که درک کنه پادمون حالش چطوره و زمانی که حالش میزون بود سمتش ترافیک بفرسته.Kubernetes Resource Management:k8s resource requests and limitsزمانی که Resource Request را برای کانتینرهای یک پاد مشخص می‌کنید، Scheduler از این اطلاعات برای تصمیم‌گیری در مورد اینکه پاد روی کدام نود قرار بگیرد استفاده می‌کند. زمانی که محدودیت منابع Resource Limit را برای یک کانتینر مشخص می‌کنید، kubelet این محدودیت‌ها را اعمال می‌کند تا کانتینر در حال اجرا اجازه نداشته باشد بیش از حدی که تعیین کرده‌اید از منابع استفاده کند. همچنین kubelet حداقل مقدار درخواست‌شده از آن منبع سیستم را به صورت اختصاصی برای استفاده آن کانتینر رزرو می‌کند.request and schedulerدر فایل مانیفست پاد، CPU و Memory هر کدام به عنوان یک Resource Type تعریف شده‌اند که می‌توان محدودیت‌هایی در سطح کانتینر برای آن‌ها تعیین کرد. هر نوع منبع دارای یک واحد پایه است. CPU بر حسب هسته‌های پردازشی (cores) مشخص می‌شود و Memory بر حسب بایت (bytes) تعیین می‌گردد. برای هر نوع منبع دو نوع محدودیت قابل تنظیم است: Requests و Limits.Requestمقدار منابعی است که سیستم برای پاد تضمین می‌کند و Kubernetes از این مقدار برای تصمیم‌گیری در مورد اینکه پاد روی کدام نود قرار گیرد استفاده می‌کند. به عبارتی مقدار منابعی است که کوبرنتیز و kubelet تضمین می‌کند که در اختیار pod قرار می‌دهد. مقدار منابعی است که گارانتی می‌کند.Limitحداکثر مقدار منابعی است که Kubernetes به پاد اجازه می‌دهد استفاده کند. دقت کنید اجازه می‌ده که استفاده کنی ولی گارانتی نمی‌کنه که حتما برای شما تامین کند. اگر داشت در اختیار Pod قرار می‌ده. اصلا گارانتی براش نیست. اگر وجود داشت تامین می‌شود. سقف مصرف منابع pod هست و بیشتر از اون نمی‌تونه pod منابع در اختیار بگیره.cpu request and limitدر واقع توی request به کوبرنتیز میگیم تضمین کن که این میزان رو حتما بهش بدی ولی توی limit میگیم اگه داشتی تا این حد بهش بده!requests and limitsپس دیدیم که در کوبرنتیز Requests و Limits مکانیزم‌هایی هستند که برای کنترل منابعی مانند CPU و Memory استفاده می‌شوند. فقط باید به خاطر داشت که مقدار Limit هرگز نمی‌تواند کمتر از مقدار Request باشد. اگر این کار را امتحان کنید، Kubernetes خطا می‌دهد و اجازه اجرای pod را نمی‌دهد.یه نکته‌ی مهم اینکه این حد و حدود منابع برای pod تنظیم می‌شود. اینکه اون پاد چند تا کانتینر داشته باشه فرقی نمی‌کنه و این منابع برای مجموع اون کانتینرها می‌باشد. اگر ۴ تا کانتینر داشته باشه و میزان لیمنت منابع روی ۲ گیگ رم باشه مجموع اون ۴ تا کانتیر می‌تونن ۲ گیگ رم مصرف کنند. به این نکته توجه کنید که کوچکترین یونیت قابل مدیریت داخل کوبرنتیز Pod است.برای دیدن اینکه هر نود توی کلاستر داره چه میزان از منابع رو مصرف میکنه میتونید از کامند زیر استفاده کنید.kubectl get nodes --no-headers | awk '{print $1}' | xargs -I {} sh -c 'echo {}; kubectl describe node {} | grep Allocated -A 5 | grep -ve Event -ve Allocated -ve percent -ve -- ; echo'​این کامند به صورت مرحله‌ای اجرا می‌شود تا اطلاعات مصرف منابع را برای تمامی نودهای کلاستر Kubernetes نمایش دهد. اجازه دهید مرحله به مرحله آن را توضیح دهیم:kubectl get nodes --no-headersاین بخش لیستی از تمامی نودهای موجود در کلاستر را بدون نمایش هدر (ستون‌های عنوان) دریافت می‌کند. خروجی این بخش شامل نام نودها است، مثلا:node - 1node - 2node - 3awk '{print $1}'این دستور ستون اول خروجی (نام نودها) را استخراج می‌کند. در نتیجه، تنها نام نودها به مراحل بعدی منتقل می‌شود.xargs -I {} sh -c '...'این دستور به ازای هر نام نود ({})، یک شل اسکریپت اجرا می‌کند. داخل این اسکریپت مراحل زیر انجام می‌شود:الف) echo {}نام نود فعلی را چاپ می‌کند تا در خروجی مشخص باشد کدام نود بررسی می‌شود.ب) kubectl describe node {}برای نود فعلی ({})، دستور kubectl describe node اجرا می‌شود. این دستور اطلاعات مفصلی درباره نود ارائه می‌دهد، از جمله منابع تخصیص‌یافته و وضعیت پادهای در حال اجرا.ج) grep Allocated -A 5در خروجی دستور بالا، خطوطی که شامل عبارت Allocated هستند و ۵ خط بعد از آن فیلتر می‌شوند. این خطوط اطلاعات مصرف منابع CPU و Memory را نشان می‌دهند.د) grep -ve Event -ve Allocated -ve percent -ve --این بخش، خطوطی که شامل عبارت‌های اضافی مانند Event، Allocated، یا percent باشند را فیلتر می‌کند تا خروجی تمیزتر شود و فقط اعداد و اطلاعات مهم نمایش داده شوند.ه) echoیک خط خالی بین اطلاعات هر نود چاپ می‌کند تا خوانایی خروجی بهتر شود.نمونه خروجی:فرض کنید کلاستر شما ۳ نود دارد. خروجی این کامند ممکن است به صورت زیر باشد:node-1 CPU Requests: 100m (10%) CPU Limits: 200m (20%) Memory Requests: 512Mi (25%) Memory Limits: 1Gi (50%) node-2 CPU Requests: 150m (15%) CPU Limits: 300m (30%) Memory Requests: 256Mi (10%) Memory Limits: 512Mi (20%) node-3 CPU Requests: 200m (20%) CPU Limits: 400m (40%) Memory Requests: 1Gi (50%) Memory Limits: 2Gi (100%)این کامند به شما امکان می‌دهد به صورت سریع و تمیز مصرف منابع Allocated در هر نود را مشاهده کنید.مناسب برای بررسی مشکلات مربوط به تخصیص منابع یا شناسایی نودهایی که ممکن است دچار کمبود منابع شوند.این کامند وابسته به خروجی دقیق دستور kubectl describe node است و ممکن است در نسخه‌های مختلف Kubernetes تغییرات جزئی داشته باشد.QoS on Kubernetes:برای کوبرنتیز مهمه که میزان ریکوئست و لیمیت رو چقدر تنظیم کردید و فاصله‌ی آنها با هم چقدر است. از اون می‌تونه تشخیص بده که پاد چقدر برای شما مهمه. خیلی مکانیزم جالبی داره.زمانی که Kubernetes یک پاد ایجاد می‌کند، یکی از کلاس‌های QoS (Quality of Service) زیر را به آن اختصاص می‌دهد:Guaranteed:یک پاد زمانی این کلاس را دریافت می‌کند که شرایط زیر را داشته باشد:مقدار request برای مموری با limit برابر باشد.مقدار request برای cpu با limit برابر باشد.یعنی میزان ریکوئست و لیمیت اندازه‌ی هم ست شده باشه. این طوری داری می‌گی به کوبرنتیز که دوست من این پاد برام خیلی مهمه و سقف منابعی که لازم داره رو براش گارانتی کن. این طوری کوبرنتیز باید بگرده جایی رو پیدا کنه که بتونه این پاد رو اونجا با این میزان منابع دلیور کنه.Burstable:پاد وقتی این کلاس را دریافت می‌کند که برای Memory یا Cpu دارای request و limit باشد. یعنی وقتی که تنظیمات منابع رو داشته باشه تو این کلاس قرار می‌گیره. اگر یادتون باشه ما با limite range که تو namespace ایجاد می کردیم برای همه منابع ست می‌کردیم.BestEffort:این کلاس به پادی اختصاص می‌یابد که request و limit مشخصی برای مموری و cpu نداشته باشند.Quality of Serviceزمانی که منابع کلاستر در حال اتمام باشد، Kubernetes ابتدا پادهایی با کلاس QoS از نوع BestEffort را حذف می‌کند و سپس سراغ پادهای Burstable می‌رود.به عبارت دیگر، پادهایی که کمترین اولویت را دارند ابتدا خاتمه داده می‌شوند.اگر منابع کافی داشته باشید، می‌توانید تمام پادها را به کلاس Guaranteed اختصاص دهید. این کار را می‌توان به عنوان یک معامله بین منابع محاسباتی و کارایی و پایداری در نظر گرفت.ممکن است انتظار سربار بیشتری داشته باشید، اما کلاستر شما می‌تواند به صورت کارآمدتری کار کند. در عین حال، برای بهبود بهره‌وری منابع، می‌توانید پادهایی که سرویس‌های تجاری را اجرا می‌کنند به کلاس Guaranteed اختصاص دهید.برای سایر سرویس‌ها، آن‌ها را بر اساس اولویتشان به کلاس Burstable اختصاص دهید.یه نکته‌ی دیگه این هر چقدر فاصله‌ی این دو تا منابع بیشتر باشه اولویت پاد پایین‌تر و هر چقدر به هم نزدیک‌تر باشه اولویت پاد بیشتر می‌شود. با استفاده از LimitRange میتوانیم محدودیت‌هایی رو از قبیل مواردی‌که در ادامه اشاره می‌کنیم رو ایجاد کنید.اعمال حداقل و حداکثر استفاده از منابع محاسباتی (Compute Resources) برای هر پاد یا کانتینر در یک Namespace.اعمال حداقل و حداکثر درخواست ذخیره‌سازی (Storage Request) برای PersistentVolumeClaim در یک Namespace.اعمال نسبت بین Request و Limit برای یک منبع در یک Namespace.تنظیم درخواست‌ها/محدودیت‌های پیش‌فرض برای منابع محاسباتی در یک Namespace و تزریق خودکار آن‌ها به کانتینرها در زمان اجرا.Node Resource Management:مدیریت منابع نود (Node Resource Management) یکی از جنبه‌های کلیدی در Kubernetes است که به توزیع بهینه منابع بین سرویس‌ها و پادها کمک می‌کند. در این مدیریت، منابع نود به چند دسته تقسیم می‌شوند:Node Resource Management۱. منابع مورد نیاز سیستم‌عامل و سرویس‌های سیستمی:این دسته شامل منابعی است که برای اجرای سیستم‌عامل و سرویس‌های پایه‌ای مورد نیاز هستند، مانند SSH، systemd، و سایر فرآیندهای سیستم‌عامل. این منابع برای اطمینان از عملکرد پایدار سیستم‌عامل نود رزرو می‌شوند.۲. منابع مورد نیاز عوامل Kubernetes:این منابع برای اجرای اجزای Kubernetes در هر نود استفاده می‌شوند، از جمله:اجرای Kubelet که مسئول مدیریت پادها و کانتینرها در نود است.اجرای Container Runtime که اجرای کانتینرها را مدیریت می‌کند.اجرای Node Problem Detector که مشکلات موجود در نود را شناسایی و گزارش می‌دهد.Node Resource Management۳. منابع در دسترس برای پادها:منابعی که پس از رزرو شدن برای سیستم و عوامل Kubernetes باقی می‌مانند، به پادها تخصیص داده می‌شوند. این منابع شامل CPU، Memory و Storage است که توسط پادها بر اساس Requests و Limits تعریف‌شده در تنظیماتشان مصرف می‌شوند.۴. منابع رزرو شده برای آستانه Eviction:بخشی از منابع نود برای شرایط خاص رزرو می‌شود. اگر مصرف منابع نود به این آستانه برسد، Kubernetes اقدام به خروج اضطراری (Eviction) پادها با اولویت پایین‌تر می‌کند تا از پایداری نود و کلاستر اطمینان حاصل شود.هدف اصلی از مدیریت منابع نود، اطمینان از استفاده بهینه از منابع، حفظ پایداری سیستم و جلوگیری از مشکلاتی مانند کمبود منابع یا مصرف بیش از حد است. مواردی مانند ResourceQuota و Pod QoS به این فرآیند کمک می‌کنند.به جز مواردی که توضیح دادیم کوبرنتیز این امکان رو بهمون میده که روی تعداد پراسس آی‌دی ها (PID) هم لیمیت بذاریم و برای یک پاد یا یک نود کلاستر این تعداد رو محدود کنیم.برخی از نصب‌های مشخص لینوکس به صورت دیفالت این تعداد رو ۳۲۷۶۸ قرار می‌دهند و ممکنه نیاز باشه که اون رو بیشتر کنیم با توجه به نیازی که داریم چون ممکنه قبل از رسیدن به لیمیت باقی ریسورس‌ها به لیمیت PID برخورد کنیم که برای کانفیگ این مورد میتونیم از طریق مسیر proc/sys/kernel/pid_max/ اقدام کنیم.در ادامه مسیر میریم سراغ ادامه مطالب کوبرنتیز و موارد مربوط به فرآیند pod to node رو بررسی می‌کنیم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شوید.خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 21 Dec 2024 10:53:32 +0330 https://virgool.io/@rafiee/%D8%A7%D8%B3%D8%AA%D9%88%D8%B1%D8%AC-%DA%A9%D9%88%D8%A8%D8%B1%D9%86%D8%AA%DB%8C%D8%B2-%D9%82%D8%B3%D9%85%D8%AA-%D9%87%D8%B4%D8%AA%D9%85-r3tqsc6i9mv7 تو قسمت هشتم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم استورج توی کوبرنتیز و با هم بررسی می‌کنیم که چطوری توی کلاستر میتونیم به پادها والیوم بدیم و دسترسی اونها به استورج کلاستر رو مدیریت کنیم.Kubernetes Storageخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.Kubernetes Storage Objectsقدم به قدم با هم بررسی می‌کنیم که از چه طریقی می‌تونیم به پادهامون توی کلاستر به استورج دسترسی بدیم و این دسترسی رو محدود کنیم و مدیریتش رو انجام بدیم.اول ببینیم که Volume توی کوبرنتیز چیه؟Volumes:یه کوبرنتز والیوم در واقع یه دایرکتوری هست که شامل دیتایی میشه که در دسترس یک کانتینر هستن توی یه پاد مشخص توی کلاستر. بذارید در ادامه یه خرده بهتر اینو توضیح بدم و یه یادآوری کنیم از پست‌های داکر.image layersتوی مثال بالا یه پاد رو می‌بینیم سمت چپ که برای نوشتن دیتای خودش همونطور که قبلا توضیح دادیم روی یک لایه writeable بالای لایه‌های ایمیج کانتینر که فقط خواندنی هستند، مینویسه. اگه میخواید دقیق‌تر در موردش بدونید این بلاگ پست در مورد تکنولوژی که داکر ازش استفاده میکنه رو بخونید و Union FS رو اونجا ببینید. حالا اگه این کانتینر سمت چپ به هردلیلی از بین بره دیتایی هم که توی لایه سبز رنگ نوشته پاک میشه و کانتینر جدید سمت راست که جایگزینش میشه دیگه اون دیتا رو نداره و از اول باید توی لایه نوشتنی خودش دیتا رو بنویسه. اگه اون دیتا و فایل‌هایی که توی لایه سبز رنگ توسط کانتینر نوشته میشه برامون اهمیت داشته باشه باید به طریقی اون رو از کانتینر خارج کنیم و در بیرون کانتینر جایی اون رو نگهداریم.volume in kubernetesبنابراین میاییم یه والیوم ایجاد می‌کنیم و دسترسی بهش رو به پاد میدیم تا کانتینرهای پاد بتونن دیتاشون رو روی اون بنویسن و وقتیکه یک کانتینر از بین رفت، کانتینر جدیدی که جایگزینش میشه به همون دیتا دسترسی داره و میتونه کارش رو ادامه بده.حالا بریم ببینم انواع والیوم توی کوبرنتیز چی هستن؟hostPath:قبل از اینکه توضیحش بدم لازمه بدونید که به هیچ عنوان استفاده از این مدل والیوم توصیه نمیشه و نباید ازش استفاده کنید! مشکل امینتی داره و اگر درست کانفیگ نکنید هر کی می‌تونه به راحتی ادمین کوبرنتیز بشه و کلا کلاستر رو بفرسته اردوگاه توریستی که اصلا چیز مطلوبی نیست. این نوع از والیوم یه‌جورایی شبیه bind mount توی داکر هست.hostpathوالیوم از نوع hostPath یک فایل یا دایرکتوری هست که به صورت مستقیم از فایل سیستم نود کوبرنتیز mount میشه به پاد در حالیکه این میزان از دسترسی به فایل سیستم برای پاد دسترسی زیادی هست و میتونه خطرات امنیتی زیادی رو برامون به همراه بیاره. مثلا فرض کنید ما اومدیم یه مقدار دیسک بدیم به یه پاد که دیتاشو اونجا نگه‌داره بعد اون پاد از همون طریق سکرت‌های ادمین کلاسترمون رو تونسته بره برداره!!! چون دسترسی‌ای که بهش دادیم بیشتر از نیازیه که داشته. میتونید اینجا بیشتر در مورد hostPath بخونید. کلا توصیه می‌کنم که این نوع والیوم رو کلا جلوش رو بگیرید یا فقط یه سری مسیر‌های خاص رو بهش اجازه بدید.emptyDir:این نوع والیوم زمانیکه پاد به یک نود اختصاص داده میشه، ساخته میشه و مثل اسمش از اول خالیه. تمام کانتینرهای توی پاد میتونن توی این والیوم بنویسن و ازش بخونن، بنابراین این والیوم میتونه در مسیرهای یکسان یا متفاوت توی کانتینرهای مختلف mount بشه. زمانیکه پاد از روی نود کلاستر پاک بشه به هردلیلی، دیتای emptyDir هم به صورت کامل پاک میشه. اما crash کردن کانتینر درون پاد منجر به پاک شدن دیتای این نوع والیوم نمیشه. مثلا ازین نوع والیوم میتونیم برای چک پوینت گذاشتن طی انجام یک فرآیند محاسباتی استفاده کنیم تا اگر کانتینری crash کرد دیتا از بین نره.emptyDirتوی کوبرنتیز emptyDir.medium کنترل میکنه که والیوم کجا ذخیره بشه، به صورت دیفالت والیوم‌های emptyDir روی همونجایی که نود بهش برمیگرده ذخیره میشن حالا میتونه دیسک HDD باشه یا SSD یا نتورک استورج. حتی میتونیم emptyDir.medium رو روی Memory تنظیم کنیم و عملکردی شبیه tmpfs توی داکر رو داشته باشیم و دیتای والیوم روی RAM ذخیره بشه، فقط در این حالت محدود به حجم مموری هستیم که باید حواسمون بهش باشه.به طور کلی والیوم هارو توی کوبر میتونیم توی دوتا دسته کلی جا بدیم دسته اول Ephmeral Volumeها و دسته دوم که در ادامه توضیح میدیم Persistent Volumeها. دسته اول در واقع والیوم‌هایی هستن که ماندگار نیستند مثل همین emptyDir که توضیش دادیم، انواع دیگه‌ای مثل configMap و downwardAPI و secret هم هستند توی این دسته که هرکدوم استفاده‌های خودشون رو دارند، اینجا میتونید بیشتر در مورد والیوم‌های Ephemeral بخونید.اما دسته دوم والیوم‌های ‌Persistent هستند که در ادامه توضیح میدیم در موردشون.Persistent Volume:این نوع والیوم یک API کوبرنتیز رو در اختیار ادمین کلاستر میذاره که جزئیات و پیچیدگی‌های دسترسی به استورج رو پنهان میکنه و در قالب یک مفهوم abstract امکان استفاده از استورج رو فراهم میکنه. یک PV یا PersistentVolume قسمتی از استورج هست که توسط ادمین کلاستر یا مکانیزمی که در ادامه توضیحش میدیم یعنی استفاده از استورج‌کلاس ایجاد شده.خب پس حالا که دسترسی ایجاد این نوع والیوم رو فقط ادمین کلاستر داره، پس یوزر کلاستر اصلا چجوری ازین والیوم استفاده کنه؟مفهومی رو در کوبرنتیز داریم تحت عنوان Persistent Volume Claim که به نوعی می‌تونیم بگیم درخواستی هست برای PV، یعنی یوزر کلاستر با استفاده از PVC یه درخواست میده که من PV میخوام بدون اینکه نیاز باشه چیزی از جزئیات پیاده‌سازی و موارد مربوط به کلاستر و یا پروایدری که داره سرویس رو ارائه میده و نحوه ایجاد استورج بدونه.PV and PVCبنابراین همانطور که در تصویر بالا می‌بینیم دولوپر به عنوان یوزر کلاستر نیاز داره که یک والیوم درون پاد قرار بده و این نیاز رو از طریق PVC اعلام میکنه. اما به Persistent Volume های کلاستر دسترسی نداره و اونها رو ادمین کلاستر مدیریت میکنه و باید از طریق ادمین مورد تایید قرار بگیره تا دسترسی به استورج به پاد داده بشه.نکته‌ی مهم اینه که می‌شد مفهومی مثل PV وجود نداشته باشه ولی این طوری باید دسترسی استوریج خودمون که چیز مهمی هم هست رو در اختیار همه‌ی استفاده کننده‌های کلاستر قرار بدیم که خب حتما می‌دونید دسترسی که زیاد در اختیار دیگران باشه کلا می‌تونیم پابلیک در نظرش بگیریم چون پخش می‌شه و نمی‌تونیم جلوش رو بگیریم. ولی مفهوم PV وجود داره که این دسترسی در اختیار ادمین کلاستر باقی بمونه و پخش نشه. مطلب دیگه‌ای که خوبه اینجا اشاره کنیم بحث مودهای دسترسی والیوم هست یا همون Access Modeها.Access Modesحالت Read Write Once که در اون والیوم میتونه برای خواندن و نوشتن به یک پاد یا پروسه mount بشه. که همون نوع بلاک استوریج هست که از انواع سرویس‌های استوریج می‌باشد.حالت Read Write Many که در اون والیوم میتونه به چندین پاد یا پروسه mount بشه که هم از اون بخونن و هم بتونن در والیوم بنویسن. این حالت رو بهش مالتی اتچ‌منت هم می‌گن که فقط نوع فایل share استوریج می‌تونه در اختیار ما قرار بده.حالت Read Only Many که در اون چندین پاد یا پروسه میتونن فقط از والیوم بخونند. حالت باحالی هست. فقط خواندنی اما برای تعدادی زیاد که داستان پر کردن دیتای آن باحاله. کلا وقتی فقط خواندنی هست چطوری داخلش دیتا می‌ریزن که بعدش بخونند. این والیوم‌ها از یه والیوم دیگه می‌تونن کلون بشن و بعدش دیگه فقط خواندنی هستند.و نهایتا حالت Read Write Once Pod که در کوبرنتیز ورژن 1.22 به بعد ساپورت می‌شود و در اون تنها یک پاد میتونه برای خواندن و نوشتن از والیوم استفاده کنه.Storage Class:Static Provisioningتا به اینجای کار روال نوعی از اختصاص حافظه که به اون static provisioning گفته میشه و فهمیدیم که دسترسی استورج رو نباید به یوزر به شکل مستقیم بدیم و PVهارو ادمین کلاستر مدیریت میکنه فقط، اما حالا که فقط ادمین میتونه دسترسی داشته باشه یعنی ما pend اون میمونیم برای والیوم گرفتن؟ یعنی هر کاربری که والیوم بخواد باید صبر کنه تا ادمین تایید بده؟ خیلی مسیر خوبی نیست. اینطوری مدام ما پند ادمین می‌شیم و یا ادمین به جای انجام کارهای مهم دیگه باید همش بیاد والیوم بسازه و در اختیار ما قرار بده که اصلا مسیر مطلوبی نیست و خیلی به کوبرنتیز و فرآیند‌هایی که تا الان در موردش صحبت کردیم نمی‌خوره.Dynamic Volume Provisioningروش دیگری از اختصاص حافظه وجود دارد که به صورت Dynamic بهمون امکان استفاده از استورج رو میده. مفهومی تحت عنوان استورج‌کلاس تعریف میشه که با استفاده از اون ادمین کلاستر میتونه استورج‌ یا استورج‌های مختلف رو به کلاس های متفاوتی تقسیم کنه که برای هرکدوم پالیسی‌های مرتبط به خودشون رو بذاره، مثلا اینکه آیا از این کلاس استورج بکاپ گرفته بشه یا نه. و مهمترین موضوع این که دسترسی‌هایی که برای ساخت والیوم روی اون پروایدر استوریج نیاز است رو داخل اون قرار می‌ده. کاربر هم نمی‌تونه دسترسی‌ها رو ببینه ولی می‌تونه از اون استوریج کلاس استفاده کنه و با استفاده از آن والیوم بسازه. این طوری هم دسترسی رو نداده و هم کارها دیگه پند اون نیست.Dynamic Volume Provisioningدر این روش ادمین کلاستر از قبل کلاس‌ها رو ایجاد میکنه و دسترسی‌ها و محدودیت‌های اونها رو مشخص میکنه و زمانیکه کاربر بخواد درخواست استورج بده به جای اینکه منتظر تایید ادمین کلاستر بمونه به یک استورج‌کلاس که بهش داده شده اشاره میکنه که اونجا اجازه ساخت و محدودیت‌ها و باقی موارد اعمال شده و کلاستر به نوعی متوجه میشه که تایید ادمین از قبل به این درخواست داده شده و فرآیند رو پیش میبره.و اصطلاحا در این روش flow ایجاد PV و PVC به صورت خودکار انجام می‌شود.Storage Classدر تصویر بالا مراحل رو به ترتیب می‌بینیم که ابتدا ادمین کلاستر استورج‌کلاس رو ایجاد میکنه سپس کاربر یک پاد رو میسازه و میتونه ببینه که چه استورج‌کلاس‌هایی توی کلاستر ساپورت میشه و در مرحله بعد با قراردادن استورج‌کلاسی که انتخاب میکنه در PVC به صورت خودکارprovisioner برای این درخواست PV مناسبش رو آماده میکنه.توی پست‌های قبلی مسیر کوبرنتیز در مورد pod phase گفته بودیم، والیوم‌ها هم میتونن توی phaseهای مختلفی باشند.والیوم Available به ریسورسی میگیم که هنوز به هیچ pvc اختصاص داده نشده.والیوم Bound به والیومی میگیم که به یک pvc اختصاص داده شده.والیوم Released به والیومی گفته میشه pvc اون پاک شده اما هنوز ریسورسی که گرفته به کلاستر برنگشته یا اصطلاحا reclaim نشده.والیوم Failed به والیومی گفته میشه که توی فرآیند reclamation به خطا خورده و به صورت خودکار reclaim نشده.در انتهای این قسمت از بلاگ پست‌های کوبر هم خوبه که چنتا مفهوم دیگه رو مرتبط با بحث استورج‌ها معرفی کنیم.مثل استورج‌ها مفاهیم مشابهی رو برای اسنپ‌شات داریم.snapshot in kubernetesیعنی VolumeSnapshot داریم که مثل pvc هست و به نوعی درخواست یوزر برای اسنپ‌شات گرفتم از یک والیوم هست. VolumeSnapshotContent که مثل pv هست و همون اسنپ‌شات گرفته شده از یک والیوم هست که توی کلاستر توسط ادمین ایجاد شده و مشابه استورج‌کلاس VolumeSnapshotClass رو داریم که کلاس‌های مختلف استورج رو برای والیوم در اون ایجاد می‌کنیم.و شبیه کانفیگ و secret که توی داکر داشتیم اینجا توی کوبرنتیز هم configMap و secret رو داریم که جزو Ephemeral storage هستند که بالاتر توضیح دادیم و اگه بخواید میتونید در لینک‌هایی که براشون گذاشتیم بیشتر در مورد اونها بخونید.در ادامه مسیر میریم سراغ ادامه مطالب کوبرنتیز و موارد مربوط به probe رو بررسی می‌کنیم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شویدخوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 14 Dec 2024 10:36:31 +0330 https://virgool.io/@rafiee/%D9%86%D8%AA%D9%88%D8%B1%DA%A9-%DA%A9%D9%88%D8%A8%D8%B1-%D9%82%D8%B3%D9%85%D8%AA-%D9%87%D9%81%D8%AA%D9%85-f9jkfbfxpolj تو قسمت هفتم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم نتورک توی کوبرنتیز و با هم بررسی می‌کنیم که چطوری ریکوئست‌ها توی کلاستر به مقصد خودشون میرسن.kubernetes networkخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.مفاهیم مختلف توی نتورک کوبرنتیز رو دونه دونه در ادامه توضیح میدیم، کم‌کم‌ که بیشتر در مورد آبجکت‌های نتورکی کوبر بخونید مدلش دستتون میاد و متوجه میشید که چه اتفاقی داره میافته.kubernetes networking objectsService:توی کوبرنتیز، سرویس یک مفهوم انتزاعی هست که یک دسته از پادها رو مشخص میکنه و پالیسی‌های دسترسی به اونها رو داره. به این الگو میکروسرویس هم گفته میشه و معمولا میکروسرویسی که توسط سرویس تارگت میشه با سلکتور مشخص میشه. بنابراین شما دیگه کاری به پاد‌های فرانت‌اند به عنوان مثال نداری، با سرویسش حرف میزنی، کاری به پاد‌های بکند نداری درخواست‌هات رو به سرویس‌ش میفرستی و اون وظیفه داره که درخواست شما رو به پاد مناسبش برسونه. و وقتی چندین تا پاد هم داشته باشه بین آنها لودبالانس می‌کنه و کمک می کنه که درخواست‌ها به خوبی توزیع بشن.kubernetes serviceبنابراین ما درخواست‌هامون رو میفرستیم سمت سرویس و اون به نوعی لودبالانس رو انجام میده و بین پاد‌هایی که مربوط بهش هستن پخش میکنه درخواست هارو که معمولا این پاد‌ها با لیبل و سلکتور اتصالشون به سرویس برقرار میشه.حالا چرا معمولا؟ مگه بدون لیبل و سلکتور هم داریم؟ بله!فرض کنید شما میخواید با دیتابیسی بیرون از کلاستر کوبرنتیز صحبت کنید برای پروداکشن‌تون ولی مثلا توی محیط دولوپ دیتابیس‌تون هم روی کلاستر هست. یا مثلا میخواید به سرویسی در یک نیم‌اسپیس دیگه یا یک کلاستر دیگه اشاره کنید. یا مثلا در حال مهاجرت به کوبرنتیز هستید ولی همچنان بخشی از سرویس بکند شما بیرون کلاستر هست ... در این موارد نیاز داریم که از سرویس بدون سلکتور استفاده کنیم. قبل‌تر گفتیم که هر نود کلاستر کوبرنتیز روی خودش kubelet و kubeproxy داره. کیوب‌پروکسی موظف هست که به نوعی یک virtual ip برای انواع سرویس ( به جز headless که در ادامه توضیح میدیم ) پیاده سازی کنه تا بتونیم با سرویس توی نود‌ها مختلف ارتباط برقرار کنیم.kube-proxy and kubernetes serviceحالا اگه لود بالانس نیاز نداشتیم چی؟ مثلا گاهی نیاز میشه که یک سرویس ip واحد نخواهیم و نیاز نداشته باشیم که کیوب‌پروکسی برامون سرویس رو هندل کنه و لودبالانس انجام بده. مثلا کجا؟headless serviceمثلا یه کلاستر دیتابیس داشته باشیم با ورک‌لود statefulset، در این موارد از مفهومی به اسم Headless Service استفاده می‌کنیم.service vs headless serviceچهار type مختلف سرویس در کوبرنتیز داریم، به ترتیب هر کدوم ویژگی‌های قبلی رو داره و یه سری نکات بیشتر هم داره که در ادامه اونها رو بررسی می‌کنیم:kubernetes service typesClusterIP:نوعی از سرویس که روی ip داخلی کلاستر اسکپوز میکنه سرویس رو کلاسترآی‌پی هست. بنابراین اگه از کلاستر آی‌پی استفاده کنیم سرویس ما فقط درون کلاستر در دسترس هست ازین طریق و type دیفالت سرویس هم همین کلاسترآی‌پی هست.ClusterIPclusteripبرای درک بهتر اهمیت مفهوم سرویس، توی مثال کلاسترآی‌پی بالا تصور کنید که مفهوم سرویس وجود نداشت و هر کدوم از پاد‌های فرانت‌اند به پاد بک‌‌اند متناظرش در سطر پایین‌تر متصل بود و به همین شکل بین بک‌اند و ردیس. حالا اگه یه صورت قطری سه تا پاد از بین بروند هر سه مسیر سرویس‌دهی ما مختل می‌شود در حالیکه با استفاده از سرویس به صورت بالا اگه از سه ‌تا پاد بک‌اند مثلا دوتاش هم بیافته باز سرویس همچنان بالا میمونه.NodePort:تایپ بعدی سرویس توی کوبرنتیز NodePort هست که سرویس رو روی یک پورت ثابت روی همه نودهای کلاستر اکسپوز میکنه، در این حالت میتونیم از بیرون کلاستر هم به سرویس دسترسی داشته باشیم و کافیه که به آی‌پی یکی از نودهای کلاستر و NodePort مورد نظر درخواست بدیم.NodePortمطلبی که مهم هست اینجا تفاوت بین port و nodeport و targetport هست.port vs nodeport vs targetportهمونطور که بالاتر گفتیم پورتی که روی تمام نودهای کلاستر اکسپوز شده NodePort هست، پورتی که واقعا روی اون پاد داره اکسپوز میشه TargetPort هست و نهایتا پورتی که سرویس ما روی اون داره گوش میده رو Port میگیم. دقت کنید که نود پورت تمام فانکشن clusterip رو دارا هست.LoadBalancer:این تایپ سرویس باید امکانش توسط کلاد پروایدر برامون فراهم بشه. با استفاده از این تایپ سرویس میتونیم از طریق لودبالانسر کلاد پروایدر سرویس‌مون رو اکسپوز کنیم به بیرون. به نوعی ویژگی دوتای قبلی یعنی کلاسترآی‌پی و نودپورت رو داره اما Routing رو لودبالانسر کلاد پروایدر برامون انجام میده. یعنی بهمون پابلیک آی پی می ده که از بیرون کلاستر هم قابل دسترس باشه.LoadBalancerExternalName:اگه همون حالت قبلی LoadBalancer رو با یه رکورد CNAME توی dns داشته باشیم، تایپ چهارم سرویس یعنی ExternalName رو داریم.ExternalNameقبل از اینکه ادامه بدیم یه مقدار در مورد سرویس عمیق‌تر شیم، گفتیم سرویس یه مفهوم انتزاعیه و توسط کیوب‌پروکسی پیاده سازی میشه، یعنی مثلا مثل api-server یه کامپوننت کلاستر نیست که بخوایم جداش کنیم و بگیم این سرویس هست. خب کیوب‌پروکسی چجوری پیاده سازی میکنه سرویس رو مثلا؟loadbalancing in iptablesتوی تصویر بالا سه تا پاد رو میبینیم که پشت یه سرویس هستن، کیوب‌پروکسی هم توی این کلاستر با iptables کار میکنه چون می اونه با ipvs هم باشه. همونطور که مشخصه رول‌های iptables رو به شکلی میزنه کیوب پروکسی که از ترافیکی که سمت سرویس میاد اول یک‌سومش بره سمت پاد اول، بعدش از باقی‌مانده ترافیک نصفشم بره سمت پاد دوم و نصف دیگه سمت پاد سوم. به این صورت با استفاده از iptables لودبالانس بین پادهای یک سرویس انجام میشه.خب پس تا اینجا سرویس و انواع اون رو توضیح دادیم، بریم سراغ بقیش :)EndPoint:توی کوبرنتیز API، اندپوینت ریسورسی هست که یه لیست از endpointهای نتورکی رو مشخص میکنه که معمولا یه سرویس برای مشخص شدن پادهایی که باید ترافیک رو سمتشون بفرسته ازش استفاده میکنه.و مفهوم جدیدتری که اومده و پیشنهاد میشه به جای endpoint، مفهوم EndpointSlice هست که یه مسیر ساده تر که قابلیت scale پذیری راحت‌تری هم داره رو برای track کردن اندپوینت‌های نتورکی استفاده میکنه.Endpoint & Endpoint Sliceقبل از اینکه بریم سراغ توضیح Ingress دوتا مفهوم دیگه هم هست که صرفا معرفی‌شون می‌کنیم که بدونیم نباید ازشون استفاده کنیم! چون بست پرکتیس نیست.مفهوم Host Network رو هم توی کوبر داریم که یه جورایی شبیه نتورک هاست داکر هست، یعنی پادی که با Host Network میاد بالا به نوعی به همه‌ی اینترفیس‌های شبکه اون ماشینی که روش اومده بالا دسترسی داره و ایزوله سازی ای در مورد شبکه‌اش اتفاق نیافتاده.HostPort vs NodePortبه همین شکل چیزی مشابه مفهوم پابلیش کردن پورت توی داکر داریم که توی کوبر بهش میگیم Host Port که پورت یه پاد رو مپ میکنه به یکی از پورت های نودی که پاد روش هست، که در این حالت ازون پاد فقط یه دونه باید داشته باشیم چونکه دوتا پروسه نمیتونن با هم bind بشن به یه پورت از طریق Host Port، بنابراین اگه سه تا نود توی کلاسترمون داشته باشیم و بخوایم یه پاد با چهارتا رپلیکا رو به اینصورت دیپلوی کنیم فقط سه تاش اسکجول میشه و چهارمی توی حالت پندینگ میمونه. تفاوتی که با نود پورت داره اینه که تو نود پورت مهم نیست پاد کجا بالا اومده اون پورت روی همه نودها پابلیش می سه ولی تو host port تنها روی همون هاستی که پاد اومده بالا پابلیش می شه.HostPortNetwokPolicy:قبل‌تر گفتیم که میتونیم با استفاده از namespace توی یک کلاستر کوبرنتیز چنتا کلاستر به صورت مجازی داشته باشیم و به مشتری‌های مختلف سرویس بدیم، اما اگه نخوایم مثلا پادهای توی namespace اول بتونن پادهای توی namespace دوم رو ببینن و بهشون دسترسی نداشته باشن چیکار باید بکنیم؟یا مثلا فرض کنید نیاز داریم پادهای یه سرویس کاملا به لحاظ نتورکی ایزوله باشند، در این موارد باید از نتورک پالیسی‌ها توی کوبرنتیز استفاده کنیم.NetworkPolicyبه صورت پیش‌فرض توی کلاستر تمام ترافیک ورودی (ingress) و تمام ترافیک خروجی (egress) به صورت allowed هست و اگه بخوایم میتونیم با استفاده از نتورک پالیسی‌ها flow ترافیک رو کنترل کنیم هم در لول IP و هم در لول پورت یعنی در لایه‌های سه و چهار شبکه این امکان رو داریم که نتورک پالیسی در نظر بگیریم برای اپلیکیشن‌هامون.NetworkPolicyنتورک پالیسی بهمون این امکان رو می ده که ایزولیشن نتورکی ایجاد کنیم. البته باید cni که استفاده می کنید این موضوع رو پشتیبانی کنه وگرنه امکانش براتون فراهم نمی‌شه.Ingress:باتوجه به اینکه توی ایران هنوز کلاد پروایدری که بهمون امکان استفاده از تایپ‌های LoadBalancer و ExternalName نداریم، اگر داریم سرویسی رو روی کلاستر کوبرنتیزمون دیپلوی می‌کنیم که میخوایم اونو به بیرون اکسپوز کنیم و با دامنه در اختیار مشتری قرارش بدیم، بهترین گزینه‌ای که می‌تونیم ازش استفاده کنیم اینگرس هست.ingressاینگرس یه تایپ سرویس نیست، بلکه به نوعی یه روتر هوشمند برای کلاسترمون هست که بهمون این امکان رو میده که ترافیک ورودی رو route کنیم به سمت ریسورسی که میخوایم و همچنین بتونیم چندین سرویس رو پشت یه ip واحد داشته باشیم. یه جورایی مفاهیم ریورس‌پروکسی‌ها رو توی کوبرنتیز میتونیم با استفاده از اینگرس داشته باشیم.ingressبا اینگرس میتونیم توی لایه هفتم شبکه ترافیک رو تفکیک کنیم و از روی path و header و موارد این چنینی در خواست‌هارو جدا کنیم و به سمت پاد‌هایی که میخوایم بفرستیم.اینگرس کنترلر های متفاوت و بزرگی داریم که هر کدوم امکانات متفاوت و متعددی رو در اختیار ما قرار می دن از nginx و traefik بگیر تا کلی چیز دیگه. خوبه در مورد اینگرس بیشتر بخونید چون دنیای بزرگی داره و کلی امکان در اختیار ما قرار می ده.و نهایتا خوبه که PortForwarding رو هم بشناسیم، گاهی پیش میاد که در زمان کار با کلاستر میخوایم برای دیباگ یا بررسی چند لحظه‌ای پورت یکی از پادها رو بیاریم روی لپ‌تاپ خودمون bind کنیم به یه پورت و ببینیمش، اینجا پورت فورواردینگ توی کوبرنتیز بهمون کمک میکنه.kubectl -n <namespace> port-forward <resource_name> <host_port>:<pod_port>​با دستور بالا میتونیم این کار رو انجام بدیم و وضعیت اون پورت از پادی که مدنظرمون هست رو بررسی کنیم.Port-Forwardingدقت کنید که پورت فورواردینگ قط برای تیشوت مناسبه و کاربرد داره و برای سرویس دهی اصلا روش مناسبی نیست. ولی برای تیشوت راهکار خیلی خوب و دم دستی هست.در ادامه مسیر میریم سراغ ادامه مطالب کوبرنتیز و موارد مربوط به استورج رو بررسی می‌کنیم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شویدخوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 07 Dec 2024 03:35:40 +0330 https://virgool.io/@rafiee/%D8%A7%DA%AF%D9%87-%D9%84%D8%A7%D8%B2%D9%85-%D8%B4%D8%AF-%DA%A9%D9%88%D8%A8%D8%B1-%D8%AE%D9%88%D8%AF%D8%B4-%DA%AF%D9%86%D8%AF%D9%87-%D9%85%DB%8C%D8%B4%D9%87-%D9%82%D8%B3%D9%85%D8%AA-%D8%B4%D8%B4%D9%85-js66c48xxzwn توی این پست میریم سراغ بررسی استراتژی‌های مختلف دیپلویمنت‌ توی کوبرنتیز و بعدشم ورک‌لودهای مربوط به Auto Scaling رو بررسی می‌کنیم.kubernetes autoscalingخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.اگه یادتون باشه توی بلاگ پست قبلی گفتیم که ورک‌لودی توی کوبرنتیز داریم به اسم deployment که همون replicaset هست با این تفاوت که بهمون versioning و deployment strategy میده.حالا بریم استراتژی‌های مختلف دیپلویمنت رو با هم بررسی کنیم.deployment strategies1 - Recreate:استراتژی اول به این شکل هست که اگه ما بخواهیم بریم به سراغ ورژن بعدی، ابتدا تمام پادهایی که از ورژن حاضر داریم رو از بین ببریم و بعدش شروع کنیم از اول نسخه‌ جدید اونها رو بیاریم بالا، اولین نکته منفی این روش که احتمالا متوجه‌ش شدید اینه که داون تایم میدیم، یعنی سرویس‌مون در فاصله بین از بین رفتن پادهای قدیم تا ایجاد پادهای جدید، از دسترس خارج میشه و نکته دیگه اینکه اگه به هردلیلی نیاز پیدا کنیم که برگردیم به نسخه قدیم و roll back کنیم، این فرآیند زمانبر خواهد شد. اما از طرف دیگه این روش کم‌هزینه هست برامون و با همون منابع قبلی قابل انجام هست و به نسبت بقیه استراتژی‌ها پیچیدگی کمتری رو داره. این استراتژی بیشتر برای statefulها کاربرد داره که می‌خواهیم کسی که با دیتا کار می‌کنه کامل بیاد پایین و بعد بعدی شروع کنه. یعنی کاربرد خودش رو داره.recreate2 - Rolling Update:استراتژی بعدی که یکی از متداول‌ترین استراتژی‌ها هم هست، rolling update یا ramped هست. توی این روش می‌تونیم مشخص کنیم که با چه طول گامی، قدم‌های این آپدیت برداشته بشه. مثلا بگیم اول چند درصد پادهارو با نسخه جدید جایگزین کن بعد برو سراغ بقیه. یا مثلا بگیم سه تا سه تا اینارو جدید کن. یه مقدار کمی به نسبت روش recreate پیچیدگی بیشتری داره اما در عوض داون تایم نمیدیم و مشتری رو تحت تاثیر نمیذاره و هزینه کمی هم به نسبت داره اما بازهم در صورت مشکل و نیاز به rollback به نسخه قبلی، این روش زمانبر هست. متداول‌ترین استراتژی هست که برای statelessها استفاده می‌شود. خیلی کاربردی و خوبه و کمک می‌کنه که بدون اینکه مشتری چیزی متوجه بشه تمام سرویس جدید رو با قدیمی عوض کنیم.rolling update3 - Shadow:این روش که پیچیدگی زیادی رو هم به نسبت دوتای قبلی داره به این صورت هست که ما درکنار نسخه حاضرمون که داره کار میکنه، پادهای نسخه جدید رو هم میاریم بالا که تا همینجاش میشه هزینه‌بر بودن این روش رو متوجه شد چون به دو برابر منابع نیاز داره. بعدش که با ترافیک واقعی یوزرهامون نسخه جدید رو تست کردیم، در لحظه مثلا لیبل‌های سرویس رو عوض می‌کنیم و کل ترافیک رو به سمت پادهای جدید میفرستیم. زمان rollback توی این روش بسیار پایینه و مشتری رو تحت تاثیر قرار نمیدیم و داون تایم نداریم. تو shadow ما داریم با لود ترافیک واقعی سیستم جدید رو تست می‌کنیم ولی پاسخ مشتری رو از طریق سیستم قبلی می‌دیم.shadow4 - Canary:روش قناری از همون ایده تست قناری که توی بلاگ پست‌های قبلی توضیح دادیم استفاده میکنه و به لحاظ پیچیدگی بین روش‌های ساده recreate , rolling update و روش‌های پیچیده shadow , A/B testing قرار میگیره. توی این روش یه درصد کمی از ترافیک رو مثلا ۱۰ درصد سمت ورژن جدید میفرستیم و بعد از اینکه از عملکردش اطمینان حاصل کردیم به صورت کامل با ورژن قبلی جایگزینش می‌کنیم. هزینه این روش به نسبت shadow کمتره چون در لحظه دو برابر منابع رو مصرف نمی‌کنیم و زمان rollback پایینی داره چون تنها درصد کمی از ترافیک اصلی رو سمت نسخه جدید بردیم. کلا هم از نظر هزینه و هم از نظر پیچیدیگی بین تمام استراتژی‌ها هست. می‌تونیم قسمتی از مشتری‌ها رو با سرویس جدید تست و بررسی کنیم و بعدش اگر همه چیز خوب بود سرویس جدید رو با قبلی عوض کنیم. برای این استراتژی نیاز به پیاده‌سازی داریم ولی بدون اون هم می‌شه با لیبل‌ها و سلکتور یه کارهای کرد.canary5 - Blue - Green:بلوگرین یکی از مرسوم‌ترین استراتژی‌هایی است که استفاده می‌شه. این طوری هست که یه نسخه‌ مثل نسخه‌ی اصلی میاریم بالا و در یه لحظه تمام درخواست‌ها رو می‌فرستیم سمت نسخه‌ی جدید. اینجا هم هزینه‌مون بالاتر هست چون دو برابر منابع مصرف می‌کنیم، زمان rollback بسیار پایینه و در حد عوض کردن لیبل‌های سرویسه، یه جورایی با درخواست‌های واقعی نسخه جدید رو تست می‌کنیم. برای این استراتژی هم نیاز داریم که پیاده‌سازی داشته باشیم ولی خودمون می‌تونیم با چند تا لیبل و اینا ردیفش کنیم. استراتژی خوبی هست زمانی که مشکل منابع نداریم و تغییرات سریع مد نظرمون هست.Blue-Green6 - A/B Testing:فرض کنید ما یه فیچر جدید به سرویس‌مون اضافه کردیم که مربوط به کاربران موبایل هست، یا مثلا مربوط به مشتری‌هایی هست که از مرورگر خاصی استفاده می‌کنند. برای اینکه این نوع تغییرات رو ببریم به نسخه جدید نیاز هست که اصطلاحا targeted user رو تست کنیم و بعد چنج بزنیم. توی این روش ابتدا درصدی از ترافیک واقعی یوزرهای مشخص شده‌ای رو سمت نسخه جدید میفرستیم و بعد از تست نسخه جدید رو دیپلوی می‌کنیم. این روش مانند روش‌های shadow و blue-green هزینه‌بر نیست و زمان rollback پایین داره اما پیچیدگی این روش به نسبت زیاد هست چونکه باید از مفاهیم service mesh و ابزارهایی مثل istio برای تارگت کردن یوزرهای خاص استفاده کنیم. یکی از استراتژی‌هایی هست که برای پیاده‌سازی آن نیاز به ابزار با پیچیدگی زیادی داریم.A/B Testingیه جدول مقایسه روش‌های مختلف رو در ادامه براتون میذارم. تو این جدول خیلی خوب این استراتژی‌ها رو باهم مقایسه کرده. مقایسه‌ی خوبی که از هزینه‌ی پیاده‌سازی تا تاثیرگذاری روی کاربر یا زمان رول‌بک رو مقایسه کرده. جدول خوبی هست با دقت بررسیش کنید.kubernetes strategiesAutoScalingAutoScalingتوی کوبرنتیز سه مدل AutoScaler داریم، HPA که تعداد رپلیکا رو scale میکنه، VPA که ریسورس و منابع کانتینرها رو scale میکنه و CA که تعداد نودهای کلاستر رو scale میکنه.HPAاز HPA یا Horizontal Pod Autoscaler برای scale out کردن سرویس‌مون استفاده می‌کنیم، زمانیکه ورک‌لود HPA رو برای دیپلویمنت‌مون تعریف می‌کنیم، مشخص می‌کنیم که مثلا اگه مصرف منابع پادهای این سرویس به ۸۰ درصد رسید اون رو تا سقف مثلا ۳۰ عدد میتونی scale out کنی و تعدادش رو بیشتر کنی و برعکس زمانیکه اون تعداد نیاز نبود تعداد پادهای این سرویس رو کم کن ولی حداقل پنج تا ازش بالا باشه.کنترلر HPA با کمک متریک‌سرور توی کلاستر محاسبات لازم رو انجام میده و تغییرات مورد نیاز رو روی deployment میزنه تا به حالت مطلوب‌مون برسیم. کلا برای Auto Scaling حضور و وجود متریک‌سرور الزامی هست.نکته دیگه در مورد HPA این هست که به صورت دیفالت همراه کوبرنتیز هست و برای استفاده ازش توی کلاسترمون نیاز به کار اضافه‌ای نداریم.HPAبرای مثال به تصویر زیر توجه کنید تا نحوه محاسبه HPA رو بررسی کنیم.hpa calculate replicaدر مثال بالا ما تارگت ۵۰ درصد رو برای مصرف CPU و تارگت ۲۰ رو برای تعداد درخواست‌های یک پاد در ثانیه مشخص کردیم، حالا متریک سرور اطلاعاتی رو از سه تا پاد اون سرویس به HPA داده، برای محاسبه تعداد لازم hpa میاد مصرف CPU هارو جمع میشه و به میزان مطلوب تقسیم میکنه. که در این مثال برای CPU میشه چهار، در واقع الان ما به ۲۰۰ واحد مصرف CPU مثلا با واحد (میلی کور) نیاز داریم و میدونیم که میخوایم نهایتا با واحدهای مصرف ۵۰ تایی این نیاز رو پوشش بدیم، پس تعداد پادی که نیاز داریم چهار هست، به همین ترتیب برای تعداد درخواست‌ها در ثانیه به عدد سه میرسیم و نهایتا برای اینکه هر دو شرط برقرار بشه از حاصل محاسبات ماکسیمم می‌گیریم.معمولا برای HPA باید چهار تا پارامتر رو مشخص کنیم. اول اون ریسورسی که میخوایم scale ش کنه، مثلا دیپلویمنت سرویس‌مون. دوم حداقل و حداکثر تعداد رپلیکا که باید در اون محدوده حرکت کنیم مثلا حداقل سه تا و حداکثر ۳۰ تا. سوم متریکی که بر اساس اون scale کنیم مثلا میزان مصرف ram و نهایتا چهارم تارگتی که برای اون متریک داریم مثلا ۸۰ درصد ram پاد مصرف بشه.VPAVPAاز VPA یا Vertical Pod Autoscaler برای scale up کردن سرویس‌مون استفاده می‌کنیم. VPA به صورت دیفالت روی کلاستر نیست و باید اون رو جداگانه اضافه کنیم و بعد از اینکه VPA روی کلاسترمون نصب شد بهمون این امکان رو میده تا برای ورک‌لودهامون CRD بسازیم که تعریف کنه چه زمانی و چه میزان ریسورس‌های اون پادهارو scale بشه. برای اینکه به صورت in-place منابع پاد scale بشن نیاز داریم که روی کوبر v1.27 به بالا باشیم و InPlaceVerticalScaling هم فعال شده باشه توی کلاستر.چهارتا update mode داره VPA که در ادامه به اختصار اونها رو توضیح میدم:offتوی این حالت VPA فقط پیشنهادش برای منابع مصرفی رو بهمون میده و اون رو اعمال نمیکنه. این ریکامندیشن یکی از فانکشن‌های خیلی کاربردی VPA هست که خیلی می‌تونه کمک کنه و در زمان‌هایی که نمی‌دونیم چقدر باید منابع برای سرویس‌مون در نظر بگیریم بهمون کمک می‌کنه.initialتوی این مود VPA تنها زمان ساخته شدن پاد ریسورسی که محاسبه کرده رو به پاد assign میکنه و دیگه تغییرش نمیده.recreateتوی این مود VPA ریسورس رو به پادهای جدیدی که ساخته میشن اعمال میکنه و پادهایی که از قبل بالا بودن رو از بین میبره و با ریسورس جدید بالا میارهauto modeدر حال حاضر این مود مثل recreate کار میکنه اما در ورژن‌های بعدی قراره به این شکل بشه که بدون recreate کردن پادها درجا ریسورس اونها رو تغییر بده. یعنی الان قسمت auto داره کار نمی‌کنه و قراره تو نسخه‌‌های بعدی این موضوع درست بشه.VPAکلا سه تا بخش داره VPA برای اینکه عملکرد scale up کردن رو بهمون بده، اول admission controller هست که هر پادی که میاد توی کلاستر از این رد میده تا چک کنه که آیا این پاد برای خودش یا ورک‌لودی که بالای سرش هست VPA تعریف شده یا نه. بخش دوم VPA Recommender هست که متصل میشه به متریک‌سرور و دیتای مربوط به تاریخچه مصرف و مصرف الان پاد رو میگیره و بر اساس اون یه خروجی پیشنهادی برای میزان ریسورس درخواستی پاد و لیمیت اون بهمون میده و نهایتا بخش سوم که VPA Updater هست که هر یک دقیقه ران میشه و اگه پادی که داره ران میشه توی اون رنج مشخص شده توسط VPA Recommender نباشه اون رو میکشه تا دوباره در فرآیند بالا اومدن با ریسورس آپدیت شده بالا بیاد. البته قراره قستم Auto هم درست بشه که دیگه این VPA به صورت خودکار انجام بشه.CAاین نوع از Autoscaler ها رو زمانیکه کوبرنتیز رو از کلاد پروایدر سرویس بگیریم و اون کلاد پروایدر قابلیتش رو بهمون بده میتونیم استفاده کنیم، به این شکل که مثلا تعریف می‌کنیم که در زمان لازم تعداد نودهای کلاسترمون رو بیشتر کنه، مثلا به AWS بگی که زمان جشنواره یا پیک فروش یا موارد مشابه ... اگه نیاز شد نودهای ورکر کلاستر من رو تا سقف ده تا زیاد کن. اونوقت میگن خدا نیست :)CAبا استفاده از CA ما می‌تونیم کلاستر کوبرنتیز خودمون رو Scale کنیم که خیلی قابلیت خوبی هست و این امکان باعث می‌شه که در زمان مورد نیاز وقتی منابع داخل کلاستر رو به انتها هست اون رو بزرگ کنیم و وقتی لود از کل کلاستر برداشته می‌شه اون رو کوچیک کنیم. دنیای جالبی هم اینجا وجود داره که چطور یه نود رو اضافه کنه و چطور اون رو خالی نگه داره یا رزرو کنه و کلی داستان دیگه که این جا داریم. تو ادامه‌ی مسیرمون میریم سراغ نتورک کوبرنتیز 🔥مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شویدخوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 30 Nov 2024 10:12:14 +0330 https://virgool.io/@rafiee/%D9%88%D8%B1%DA%A9-%D9%84%D9%88%D8%AF%D9%87%D8%A7%DB%8C-%DA%A9%D9%88%D8%A8%D8%B1-%D9%88-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%85%D9%86%D8%A7%D8%A8%D8%B9-%DA%A9%D9%88%D8%A8%D8%B1-%D9%82%D8%B3%D9%85%D8%AA-%D9%BE%D9%86%D8%AC%D9%85-zkdkrjoech08 توی این قسمت میخوایم ورک‌لودهای کوبرنتیز رو باهم بررسی کنیم اما قبلش با هم namespace و resource quota رو میبینم و در مورد مدیریت منابع کلاستر توضیح میدیم.kubernetes workloadخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.در محیط‌های Kubernetes، مدیریت منابع و جداسازی پروژه‌ها و تیم‌ها از اهمیت ویژه‌ای برخوردار است. استفاده از Namespaces، Resource Quotas و LimitRange ابزارهایی قدرتمند برای دستیابی به این اهداف بهمون میده.کوبرنتیز Namespace:کوبرنتیز می‌تواند از قابلیت ارائه چندین کلاستر به صورت مجازی پشتیبانی کند در حالیکه به صورت فیزیکی پشت اونها یک کلاستر مشابه باشد. به هر کدوم ازین کلاستر‌های مجازی میگن یه namespace.بنابراین با استفاده از نیم‌اسپیس میتونیم منابع کلاستر رو بین چندین یوزر تقسیم کنیم. نیم‌اسپیس‌هایی که اول اسمشون با -kube شروع میشه مربوط به سیستم کوبرنتیز هستن و ما نباید اسم نیم‌اسپیس‌هایی که میسازیم رو ازاین فرمت انتخاب کنیم. نه اینکه نتونیم بلکه بهتره که این کار رو نکنیم.Kubernetes Namespacesموقعی که کلاستر رو ستاپ می‌کنیم چهارتا نیم‌اسپیس اولیه داره که در ادامه اونارو به اختصار بررسی می‌کنیم:default:یکی از نیم‌اسپیس‌هایی هست که به صورت پیش‌فرض هست و هیچی داخلش نیست و ما می‌تونیم سرویس‌های خودمون رو اونجا داشته باشیم. تنها یه سرویس داخلش ساخته شده. نیم‌اسپیس پیش‌فرض کوبرنتیز نیز می‌باشد.kube-system:این نیم‌اسپیس برای آبجکت‌هایی که توسط سیستم کوبرنتیز ایجاد شدن استفاده میشه.kube-public:این نیم‌اسپیس به صورت خودکار ایجاد میشه و برای تمام یوزرها حتی اونایی که authenticate نشدن توسط کلاستر قابلیت خواندن داره. دقت کنید که این نیم‌اسپیس به صورت قراردادی با این نام ایجاد شده و وجودش اجباری نیست.kube-node-lease:این نیم‌اسپیس Lease آبجکت‌هارو توی هرنود نگهداری میکنه. نود لیزها به kubelet امکان اینو میدن که heartbeats بفرستن تا control plane بتونه failure های نود رو تشخیص بده.بنابراین Namespace در Kubernetes به عنوان یک مکانیزم برای تقسیم‌بندی منابع در یک کلاستر عمل می‌کند. هر Namespace می‌تواند به عنوان یک محیط مجزا برای یک تیم یا پروژه خاص در نظر گرفته شود که امکان مدیریت مستقل منابع را فراهم می‌کند.بررسی Resource Quota:توی کوبرنتیز Resource Quotas امکانی برای محدود کردن مصرف منابع در یک Namespace خاص هستند. این قابلیت به مدیران سیستم اجازه می‌دهد تا از استفاده بیش از حد منابع توسط تیم‌ها یا پروژه‌ها جلوگیری کنند و منابع را هر طور که تمایل داشتن بین آن‌ها تقسیم کنند.کنترل مصرف منابع مثل محدود کردن میزان CPU، حافظه، فضای دیسک و دیگر منابع ، جلوگیری از این که یک تیم یا پروژه بتواند منابع کل کلاستر را مصرف کند و اختلال در ح-هکلاستر ایجاد کند، از مزایای ریسورس‌کوتا هستن.ResourceQuota & LimitRangeبررسی Limit Range:توی کوبرنتیز LimitRange ابزاری برای تعیین محدودیت‌های پیش‌فرض و حداکثر/حداقل منابع برای پادها و کانتینرها در یک Namespace است. این قابلیت تضمین می‌کند که هر پاد یا کانتینر حداقل و حداکثر منابع مشخصی مصرف کند. بنابراین با استفاده از LimitRange می‌تونیم مصرف منابع یک پاد رو کنترل کنیم که زیاد نشه.LimitRange & ResourceQuotaپس با ریسورس کوتا منابع نیم‌اسپیس و با لیمیت‌رنج منابع پادهای داخل نیم‌اسپیس رو میتونیم کنترل کنیم و براشون سقف و کف بذاریم. این موضوع خیلی مهمه و همیشه‌ سعی می‌کنیم در کنار ایجاد namespace این دو تا ریسورس مهم رو هم ایجاد کنیم. با این کار کمک می‌کنه که مدیریت بهتری روی منابع کلاستر خودمون داشته باشیم.توی قدم بعدی میریم سراغ ورکلودهای کوبرنتیز ...ورک‌لودهای کوبرنتیز:kubernetes workloadsگفتیم پاد واسه کوبرنتیز میشه، مجموعه یک یا چند کانتینر که داره روی کلاستر ران میشه. حالا ورک‌لود یه اپلیکیشن‌ هست که داره روی کلاستر ران میشه که ممکنه یک کامپوننت باشه یا چنتا کامپوننت که با هم کار میکنن در قالب یه مجموعه‌ای از پادها.هر پادی توی کلاستر یه lifecycle داره، مثلا موقعی که یه پاد داره روی کلاستر ران میشه و به یه مشکل مثل fault توی نودی که این پاد روش اومده بالا میخوره، معنیش اینه که تمام پادهای رو اون نود fail می‌کنند و نهایتا رفتاری که باید کوبرنتیز نشون بده این هست که به جای پادهایی که خراب شدن، پاد جدید ایجاد کنه روی کلاستر حتی اگه بعدا اون نود که به fault خورده برگرده به حالت healthy. حالا برای اینکه کارمون رو راحت‌تر کنیم نیازی نیست بریم مستقیم با پادها کار کنیم.میتونیم از ورک‌لودها به جاش استفاده کنیم. از طریق اونها میتونیم کنترلرهایی رو کانفیگ کنیم که همیشه حواسشون باشه که تعداد مطلوبی از پادها بالا باشه. دقت کنید نه تنها می‌تونیم بلکه باید از ورک‌لودها استفاده کنیم. برای اینکه بتونیم از controller manager و قابلیت‌های آن استفاده کنیم نیاز داریم که حتما از ورک‌لود‌ها استفاده کنیم. توی کوبرنتیز به صورت built-in تعدادی ورک‌لود داریم که در ادامه تعدادی از اونها رو با هم بررسی می‌کنیم.ReplicaSetreplicasetتوی رپلیکا ست هدف اینه که یه تعداد مشخصی از پادهای سرویس‌مون همیشه بالا باشه و یه کنترلر می‌سازه که حواسش به تعداد این پاد باشه، بنابراین از ReplicaSet بیشتر جاهایی که میخوایم در دسترس بودن تعداد مشخصی از یک پاد گارانتی کنیم، استفاده می‌کنیم. این ورکلود ساده‌ترین و دم دستی ترین ورکلود کوبرنتیز هست و تنها کاری که می‌کنه اینه که حواسش به تعداد رپلیکا هست و اون رو کنترل و مدیریت می‌کنه.replicasetDeploymentdeploymentدیپلویمنت همون رپلیکاست هست ولی با دوتا فرق مهم، هم حافظه داره و هم میشه باهاش حرف زد!!! البته برای اینکه راحت‌تر درکش کنیم این‌طوری می‌گیم.حافظه داره یعنی اینکه versioning داره و بهمون قابلیت rollout و rollback میده، مثلا وقتی یه نسخه‌ی جدید از اپلیکیشنمون می‌دیم و ایمیج اون دیپلویمنت رو آپدیت می‌کنیم اگر خواسته باشیم می‌تونیم برگردیم به استیت قبلی و ایمیج قبلی خودمون و بریم روی نسخه‌ی قبلی. یه نکته‌ی مهم اینکه دیپلویمنت برای اینکه بتونه این history رو داشته باشه خودش داره از ReplicaSet استفاده می‌کنه و با استفاده از آن این کار رو انجام می‌ده.میشه باهاش حرف زد یعنی اینکه deployment strategy بهمون میده، مثلا میتونیم بهش بگیم اگه من تغییری توی این سرویس دادم و ازش ده تا پاد بالا هست شما اول دوتاشو بیار پایین و دوتا جدید رو جایگزینش کن و بعد دوتای بعدی و ... یا اینکه بگیم اول همه ده تا رو بزن نابود کن و بعدش ده تا از جدیده بیار بالا و ... این استراتژی‌ها خیلی کمک می‌کنه که بتونیم بهترین عملکرد رو در تغییرات داشته باشیم.در ادامه مسیر انواع استراتژی‌هارو توضیح میدیم.deploymentدقت کنید که وقتی میگیم مثلا دیپلویمنت گارانتی میکنه یه تعداد مشخصی از پادهای سرویس‌تون رو، منظور این نیست که دیگه شما یه دیپلویمنت بزنی دیگه بعدش میتونی دست رو قرآن بذاری که داون نمیشه هیچ‌وقت!!! دیپلویمنت کاری که میکنه اضافه کردن یه کنترلر هست که اون تعداد رو چک کنه ولی اگه فرآیند بالا اومدن پادهای دیپلویمنت fail بشه که اصلا بعید نیست دیگه دیپلویمنت کاریش نمیتونه بکنه که دلایل مختلفی هم میتونه داشته باشه این مساله، مثلا ممکنه resource quota و limit range جلومون رو بگیره یا توی pull کردن ایمیج به ارور بخوریم که اتفاقا بسیار متداول هست برای ماهایی که این سمت آب‌های نیلگون هستیم یا مثلا دیپلویمنت permission های کافی رو نداشته باشه یا readiness probe ها fail کنن یا کانفیگ اشتباه منجر به درست کار نکردن اپلیکیشن در runtime بشه و ...دیپلویمنت تنهای موقعی rollout میکنه و میره ورژن بعدی که تغییری توی پاد تمپلت اونو تریگر کنه مثلا لیبل‌ها آپدیت بشن یا ایمیج کانتینرهاش تغییر کنن، آپدیت های دیگه مثل scale کردن دیپلویمنت منجربه تریگر کردن rollout نمیشه.DaemonSetdaemonsetفرض کنید که میخوایم از یه پادی روی همه نودهای کلاستر داشته باشیم، مثلا اگه یه نود به کلاستر اضافه شد یه دونه ازون پاد هم بره روش، مثلا برای یه سرویسی مثل ایجنت مانیتورینگ همچین نیازی داریم یا برای دیمن استورج یا سیستم لاگینگ. دیمن‌ست کارش همینه، که مطمئن شه روی همه نود‌های کلاستر یه نسخه از پادی که بهش گفتیم بالا هست و اگه نود پاک شه و از مدار خارج بشه یکی از رپلیکای آن هم کم می‌شه. یعنی به زبان ساده تعداد رپلیکای ما به تعداد نودهای ما وابسته هست.ممکنه یه سوال اینجا پیش بیاد که فرقش با static pod چیه؟ پاسخ این هست که درسته که هم استاتیک پاد و هم دیمن‌ست اسکجولر کوبرنتیز را ignore می‌کنند و روی همه نودهایی که باشن بالا میان ولی تفاوت اینجاست که استاتیک پاد رو kubelet بالا میاره و اصلا به کنترل پلین نیازی نداره و بیشتر برای دیپلوری کردن کامپوننت‌های control plane ازش استفاده می‌کنیم ولی دیمن‌ست رو Api-Server بعد از درخواست کنترلر دیمن‌ست می‌سازه و روند ساختش مثل پادهای عادی هست و همون مسیر رو طی میکنه و ازش بیشتر برای ایجنت‌های مانیتورینگ و لاگ و ... استفاده می‌کنیم.daemonsetStatefulSetstatefulsetاین ورک‌لود همونطوری که از اسمش مشخصه اومده تا برای دیپلوی کردن اپلیکیشن‌های stateful بهمون کمک کنه. به نوعی شبیه دیپلویمنت برامون یه دسته از پاد رو گارانتی میکنه که بالا باشه اما مشخصه‌ای که داره ordering و uniqueness پادهاش هست و به ترتیب میاد بالا یا اگه پاک کنیم به ترتیب شماره از آخر شروع میکنه به پاک کردن، که این مساله بهمون کمک میکنه تا بتونیم با استفاده از statefulset اپلیکیشن‌های stateful رو روی کلاسترمون دیپلوی کنیم.چنتا نکته که درمورد statefulset خوبه حواسمون بهش باشه:اگه یه statefulset رو پاک کنیم یا scale down کنیم، والیوم‌هایی که بهش داده شده بود پاک نمیشن که به نظرم این چیز بدی نیست ولی اگر ندونیم بد چون ممکنه مجدد اسکیلش رو زیاد کنیم و بیاد از همون والیوم قبلی استفاده کنه. پس بهش دقت کنیم.برای ارتباط با پادهای statefulset از headless service باید استفاده کنیم که در بخش نتورک در ادامه مسیر بیشتر توضیح خواهم داد در موردش. به زبان ساده سرویسی هست که لودبالانس نمی‌کنه و همه‌ی درخواست‌های ما رو به یکی از پادها می‌رسونه.هیچ گارانتی وجود نداره که اگه statefulset رو پاک کنیم پاد‌های اون هم terminate میکنن و از بین میرن.پادهایی که بالا میان hostname شون از یه الگو پیروی میکنه که شامل نام stateful و شماره ترتیب پاد هست، به این صورت هر پاد نام یونیکی داره.statefulsetJob & CronJobkubernetes jobیک جاب توی کوبر میاد یک یا چند پاد رو میسازه و انقدر این کار رو تکرار میکنه تا یه تعداد مشخصی از اونها به صورت موفق terminate کنند و اجراشون تموم بشه. زمانی‌که پادهای با موفقیت کامل بشن جاب هم کامل شده. حالا همون جاب رو اگه بخوایم سر یه تایم‌های مشخصی اجراش تکرار بشه از cronjob استفاده می‌کنیم، یوزکیسش میشه مثلا بکاپ گرفتن از یه دیتایی به صورت هفتگی.kubernetes cronjobدر ادامه مسیرمون میریم سراغ استراتژی‌های مختلف دیپلویمنت و ورک‌لودهای مربوط به auto scaling در کوبرنتیز رو بررسی می‌کنیم. 🌹مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شویدخوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 23 Nov 2024 14:22:20 +0330 https://virgool.io/@rafiee/%D9%BE%D8%A7%D8%AF%D9%87%D8%A7-%D9%88-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%A7%D9%88%D9%86%D9%87%D8%A7-%D8%AF%D8%B1-%DA%A9%D9%88%D8%A8%D8%B1%D9%86%D8%AA%DB%8C%D8%B2-%D9%82%D8%B3%D9%85%D8%AA-%DA%86%D9%87%D8%A7%D8%B1%D9%85-hcd4tgchlboa توی این پست میریم سراغ پادها توی کوبر و اونها رو بیشتر میشناسیم و بررسی‌شون می‌کنیم.Kubernetes Podsخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.ساختار پادها و جزئیات اجزای آن (Containerها، Volumeها)podپاد (Pod) کوچک‌ترین واحد اجرایی در کوبرنتیز است که یک یا چند کانتینر را در بر می‌گیرد. کانتینرها درون یک پاد منابع شبکه و فضای ذخیره‌سازی را به اشتراک می‌گذارند. درون هر پاد ممکنه یک یا چند کانتینر و یک یا چند والیوم باشه اما کوچکترین واحدی که کوبرنتیز اونو کنترل میکنه پاد هست.هر کانتینر یک اپلیکیشن یا سرویس را اجرا می‌کند. آنها بر اساس ایمیج‌های داکر ساخته می‌شوند و درون پاد با یکدیگر ارتباط دارند.والیوم‌ها فضای ذخیره‌سازی مشترکی هستند که بین کانتینرهای یک پاد به اشتراک گذاشته می‌شوند. آنها برای حفظ داده‌ها در صورت ازبین رفتن یا جابجایی کانتینرها استفاده می‌شوند.پادهایی که بیش از یک کانتینر دارند به عنوان پادهای مالتی‌پل کانتینر شناخته می‌شوند. این کانتینرها برای انجام وظایف مکمل در کنار هم اجرا می‌شوند.معمولا توی کوبرنتیز پاد رو به صورت مستقیم نمیسازن حتی پادهایی که یه دونه هستن، به جاش پادهارو با استفاده از ورکلودهایی مثل Deployment و Job میسازن یا اگه نیاز باشه که state پاد رو track کنیم از StatefulSet استفاده میشه. هر پاد معمولا یک اینستنس از اپلیکیشن مورد نظر رو توی خودش داره و سرویس میده و در صورتی‌ نیاز باید تعداد بیشتری از این پادها بالا بیاریم که به این کار رپلیکیشن میگن و معمولا پادهایی که نیاز داریم تعدادشون بیشتر باشه رو Replicated می‌کنیم و با یک ورکلود و کنترلرش اونها رو منیج می‌کنیم.sidecarinitکانتینر Sidecar:معمولا توی پادهایی که چنتا کانتینر دارند یکیشون هست که داره سرویس اصلی رو میده و باقی کانتینر‌ها یه جورایی دارن کارای جانبی اون یک کانتینر اصلی رو میکنن، مثلا لاگی رو جنریت میکنن یا فایلی رو براش آپدیت میکنن و ... به اون کانتینرهای کناری میگن سایدکار.بررسی Init Containerinit containerتوی صنعت بعضی کارخونه‌ها یه سری موتورهای خیلی بزرگ دارن که یکی از دغدغه‌های اصلی در مورد اونها روشن کردنشون هست! چون اگه اونها رو مستقیم از حالت سکون به برق وصل کنیم تا شروع به کار کنند، توان مصرفی بسیار بالایی نیاز هست و معمولا تامین اون برق ممکن نیست. به عنوان راه حل میان از یک موتور کوچیکتر در کنار اون بزرگه استفاده میکنن و اول اون کوچیکه رو روشن میکنن تا با کمک اون موتور بزرگ اصلی رو به یه گشتاور حداقلی برسونن و بعد دیگه موتور اصلی رو به برق وصل می‌کنن. به اون موتور کوچیکه میگن اینیت موتور :)اینیت کانتینرها هم همینجوری هستن، کانتینرهایی هستند که قبل از کانتینرهای اصلی در یک پاد اجرا می‌شوند و کارهای اولیه مانند تنظیمات یا انتظار برای منابع خارجی رو انجام میدن تا بعد از اونها کانتیر اصلی کارش را انجام دهد.تا زمانی که همه Init Containerها تکمیل نشوند، کانتینرهای اصلی شروع به کار نمی‌کنند.مثلا یک Init Container که قبل از اجرای اپلیکیشن، فایل‌های پیکربندی را دانلود و آماده می‌کند.بررسی Static Podstatic podتوی پست‌های قبلی توضیح دادیم که درخواست ایجاد پاد به api-server میرسه و بعد scheduler نود مقصد رو مشخص میکنه و بعد api-server درخواست ایجاد این پاد رو میده به kubelet رو اون نود تا ایجاد بشه. اما خود api-server و scheduler هم پاد هستن، خود اینارو کی میاره بالا ؟!! اینجاست که سرو کله‌ی استاتیک پاد پیدا میشه، کیوبلت میگه آقاجان من اصلا کاری ندارم api-server چی میگه و ... اگر مانیفست پادی رو توی مسیر/etc/kubernetes/manifestsببینم، اونو میارم بالا ! استاتیک پادها پادهایی هستند که مستقیماً توسط Kubelet در هر نود ایجاد می‌شوند، بدون اینکه در API سرور ثبت شوند. پس ما میتونیم api-server و ... که نیاز داریم بیان بالا با استفاده از استاتیک پاد ایجادشون کنیم. یا مثلا ممکنه برای اجرای سرویس‌های خیلی حیاتی ازش استفاده کنیم. دقت کنید این پاد ها بدون کنترل پلین و فقط توسط kubelet اجرا می شوند.بررسی و توضیح Pod Templatepod templateپاد تمپلت یک قالب است که مشخصات پادها را تعریف می‌کند و در منابعی مانند Deployment، ReplicaSet و ... استفاده می‌شود.مثلا در یک Deployment، از Pod Template برای تعریف نسخه جدید اپلیکیشن استفاده می‌شود تا در هنگام به‌روزرسانی، پادهای جدید با این قالب ساخته شوند.بررسی pod phase:pod phaseپادها توی کوبرنیز میتونن توی حالت‌های مختلفی قرار بگیرن که در ادامه هرکدوم رو به اختصار توضیح میدیم.Pending:زمانیکه یه پاد توسط کوبرنتیز پذیرفته شده اما هنوز یک یا چندتا از کانتیرهای اون پاد آماده نشده باشند، حالا به دلیل اینکه ایمیج‌شون دانلود نشده یا مثلا هنوز اسکجولر تکلیفشون رو مشخص نکرده و ... میگیم که این پاد پندینگ هست.Running:زمانیکه یه پاد به یک نود مشخص باند شده باشه و تمام کانتینرهای اون ساخته شدن باشند و حداقل یکی از اونها در حال ران شدن باشه یا پروسه ای رو توی حالت start داشته باشه میگیم که این پاد رانینگ هست.Succeeded:زمانیکه تمام کانتینرهای توی پاد به صورت موفق terminate شده باشند و ری‌استارت هم نشده باشند میگیم که پاد ساکسیدد شده.Failed:زمانیکه تمام کانتینرهای توی پاد terminate شده باشند و حداقل یکی‌شون توی حالت failure بوده باشه زمان terminate شدن، حالا یا با exit code جز صفر terminate شده باشه یا اینکه توسط سیستم فرقی نمیکنه. توی این حالت میگیم که پاد فِیل شده.Unknown:زمانیکه وضعیت پاد قابل تشخیص نباشه که معمولا به علت ایراد در کانکشن بین api-server و نودی که پاد روی اون هست این اتفاق میافته، میگیم که پاد Unknown هست.بررسی Container States:کانتینرها هم مثل پادها میتونن توی استیت‌های مختلفی باشند که در ادامه به اختصار توضیح میدم:Waiting:اگه یه کانتینر نه توی استیت Running باشه و نه استیت Terminated اون موقع توی استیت ویتینگ هست!!!موقعیکه یه کانتینر توی حالت ویتینگ هست یعنی هنوز داره آپریشن‌هایی که برای بالا اومدن نیاز داره رو انجام میده تا اصطلاحا استارت‌آپش کامل بشه.Running:استیت رانینگ به این معنی هست که کانتینر بدون مشکل داره اجرا میشه و اگه یه poststart (جلوتر میگم چیه) داشته اون اجرا شده و تموم شده.Terminated:یه کانتینر توی حالت terminated هست زمانیکه شروع به اجرا کرده باشه و بعدش یا کارشو کامل کرده باشه و پروسه‌اش کامل شده باشه یا اینکه به هردلیلی fail شده باشه.بررسی PostStart و PreStop:PreStart & PostStopکوبرنتیز بهمون این امکان رو میده که یه سری اکشن‌های کاستوم‌شده رو تو زمان‌های مشخصی در lifecycle کانتینر اجرا کنیم که بهشون میگیم PreStop and PostStart lifecycle hooks.بلافاصله بعد از اینکه کانتینر ساخته میشه و قبل از اینکه entrypoint command اجرا شه، PostStart hook اجرا میشه که یوزکیسش مثلا میشه ستاپ کردن کانفیگ یا اجرای یه سری اسکریپت برای آماده کردن environment یا آماده سازی دیتابیس و ...و درست قبل از اینکه کانتینر terminated بشه PreStop hook اجرا میشه که معمولا تسک‌های cleanup و مواردی مثل gracefully shutting down یا ذخیره کردن state یا ارسال نوتیف استاپ شدن سرویس یوزکیس‌های مرتبط باهاش هستن.بررسی لیبل و سلکتور :label & selectorلیبل‌ها (Labels): برچسب‌های کلید-مقداری هستند که به منابع کوبرنتیز اضافه می‌شوند تا آنها را دسته‌بندی و سازماندهی کنیم.سلکتورها (Selectors): ابزارهایی هستند که به ما امکان می‌دهند منابع را بر اساس لیبل‌هایشان انتخاب کنیم.لیبل‌ها به آبجکت‌های‌ کوبرنتیز مثل پادها اضافه میشن و ازشون برای مشخص کردن دسته‌ای از آبجکت‌ها استفاده میشه، لیبل‌ها هم زمان ساخت میشه اضافه کرد و هم بعدش میتونن اضافه بشن یا تغییر کنند. هر کلید لیبل برای یک آبجکت باید به صورت یونیک باشه.label & selectorنکته مهمی که اینجا هست اینه که کوبرنتیز داره یه کار سخت رو با استفاده از موضوعات ساده‌ای مثل لیبل و سلکتور انجامش میده، حالا در ادامه بهتر متوجهش میشیم ولی مثلا با یه لیبل سلکتور تمام پادهای اپلیکیشن ما میرن میشنن پشت سرویسی که باید و به همین راحتی لودبالانس انجام میشه.بررسی و توضیح Annotations و تفاوتش با Labelsبا استفاده از انوتیشین میتونید متادیتای دلخواه‌تون رو به آبجکت‌ها و پادهای کوبر اضافه کنید. مثلا شماره تماس افرادیکه مسئولیت نگهداری اون پاد رو دارن یا اطلاعاتی که زمان دیباگ کردن کمک کننده هستن. انوتیشین‌ها میتونن هر نوع دیتایی رو نگه دارن و کلید و مقدار های انوتیشین محدودیت خاصی ندارن، بنابراین میتونید برای ذخیره اطلاعاتی که به نظرتون لازمه ازش استفاده کنید.annotationsهم لیبل و هم انوتیشن در واقع دارن متادیتا به آبجکت‌ها کوبرنتیز اضافه می‌کنند، درحالیکه لیبل‌ها امکان این رو بهمون میدن که آبجکت‌ها کوبرنتیز رو به نوعی شناسایی کنیم و سازماندهی کنیم ولی انوتیشن‌ها اینطور نیستند. لیبل‌ها محدودیت‌های RFC 1123 رو دارند اما انوتیشن روی کلید و مقدارهاش محدودیتی نداره.لیبل‌ها در کنار سلکتور استفاده می‌شوند و به صورت داخلی هم کوبرنتیز ازشون استفاده میکنه و محدودیت‌های naming کوبرنتیز با اونها انجام میشه در حالیکه انوتیشن‌ها بیشتر توسط ابزارها و افرادیکه با کلاستر کار می‌کنند استفاده میشن.بررسی و توضیح Finalizers و کاربرد آنfinalizerفاینالایزر مکانیزمی در کوبرنتیز هستند که قبل از حذف یک منبع، عملیات خاصی را اجرا می‌کنند.کاربرد فاینالایزر توی جلوگیری از حذف منابع تا زمانی که عملیات پاک‌سازی انجام شود.در واقع فاینالایزرها کلیدهایی هستن توی namespace که به کوبرنتیز میگن تا زمانیکه یه شروط خاصی برقرار نشدن اجازه حذف یه سری ریسورس که از قبل مارک کردن رو نده.معمولا از فاینالایزرها روی pv و pvc توی کوبرنتیز استفاده می‌کنیم که از پاک شدن اشتباهی والیوم‌ها جلوگیری کنیم.توی این پست سعی کردیم تا بیشتر با پادها توی کوبرنتیز آشنا بشیم و ببینیم که چطوری اونها رو مدیریت می‌کنند.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شویدخوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 16 Nov 2024 10:37:56 +0330 https://virgool.io/@rafiee/%DA%A9%D8%A7%D9%85%D9%BE%D9%88%D9%86%D9%86%D8%AA-%D9%87%D8%A7%DB%8C-%DA%A9%D9%88%D8%A8%D8%B1-%D9%82%D8%B3%D9%85%D8%AA-%D8%B3%D9%88%D9%85-cgr9z9qr3dsc توی این قسمت میخوایم بریم به سراغ شناخت انواع نودها توی کلاستر کوبر و بررسی اینکه هرکدوم شامل چه کامپوننت‌های هستن، تا کم‌کم ورود کنیم به بررسی و شناخت هریک از اجزای کوبرنتیز.kubernetes componentsخب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.انواع نود کوبر:Control Plane and Worker Nodeمعمولا دو دسته نود داریم توی کوبر، دسته اول Control Plane یا همون Master node ها و دسته دوم Data Plane یا همون Worker node ها.اولا که هر نودی که Kubelet توش باشه ( اگه نمیدونید چیه در ادامه قدم‌هامون متوجه میشیم همه کامپوننت‌هارو... ) نود کلاستر کوبر هست. حالا به نودهایی که توی اونا چهار تا کامپوننت خاص که در لیست زیر اومده هم باشن، نودهای کنترل یا مستر میگیم.API ServerEtcdSchedulerController Managerاگر این چهار تا کامپوننت رو نداشته باشه و تنها سه تا کامپوننت اصلی یعنی kubelet و kubeproxy و Container Runtime رو داشته باشه بهش ورکر نود می‌گیم.kubernetes node typesپس تا اینجا متوجه شدیم که توی کلاستر کوبرنتیزمون نودهای مختلف رو میتونیم به دو دسته تقسیم کنیم، دسته اول که توی خودشون اون لیست چهارگانه بالا رو دارن نودهای مستر هستن و نودهای ورکر هم که تنها تو دلشون سه تا کامپوننت kubeproxy , kubelet , container runtime رو دارند.حالا بریم تک به تک بررسی‌شون کنیم ببینیم هرکدوم چیکار میکنن.etcd:etcdیک دیتابیس بسیار استیبل و پایدار که کوبر ازش استفاده میکنه، یعنی ماشالا به این کامپوننت توی این مدتی که با کلاسترهای کوبر توی سایزهای مختلف کار کردم تا حالا نشده که etcd بازی در بیاره، یک دیتابیس توزیع شده به صورت key-value که تنها کامپوننت state دار کلاستر کوبرنتیز هست و بهمون یه راهکار قابل اتکا برای ذخیره استیت موردنیاز کوبر رو میده.ازونجایی که تنها کامپوننت stateful کوبرنتیز etcd هست، معمولا دیزاین‌ها برای کلاستر کوبر به دو دسته stacked etcd و external etcd تقسیم میشن، یعنی به طور خلاصه ما قاعده کوآرم رو برای کامپوننت etcd رعایت میکنیم و اگه اون رو از کلاستر جدا کنیم دیگه باقی کامپوننت‌ها لزومی نداره که مثلا سه‌تا‌ نود براشون بیاریم بالا، که حالا در ادامه مسیر این مورد رو بیشتر بررسی میکنم.کار انتخاب لیدر رو توی کلاسترش با استفاده از الگوریتم raft انجام میده و نتورک پارتیشن هارو هندل میکنه به هنگام failure حتی زمانیکه نود لیدر به مشکل بخوره.raft algorithmروی پورت 2379 این دیتابیس سرویس میده و پورت 2380 رو واسه کلاسترینگ و 2381 رو برای متریک‌هاش استفاده میکنه، که باید موقع ستاپ کلاستر توی کانفیگ فایروال حواسمون به این موارد باشه.ازونجایی که کلا دیتای store شده روی هر نود کلاستر در دسترس هست اصطلاحا میگیم etcd کاملا replicated هست و دیزاین این ابزار رو برای HA آماده کرده و بهمون این امکان رو میده که spof نداشته باشیم.بهمون consistency میده بنابراین در پاسخ هر درخواست read که بهش میرسه دیتای متناظر با آخرین write رو بهمون برمیگردونه. توی بنچمارک‌هایی که انجام شده تا 10,000 write در ثانیه رو هندل کرده و چون از TLS استفاده میکنه امنه. استفاده از api خوش تعریفی که داره با gRPC بهش سادگی داده و الگوریتم Raft هم این کامپوننت رو برامون تبدیل به یه جز کاملا قابل اتکا توی کلاستر کرده.خیلی خب پس با اولیش که etcd هست آشنا شدیم و فهمیدیم که تنها state دارشونم همین etcd هست، برم سراغ بعدی!api-server:api-serverکامپوننتی که همیشه یه سر قضیه‌س!!! از api-server برای validate کردن و کانفیگ کردن دیتای api آبجکت‌های کوبر ( پادها، سرویس‌ها، رپلیکاست‌ها و ... ) استفاده می‌کنیم. کامپوننت‌های توی کلاستر نیاز دارن که با هم ارتباط بگیرن و یه دیتای به اشتراک گذاشته شده رو مدام چک کنن و تغییرش بدن، برای این کار یه کامپوننت اون وسط ایجاد شده که همه با اون حرف میزنن و طراحی شده برای اینکه به راحتی بتونه scale کنه و ما بتونیم هرموقع که لازم شد تعداد instanceهاش رو بیشتر کنیم.همونطور در شکل بالا میبینید هرکی با etcd بخواد حرف بزنه باید بره سراغ api-server، حتی خود ادمین کلاستر هم که کامند میخواد اجرا کنه با api-server حرفاشو میزنه، همینجا یه چیزی برامون مشخص میشه ...اگه من بخوام لاگ کلاسترم رو جمع کنم، یعنی بفهمم در هر لحظه داشته چه اتفاقی میافتاده باید چیکار کنم؟ مگه هرکی هرکاری داره نمیره سراغ api-server ؟ پس اگه لاگ api-server رو داشته باشم انگار همه چیزو فهمیدم :)بنابراین اگه بخوایم مسئولیت‌های api-server رو توی کلاستر بگیم:هندل کردن تمام API request ها و اکسپوز کردن API endpointها و کلا منیج کردن API کلاستر رو انجام میده.با استفاده از مواردی مثل Client certificates, Bearer Tokens, HTTP Basic Authentication میاد آتنتیکیشن رو برامون انجام میده و با استفاده از مواردی مثل ABAC , RBAC هم آتوریزیشن رو انجام میده.تنها کامپوننتی هست که میتونه با etcd حرف بزنه.تمام پروسه ارتباط بین نودهای ورکر و مستر ( control plane ) از طریق api-server هماهنگ میشه.یک built-in bastion proxy داره که قسمتی از پروسه API Server هست که ازش استفاده میکنه برای اکسس دادن به سرویس ClusterIP از بیرون کلاستر ( به بخش نتورک برسیم بیشتر توضیح میدم ) در حالیکه این سرویس‌ها معمولا فقط داخل خود کلاستر در دسترس هستن.توی این مقاله توضیح داده شده که توی سال ۲۰۲۲ بیش از 380 هزار تا کوبرنتیز API Server نا امن پیدا شده که به غریبه‌ها هم ۲۰۰ میدادن :)) بنابراین یکی از اولین و مهم‌ترین جاهایی که توی کلاستر کوبرتون باید امنیتش رو سفت بگیرید و شوخی بردار نیست، همین آقای API Server هست.یه نکته‌ی مهم: اگر ابزاری جذاب و محبوب باشه و خیلی مورد استقبال قرار گرفته باشه و همه ازش استفاده کنند برای هکر‌ها و خراب‌کاری هم خیلی محبوب هست. برای همین باید خیلی حواسمون بهش باشه.بریم بعدی !Controller Manager:Controller Managerتوی کوبرنتیز یه کامپوننتی داریم که وظیفه‌اش اینه که بیس‌چاری دلواپس باشه !!!یعنی کنترلر میاد بالا توی یه لوپ مدام state کلاستر رو از طریق api-server چک میکنه و هرجا که متوجه بشه الان کلاستر اون وضعیتی که ما به عنوان مطلوب (desired state) تعریف کردیم رو نداره، دست به کار میشه و شروع میکنه چنج زدن روی وضعیت موجود (current state) .Desired State and Current Stateواقعا عکس خوبیه. خیلی مفهومی که می‌خوایم بهش بپردازیم رو قشنگ نمایش داده.انواع مختلف کنترلر رو هم داریم مثل replication controller, endpoints controller, namespace controller, serviceaccounts controller که هرکدوم دلواپس ورکلود و ریسورس مربوط به خودشون هستن :) و البته‌ که سرشون تو کار خودشونه :))Controllerدر ادامه مسیر با جزئیات بیشتری چنتا از مهم‌هاش مثل Deployment Controller و Replicaset Controller و Daemonset Controller رو بررسی می‌کنیم.یه کامپوننت دیگه‌ای هم داریم که اینجا فقط کوچیک معرفیش می‌کنیم اون هم یکی از کامپوننت‌های control plane هست که ادغام شده در دل لاجیک‌های کنترلی کلاد. Cloud Controller Manager به شما امکان این رو میده که کلاستر خودتون رو به API های کلاد پروایدر متصل کنید و کنترلرهایی برای Nodeها و ‌Route و Service داشته باشید. مثلا تصور کنید به وقت نیاز کلاستر شما متوجه بشه که باید کلا اسکیل کنه و دوتا نود ورکر به خودش اضافه کنه ... و این کار رو با کنترلر کلادش انجام بده!Cloud Controller Managerبریم بعدی ...Scheduler:تا اینجا فهمیدیم که توی control plane کی دیتای کلاستر رو نگه میداره، کی مسئول برقراری ارتباط کامپوننت‌هاست و کی دلواپسه که همه‌چیز طبق انتظارمون باشه و ...، حالا فرض کنید که یه درخواست میاد به api-server که مثلا این پنج‌تا پاد رو بیاریم بالا ( اگه پاد براتون آشنا نیست، فعلا فرض کنید مثلا میخوایم روی کوبرنتیز پنج‌تا کانتینر که توی داکر دیدید بیاریم بالا )، خب حالا اینارو کجا بیاریم بالا؟یعنی کنترل منیجر مثلا متوجه میشه که آقا الان پنج‌تا پاد میخوایم که توی استیت فعلی‌مون نیستن ... ولی خب اینکه اینارو روی نود اول بیاره بالا ... یا نود دوم بیاره بالا ... رو از کجا بدونه؟ از رفت روی نود اول بیاره بالا ولی اون به اندازه کافی ram نداشتیم چی مثلا؟اسکجولر کار اصلی‌ش همینه ... اصطلاحا می‌گیم فرآیند pod to node رو انجام میده یعنی مشخص میکنه که این پاد بره روی کدوم نود بشینه. اسکجولر این وظیفه رو با انجام دوتا کار به صورت کلی انجام میده، اول filtering و دوم Scoring.Schedulerتو گام اول یعنی فیلترینگ اسکجولر اون نودهایی که اصلا امکان اینکه این پاد بتونه روشون دیپلوی بشه رو پیدا میکنه، به عنوان مثال PodFitsResources فیلتری هست که چک میکنه آیا نودهای کاندید ریسورس کافی رو دارند یا نه. بعد از فیلترینگ حالا یه لیستی از نودهای مناسب داریم که معمولا بیشتر از یک نود توی این لیست هست و حالا باید به شکل دیگری انتخاب رو انجام بدیم، اگر هم این لیست خالی باشه که پاد دیپلوی نمیشه و اصطلاحا قابلیت اسکجول میگیم نداره.Scheduler Filteringتوی قدم دوم یعنی Scoring اسکجولر یه امتیاز به هرکدوم از نودهای کاندید توی لیست میده و نهایتا نود با امتیاز بالاتر انتخاب میشه برای اینکه پاد بره اونجا و اگه امتیاز دو یا چنتا نود مساوی بشه رندم میفرسته سمت یکیشون، اما این امتیاز رو چجوری میده؟Scheduler Scoringهمونطور که توی تصویر بالا میبیند فاکتورای زیادی توی این امتیاز دخیل هستن که خیلیاشون ممکنه هنوز براتون آشنا نباشه، مثلا مباحث مرتبط با آفینیتی و تالرنس رو در ادامه مسیر میبینید، اما مثلا میبینید که فاکتورایی مثل بالانس بودن اختصاص منابع و priorityهای مختلف توی این امتیاز نقش دارند.پس متوجه شدیم اسکجولر فیلتر میکنه و بعد امتیازدهی نودی که رنک بالاتری داره رو انتخاب میکنه تا پاد بره سمتش.pod deployment processبریم سراغ کامپوننت‌های دیگه: یه نکته بگم اینکه این ۳ تا کامپوننت داخل مستر نودها هم وجود داره و باید باشه. ولی اگر تنها این سه تا کامپوننت بود بهش میگیم ورکر نود و اگر کامپوننت‌های مستر رو هم داشت بهش می‌گیم مستر نود.Kubelet:این کامپوننت ایجنتی هست که روی تمام نودهای کلاستر ران میشه و کارش اینه که مطمئن شه کانتینرا توی پاد دارن ران میشن و هرموقع Control Plane نیاز داشته باشه اتفاقی روی نود بیافته، api-server با kubelet حرف میزنه که بره اکشن لازم رو بزنه.kubeletساختن و تغییردادن و پاک کردن کانتینرا برای پاد کار کیبولت هست. مسئولیت هندل کردن liveliness و readiness و startup probes با کیوبلت هست.کیوبلت کانفیگ پادهارو میخونه و کار ساخت دایرکتوری و مانت کردن والیوم رو انجام میده، همچنین جمع آوری وضعیت کلی نود و پاد ریپورت دادنش به درخواست های api-server رو هم کیوبلت انجام میده.کامپوننتی که با CRI و CSI و CNI کار میکنه تا نهایتا پاد با ریسورس های مورد نیازش بیاد بالا کیوبلته.بریم سراغ کامپوننت بعدی...kubeproxy:یه کانسپت بزرگتر توی کوبرنتیز داریم به اسم service که حالا بهش میرسیم توی مسیرمون که حالا این کیوب‌پروکسی به نوعی پیاده‌سازی بخشی ازون کانسپته.مثلا maintain کردن رول‌نتورکی رو روی نودهای کلاستر رو کیوب‌پروکسی انجام میده، که همین رول‌ها امکان ارتباط شبکه‌ای با پادها رو از داخل و بیرون کلاستر نهایتا فراهم می‌کنند.kube-proxyکیوب‌پرکسی به عنوان یه daemonset (تو مسیر بررسیش می‌کنیم اگه نمیدونید چیه) میاد بالا و روی تمام نودها هست، وقتی که یه پورت یه پاد رو اکسپوز می‌کنیم سرویسی که میده رو از طریق Service مثلا ClusterIP ... کیوب‌پروکسی ملزومات نتورکی رو انجام میده و رول‌هارو میزنه تا ترافیک ورودی برسه به اون پاد و میتونیم بگیم که لودبالانس و سرویس دیسکاوری توی کوبرنتیز داره توسط کیوب‌پروکسی هندل میشه ...اگه این جملات براتون نامفهومه صبر کنید تا توی مسیرمون به نتورک کوبر برسیم. به زبون ساده kube-proxy کارش اینکه که مسیر دسترسی ما به سرویس رو برامون فراهم می‌کنه. حالا چطوری این کار رو می‌کنه بعدا بهش می‌پردازیم ولی تمام مواردی که لازم داره رو فراهم می‌کنه تا بتونیم دسترسی به سرویس خودمون پیدا کنیم.kube-proxyخب حالا که توی ورکرنودها هستیم بریم CRI و CSI و CNI رو هم باهم بررسی کنیم.CRI CNI CSIتوی پست‌های قبلی گفتیم که مقایسه کوبرنتیز و داکر اشتباهه چونکه کوبرنتیز کارش ارکستریشن هست و نه کانتینر ران‌تایم ... به طورکلی یکی از دلایلی که کوبرنتیز اینقدر ترکید میتونه این باشه که اومد اینترفیس ارتباط رو استاندارد کرد و گفت حالا هرکی میخواد تو بازی باشه بره خودشو تطبیق بده!!!یعنی مادامیکه کانتینر ران تایم شما، پلتفرم استورج شما و یا ابزاریکه برای شبکه استفاده می‌کنید با اینترفیس کوبرنتیز بتونه ارتباط بگیره، برای کوبرنتیز فرقی نمیکنه که از هر چی دوست دارید استفاده کنید.CRI (Container Runtime Interface) :کوبرنتیز از کانتینر ران‌تایم‌های مختلفی مثل Docker و Containerd و CRI-O و هر پیاده‌سازی دیگه‌ای که Kubernetes CRI رو داشته باشه، پشتیبانی میکنه.CRIیه زمانی خبر اینکه کوبرنتیز از داکر پشتیبانی نمیکنه دیگه و داکر دپریکیت میشه پخش شد، در اصل کوبرنتیز گفت از نسخه 1.20 دیگه به داکر وارنینگ میده و از 1.23 به بعد دیگه ارور میده. میگفتن دیگه داکر تموم شد و وقتتون رو تلف نکنید واسه یادگیریش و ... که بعدشم خود کوبرنتیز یه مقاله نوشت گفت پنیک نکنید :) آقا ماجرا چیز دیگه‌ایه ... حالا بریم با هم ببینیم ماجرا چی بوده ...docker and containerdانجین داکر با containerd ارتباط میگیره که اون هم از طریق containerd-shim با یک Open Container Initiative که استانداردی برا پروسه‌های سیستم عامل و کانتینر هست، کانتینر رو ایجاد میکنه که حالا مثلا داکر OCI که استفاده میکنه runc هست.Docker and k8s uses containerdحالا کوبرنتیز هم میتونه از طریق CRI API که داره با containerd خودش حرف بزنه و همون کار ساخت کانتینر رو انجام بده، یعنی کوبرنتیز هم از روش مشابه روش داکر استاندارد خودش رو ایجاد کرده یه جورایی.حالا اگه بخوایم توی کوبرنتیز از داکر استفاده کنیم یه جورایی باید مسیری که وجود داره رو برگردیم ... از بالاتر یه داکرشیم بین کوبرنتیز و داکر اضافه کنیم تا دوباره همین راه رو بیاییم !!!k8s before and after dockerبنابراین مشخص میشه که بهتره که با کوبر همون اول بریم سراغ containerd، هرچند که dockershim رو کامیونیتی داره توسعه میده.خب حالا از این ماجرا که بگذریم پس متوجه شدیم که کیوب‌لت نیاز به یک CRI داره که بغل دستش باشه تا بهش بگه که کانتینر پادهایی که میخواد رو بالا بیاره.حالا بریم سراغ استورجش ...CSI (Container Storage Interface) :قبل از CSI کوبرنتیز فقط از پلاگین والیوم داخلی خودش پشتیبانی می‌کرد که توی core binary کوبرنتیز توسعه داده میشد، بنابراین استورج پروایدرها باید کدبیس کوبر رو چک میکردن تا بتونن اون استورج سیستم رو پشتیبانی کنند. Flex-volume یه راه حل برپایه پلاگین بود که اومد تا این مشکل رو حل کنه با استفاده از executable-based plugin هایی که با پلاگین کوبرنتیز یه تردپارتی ایجاد میکنند.با اینکه این روش داشت کار میکرد اما چنتا مشکل داشت، اول اینکه دسترسی root به مسترا و فایل سیستم میخواست تا بتونه درایورهاش رو دیپلوی کنه و مشکل دوم اینکه یه عالمه دیپندنسی و پیش‌نیاز میخواست که از هاست در دسترس باشند. CSI اومد تا مشکلات این مدلی رو رفع کنه با استفاده از کانتینرایز کردن و سطح بندی دسترسی استورج. قبلا میگفتن in-tree k8s storage plugin ولی CSI تونست out-tree رو فراهم کنه که به استورج پروایدرا امکانش رو داد تا بتونن با کوبرنتیز سازگار بشن و توسعه‌دهندگان با وجود CSI می‌توانند پلاگین‌های CSI را برای انواع مختلف سیستم‌های ذخیره‌سازی توسعه دهند بدون اینکه نیاز به تغییر در کوبرنتیز باشد. همچنین امکان اتصال انواع مختلف ذخیره‌سازی مانند NFS، AWS EBS، Google Persistent Disks و ... به پادهای کوبرنتیز فراهم شد.فرض کنید شما نیاز به اتصال یک پایگاه داده به یک ذخیره‌سازی پایدار دارید. با استفاده از CSI، می‌توانید به راحتی یک PVC (PersistentVolumeClaim) ایجاد کنید که به یک سیستم ذخیره‌سازی مانند AWS EBS متصل می‌شود. کوبرنتیز به صورت خودکار حجم مورد نیاز را ایجاد و به پاد شما متصل می‌کند.CRI CSI CNICNI (Container Network Interface) :در تعریف CNI یک استاندارد واسط برای مدیریت شبکه در ارکستریشن کانتینرها است. این رابط امکان می‌دهد تا پلاگین‌های مختلف شبکه به کوبرنتیز متصل شوند و قابلیت‌های شبکه‌ای مانند اتصال، مسیریابی و سیاست‌های امنیتی را فراهم کنند.انعطاف‌پذیری CNI باعث میشه تا امکان انتخاب و ترکیب پلاگین‌های مختلف برای پاسخگویی به نیازهای خاص شبکه رو بهمون بده.بنابراین با استفاده اگه CNIها میتوانیم مواردی از قبیل تنظیم و مدیریت شبکه پادها در کوبرنتیز، اعمال سیاست‌های امنیتی شبکه مانند فایروال‌ها و لیست‌های کنترل دسترسی (ACL) و پشتیبانی از قابلیت‌هایی مانند شبکه‌بندی چند لایه، VPN و ... رو داشته باشیم.این میشه قدم سوم‌مون توی مسیر کوبرنتیز که با کامپوننت‌هاش سعی کردیم بیشتر آشنا بشیم و بدونیم که هرکدوم توی نودهای کلاستر دارن چیکار میکنن.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شویدخوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 09 Nov 2024 08:23:11 +0330 https://virgool.io/@rafiee/%DA%A9%D9%88%D8%A8%D8%B1-%D8%B3%DB%8C%D9%86%DA%AF%D9%84-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-yqfdm1fnwryh توی قسمت دوم از مسیر کوبرنتیز بعد از بررسی kubectl میریم به سراغ ابزارهایی که با اونها می‌تونیم یه کوبرنتز دمه‌دستی! ستاپ کنیم که بتونیم باهاش تمرین کنیم.خب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.بررسی Kubectl :Kubectlابزار کامندلاین کوبرنتیز kubectl هست که بهمون این امکان رو میده تا کامندهامون رو روی کلاستر کوبرنتیز اجرا کنیم. از kubectl میتونیم برای دیپلوی کردن اپلیکیشن‌ها و مدیریت منابع‌مون و بررسی لاگ‌ها‌ و ... استفاده کنیم. اینجا میتونید بیشتر در موردش بخونید.توصیه میکنم برای اینکه راحت‌تر بتونید با کامندلاین کوبر کار کنید مواردیکه توی قسمت kubectl ریپو دواپس سرتیفیکیشن گذاشتم گیتهاب رو دنبال کنید و ازشون استفاده کنید تا راحت‌تر بتونید با کوبر کار کنید. در ادامه یه توضیح کوتاه در مورد یکی دوتا از مواردیکه کار با کامندلاین رو راحت تر میکنن براتون میذارم. این موارد به نظرم خیلی برای کار با کوبرنتیز به دردتون می‌خوره و کاملا کاربردی هست که خوبه حتما ازش استفاده کنید.ابزار kubectx:اگر شما هم مثل من چندتا کلاستر kubernetes دارید که هر کدوم داره کاری انجام می‌ده و لازم دارید به راحتی بین اون‌ها جابه‌جا بشید، این ابزار خیلی بهتون کمک می‌کنه. با استفاده از این ابزار می‌تونید به راحتی بین کلاسترهای خود جابه‌جا بشید و کانتکس مربوط به kubectl را خیلی راحت تغییر دهید.kubectx demoابزار kubens:و برای جابه‌جایی بین namespaceهای مختلف این ابزار به شما کمک می‌کند. باهاش به راحتی می‌تونید بین namespaceهای کوبرنتیز جابه جا بشید.kubens demoبررسی kubeconfig:kubeconfigکیوب کانفیگ فایلی هست که توی اون ما دیتای مربوط به کلاسترها، یوزرمون و namespaceها رو نگهداری می‌کنیم همچینین اطلاعات مربوط به مکانیزم آتنتیکیشن‌مون به کلاسترها رو. کامندلاین کوبر با استفاده از این فایل کانفیگ اطلاعاتی رو که برای برقراری ارتباط با API Server نیاز داره رو پیدا میکنه. به عبارت دیگه تو این کانفیگ مشخص می‌کنیم که endpoint ارتباطی ما با هر کلاستر و کاربرمون و نحوه‌ی احراض هویت اون به چه صورت است. از روی این کانفیگ می‌تونیم متوجه بشیم که به کدوم کلاستر چطوری می‌تونیم متصل بشیم.به صورت پیش فرض فایل کانفیگ کوبر رو در دایرکتوری kube. یوزری که باهاش کار می‌کنیم نگهداری می‌کنیم. با استفاده از متغیر محیطی KUBECONFIG و فلگ kubeconfig -- هم میشه این فایل رو تعیین کرد.kubeconfig pathهر فایل کیوب‌کانفیگ از چند قسمت کلی تشکیل میشه:clustersتوی این قسمت لیست همه کلاسترهایی که بهشون اکسس داریم رو قرار میدیم. هر کلاستر شامل جزئیاتی از قبیل URL مربوط به API Server اون کلاستر (endpoint)، سرتیفیکیت متناظر با اون کلاستر و یک اسم برای مشخص کردن کلاستر میشه.usersتوی این قسمت هر یوزر با یک اسم مشخص به همراه دیتای مربوط به آتنتیکیشن که مثلا میتونه یه کلاینت سرتیفیکیت باشه مشخص می‌شود. موارد دیگه مثل bearer tokens و authenticating proxy توی این قسمت قرار میگیرن.contextیکی از بخش‌های فایل کانفیگ کوبرنتیز context هست که برای تبدیل دسترسی به یک اسم ازش استفاده می‌کنیم. هر context از جمع شدن سه تا پارامتر درست میشه، چه کلاستری ... چه نیم‌اسپیسی ... چه یوزری ... اینا میشن یه context که کامندلاین کوبر بر اساس اونا با کلاستر ارتباط می‌گیره و با کامند kubectl config use-context میتونیم به کانتکست موردنظرمون جابجا شیم.current contextهمونطور که از اسمش هم مشخصه کانتکستی که الان توش هستیم رو نشون میده.kubeconfig fileکلاستر سینگل نود:حتما شما هم زیاد اسم کوبرنتیز رو شنیدید و کم و بیش می‌دونید چی هست و قراره چه کارهایی برامون انجام بده. اما نکته‌ی مهمی که هست، برای یادگیری نیاز داریم که یه آزمایشگاه برای خودمون داشته باشیم تا تمام موارد رو اونجا بررسی کنیم. به خاطر همین قبل از این که شروع کنیم در مورد کوبرنتیز صحبت کنیم نحوه راه‌اندازی اون با کمترین منابع رو بررسی می‌کنیم. به راحتی و با کمترین هزینه آزمایشگاه کوبرنتیز خودتون رو راه‌اندازی کنید. در این مستند برای سیستم‌عامل‌های مختلف راه‌حل ارائه می‌شود.من قبلا توی دوره‌های دواپس شروع می‌کردم و مطالب مربوط به کوبرنتیز رو آموزش می‌دادم و میگفتم و میرفتیم جلو تا اینکه اون آخرا می‌رسیدیم به نصب و ستاپ کلاستر و ... تازه اونجا بچه‌ها شروع می‌کردن کامند زدن و دست به کیبورد شدن، که متوجه شدم این مدلی بچه‌ها نمی‌تونن خیلی‌ خوب مطالب رو فالو کنن و برای اینکه از همون اول همراه مطالب بتونن تمرین کنن و دست به کیبورد بشن این قسمت رو اضافه کردم. این طوری از همون ابتدا یه کلاستر مینیمال کوبرنتیز دارند که طی دوره تمام مواردی که یاد می‌گیرند رو می‌تونن روی اون تست و بررسی کنند. خود کوبرنتیز برای تست‌های خودش از همین راهکارها استفاده می‌کنه.قبل از اینکه شروع کنیم سه تا نکته مهم:نکته‌ی اول: برای اینکه راحت کارتون پیش بره چون تمام لینک‌ها و کارهایی که داریم انجام می‌دهیم تحریم است بهتره که کلا از اول یا پروکسی تنظیم کنید یا از یکی از روش‌های که توی پست های قبل گفتیم، استفاده کنید.نکته‌ی دوم: هر کدوم از روش‌ها رو شما انتخاب کنید به دستور kubectl نیاز دارید و باید این دستورالعمل رو داخل کامپیوتر خودتون نصب کنید که به دلیل استفاده در این مستند، بالاتر توضیحش دادم.نکته‌ی سوم: اگر دارید روی لپ‌تاپ و یا کامپیوتر کاری خودتون نصب می‌کنید، خوبه که مستقیم این کار رو انجام ندید و روی یک vm آن را نصب کنید. ابزارهای مختلفی وجود دارد که به شما این امکان را می‌دهد که داخل سیستم‌عامل خود VM داشته باشید که از ساده‌ترین اون‌ها می‌تونم به VirtualBox اشاره کنم که از اینجا می‌توانید آن را دانلود کنید. البته امکان این رو هم دارید که مستقیم روی سیستم خودتون داشته باشید. هر طوری راحت‌تر هستید که مدیریتش کنید عمل کنید.استفاده از ارائه کننده‌های سرویس کوبرنتیز:معمولا یکی از راحت‌ترین و سریع‌ترین راه‌حل‌های موجود، استفاده از ارائه‌کننده‌های Cloud می‌باشد که سرویس‌هایی همانند کوبرنتیز را ارائه می‌کنند که این راه برای ما داخل ایران هم بسیار هزینه‌بر بوده (با توجه به نسبت ارزهای دیگه به پول ما) و هم امکانش به راحتی فراهم نیست زیرا از سمت کمپانی‌های ارائه کننده‌ی خدمات کلاد سرویس این امکانات برای ایران محدود و مسدود شده است.بریم با هم یه معرفی داشته باشیم روی چنتا ابزاری که با استفاده از اونا می‌تونیم یه کلاستر سینگل نود داشته باشیم.minikube :minikubeمینی‌کیوب یک کوبرنتیز لوکال هست که میتونیم ازش برای یادگیری کار با کوبرنتیز و توسعه اپلیکیشن روی اون استفاده کرد. برای استفاده از مینی کیوب تنها نیازه که داکر رو نصب داشته باشید ( و البته بتونید ایمیجش رو هم بگیرید اگه توی ایران هستید ) و یا اینکه یه ماشین مجازی داشته باشید و خیلی ساده با یه کامند minikube start میتونید کار رو شروع کنید. داکرم الزامی نیست هرکدوم از لیست زیر باشه هم اوکیه:Docker, QEMU, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMware Fusion/Workstationحداقل به 2Core CPU و 2GB ram و 20GB دیسک نیازه برای راه‌اندازی مینی کیوب نیاز داریم و همچنین اینترنت!شما می‌تونید نسخه‌ی آخر minikube رو بر اساس سیستم‌عامل خود از اینجا دریافت و برای نصب آن نیز از اینجا استفاده کنید.مینی کیوب یه ابزار خوب و کاربردی برای شماست که بتونید با استفاده از آن کار با کوبرنتیز رو تمرین کنید. کلی امکاناتی که تو کوبرنتیز نیاز داریم رو به خوبی برای ما فراهم می‌کنه و در اختیارمون قرار می‌ده. کار کردن باهاش خیلی راحت و دم دستی هست و به خوبی می‌تونید ازش استفاده کنید تا یک کوبرنتیز لوکال داشته باشید.kind :kindسرویس kind به شما این امکان را می‌دهد که بر روی داکر، کوبرنتیز داشته باشید و برای تست به راحتی آن را راه‌اندازی کنید. تصویری که به عنوان لوگو داره استفاده می‌کنه هم خیلی قشنگ و کامل هست و به همین موضوع که کوبرنتیز رو داره تو یه کانتینر به شما می‌ده اشاره می‌کنه.برای استفاده ابتدا نیاز است که شما داکر را بر روی ماشین خود نصب داشته باشید. اینجا تفاوتی ندارد که شما از چه سیستم‌عاملی استفاده می‌کنید و یا اینکه داکر را به چه صورت روی ماشین خود نصب کرده‌اید.بعد از نصب داکر، نسخه‌ی آخر kind رو از اینجا دریافت کنید. برای نصب طبق سیستم‌عامل خود مطابق دستورات عمل کنید.حالا بعد از نصب kind می‌توانید با استفاده از دستور زیر یک کلاستر kubernetes برای خودتون ایجاد کنید.kind create cluster --name DockerMeدر تصویر زیر نتیجه‌ی دستور بالا را مشاهده می‌کنید.kind create clusterهمواره بعد از ایجاد کلاستر، کانفیگ مربوط به kubectl را نیز خودش انجام می‌دهد و دستور kubectl شما به کلاستر kind متصل خواهد شد. با دستور زیر می‌توانید ببینید که در حال حاضر kubectl شما به کدام کلاستر متصل می‌باشد.kubectl config current-contextبا استفاده از دستور زیر می‌توانید نودهای داخل کلاستر خود را مشاهده کنید و podهایی که دارد را بررسی کنید.kubectl get nodes kubectl get po -Ahttps://virgool.io/d/yqfdm1fnwryh/%D8%A7%DB%8C%D8%AC%D8%A7%D8%AF%DA%A9%D9%84%D8%A7%D8%B3%D8%AA%D8%B1multi-nodes:%D8%A8%D8%A7kind%D8%A7%DB%8C%D9%86%D9%82%D8%A7%D8%A8%D9%84%DB%8C%D8%AA%D9%88%D8%AC%D9%88%D8%AF%D8%AF%D8%A7%D8%B1%D9%87%DA%A9%D9%87%D8%B4%D9%85%D8%A7%D8%A8%D8%AA%D9%88%D9%86%DB%8C%D8%AF%DB%8C%DA%A9multi-nodes%DA%A9%D9%84%D8%A7%D8%B3%D8%AA%D8%B1%DA%A9%D8%A7%D9%85%D9%84%DA%A9%D9%87%D8%B4%D8%A7%D9%85%D9%84%DB%B3%D8%AA%D8%A7%D9%86%D9%88%D8%AFmaster%D9%88%DB%B3%D8%AA%D8%A7%D9%86%D9%88%D8%AFworker%D8%A8%D8%A7%D8%B4%D8%AF%D8%A7%DB%8C%D8%AC%D8%A7%D8%AF%DA%A9%D9%86%DB%8C%D8%AF.%D8%A7%DB%8C%D9%86%D8%AE%DB%8C%D9%84%DB%8C%D8%AE%D9%88%D8%A8%D9%87%DA%A9%D9%87%D8%A8%D8%AA%D9%88%D9%86%DB%8C%D8%AF%DB%8C%DA%A9%DA%A9%D9%84%D8%A7%D8%B3%D8%AA%D8%B1multimaster%D8%B1%D9%88%DB%8C%DB%8C%DA%A9%D9%85%D8%A7%D8%B4%DB%8C%D9%86%D8%A8%D8%B1%D8%A7%DB%8C%D8%AA%D8%B3%D8%AA%D8%B1%D8%A7%D9%87%E2%80%8C%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%DB%8C%DA%A9%D9%86%DB%8C%D8%AF%D9%88%D8%AF%D8%A7%D8%B4%D8%AA%D9%87%D8%A8%D8%A7%D8%B4%DB%8C%D8%AF.%D8%A8%D8%B1%D8%A7%DB%8C%D8%A7%DB%8C%D9%86%DA%A9%D8%A7%D8%B1%D9%86%DB%8C%D8%A7%D8%B2%D8%AF%D8%A7%D8%B1%DB%8C%D8%AF%DA%A9%D9%87%DB%8C%DA%A9%DA%A9%D8%A7%D9%86%D9%81%DB%8C%DA%AF%D9%81%D8%A7%DB%8C%D9%84%D8%A8%D8%B1%D8%A7%DB%8C%D8%A2%D9%86%D8%A7%DB%8C%D8%AC%D8%A7%D8%AF%DA%A9%D9%86%DB%8C%D8%AF%D8%9B%DB%8C%DA%A9%D9%81%D8%A7%DB%8C%D9%84%D9%87%D9%85%D8%A7%D9%86%D9%86%D8%AF%D9%81%D8%A7%DB%8C%D9%84%D8%B2%DB%8C%D8%B1%DA%A9%D9%87%D8%AF%D8%A7%D8%AE%D9%84%D8%A2%D9%86%D9%86%D9%82%D8%B4%D9%88%D8%AA%D8%B9%D8%AF%D8%A7%D8%AF%D9%86%D9%88%D8%AF%D9%87%D8%A7%D8%B1%D8%A7%D9%85%D8%B4%D8%AE%D8%B5%DA%A9%D8%B1%D8%AF%DB%8C%D8%AF.vim my-cluster-config.yaml kind: Cluster apiVersion: kind.sigs.k8s.io/v1alpha3 nodes: - role: control-plane - role: control-plane - role: control-plane - role: worker - role: worker - role: workerبعد از ایجاد فایل بالا، با استفاده از دستور زیر از روی آن می‌توانید کلاستر خود را ایجاد کنید.kind create cluster --name DockerMe-Cluster --config my-cluster-config.yamlبا kind دوست باشید و ازش استفاده کنید. به راحتی برای شما کلاستر kubernetes آماده می‌کنه و می‌تونید تمام تست‌های خود را روی آن انجام دهید. خود کوبرنتیز تو تست‌های e2e خودش از kind استفاده می‌کنه و فانکشن جدیدش رو با این سرویس تست و بررسی می‌کنه. راستی kind یعنی kubernetes in docker که خیلی به مفهومی که داره ازش استافده می‌کنه اشاره می‌کنه. این طوری هر نود کلاستر کوبرنتیز رو داخل یک کانتینر ایجاد می‌کنه و ازش استفاده می‌کنه.MicroK8S :microk8sاین ابزار که توسط شرکت Canonical (شرکت ارائه دهنده‌ی سیستم‌عامل ubuntu و کلی ابزار مفید و خفن دیگه) ارائه می‌شود، می‌خواهد به ما کمک کند که با سرعت زیاد و بسیار سبک بتونیم یک نسخه kubernetes برای خودمان داشته باشیم. تمرکز این ابزار بر سبک‌ بودن و سادگی ارائه kubernetes می‌باشد.از هر سیستم‌عاملی که استفاده کنید microk8s یه راه‌حل خوب برای شما می‌باشد و حتی می‌تونید با استفاده از آن کلاسترهای پروداکشن ردی هم ایجاد کنید و ازش استفاده کنید.اگر از ویندوز استفاده می‌کنید می‌توانید از اینجا آن را دانلود و نصب کنید. اینجا هم می‌تونید داکیومنت نصب روی ویندوز و مک این ابزار را بررسی کنید.در لینوکس هم با استفاده از ابزار snap می‌توانید به راحتی همانند دستور زیر آن را نصب کنید.sudo snap install microk8s --classic --channel=1.18/stablemicrok8s installبرای اینکه لیستی از channelها که نسخه‌های نصبی شما می‌باشد را بدست بیاورید می‌توانید از این دستور استفاده کنید.snap info microk8sبعد از نصب می‌توانید بررسی کنید که وضعیت آن به چه صورت می‌باشد.microk8s status microk8s status --wait-readyآپشن wait-ready برای بررسی وضعیت کلاستر kubernetes می‌باشد و تا زمانی که وضعیت آن آماده‌ به کار باشد صبر می‌کند. اگر دستور بالا زیاد طول کشید، برای اینکه بدونید در چه وضعیتی می‌باشد می‌توانید از دستور زیر استفاده کنید که جزئیات بیشتری را در اختیار شما قرار می‌دهد.microk8s inspectبا استفاده از این دستور می‌توان نودهای کلاستر نصب شده را بررسی کرد.microk8s kubectl get nodes microk8s kubectl get services microk8s kubectl get po -Aبرای اینکه بتوانید از دستور kubectl خود سیستم استفاده کنید می‌بایست آن را کانفیگ کنید تا از کانفیگ مربوط به microk8s استفاده کند از این رو ابتدا کانفیگ فایل مربوطه را ایجاد و سپس از آن استفاده می‌کنیم.microk8s.config > microk8s.yaml export KUBECONFIG=$PWD/microk8s.yaml kubectl config current-contextحالا می‌توانیم با دستور kubectl موارد این کلاستر را بررسی کنیم.kubectl get nodes kubectl get po -Aبا استفاده از دستور زیر می‌توانیم یک دیولویمنت روی kubernetes جدید خود داشته باشیم.kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1حالا اگر لیست podهای خود را بررسی کنید می‌توانید آن را مشاهده کنید.kubectl get po -Ahttps://virgool.io/d/yqfdm1fnwryh/%F0%9F%93%B7k3sاین ابزار به ما کمک می‌کنه که یک kubernetes خیلی سبک برای استفاده در iot و Edge computing داشته باشیم. این ابزار توسط کمپانی Rancher ارائه شده است که خوب بسیار سبک و کاربردی است. صفحه‌ی اول سایت rancher نشان می‌ده که این شرکت تمرکزش روی چی هست و داره چی‌ کار می‌کنه.https://www.youtube.com/watch?v=nRVBNkcr4eM&t=112sنحوه‌ی عملکرد k3s در تصویر زیر مشخص می‌باشد.How it Works k3sنصب این ابزار خیلی ساده است و کافیه که شما اسکریپت زیر را اجرا کنید تا بر روی ماشین شما نصب و پیکربندی شود.curl -sfL https://get.k3s.io | sh -با استفاده از دستور زیر می‌توانید لیست نودهای آن را بررسی کنید.sudo k3s kubectl get node sudo k3s kubectl get po -Aکانفیگ مربوط به k3s نیز در مسیر زیر قرار دارد و می‌توانید دستور kubectl خود را کانفیگ کنید تا از آن استفاده کند.vim /etc/rancher/k3s/k3s.yaml cat /etc/rancher/k3s/k3s.yaml > k3s.yaml export KUBECONFIG=$PWD/k3s.yaml kubectl config current-contextحال دیگه می‌تونید با دستور kubectl ماشین خودتون هم با کلاستر صحبت کنید.kubectl get node kubectl get po -Aاین ابزار رو جدی بگیرید می‌تونید باهاش کلاستر با تعداد نودها‌ی مختلف هم راه‌اندازی کنید. برای این کار نیاز دارید که به تعداد نودهای خود ماشین مجازی داشته باشید.K3d :k3dبالاتر گفتیم برای اینکه بتونیم k3s را به صورت کلاستر تست کنیم، نیاز داریم که چند تا ماشین داشته باشیم. حالا تیم rancher ابزاری را ارائه کرده است که بتوان k3s را داخل یک کانتینر داشت و با استفاده از آن می‌توان کلاستر با استفاده از k3s را بر روی یک ماشین پیاده‌سازی و تست کرد. دقیقا شبیه kind با این تفاوت که کلاستر داخل کانتینر که راه‌اندازی می‌کنه با استفاده از k3s است و از اون داره استفاده می‌کنه.نیاز‌مندی این ابزار این است که داکر روی ماشین شما نصب باشد. برای نصب داکر می‌تونید از قسمت‌ اول و دوم این مستند استفاده کنید که نحوه‌ی نصب آن به صورت ویدئو توضیح داده شده است.برای نصب k3d از اسکریپت زیر استفاده می‌شود. به همین راحتی k3s نصب شد.curl -s https://raw.githubusercontent.com/rancher/k3d/master/install.sh | bashبعد از نصب دستور k3d می‌توانیم با استفاده از دستور زیر یک کلاستر با ۳ تا worker بر روی داکر راه‌اندازی کنیم.k3d create --workers 3 --name DockerMe-k3dk3d setup clusterدر انتهای راه‌اندازی کلاستر دستور مربوط به کانفیگ kubectl رو در اختیار شما قرار می‌دهد. پس همان دستور رو بزنید و بعد با استفاده از kubectl کلاستر را بررسی کنید.export KUBECONFIG="$(k3d get-kubeconfig --name='DockerMe-k3d')" kubectl config current-context kubectl cluster-info kubectl get node kubectl get po -Aبعد از نصب می‌توانید با دستور docker ps مشاهده کنید که چند تا کانتینر و هر کدام با چه نقشی ایجاد شده‌اند و اگر لازم بود کلاستر خود را گسترش دهید.k3d clusterبسیار خب این میشه قدم دوم‌مون در مسیر کوبرنتیز، تو پست‌های بعدی میریم به سراغ این ابزار و با جزئیات بیشتر باهاش آشنا میشیم.مراقب خودتون باشید. 🌹🐳🌹با ما متخصص شویدخوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 02 Nov 2024 10:17:07 +0330 https://virgool.io/@rafiee/%D8%A2%D8%BA%D8%A7%D8%B2-%D9%85%D8%B3%DB%8C%D8%B1-%DA%A9%D9%88%D8%A8%D8%B1-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-jekdzcpm6pzq بالاخره رسیدیم به حضرت کوبرنتیز 😎 اما قبلش اول یه مروری بکنیم که تا الان چه پست‌هایی داشتیم و بعدش از مرور مفاهیم کانتینر و تاریخچه کوبر شروع می‌کنیم و قدم به قدم با هم پیش میریم.خب یه مروری کنیم پست‌های قبلی رو:دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیمدر مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.مرور مفهوم کانتینر:Containerکانتینر رو به نوعی میتونیم بگیم یه فرم مجازی‌سازی در سطح سیستم‌عامل گفت، از یه کانتینر میتونیم برای ران کردن برنامه‌های مختلف از یک میکروسرویس کوچیک تا پروسه‌های یه اپلیکیشن بزرگ، استفاده کرد.داخل یک کانتینر تمام کدهای باینری،‌ کتابخانه‌ها و فایل‌های کانفیگ و برنامه‌های اجرایی مورد نیاز اون پروسه وجود دارند، بنابراین کانتینر رو میتونیم هرجایی بالا بیاریم و مثل قبل برامون کار کنه.کانتینرهای و تمام نیازمندی‌هایی که دارهنسبت به روش‌های دیگه مثل ماشین مجازی و سرور و ... کانتینرها سبک‌ترند و راحت‌تر و با overhead کمتری میشه اونا رو جابجا کرد. توی پست‌های داکر در مورد کانتینرها و مقایسه اونها با جزئیات بیشتری توضیح دادیم که میتونید برگردید مطالعه کنید.ارکستریشن Orchestration:Thanks to DALL-Eحالا تا وقتی‌که توی یک سرور هستیم با داکر و داکر کامپوز میتونیم به راحتی کانتینرهامون رو مدیریت کنیم ولی اگه ابعاد از چند تا سرور بیشتر بشه دیگه نیاز داریم که از ابزارهای ارکستریشن استفاده کنیم برای مدیریت کانتینرامون که مثل رهبر ارکستر بیایستن بالاسر سیستم ما تا صدای ساز کانتینرامون رو به خوبی بشنویم 🙃orchestrationابزارهای ارکستریشن‌، ابزارهایی برای automated configuration, management, coordination اپلیکیشن‌ها و سرویس‌ها و سیستم‌های کامپیوتری هستن. توی دنیای IT اونا به ما کمک می‌کنن تا تسک‌ها و ورک‌فلوهای پیچیده رو به آسانی مدیریت کنیم.مقایسه ابزارها:Container Orchestrationمقایسه داکر و کوبر:با اینکه این مقایسه به نوعی اشتباهه اما خیلی جاها می‌بینیم که این دوتا ابزار رو با هم مقایسه میکنن. چرا میگم این مقایسه اشتباهه؟! چونکه داکر یک پلتفرمی است که به با استفاده از یه Container Runtime به ما امکان این رو می‌ده که لینوکس کانتینرها رو داشته باشیم. ولی کوبرنتیز ابزار Orchestration هست کار مدیریت رو انجام میده حتی میتونیم کانتینرهای خود داکر رو با استفاده از کوبرنتیز مدیریت کنیم.Docker vs Kubernetesدر واقع داکر می‌تونه اپلیکیشن‌های کانتینری رو روی یک نود به صورت پکیج شده نگهداری کنه در حالی‌ که کوبرنتیز برای مدیریت کلاسترهای چند نوده طراحی شده. بنابراین اگر هم ما بخوایم کوبرنتیز و داکر رو مقایسه کنیم بهتره که کوبرنتیز رو با داکر سوآرم که ارکستریتور داکر هست، مقایسه کنیم که در ادامه میریم سراغش!اگه بخوایم خلاصه طور روند پیشرفت نگهداری اپلیکیشن‌ها رو یه بررسی بکنیم، مرحله اول به این صورت بود که روی همون سیستم‌عامل شروع می‌کردیم به نصب کردن فریم‌ورک‌ها و لایبرری‌های مورد نیاز و توسعه اپلیکیشن و نهایتا اپلیکیشن‌مون در قالب یک سرویس روی سرور بالا می‌آوردیم.مرحله دوم به این صورت هست که مستقیم روی سخت افزار یا روی‌ سیستم‌عامل یک هایپروایزر نصب می‌کنیم که با استفاده از اون میتونیم مجازی سازی رو در سطح ‌hardware انجام بدیم و منابع‌مون رو به صورت ایزوله شده و محدود به ماشین‌های مجازی مختلف اختصاص بدیم و روی اون ‌VM ها حالا اپلیکیشن خودمون رو راه‌اندازی کنیم. این همون مجازی‌سازی مرسوم است که خیلی پر استفاده و کاربردی می‌باشد.Virtualization vs Docker vs Kubernetes deploymentدر مرحله سوم با استفاده از ابزاری مثل داکر میاییم کرنل رو به اشتراک میذاریم اما در سطح پروسه‌های سیستم عامل مجازی‌سازی رو انجام میدیم و منابع رو به صورت ایزوله‌شده و مدیریت شده در اختیار کانتینرها می‌ذاریم و سرویس‌هامون رو با کانتینرها بالا میاریم.و حالا در مرحله چهارم این مسیر تکاملی مدیریت کانتینر هامون رو هم به یک ابزار کاربلد ارکستریشن میسپاریم تا بتونیم راحت‌تر اسکیل کنیم و ابعاد بزرگ رو مدیریت کنیم.مقایسه داکر سوآرم و کوبر:Docker-Swarm vs Kubernetesداکر سوآرم در واقع یه گروهی از چنتا سرور فیزیکی یا ماشین‌مجازی هست که داکر روی اونها نصب شده و کانفیگ‌شون کردیم تا با هم کلاستر بشن و مدیریت این کلاستر رو ارکستریشن داکر یعنی سوآرم انجام میده.بنابراین سوآرم به کانتینرها این امکان رو میده که روی کلاستری شامل چندین هاست بالا بیان و کار کنند و باهم ارتباط داشته باشند. این ارتباط رو خود ارکستریشن ایجاد می‌کنه.به‌ طور کلی سوآرم خیلی ساده‌تره از کوبرنتیز اما این سادگی در مقابل دست مارو هم میبنده خیلی جاها.Swarm vs Kubernetesمثلا سوآرم به ما قابلیت Auto Scaling نمیده در حالی‌که کوبر این امکان رو بهمون میده. سوآرم کامیونیتی خوبی داره اما کامیونیتی کوبر بسیار بزرگ و فعاله. سوآرم محدود به قابلیت‌های api داکر هست در حالیکه توی کوبر خیلی بیشتر دستمون باز هست اما در مقابلش هم راه اندازی سوآرم به آسونی چنتا دونه کامند ساده هست ولی کوبرنتیز یه مقداری مشکله راه‌اندازیش. راه‌اندازی کوبرنتیز پیچیده‌تر هست اما در کنارش اونقدر ابزار توسعه پیدا کرده که این کار رو برای ما خیلی ساده و روان کرده.به نظرم برای سایزهای کوچیک سوآرم بعضا انتخاب مناسب‌تری هست از کوبرنتیز حتی ... گاهی وقتا موقعی‌که به شرکتا این پیشنهاد رو میدم برداشت اشتباه میکنن، میگن مثلا طرف کوبرنتیز بلد نیست که میگه سوآرم و ... ولی واقعیتش اینه که توی یه اسکیل‌های کوچیکی اصرار به داشتن کوبرنتیز اشتباهه. دیدم آدمایی رو که به زور واسه دوتا سرویس کوچیک کلاستر کوبر ستاپ کردن و با اون کلاسترشون پدر خودشون و شرکت و همه رو با هم در آوردن 😬 هر چیزی در جای خودش درسته. به نظر من اگر شما تیم نگهداری و پایش کلاستر ندارید و تعداد تغییراتتون کمه و قابلیت‌های زیادی هم از ارکستریشن توقع ندارید سوارم راه‌ حل منطقی برای شما هست. اما اگر یکی از این موارد نقض بشه دیگه سوارم نمی‌تونه جواب نیازمندی شما رو بده.مقایسه نومَد و کوبر:Nomad vs Kubernetesابزار کمپانی hashicorp برای ارکستریشن یعنی Nomad یک ابزار ساده و منعطف برای ارکستریشن ورک‌لودهای مختلف هست. مزیت رقابتی که این ابزار نسبت به کوبرنتیز داره این هست که میتونه به صورت Automated لایف سایکل اپلیکیشن‌های کانتینری و همچنین غیرکانتینری رو مدیریت کنه. به طورکلی اخلاق هشی‌کورپ این مدلیه که میره یه جایی از مارکت رو سعی میکنه پوشش بده که کمتر رفتن سمتش. مثلا با Nomad میشه یه اسکریپ بش رو هم توی کلاستر مدیریت کرد و لزومی نداره حتما کانتینری باشه.از طرفی طراحی Nomad به شکلی هست که از اول برای هندل کردن پیاده سازی‌های مالتی دیتاسنتر و یا حالا برای اونایی که به کلادهای درست حسابی دسترسی دارن مالتی region، طراحی شده.Nomad vs Kubernetesکوبرنتیز به لحاظ کامیونیتی بسیار فعال‌تر هست و ساپورتی که از کامیونیتی میگیرید قابل مقایسه با Nomad نیست از طرفی Nomad استفاده و یادگیریش ساده تر هست. به طورکلی Nomad سعی کرده برای اسکیل‌های خیلی بزرگ کارآمد باشه در عین رعایت کردن سادگی. اما کوبرنتز با اینکه پیچیده تر هست اما دستمون هم توش بیشتر باز هست و کامیونیتی قوی‌تری هم داره. توی Nomad هم با کانتینرهای لینوکسی و هم ویندوزی میتونیم کار کنیم و نسبت به کوبرنتیز کمتر درگیر کانفیگ‌های متعدد میشیم و کمتر با چالش‌های نتورکی مواجه هستیم.اما اینکه آیا این مزیت رقابتی Nomad باعث میشه که در آینده بتونه مارکت رو بکشونه سمت خودش ... سوالیه که باید منتظر جوابش بمونیم ولی حداقل فعلا که کوبرنتیز تو کار خودش یکه‌تاز هست.مقایسه اوپن‌شیفت و کوبر:OpenShiftپلتفرم متن‌باز RedHat برای منیج، دیپلوی و توسعه اپلیکیشن‌های کانتینری OpenShift هست. اوپن‌شیفت میتونه یه IDE در اختیار دولوپر بذاره که اپلیکیشنش رو توسعه بده و دیپلوی کنه و مدیریتش روی کلاستر کوبر رو اوپن شیفت انجام بده.Openshift vs Kubernetesشاید مثلا توی مواردی مثل اینتگریت شدن با یه سری ابزارهای جانبی اوپن‌شیفت بهتر باشه اما من میگم موقع کار با اوپن‌شیفت هم اول آخرش باید کوبرنتیز رو بلد باشی، پس دیگه این واسطه رو میشه برداشت و مستقیم رفت سراغ کار کردن با خود کوبرنتیز، اینجوری overhead یادگرفتن یه ابزار دیگه هم کم میشه و میتونی تمرکز بیشتری رو روی کار خودت و نگهداری کلاسترت بذاری.یه نکته‌ی دیگه‌ای هم که در مورد اپن‌شیفت دارم اینه که به صورت رایگان وقتی داری ازش استفاده می‌کنی یه مشکلاتی باهاش مواجه می‌شی که خیلی راه‌ حل درست و منطقی براش پیدا نمی‌کنی و باید کلی بگردی و خودت به خوبی پیداشون کنی. بیشتر این موارد تو ساپورت داره حل می‌شه که خود ردهت داره ازش درآمد کسب می‌کنه و به همین راحتی نمی‌تونی بهش برسی. من پروژه‌های زیادی دیدم که رفتن سمت کوبرنتیز و مجبور شدن که اپن‌شیفت خودشون رو تغییر بدن. خیله خب دیگه از مقایسه‌ها بگذریم و بریم سراغ خود جناب کوبرنتیز 😎کوبرنتیز Kubernetes :Kubernetesکوبرنتیز یک پلتفرم متن‌باز برای مدیریت سرویس‌ها و ورکلودهای کانتینری هست که کانفیگوریشن و اتومیشن رو به صورت توصیفی ساده سازی کرده و کامیونیتی و بزرگ و درحال رشدی هم داره.طبق این مقاله از سایت کوبرنتیز، تجربه بیش از یک دهه نگهداری سرویس‌های کانتینری در گوگل توی پروژه‌های مختلف، در قالب پروژه Borg متن باز شده که کوبرنتیز هم مسیر همون پروژه رو داره ادامه میده و بسیاری از توسعه‌دهندگان کوبرنتیز افرادی هستن که قبلا روی بورگ کار میکردن.Kubernetes historyتوصیه میکنم قسمت اول و قسمت دوم مستند کوبرنتیز که هم‌روش زحمت زیرنویسش رو کشیده حتما ببینید، خیلی جالبه که ببینیم غول‌های تکنولوژی برای موندن توی مارکت گاها چه تصمیماتی می‌گیرن.K8Sاسم kubernetes یکم طولانی هست ازونجایی که هشت حرف بین k , s قراره داره بهش K8S هم میگن! و این ابزار ارکستریشن امروزه تبدیل شده به یکی از محبوب‌ترین ابزارهایی که سازمان‌های مختلفی دارن سمتش میرن و به اینکه مهاجرت کنن روی کوبر تا از امکانات بهره‌مند بشن، جدی‌تر و بیشتر فکر میکنن.اما چرا کوبر؟توی مسیری که داریم با هم پیش میریم متوجه شدیم که کانتینرها راه‌حل خوبی برای اجرای اپلیکیشن‌ها‌ توی محیط‌های پروداکشنی هستن، بنابراین ما نیاز داریم که بتونیم کانتینرهارو مدیریت کنیم و مطمئن بشیم که سرویس‌هامون پایدار هستن و اصطلاحا down time نداشته باشیم.کوبرنتیز با امکاناتی از قبیل مواردیکه در ادامه براتون لیست می‌کنم رو در اختیار ما میذاره تا بتونیم با استفاده از اونها کانتینرهامون رو مدیریت کنیم و توی اسکیل‌های بزرگ حتی بتونیم سرویس‌های پایداری رو داشته باشیم.Service discovery and Load balancingAutomated rollouts and rollbacksAutomatic bin packingSelf-healingSecret and configuration managementWhy Kubernetesتصور کنید ابزاری در اختیار دارید که شما براش توضیح می‌دید و می‌گید مثلا از این ایجنت مانیتورینگ من توی هر سرورم یه دونه بیار بالا، از سرویس فرانت‌اند سایتم مثلا میخوام چهارتا دونه بالا باشه که هرکدومش حداقل فلان میزان cpu و فلان میزان ram رو باید داشته باشند و حتی بهش می‌گید که حواست باشه که از مصرف کانتینرهای این سرویس من بالا رفت مثلا اگه ۸۰ درصد ram شون زیرلود پر شد اونوقت تو شروع کن و خودت تعداد اون‌ها ببر بالا مثلا تا سقف ۴۰ تا دونه!!! و بعدش که لود کمتر شد دوباره خودت این تعداد رو کم کن ولی دیگه از سه تا کمتر نشه و همیشه حداقل سه تا بالا باشه.یا مثلا میخوایم آپدیت انجام بدیم من بهت میگم که مثلا دوتا دوتا از کانتینرهای سرویس قبلی بیار پایین و دوتا ازین نسخه جدید جایگزینش کن، یا نه اصلا اگه الان پنجاه تا دونه از نسخه قبلی بالا هست اشکالی نداره من منابع کافی در اختیارت میذارم تو پنجاه تا هم از نسخه جدید اول بیار بالا من تست بگیرم مطمئن که شدم بعد کلا لود مشتری رو جابجا کن روی این نسخه جدید ...میبینید؟ اگه تجربه نگهداری سرویس‌های یه مقدار بزرگ توی پروداکشن رو داشته باشید متوجه میشید که اینا کارای بزرگی هستن و ابزاری که این توانایی هارو به ما بده، ابزار ارزشمندیه. کم‌کم داره معلوم میشه چرا کوبر سروصدا کرده :)Kubernetes adoptionطبق گزارش‌هایی که داده شده درصد زیادی از کمپانی‌هایی که سرویس‌های کانتینری نگهداری میکنن توی محیط پروداکشن‌شون هم از کوبرنتیز استفاده می‌کنند.مدارک کوبرنتیز :Kubernetes Certificatesسه تا مدرک هست که برای کوبرنتیز هستن و مدارک معتبری هستن که CNCF با همکاری Linux Foundation اونها رو بعد از آزمون‌هایی که میگیره به افراد میده، به نام های CKAD, CKA, CKS که در ادامه بررسی‌شون می‌کنیم. دوتا مدرک دیگه هم هست KCNA و KCSA که اونا رو هم توضیح میدم. کوبرنتیز ابزار بسیار بزرگی هست که از زوایای مختلف می‌شه به اون نگاه کرد که این موضوع به خوبی تو مدرک‌های کوبرنتیز قابل مشاهده است.Certified Kubernetes Administrator (CKA)هدف این مدرک ارزیابی توانایی‌های ادمین کلاستر کوبر هست که در قالب یک آزمون عملی انجام میشه و این مدرک برای افرادی هست که نگهداری کلاستر رو انجام میدن. این نگاه سمت administration خود کوبرنتیز است.Certified Kubernetes Application Developer (CKAD)هدف این مدرک ارزیابی توانایی های افراد برای استفاده از کوبرنتیز برای build و مانیتور و Tshoot اپلیکیشن‌هایی که توسعه میده هست و مناسب افرادی هست که از ساید توسعه‌دهنده ها هستن اما اپلیکیشن اونا قراره روی کوبر مستقر بشه. اینجا نگاه سمت استفاده کننده کوبرنتیز است. یعنی شما به نگهداری کلاستر کاری ندارید و به عنوان مشتری دارید از خود کوبرنتیز استفاده می‌کنید.Certified Kubernetes Security Specialist (CKS)افرادی که بخوان این مدرک رو بگیرن ابتدا باید CKA رو داشته باشند و بعد از اون میتونن سراغ این مدرک بیان که بیشتر هدفش تمرکز روی بست‌پرکتیس ها و امن کردن کانتینرها هست و دانش امنیتی افراد رو میسنجه. این نگاه برای افزایش امنیت در استفاده از کوبرنتیز است.Kubernetes and Cloud Native Associate (KCNA)این هم یک مدرک دیگه هست برای افرادیکه کمتر حرفه‌ای هستن که آشنایی اولیه با محیط‌های کلاد نیتیو و اکوسیستم ابری رو میسنجه و آشنایی اولیه با کوبرنتیز که میتونی به نوعی برای آمادگی قبل از سه مدرک دیگه ازش استفاده بشه.Kubernetes and Cloud Native Security Associate (KCSA)این هم مثل قبلیه اما واسه سکیوریتی !Kubestronaut Bundleبه کسی هم که هر پنج مدرک رو با هم میگیره اصطلاحا Kubestronaut میگن که اینجا میتونید بیشتر در موردش بخونید.ما تو ایران هستیم نمی‌تونیم این مدرک‌های رو بگیریم و اونا ما رو تحریم کردن و بهمون نمی‌دن. البته ایرانی‌ها می‌تونند بگیرن ولی اینکه تو کشور ایران هستیم نمی‌شه. دیدم که بعضی‌ها با مسافرت تونستن بگیرن ولی نرمالی اگر فقط سفر کردی نرمالی بهت نمی‌دن. برای امتحانش هم یه نفر آنلاین می‌شه و بررسی می‌کنه که چیت‌ نکنی و درست امتحان بدی. کلا مدرک‌های معتبری هست که توصیه می‌کنم اگر امکانش رو داشتید حتما براش اغدام کنید. سایت‌های زیادی هستن که کمکتون می‌کنند که این مدرک‌ها رو بتویند به خوبی بگیرید که این سایت یکی از بهترین‌ها هست و می‌تونید ازش استفاده کنید.بسیار خب این میشه قدم اول‌مون در مسیر کوبرنتیز، تو پست‌های بعدی میریم به سراغ این ابزار و بیشتر باهاش آشنا میشیم.مراقب خودتون باشید. 🌹🐳🌹خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.🫀 Follow DockerMe 🫀🔔 Follow YouTube 🔔📣 Follow Instagram 📣🖇 Follow LinkedIn DockerMe🖇🔎 Follow Linkedin Ahmad Rafiee 🔎🕊 Follow Twitter 🕊 احمد رفیعی احمد رفیعی Sat, 26 Oct 2024 11:41:47 +0330