Kubernetes v1.32 - Kısaca Neler Yeni


Kubernetes v1.32: "Penelope" resmi olarak duyuruldu.

Bu sürüm daha çok şu konulara odaklandı:

Red Hat OpenShift 4.17 Kurulumu: Windows Makinenizde OpenShift Deneyimi!


Merhaba, bu yazıda ve ilgili videoda, Red Hat’in container yönetim platformu olan OpenShift’in en son sürümü (4.17) ile Windows makineniz üzerinde nasıl bir kurulum gerçekleştirebileceğinizi detaylıca ele alıyorum. Amacım sadece kurulum adımlarını göstermek değil; aynı zamanda platformun farklı özelliklerini de sizinle paylaşmak. 😊

Immutable Nedir ?


"Immutable" kelimesi, değiştirilemez veya sabit anlamına gelir. Bilgisayar bilimlerinde ve veri koruma alanında bu terim, bir kez yazıldıktan sonra değiştirilemeyen veya silinemeyen verilere işaret eder. Özellikle yedekleme (backup) çözümlerinde immutable backup terimi çok sık kullanılır.

Ansible vs. Terraform


Ansbile ve Terroform şu anda ister cloud ister on prem yapılarınız içinde özellike infra yapılarınızın merkezi olarak ve belirli işleri berlirli zaman aralık ve sürelerde arka arkaya yapılması gereken süreçleri otomatikleştirmek CI/CD pipeline içinde depolayment kısımında gerekiyor ise yeni infra ypaılarını kurmaya kadar giden sürçeleri yönetmeniz için gerkeli tool' lar bir karşılaştırma buldum ve siteye ekledim umarım sizlerinde faydasına olur. Kolay gelsin. 

systemd ile Service Oluşturarak Rocky Linux 9.4'te Otomatik Komut Çalıştırma

Rocky Linux 9.4 gibi modern Linux dağıtımlarında, sistem başlangıcında otomatik olarak komut çalıştırmak için en etkili yöntemlerden biri systemd service oluşturmaktır. Bu yöntem, sistemin daha düzenli ve yönetilebilir olmasını sağlar.

VMware Tools Install on Rocky Linux 9.4


Rocky Linux Üzerinde VMware Tools Install

Orijinal doküman burada :  https://docs.rockylinux.org/pl/guides/virtualization/vmware_tools/ 

Buildah Nedir ve Ne İçin Kullanılır?


Buildah, konteyner imajlarını oluşturmak, yönetmek ve değiştirmek için kullanılan bir araçtır. Genellikle Podman ile birlikte kullanılır ve konteyner oluşturma işlemi için Docker Daemon gibi bir arka plan hizmetine ihtiyaç duymadan çalışır. Buildah, özellikle güvenlik ve konteyner imajlarının esnek bir şekilde inşa edilmesi açısından güçlü bir alternatiftir.

Docker ve Podman Arasındaki Farklar


Docker ve Podman arasında hangisinin daha iyi olduğu, kullanıcının ihtiyaçlarına, ortamına ve kullanım senaryolarına bağlıdır. Her ikisinin de güçlü ve zayıf yönleri vardır. İşte ikisinin karşılaştırması:

Kubernetes Sürüm Bilgileri - Mini Yenilikler Listesi


Kubernetes kararlı sürümleri genellikle N-2 destek politikasıyla yayınlanır, yani en yeni sürüm ve ondan önceki iki sürüm aktif olarak desteklenir. Ekim 2024 itibarıyla desteklenen majör ve minör Kubernetes sürümleri şu şekildedir:

Linux Çekirdek Seçenekleri ve Anlamları


Linux'ta kullanıcının ihtiyaçlarına göre çeşitli sürüm ve çekirdek seçenekleri bulunmaktadır. İşte bunlardan bazıları:

RabbitMQ – Yazılımlar arası Mesajlaşma

 

Yazılımlar arası mesajlaşma ile insanlar arası mesajlaşma arasında kavramsal bir fark var. İnsanlar Skype veya WhatsApp gibi uygulamalarla doğrudan metin veya sesli mesajlar gönderir. Yazılımlar arasındaki mesajlaşma ise daha çok veri veya bilgi alışverişi anlamına gelir ve bir yazılımın diğerine veri göndermesi veya bir işlemi tetiklemesi gibi senaryolarda kullanılır.

Yazılımlar Arasında Mesajlaşma Neden Gerekli?

