Kubernetes Basics
Kubernetes Temelleri
Bu sayfanın orijinal yazarı Jorge (orijinal gönderisini buradan** okuyun)**
Mimarlık ve Temeller
Kubernetes ne yapar?
Bir konteyneri/konteynerleri bir konteyner motorunda çalıştırmaya izin verir.
Konteyner görevlerini verimli bir şekilde planlar.
Konteynerleri canlı tutar.
Konteyner iletişimine izin verir.
Dağıtım tekniklerine izin verir.
Bilgi hacimlerini yönetir.
Mimarlık
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-68.jpg&width=768&dpr=4&quality=100&sign=4902871c&sv=1)
Düğüm (Node): Pod veya pod'larla birlikte çalışan işletim sistemi.
Pod: Bir konteynerin veya birden fazla konteynerin etrafını saran bir kapsayıcıdır. Bir pod yalnızca bir uygulama içermelidir (bu nedenle genellikle bir pod yalnızca 1 konteyner çalıştırır). Pod, Kubernetes'in çalışan konteyner teknolojisini soyutlama şeklidir.
Servis (Service): Her pod'un düğümün iç ağ aralığından 1 dahili IP adresi vardır. Bununla birlikte, bir servis aracılığıyla da dışa açılabilir. Servisin de bir IP adresi vardır ve amacı pod'lar arasındaki iletişimi sürdürmektir, böylece biri ölürse yeni bir yerine geçen pod (farklı bir dahili IP ile) servisin aynı IP'sinde erişilebilir hale gelir. İçsel veya harici olarak yapılandırılabilir. Servis, 2 pod'un aynı servise bağlandığında bir yük dengeleyici olarak da hareket eder. Bir servis oluşturulduğunda, her servisin uç noktalarını çalıştırarak bulabilirsiniz
kubectl get endpoints
Kubelet: Ana düğem ajanıdır. Düğüm ve kubectl arasında iletişim kurar ve yalnızca pod'ları (API sunucusu aracılığıyla) çalıştırabilir. Kubelet, Kubernetes tarafından oluşturulmayan konteynerleri yönetmez.
Kube-proxy: apisunucusu ve düğem arasındaki iletişim (servisler) ile ilgilenen hizmettir. Temel olarak düğemler için bir IPtables'tır. Deneyimli kullanıcılar başka satıcılardan kube-proxy'ler kurabilirler.
Sidecar konteyner (Sidecar container): Sidecar konteynerler, ana konteynerle birlikte pod'da çalışması gereken konteynerlerdir. Bu yan konteyner modeli, mevcut konteynerlerin işlevselliğini genişletir ve geliştirirken onları değiştirmez. Günümüzde, uygulamanın herhangi bir yerde çalışabilmesi için tüm bağımlılıkları sarmak için konteyner teknolojisini kullandığımızı biliyoruz. Bir konteyner yalnızca bir şey yapar ve bu işi çok iyi yapar.
Ana işlem (Master process):
API Sunucusu (Api Server): Kullanıcıların ve pod'ların ana işlemle iletişim kurmak için kullandığı yoldur. Yalnızca kimlik doğrulaması yapılmış isteklere izin verilmelidir.
Planlayıcı (Scheduler): Planlama, Pod'ların Kubelet tarafından çalıştırılabilmesi için Pod'ların Düğemlere eşleştirildiğinden emin olmayı ifade eder. Yeni bir pod başlatmak için hangi düğümün daha fazla kullanılabilir kaynağa sahip olduğuna karar vermek için yeterli zekaya sahiptir. Planlayıcı yeni pod'ları başlatmaz, yalnızca düğem içinde çalışan Kubelet işlemiyle iletişim kurar ve yeni pod'ı başlatır.
Kube Denetleyici Yöneticisi (Kube Controller Manager): Replica setler veya dağıtımlar gibi kaynakları kontrol eder ve örneğin doğru sayıda pod veya düğem çalıştığını kontrol etmek için kontrol eder. Bir pod eksikse, yeni bir pod başlatmak için planlayıcıyla iletişim kurar. API'ya replikasyon, tokenlar ve hesap hizmetleri kontrol eder.
etcd: Veri depolama, kalıcı, tutarlı ve dağıtılmıştır. Kubernetes'in veritabanıdır ve küme durumunun tamamını (her değişiklik burada kaydedilir) tutan anahtar-değer depolama alanıdır. Planlayıcı veya Denetleyici yöneticisi gibi bileşenler, hangi değişikliklerin meydana geldiğini bilmek için bu verilere bağımlıdır (düğemlerin kullanılabilir kaynakları, çalışan pod'ların sayısı...).
Bulut denetleyici yöneticisi (Cloud controller manager): Akış kontrolleri ve uygulamalar için özel denetleyicidir, örneğin AWS veya OpenStack'ta kümeniz varsa.
Bir düğemde (birkaç pod çalıştıran birkaç düğem) birden fazla ana işlem olabileceği gibi, Api sunucusuna erişimleri yük dengelemeli ve etcd'leri senkronize edilebilir.
Hacimler (Volumes):
Bir pod, kaybolması durumunda kaybolmaması gereken veri oluşturduğunda, veri bir fiziksel hacme depolanmalıdır. Kubernetes, veriyi korumak için bir pod'a bir hacim eklemeye izin verir. Hacim yerel makinede veya uzak bir depolama alanında olabilir. Farklı fiziksel düğemlerde pod'lar çalıştırıyorsanız, tüm pod'ların buna erişebilmesi için uzak bir depolama alanı kullanmalısınız.
Diğer yapılandırmalar:
ConfigMap: Servislere erişmek için URL'leri yapılandırabilirsiniz. Pod, diğer servislerle (pod'larla) iletişim kurmak için buradan veri alır. Bununla birlikte, bu kimlik bilgilerini kaydetmek için önerilen yer değildir!
Secret: Şifreler, API anahtarları gibi gizli verileri saklamak için kullanılan yerdir. Pod, gerekli kimlik bilgilerini kullanmak için bu verilere erişebilir.
Dağıtımlar (Deployments): Kubernetes tarafından çalıştırılacak bileşenlerin belirtildiği yerdir. Bir kullanıcı genellikle doğrudan pod'larla çalışmaz, pod'lar ReplicaSet'lerde (çoğaltılan aynı pod'ların sayısı) soyutlanır ve dağıtımlar aracılığıyla çalıştırılır. Dağıtımlar genellikle durumsuz (stateless) uygulamalar içindir. Bir dağıtım için minimum yapılandırma adı ve çalıştırılacak görüntüdür.
StatefulSet: Bu bileşen, verilere erişmesi gereken veritabanları gibi uygulamalar için özel olarak tasarlan
PKI altyapısı - Sertifika Otoritesi CA:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-66.jpg&width=768&dpr=4&quality=100&sign=ddfcd3be&sv=1)
CA, küme içindeki tüm sertifikalar için güvenilir köktür.
Bileşenlerin birbirini doğrulamasına izin verir.
Tüm küme sertifikaları CA tarafından imzalanır.
ETCd'nin kendi sertifikası vardır.
türleri:
apiserver sertifikası.
kubelet sertifikası.
scheduler sertifikası.
Temel Eylemler
Minikube
Minikube, bir tüm kubernetes ortamı dağıtmadan kubernetes üzerinde bazı hızlı testler yapmak için kullanılabilir. Master ve node işlemlerini tek bir makinede çalıştıracaktır. Minikube, node'u çalıştırmak için virtualbox kullanacaktır. Burada nasıl kurulacağını görebilirsiniz.
Kubectl Temelleri
Kubectl
, kubernetes kümelelerinde kullanılan komut satırı aracıdır. Kubernetes'te işlemler gerçekleştirmek veya veri istemek için ana işlemciye ait Api sunucusuyla iletişim kurar.
Minikube Kontrol Paneli
Kontrol paneli, minikube'nin çalıştırdığı şeyleri daha kolay görebilmenizi sağlar, erişmek için URL'yi aşağıda bulabilirsiniz:
YAML yapılandırma dosyaları örnekleri
Her yapılandırma dosyası 3 bölümden oluşur: metadata, specification (başlatılması gereken şey), status (istenen durum). Dağıtım yapılandırma dosyasının özellik bölümünde, çalıştırılacak görüntüyü tanımlayan yeni bir yapılandırma yapısıyla bir şablon bulunabilir:
Aynı yapılandırma dosyasında bildirilen Dağıtım + Hizmet örneği (buradan alınmıştır buradan)
Bir hizmet genellikle bir dağıtımla ilişkilidir, bu nedenle her ikisi de aynı yapılandırma dosyasında bildirilebilir (bu yapılandırmada bildirilen hizmet yalnızca dahili olarak erişilebilir):
Dış servis yapılandırmasının örneği
Bu servis harici olarak erişilebilir olacak (nodePort
ve type: LoadBalancer
özniteliklerini kontrol edin):
Bu test için kullanışlıdır, ancak üretim için yalnızca dahili hizmetlere ve uygulamayı açığa çıkarmak için bir Ingress'e sahip olmanız gerekmektedir.
Ingress yapılandırma dosyası örneği
Bu, uygulamayı http://dashboard.com
adresinde açığa çıkaracaktır.
Gizli yapılandırma dosyası örneği
Şifrelerin B64 ile kodlandığına dikkat edin (bu güvenli değildir!).
ConfigMap Örneği
ConfigMap, pod'ların diğer hizmetlere nasıl erişeceğini ve bulacağını bilmesi için verilen yapılandırmadır. Bu durumda, her bir pod, mongodb-service
adının iletişim kurabilecekleri bir pod'un adresi olduğunu bilecektir (bu pod bir mongodb çalıştıracaktır):
Ardından, bir dağıtım yapılandırması içinde bu adres aşağıdaki şekilde belirtilebilir, böylece pod'un env'sine yüklenir:
Depolama yapılandırması örneği
Depolama yapılandırması yaml dosyalarının farklı örneklerini https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes adresinde bulabilirsiniz. Dikkat: Volumeler namespace'lerin içinde değildir
Namespace'ler
Kubernetes, aynı fiziksel küme tarafından desteklenen çoklu sanal kümeleri destekler. Bu sanal kümeler namespace olarak adlandırılır. Bunlar, birçok kullanıcının birden çok takıma veya projeye yayıldığı ortamlarda kullanılmak üzere tasarlanmıştır. Birkaç ila onlarca kullanıcının bulunduğu kümelere sahipseniz, namespace oluşturmanıza veya düşünmenize gerek yoktur. Sadece kubernetes'te dağıtılan her uygulama parçasının daha iyi bir kontrol ve düzenlemesine sahip olmak için namespace'leri kullanmaya başlamalısınız.
Namespace'ler, isimler için bir kapsam sağlar. Kaynakların isimleri bir namespace içinde benzersiz olmalıdır, ancak namespace'ler arasında benzersiz olması gerekmez. Namespace'ler birbirinin içine yerleştirilemez ve her Kubernetes kaynağı yalnızca bir namespace içinde olabilir.
Minikube kullanıyorsanız varsayılan olarak 4 namespace bulunur:
kube-system: Kullanıcılar tarafından kullanılmak için değil ve dokunmamanız gereken bir alan. Bu alan, master ve kubectl işlemleri için kullanılır.
kube-public: Genel olarak erişilebilir verileri içerir. Küme bilgilerini içeren bir configmap içerir.
kube-node-lease: Bir düğümün kullanılabilirliğini belirler.
default: Kullanıcının kaynak oluşturmak için kullanacağı ad alanı.
Unutmayın ki çoğu Kubernetes kaynağı (örneğin pod'lar, servisler, replikasyon denetleyicileri ve diğerleri) bir namespace içindedir. Bununla birlikte, namespace kaynakları ve düşük seviye kaynaklar gibi diğer kaynaklar, örneğin düğümler ve kalıcı birimler bir namespace içinde değildir. Hangi Kubernetes kaynaklarının bir namespace içinde olduğunu ve olmadığını görmek için:
Tüm sonraki kubectl komutları için bu bağlamda ad alanını kaydedebilirsiniz.
Helm
Helm, Kubernetes için bir paket yöneticisidir. YAML dosyalarını paketleyip, bunları genel ve özel depolarda dağıtmaya olanak sağlar. Bu paketlere Helm Charts denir.
Helm ayrıca değişkenlerle yapılandırma dosyaları oluşturmaya izin veren bir şablon motorudur:
Kubernetes sırları
Bir Secret, bir şifre, bir belirteç veya bir anahtar gibi hassas verileri içeren bir nesnedir. Bu tür bilgiler aksi takdirde bir Pod tanımında veya bir görüntüde olabilir. Kullanıcılar Secrets oluşturabilir ve sistem de Secrets oluşturur. Bir Secret nesnesinin adı geçerli bir DNS alt alan adı olmalıdır. Resmi belgelere buradan ulaşabilirsiniz.
Secrets şunlar olabilir:
API, SSH Anahtarları.
OAuth belirteçleri.
Kimlik bilgileri, Parolalar (düz metin veya b64 + şifreleme).
Bilgi veya yorumlar.
Veritabanı bağlantı kodu, dizeleri... .
Kubernetes'te farklı türde sırlar vardır
Dahili Tür | Kullanım |
---|---|
Opaque | key-value çifti (Varsayılan) |
kubernetes.io/service-account-token | hizmet hesabı belirteci |
kubernetes.io/dockercfg | serileştirilmiş ~/.dockercfg dosyası |
kubernetes.io/dockerconfigjson | serileştirilmiş ~/.docker/config.json dosyası |
kubernetes.io/basic-auth | temel kimlik doğrulama için kimlik bilgileri |
kubernetes.io/ssh-auth | SSH kimlik doğrulama için kimlik bilgileri |
kubernetes.io/tls | bir TLS istemci veya sunucu için veri |
bootstrap.kubernetes.io/token | başlatma belirteci verisi |
Opaque türü varsayılan olanıdır, kullanıcılar tarafından tanımlanan tipik bir key-value çiftidir.
Sırlar nasıl çalışır:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-164.jpg&width=768&dpr=4&quality=100&sign=407ce89f&sv=1)
Aşağıdaki yapılandırma dosyası, mysecret
adında username: YWRtaW4=
ve password: MWYyZDFlMmU2N2Rm
olmak üzere 2 key-value çiftine sahip bir secret tanımlar. Ayrıca, secretpod
adında bir pod tanımlar, bu pod mysecret
içinde tanımlanan username
ve password
'u çevre değişkenleri SECRET_USERNAME
ve SECRET_PASSWOR
olarak açığa çıkarır. Ayrıca, username
sırrını mysecret
içinde /etc/foo/my-group/my-username
yoluna 0640
izinleriyle mount eder.
etcd'teki Sırlar
etcd, tüm küme verileri için Kubernetes'in destekleyici depolama olarak kullanılan tutarlı ve yüksek erişilebilir bir anahtar-değer deposudur. Hadi etcd'de depolanan sırlara erişelim:
Sertifikaların, anahtarların ve URL'lerin FS'de nerede bulunduğunu göreceksiniz. Bunu aldıktan sonra etcd'ye bağlanabileceksiniz.
Bir kez iletişim kurmayı başardığınızda, sırlara erişebilirsiniz:
ETCD'ye şifreleme eklemek
Varsayılan olarak, tüm sırlar etcd içinde düz metin olarak depolanır, ancak bir şifreleme katmanı uygulamazsanız. Aşağıdaki örnek, https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ adresindeki belgeye dayanmaktadır.
Bundan sonra, oluşturulan yapılandırma dosyasının konumunu göstermek için kube-apiserver
üzerinde --encryption-provider-config
bayrağını ayarlamanız gerekmektedir. /etc/kubernetes/manifest/kube-apiserver.yaml
dosyasını düzenleyebilir ve aşağıdaki satırları ekleyebilirsiniz:
volumeMounts bölümünde aşağı kaydırın:
volumeMounts
içinde aşağı kaydırın ve hostPath
'e ulaşın:
Veri şifrelenmesinin doğrulanması
Veri, etcd'ye yazıldığında şifrelenir. kube-apiserver
'ınızı yeniden başlattıktan sonra, yeni oluşturulan veya güncellenen herhangi bir gizli bilginin depolandığında şifrelenmiş olması gerekmektedir. Kontrol etmek için etcdctl
komut satırı programını kullanarak gizli bilginizin içeriğini alabilirsiniz.
default
ad alanındasecret1
adında yeni bir gizli bilgi oluşturun:
Etcd'den bu gizli bilgiyi okumak için etcdctl komut satırını kullanın:
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
[...]
, etcd sunucusuna bağlanmak için ek argümanlar olmalıdır. 3. Depolanan gizli bilginin k8s:enc:aescbc:v1:
ile başladığını doğrulayın. Bu, aescbc
sağlayıcısının sonuç veriyi şifrelediğini gösterir. 4. API aracılığıyla alındığında gizli bilginin doğru bir şekilde çözümlendiğini doğrulayın:
mykey: bXlkYXRh
ile eşleşmelidir, mydata kodlanmıştır, gizli bilgiyi tamamen çözmek için bir gizli bilgiyi çözme bağlantısına bakın.
Gizli bilgiler yazılırken şifrelendiği için, bir gizli bilgide güncelleme yapmak, içeriğin şifrelenmesini sağlar:
Son ipuçları:
Sırları FS'de tutmamaya çalışın, onları başka yerlerden alın.
Sırlarınıza daha fazla koruma eklemek için https://www.vaultproject.io/'ya göz atın.
Referanslar
Last updated