Birçok yazılım veya sistem birbirleriyle doğrudan iletişim kurmak zorunda kalır. Örneğin:

E-ticaret Uygulaması: Bir müşteri sipariş verdiğinde, sipariş bilgileri veritabanına kaydedilir ve aynı anda bir kargo sistemine siparişin gönderilmesi gerekir. Bu iki yazılımın birbirinden haberdar olup mesaj alışverişi yapması gerekir.

Mikroservis Mimarisi: Bir uygulama birçok küçük servisten oluşur. Örneğin, kullanıcı kaydını yapan bir servis, e-posta gönderme servisine bir mesaj gönderir ve kullanıcıya hoş geldin e-postası iletilir.

Farklı Teknolojiler: Bir yazılım PHP ile yazılmış, diğer yazılım ise Python ile yazılmış olabilir. İki farklı teknoloji arasında doğrudan iletişim kurmak zor olabilir. Mesajlaşma sistemleri, bu iletişimi kolaylaştırır.

Bu noktada mesajlaşma sistemleri devreye girer. Örneğin, RabbitMQ gibi bir mesaj kuyruğu, bir yazılımın diğerine mesaj göndermesini sağlar ve bu mesajı belirli bir sıraya koyarak işlenmesini bekler. Yani, bir uygulama bir kuyruk aracılığıyla mesajı gönderir, diğer uygulama ise bu kuyruğu dinleyerek mesajları alır ve işleyebilir.

RabbitMQ ile İki Yazılımın Haberleşmesi: Örnek Senaryo

Şimdi bir örnek üzerinden RabbitMQ'yu anlatayım. Diyelim ki bir e-ticaret uygulaması yazıyorsunuz. Bu uygulama iki ayrı servise sahip:

1. Sipariş Servisi: Kullanıcı sipariş verdiğinde bu servis çalışır.
2. Kargo Servisi: Sipariş onaylandıktan sonra bu servis çalışarak kargo bilgilerini işler.

Bu iki servis nasıl haberleşir? İşte RabbitMQ bu noktada devreye girer. RabbitMQ'nun işleyişini şöyle bir adım adım inceleyelim:

1. Mesaj Gönderimi (Sipariş Servisi)

Sipariş servisi, bir kullanıcı sipariş verdiğinde bu sipariş bilgilerini RabbitMQ'nun sipariş kuyruğuna (queue) bir mesaj olarak gönderir. Bu mesaj, siparişin detaylarını içerir: ürün adı, miktar, adres vb.

2. Mesaj Kuyruğa Alınır (RabbitMQ)

RabbitMQ, gelen bu mesajı bir kuyruğa yerleştirir. Bu, mesajın kaybolmamasını sağlar ve alıcı sistem hazır olduğunda mesajı işleyebilir.

3. Mesajı Alma ve İşleme (Kargo Servisi)

Kargo servisi, RabbitMQ'yu dinler. Yani kargo servisi sürekli olarak RabbitMQ'dan yeni sipariş mesajları gelip gelmediğini kontrol eder.

Eğer bir sipariş mesajı kuyruğa düşerse, kargo servisi bu mesajı alır ve kargo işlemini başlatır.

Örnek RabbitMQ Mesajlaşma Süreci

1. Sipariş Servisi -> RabbitMQ (Mesaj Gönderimi)

2. RabbitMQ -> Mesaj Kuyruğa Alınır

3. Kargo Servisi -> RabbitMQ'dan Mesaj Alır ve İşler

Bu sistemin avantajı şudur:

Güvenilirlik: Mesajlar kaybolmaz. Eğer kargo servisi geçici olarak çalışmazsa, RabbitMQ mesajı sırada bekletir ve servis tekrar çalışmaya başladığında mesajı alır.

Esneklik: Servisler birbirinden bağımsızdır. Sipariş servisi işini bitirdikten sonra kargo servisi ne zaman hazır olursa mesajı işleyebilir.

Performans: Asenkron çalıştığı için sistemler birbiriyle beklemeden işlem yapabilir. Sipariş servisi hemen yeni bir sipariş işleyebilirken, kargo servisi siparişleri arka planda işleyebilir.

Bu tür bir mesajlaşma sistemi, yazılım bileşenlerinin birbiriyle bağlantılı ama bağımsız çalışmasına izin verir. Özellikle dağıtık sistemlerde, performans ve güvenilirlik açısından önemli bir yapı sunar.

Eğer bu temel yapı anlaşıldıysa, RabbitMQ'da daha derin konulara (exchange tipleri, routing, queue yapılandırmaları gibi) geçebiliriz.


HTTP Durum Kodları ve Türkçe Açıklamaları



1xx: Bilgilendirme

100 Continue: Sunucu istek başlıklarını aldı ve istemci istek gövdesini göndermeye devam etmelidir.

101 Switching Protocols: İstemci, sunucudan protokolleri değiştirmesini talep etti ve sunucu bunu kabul etti.

102 Processing: Sunucu isteği aldı ve işliyor, ancak henüz yanıt hazır değil.

2xx: Başarılı

200 OK: İsteğin başarıyla tamamlandığına dair standart yanıt.

201 Created: İstek başarılı oldu ve yeni bir kaynak oluşturuldu.

202 Accepted: İstek kabul edildi, ancak henüz işleme tamamlanmadı.

203 Non-Authoritative Information: Sunucu, başka bir kaynaktan 200 OK aldı ancak yanıtı değiştirdi.

204 No Content: Sunucu isteği başarıyla işledi, ancak içerik dönmüyor.

205 Reset Content: Sunucu isteği başarıyla işledi, istemciden görünümünü sıfırlamasını talep ediyor.

206 Partial Content: Sunucu, istemcinin gönderdiği aralık başlığı nedeniyle kaynağın yalnızca bir kısmını teslim ediyor.

207 Multi-Status: Mesaj gövdesi, yapılan alt isteklerin sayısına bağlı olarak birden fazla yanıt kodu içerebilir.

208 Already Reported: DAV bağlama üyeleri daha önce bu isteğe yanıt olarak listelenmiştir ve tekrar dahil edilmez.

226 IM Used: Sunucu, kaynak için bir veya daha fazla örnek manipülasyonu uygulamasının sonucunu temsil eden bir yanıt sağladı.

3xx: Yönlendirme

300 Multiple Choices: İstemcinin seçebileceği birden çok seçenek belirtiyor.

301 Moved Permanently: Bu ve gelecekteki tüm istekler belirtilen URI'ye yönlendirilmelidir.

302 Found: İstemciye başka bir URL'ye bakmasını (gidilmesini) söyler.

303 See Other: İsteğin yanıtı başka bir URI'de GET yöntemi kullanılarak bulunabilir.

304 Not Modified: İstek başlıkları tarafından belirtilen sürümden bu yana kaynak değiştirilmemiştir.

305 Use Proxy: İstenilen kaynak yalnızca belirtilen proxy üzerinden erişilebilir.

306 Switch Proxy: Artık kullanılmıyor. İlk başta "Sonraki istekler belirtilen proxy kullanılarak yapılmalıdır" anlamına geliyordu.

307 Temporary Redirect: Bu durumda istek başka bir URI ile tekrarlanmalıdır; ancak gelecekteki istekler yine orijinal URI kullanılarak yapılmalıdır.

308 Permanent Redirect: İstek ve gelecekteki tüm istekler başka bir URI kullanılarak tekrarlanmalıdır.

4xx: İstemci Hatası

400 Bad Request: Sunucu, istemcinin isteğini anlayamıyor veya işleyemiyor.

401 Unauthorized: Kimlik doğrulama gereklidir ve başarısız oldu veya henüz sağlanmadı.

402 Payment Required: Gelecekte kullanmak üzere ayrılmıştır.

403 Forbidden: İstek geçerli, ancak sunucu eylemi reddediyor.

404 Not Found: İstenen kaynak bulunamadı, ancak gelecekte mevcut olabilir.

405 Method Not Allowed: İstek için kullanılan yöntem istenen kaynak için desteklenmiyor.

406 Not Acceptable: İstenen kaynak, istekte belirtilen kabul başlıklarına uygun içerik üretemiyor.

407 Proxy Authentication Required: İstemci öncelikle proxy ile kimlik doğrulaması yapmalıdır.

408 Request Timeout: Sunucu isteği beklerken zaman aşımına uğradı.

409 Conflict: İstek, çakışma nedeniyle işlenemiyor, örneğin, aynı anda yapılan güncellemeler arasında bir düzenleme çakışması.

410 Gone: İstenen kaynak artık mevcut değil ve tekrar mevcut olmayacak.

411 Length Required: İstek, gereken içeriğin uzunluğunu belirtmedi.

412 Precondition Failed: Sunucu, istemcinin isteğe koyduğu önkoşullardan birini karşılamıyor.

413 Payload Too Large: İstek, sunucunun işlemeyi kabul edemeyeceği kadar büyük.

414 URI Too Long: Sağlanan URI, sunucunun işleyemeyeceği kadar uzun.

415 Unsupported Media Type: İstek varlığının medya türü, sunucu veya kaynak tarafından desteklenmiyor.

416 Range Not Satisfiable: İstemci dosyanın bir kısmını istemiştir (byte serving), ancak sunucu bu kısmı sağlayamıyor.

417 Expectation Failed: Sunucu, Expect istek başlık alanının gereksinimlerini karşılayamıyor.

418 I'm a teapot: Bu kod, 1998 yılında IETF Nisan Şakası olarak tanımlanmıştır ve gerçek HTTP sunucuları tarafından uygulanması beklenmemektedir.

421 Misdirected Request: İstek, yanıt üretemeyen bir sunucuya yönlendirilmiştir.

422 Unprocessable Entity: İstek iyi biçimlendirilmiş, ancak anlam hataları nedeniyle işlenemiyor.

423 Locked: Erişilmeye çalışılan kaynak kilitli.

424 Failed Dependency: İstek, başka bir isteğe bağımlı olduğu için başarısız oldu ve o istek başarısız oldu.

425 Too Early: Sunucu, tekrarlanabilir bir isteği işleme riskini almak istemiyor.

426 Upgrade Required: İstemci, TLS/1.0 gibi farklı bir protokole geçmelidir.

428 Precondition Required: Kaynak sunucu, isteğin koşullu olmasını gerektirir.

429 Too Many Requests: Kullanıcı belirli bir süre içinde çok fazla istek gönderdi.

431 Request Header Fields Too Large: Sunucu, başlık alanlarının çok büyük olduğu için isteği işlemek istemiyor.

451 Unavailable For Legal Reasons: Kullanıcı, bir hükümet tarafından sansürlenen bir web sayfası gibi yasal olarak erişilemeyen bir kaynak istemektedir.

5xx: Sunucu Hatası

500 Internal Server Error: Beklenmeyen bir durumla karşılaşıldığında verilen genel hata mesajı.

501 Not Implemented: Sunucu, isteği yerine getirme yeteneğine sahip değil veya isteme yöntemi tanınmıyor.

502 Bad Gateway: Sunucu, bir geçit veya proxy olarak görev yaparken, üst sunucudan geçersiz yanıt aldı.

503 Service Unavailable: Sunucu şu anda kullanılamaz (aşırı yüklendiği veya bakımda olduğu için).

504 Gateway Timeout: Sunucu, bir geçit veya proxy olarak görev yaparken, üst sunucudan zamanında yanıt almadı.

505 HTTP Version Not Supported: Sunucu, istemcinin kullandığı HTTP protokol sürümünü desteklemiyor.

506 Variant Also Negotiates: İstek için yapılan şeffaf içerik müzakeresi, döngüsel bir referansla sonuçlanıyor.

507 Insufficient Storage: Sunucu, isteği tamamlamak için gerekli olan temsili depolayamıyor.

508 Loop Detected: Sunucu, bir isteği işlerken sonsuz döngü tespit etti.

510 Not Extended: Sunucunun isteği yerine getirebilmesi için ek uzantılar gerekmektedir.

511 Network Authentication Required: İstemcinin ağ erişimi sağlamak için kimlik doğrulaması yapması gerekiyor.

Open Shift içinden dosya almak.


Konu şu arkadaşlar ortamlardan yani Open shift ortamınız içinde bulunan Node' lar veya Pod' lar içerisinden dosya alma ihtiyacınız olabiliyor bazen support case için bazen farklı durumlar için olabilir. 

Ben size iki durum içinde örmek yapmaya çalışacağım örnek olarak ise hem node' lardan hemde pod' lardan pcap almak (network trafik) üzerinden devam edeceğiz.

OpenShift içerisindeki tüm servisler ve açıklamaları


OpenShift içerisindeki tüm servisler ve hangi namespace e ait oldukları hakkında detaylı bir liste sizlerin işine yarayacaktır umarım. Aşağıda yaygın olarak kullanılan OpenShift servislerinin ve ilgili namespace lerinin listesini bulabilirsiniz bu listede ayrıca servislerin ne işe yaradığını anlatan açıklamalar ekledim.

Redhat OpenShift Kurulumu sırasında disk Önemi


Redhat OpenShift Ortamlarının kurulumu sırasında disk seçimleri önemlidir.

Genelde Worker node' lar fiziki olarak tercih edilir. Master ve Infra rollerin olduğu yapılar ise Virtaul ortamlarda kurulur.

Worker Master ve İnfra node' lar üzerinde komut çalıştırmak


Worker Master ve İnfra nodeler üzerinde komut çalıştırmak için kullanılması gereken komutlar için node' lara erişmek için aşağıdaki aşamaları kullanabilirsiniz.

ilk olarak bastion makinenizden bir cluster ortamınıza login oluyoruz.

OCP Kurulum Mode' ları hakkında bilgiler.


OpenShift Container Platform kurulum programı, bir cluster dağıtmak için dört yöntem sunar ve bunlar aşağıdaki listede detaylandırılmıştır:

Kubernetes 1.30 Install - Onprem


Gereksinimler
Onprem DNS Server : Windows veya Linux Bind vb 
Yeni kurulmuş ve update edilmiş Rocky Linux 9.3
Sudo ile birlikte admin yetkisine sahip bir kullanıcı veya direkt root user
Her makinede en az 2 vCPU 2 GB ram
Stabil bir internet bağlantısı

Lab ortamı 
ilk olarak DNS Server üzerinde gerekli dns ve sunucu isimlerini açıyoruz.
dns.1w2.io     -> 192.168.1.60 -> Windows Server
master.1w2.io  -> 192.168.1.65 -> Rocky Linux Server
worker1.1w2.io -> 192.168.1.66 -> Rocky Linux Server
worker2.1w2.io -> 192.168.1.67 -> Rocky Linux Server

1 - Linux makinelerin isimlerini aşağıdaki gibi ayarlıyoruz.
sudo hostnamectl set-hostname “master.1w2.io” && exec bash
sudo hostnamectl set-hostname “worker1.1w2.io” && exec bash
sudo hostnamectl set-hostname “worker2.1w2.io” && exec bash

Bu adımda eğer ortamınızda Windows veya Linux DNS sever yok ise kullanın, eğer dns server var ise dns kayıtlarını açmalısınız. Her bi node içindeki /etc/hosts dosyasına aşağıdaki girdileri ekleyin.

192.168.1.65   master.1w2.io
192.168.1.66   worker1.1w2.io
192.168.1.67   worker2.1w2.io


2 - Her node üzerinde takas alanının disable edin. Kubelet' in sorunsuz çalışması için tüm node’ lar takas alanını devre dışı bırakmalıyız. Swap alanının server açılışına eklenmesini de aynı aşamada yapıyoruz. Sırası ile, aşağıdaki komutları çalıştırın,

sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

3 - Kubernetes için SELinux ve Güvenlik Duvarı (Firewall) Kurallarını Ayarlama
Aşağıdaki komutları kullanarak tüm node'lardaki SELinux modunu izinli olarak ayarlayın,
(Bu ayarları her node üzerinde yapıyoruz)

sudo setenforce 0
sudo sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/sysconfig/selinux

Master Node, firewall aşağıdaki bağlantı noktalarına izin verin.

sudo firewall-cmd --permanent --add-port={6443,2379,2380,10250,10251,10252,10257,10259,179}/tcp
sudo firewall-cmd --permanent --add-port=4789/udp
sudo firewall-cmd --reload

Worker Node, firewall alttaki bağlantı noktalarına izin verin,

sudo firewall-cmd --permanent --add-port={179,10250,30000-32767}/tcp
sudo firewall-cmd --permanent --add-port=4789/udp
sudo firewall-cmd --reload

4 - Gerekli Kernel Modüllerini ve Parametreleri ekliyoruz.
Kubernetes cluster için, tüm master ve worker üzerinde overlay ve br_netfilter kernel modüllerini eklemeliyiz.

sudo tee /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF

Modulleri yüklemek için komutlar aşağıda

sudo modprobe overlay
sudo modprobe br_netfilter

Kernel parametreleri için aşağıdaki dosyayı oluşturup içine satırları ekleyip kayıt ediyoruz. ( vi veya nano kullanılabilir)
sudo vi /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables   = 1
net.ipv4.ip_forward                        = 1
net.bridge.bridge-nf-call-ip6tables = 1

Bu komut ile yaptığımız kernel modul ve parametreleri devreye alıyoruz load yapıyoruz. 

sudo sysctl --system

5 - Containerd Runtime yüklüyoruz ( Docker Yerine )
Kubernetes bir konteyner runtime gerektirir ve en popüler seçeneklerden biri containerd dir. Ancak Rocky Linux varsayılan paket depolarında mevcut değildir, bu nedenle tüm master ve worker nodeler' e aşağıdaki docker deposunu ekleyin.

sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Şimdi tüm master ve worker nodeler üzerinde containerd yüklemesi yapıyoruz.

sudo dnf install containerd.io -y

Sırada containerd' yi systemdcgroup kullanacak şekilde yapılandırma var, her master ve worker node  üzerinde aşağıdaki komutları çalıştırın.

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1
sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml

Containerd servisini restart ediyoruz ve server açılışına ekliyoruz her master ve worker node üzerinde yapıyoruz.

sudo systemctl restart containerd
sudo systemctl enable containerd

Containerd çalışma durumunu bir kontrol edelim her master ve worker node üzerinde yapıyoruz.

sudo systemctl status containerd

6 - Kubernetes araçlarını (tools) yüklüyoruz.

Kubeadm, kubectl ve kubelet gibi Kubernetes araçları Rocky Linux 9'un varsayılan paket depolarında mevcut değildir. Bu nedenle, bu araçları yüklemek için aşağıdaki depoyu her master ve worker node üzerinde ekleyin.

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF


Not: Bu yazının yazıldığı sırada Kubernetes 1.30 sürümü mevcuttur, bu nedenle depoyu eklerken v1.30'dan bahsettim.

Sırada aşağıdaki komut ile Kubernetes araçları kubeadm kubectl ve kubelet yüklemelerini her master ve her node üzerine yüklüyoruz.
sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

 

Kubernetes araçlarını yükledikten sonra, kubelet servisini her master ve her node üzerinde server  açılışına ekliyoruz.

sudo systemctl enable --now kubelet

7- Kubernetes yüklemsine başlıyoruz şimdi :) 

Şimdi, Kubernetes kurmaya kurmaya hazırız. Kubernetes cluster' in master node' dan başlatmak için Kubeadm komutunu aşağıdaki gibi çalıştırın. Komut satırının sonundaki server ismine dikkat ederek ve değiştirerek komutu uygulayınız.

sudo kubeadm init --control-plane-endpoint=master

Yukarıdaki komut sonrasında aşağıdaki gibi bir çıktı vermesi gerekiyor master node. Burada alt satırda bulunan resimde sarı ve sarı okla işaretlediğim alanda isin worker node' larınızı cluster ortamına eklemek için gerekli olan komut satırlarını göreceksiniz bu alanı bir notapad e kayıt etmeniz sizin için iyi olacaktır. Hatta prod ortamınıza sonradan cluster' e ekleme yaparkende kullanabileceksiniz.

örnek : 

kubeadm join master:6443 --token 5hihin.pd0x69fm9c84lj0l \

        --discovery-token-ca-cert-hash sha256:358499b111f8b3e6da00add3eba8b58bce57c36d9768e30bd1f3caa7ef532e1d

Sürece master node üzerinde işlem yaparak devam ediyoruz aşağıdaki komutları girerek.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Arkasından yukarıda örneği ve resimde işaretli alandaki komut ile worker node' ları cluster içine ekliyoruz.

kubeadm join master:6443 --token 5hihin.pd0x69fm9c84lj0l \
--discovery-token-ca-cert-hash sha256:358499b111f8b3e6da00add3eba8b58bce57c36d9768e30bd1f3caa7ef532e1d

Her worker node üzerinde komut çalıştırıldıktan sonra aşağıdaki resimlerdeki gibi çıktıları almanız gerekiyor.

Worker1

Worker2


Sonrasında Master node arayüzüne geçip aşağıdaki komutu çalıştırıyoruz.

kubectl get nodes


Buraya kadar bir cluster kurulumunu yaptık ve bitirdik ama default olarak birkaç ekleme yapmamız lazım ki en önemlisi network ayarı ve yönetimi bunun için 8. adımdan devam ediyoruz. Zaten resimde not ready yani network yok iletişim yok diye sadece status bölümünü istediğimiz gibi göremiyoruz birkaç adım sonra görebileceğiz ok.

8 - Calico Network Addon yüklemesi
Kubernetes cluster içinde podlar arasında iletişimi sağlamak, DNS hizmetinin küme ile çalışmasını sağlamak, master ve worker durumunu Hazır hale getirmek için Calico network addın gereklidir.
calico CNI (Container Network Interface) eklentisini yüklemek için aşağıdaki kubectl komutlarını yalnızca master node üzerinden çalıştırmalısınız.

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.3/manifests/calico.yaml

Calico yüklemesi sonrasında bir süre bekleyip aşağıdaki komut girelim bu komut calico pod durumlarını kontrol ediyor ve status durumları running modda olmalıdır.

kubectl get pods -n kube-system


Test öncesinde cluster durumu gözlemleyelim artık not ready bölümü resimde görebileceğiniz gibi ready hale geldi calico install sonrasında 
kubectl get nodes

Buraya ekstra bir not: Kubernetes Cluster kurulumu bittikten sonra ekranda 
kubectl get nodes ekran çıktısında worker node role ataması için aşağıdaki komut kullanılabilir.

kubectl label node worker1.1w2.io node-role.kubernetes.io/worker=worker
kubectl label node worker2.1w2.io node-role.kubernetes.io/worker=worker
Eklenen label silmek içinde aşağıdaki komutu kullanabilirsiniz

kubectl label node worker1.1w2.io node-role.kubernetes.io/worker- (sondaki isim ve - işareti çok önemli )
kubectl label node worker2.1w2.io node-role.kubernetes.io/worker- (sondaki isim ve - işareti çok önemli )

 Bu makaleyi 2024 Mayıs ta yazdım ama yayınlamak yeni nasip oldu bilgilerinize. :) 

OpenShift Container Platform Kurulumu için Yaygın Terimler Sözlüğü


Bu sözlük, seçilen kurulum metoduna göre kurulum içeriğiyle ilgili yaygın terimleri tanımlar. Kurulum sürecini daha iyi anlamak için aşağıdaki terimler listesini okuyun.

Kubernetes bileşenlerinin listesi


Kubernetes bileşenlerinin tam listesini hem on-premises (onprem) hem de bulut tabanlı (cloud) ortamlar için sağlayayım. Bu listede, Kubernetes kontrol bileşenlerinin yanı sıra, genellikle bu ortamlarda kullanılan diğer önemli bileşenler de bulunacaktır.
On-Premises (Onprem) Kubernetes Ortamı
1. kube-apiserver
  • Namespace: kube-system
  • Açıklama: Kubernetes API sunucusudur ve tüm API isteklerini kabul eder. Bütünleşik bir ön uç sağlar ve güvenlik kimlik doğrulaması ve yetkilendirme işlemlerini gerçekleştirir.
2. kube-scheduler
  • Namespace: kube-system
  • Açıklama: Pod'ların hangi nodelerde çalışacağını belirler. Çalışma yüklerinin dengelenmesi ve kaynakların etkin kullanımı için kararlar alır.
3. kube-controller-manager
  • Namespace: kube-system
  • Açıklama: Çeşitli kontrol döngülerini (replication controller, endpoint controller, namespace controller vb.) yönetir. Bu döngüler, kaynakları ve durumları düzenli olarak izler ve gereken değişiklikleri uygular.
4. etcd
  • Namespace: kube-system
  • Açıklama: Dağıtılmış bir anahtar-değer deposu olup, Kubernetes clusternin tüm veri ve yapılandırmalarını saklar. Veri tutarlılığı ve erişilebilirliği sağlar.
5. kube-proxy
  • Namespace: kube-system
  • Açıklama: Her nodede çalışır ve Kubernetes hizmetlerinin ağ yönlendirmesini sağlar. İsteklerin doğru pod'a iletilmesini sağlar.
6. coredns
  • Namespace: kube-system
  • Açıklama: Kubernetes cluster içinde DNS hizmetlerini sağlar. Pod'lar arasında ad çözümleme ve servis keşfi işlemlerini gerçekleştirir.
7. kubelet
  • Namespace: Her nodede çalışır, bu nedenle namespace'e bağlı değildir.
  • Açıklama: Kubernetes node ajanıdır. Pod'ların çalıştırılmasını ve yönetilmesini sağlar. API sunucusuyla iletişim kurarak nodedeki durumları günceller.
8. kube-controller-manager
  • Namespace: kube-system
  • Açıklama: Çeşitli kontrol döngülerini (replication controller, job controller, daemonset controller vb.) yöneten merkezi bileşendir. Kaynakları denetler ve durum değişikliklerini uygular.
9. metrics-server
  • Namespace: kube-system
  • Açıklama: Kubernetes cluster için temel kaynak ölçümlerini toplar ve sağlar. CPU ve bellek kullanımı gibi metriklerin izlenmesine olanak tanır.
10. calico/flannel
  • Namespace: kube-system veya özel namespace (genellikle CNI bileşenleri için özel bir namespace oluşturulabilir)
  • Açıklama: Kubernetes ağ yöneticisi olarak görev yapar. Pod'lar arasındaki ağ trafiğini yönlendirir ve güvenliğini sağlar.
Cloud Tabanlı Kubernetes Ortamı
1. kube-apiserver
  • Namespace: kube-system
  • Açıklama: Kubernetes API sunucusudur ve tüm API isteklerini kabul eder. Cloud ortamlarında, genellikle yüksek erişilebilirlik sağlamak için birden fazla bölgede dağıtılır.
2. kube-scheduler
  • Namespace: kube-system
  • Açıklama: Pod'ların hangi nodelerde çalışacağını belirler. Cloud kaynakları ile etkileşime geçer ve kaynakların verimli kullanımını sağlar.
3. kube-controller-manager
  • Namespace: kube-system
  • Açıklama: Cloud ortamlarında dinamik olarak ölçeklenebilir kontrol döngülerini yönetir. Bu, kaynakların otomatik olarak artırılması veya azaltılması gibi işlevleri içerir.
4. etcd
  • Namespace: kube-system
  • Açıklama: Dağıtılmış bir anahtar-değer deposudur ve Kubernetes cluster nin tüm veri ve yapılandırmalarını saklar. Cloud sağlayıcıları, genellikle yüksek erişilebilir ve yedekli etcd hizmetleri sunar.
5. kube-proxy
  • Namespace: kube-system
  • Açıklama: Kubernetes hizmetlerinin ağ yönlendirmesini sağlar. Cloud ortamlarında, ağ trafiğinin coğrafi olarak dağılmış kaynaklarla entegrasyonunu kolaylaştırır.
6. coredns
  • Namespace: kube-system
  • Açıklama: Kubernetes cluster içinde DNS hizmetlerini sağlar. Cloud ortamlarında, bölgesel DNS hizmetleriyle entegrasyon sağlayabilir.
7. kubelet
  • Namespace: Her nodede çalışır.
  • Açıklama: Kubernetes node ajanıdır. Cloud nodelerinde pod'ların çalıştırılmasını ve yönetilmesini sağlar.
8. cloud-controller-manager
  • Namespace: kube-system
  • Açıklama: Cloud kaynaklarının (load balancers, storage, network routes) yönetimini sağlayan bileşendir. Cloud sağlayıcılarının sunduğu hizmetlerle entegre çalışır.
9. metrics-server
  • Namespace: kube-system
  • Açıklama: Kubernetes cluster için temel kaynak ölçümlerini toplar. Cloud ortamlarında daha geniş ölçekli metrik toplama ve izleme hizmetleri ile entegre çalışır.
10. calico/flannel
  • Namespace: kube-system veya özel namespace
  • Açıklama: Cloud ortamlarında da ağ yöneticisi olarak görev yapar. Pod'lar arasındaki ağ trafiğini yönlendirir ve güvenliğini sağlar. Cloud ağ altyapısıyla entegre çalışabilir.
11. cloud-specific-components

  • Namespace: Sağlayıcıya göre değişir (örneğin aws-cloud-provider, gce-cloud-provider, azure-cloud-provider)
  • Açıklama: Cloud ortamlarında, sağlayıcıya özgü bileşenler olabilir. Bu bileşenler, kaynakların otomatik olarak sağlanmasını ve yönetilmesini sağlar. Örneğin, AWS, GCP veya Azure gibi sağlayıcıların sunduğu yük dengeleyici veya depolama çözümlerine özel bileşenler.

Özet
Her iki ortamda da Kubernetes bileşenlerinin temel görevleri benzerdir, ancak bulut ortamları genellikle yüksek erişilebilirlik, otomatik ölçeklenebilirlik ve geniş metrik toplama ve izleme yetenekleri gibi ek avantajlar sunar. Bileşenlerin namespace bilgisi çoğunlukla kube-system ile sınırlıdır, ancak bazı özel ağ ve yönetim bileşenleri farklı namespace lerde bulunabilir.