Bu yazıda, Kubernetes Objects, Resources, Custom Resources ve aralarındaki farklar hakkında detaylı bilgi edineceksiniz.

Kubernetes öğrenirken, “Kubernetes Object”, “Kubernetes Resources” ve “Custom Resources” gibi terimlerle sıkça karşılaşacaksınız. Bu kavramlar, Kubernetes’in temel konseptleri olup, anlamak için kritik öneme sahiptir.

Gelin, gerçekten ne anlama geldiklerini birlikte anlayalım.

Kubernetes Objects Nedir?

Kubernetes’te, kullanıcı tarafından oluşturulan ve saklanan her şey “Object” olarak adlandırılır. Bu, namespaces, pods, deployments, DaemonSet, volumes veya secrets gibi çeşitli öğeleri içerebilir.

Kubernetes mimarisine baktığınızda, etcd bileşeni, cluster nesnelerinin kalıcı olarak saklanmasında önemli bir rol oynar. Oluşturduğunuz herhangi bir nesne, etcd’de depolanır.

etcd, tüm nesneleri /registry dizini altında saklar. Örneğin, default namespace içinde bulunan Nginx adlı bir podun detayları, /registry/pods/default/nginx dizininde aranarak elde edilebilir. Aşağıdaki görsel, farklı nesnelerin saklandığı registry yollarını göstermektedir.

kubernetes objects

Bu nesneleri oluşturmak için, istediğiniz durumu (desired state) YAML veya JSON kullanarak bir dosyada tanımlarsınız. Bu, Object Specification olarak adlandırılır.

Pod Object Specification örneği ve podun istenen durumunu nasıl tanımladığımızı aşağıda görebilirsiniz;

apiVersion: v1
kind: Pod
metadata:
  name: webserver-pod
spec:
  containers:
  - name: webserver
    image: nginx:latest
    ports:
    - containerPort: 80

Bir nesne oluşturduktan sonra, Kubernetes’ten bu nesne hakkında bilgi almak için Kubectl veya API çağrılarını API server’a iletip sorgulayabilirsiniz.

Aşağıdaki tablo, önemli native Kubernetes object türlerini kategorilere göre düzenlenmiş olarak göstermektedir.

KategoriKubernetes Nesneleri
Workload1. Pods
2. ReplicaSets,
3. Deployments,
4. StatefulSets
5. DaemonSets
6. Jobs
7. CronJobs
8. Horizontal Pod Autoscaler
9. Vertical Pod Autoscaler
Service & Networking1. Services
2. Ingress
3. IngressClasses
4. Network Policies
5. Endpoints
6. EndpointSlices
Storage1. PersistentVolumes
2. PersistentVolumeClaims
3. StorageClasses
Configuration & Management1. ConfigMaps
2. Namespaces
3. ResourceQuotas
4. LimitRanges
5. Pod Disruption Budgets (PDB)
6. Pod Priority and Preemption
Security1. Secrets
2. ServiceAccounts (sa)
3. Roles
4. RoleBindings
5. ClusterRoles
6. ClusterRoleBindings
Metadata1. Labels and Selectors
2. Annotations
3. Finalizers

Ortak Object Parametreleri

Kubernetes’te birçok object türü vardır, ancak her object için ortak olan bazı parametreler vardır.

Kubernetes objects tarafından paylaşılan ortak parametreler aşağıdaki gibidir:

ParametreAçıklama
apiVersionThe Kubernetes API version for the object.
– Alpha
– Beta
– Stable
kindThe type of object being defined
– Pod
– Deployment
– Service
– Configmap, etc.
metadatametadata, bir Kubernetes nesnesini benzersiz şekilde tanımlamak ve tanımlamak için kullanılır. İşte bir nesneye eklenebilecek bazı yaygın anahtar metadata’lar
– labels
– name
– namespace
– annotations
– finalizers, etc.
specBir Kubernetes nesne tanımının ‘spec’ bölümünde, oluşturmak istediğimiz nesnenin istenen durumunu ve özelliklerini belirtiriz.

Object UID

Her Kubernetes nesnesi, kendine özgü bir kimliğe sahiptir. Bu kimlik, Universally Unique Identifier (UUID) veya UID olarak adlandırılır.

Aynı isimle iki nesneye sahip olamazsınız. Yani, aynı adı taşıyan iki pod (örneğin, webserver) olamaz. Ancak, webserver adlı bir pod ve webserver adlı bir Deployment’a sahip olabilirsiniz.

Bu UID’yi, pod’u tanımlayarak bulabilirsiniz. Bu bilgi, metadata bölümünde yer alacaktır.

image 11

Eğer nesneniz için benzersiz olmayan bir tanımlayıcı istiyorsanız, labels ve annotations kullanabilirsiniz.

Kubernetes Resources Nedir?

Kubernetes’te, her şey API’ler aracılığıyla erişilir.

Farklı türde object’ler oluşturmak için (örneğin pods, namespaces, configmaps vb.), Kubernetes API sunucusu API endpoint’leri sağlar.

Bu nesneye özgü endpoint’ler, API resources veya resources olarak adlandırılır. Örneğin, bir pod oluşturmak için kullanılan API endpoint’i, Pod resource olarak adlandırılır.

Daha basit bir ifadeyle, bir resource, bir nesneye erişmek için kullanılan belirli bir API URL’sidir ve HTTP action’ları (GET, POST ve DELETE gibi) aracılığıyla erişilebilir.

Örneğin, /api/v1/pods resource, Pod object’lerinin bir listesini almak için kullanılabilir ve tek bir Pod object’i, /api/v1/namespaces/pods/ resource’dan elde edilebilir.

Kubernetes’teki bazı API resource endpoint’lerinin örnekleri:

  • /api/v1/namespaces: Bu API resource, cluster’daki tüm namespaces’in bir listesini alır.
  • /api/v1/pods: Bu API resource, cluster’daki tüm pods’ların bir listesini alır.
  • /api/v1/pods/{pod-name}: Bu API resource, belirli bir pod hakkında bilgi alır, burada {pod-name} pod’un adıdır.
  • /api/v1/namespaces/{namespace-name}/pods: Bu API resource, belirli bir namespace’deki tüm pods’ların bir listesini alır, burada {namespace-name} namespace’in adıdır.
  • /api/v1/namespaces/{namespace-name}/pods/{pod-name}: Bu API resource, belirli bir namespace’deki belirli bir pod hakkında bilgi alır.

Bu endpoint’ler, mevcut birçok API resource’dan sadece birkaç örnektir.

Kubectl kullanarak bir Kubernetes object oluşturduğunuzda, YAML specification’ı JSON formatına dönüştürülür ve Pod resource’a (Pod API endpoint) gönderilir.

Pod’lar, volumes ve benzeri diğer terimlerin genel olarak “resources” olarak adlandırıldığını, (API resources olarak değil) unutmamak önemlidir. Bu iki terimi karıştırmamak gerekir.

image 12

Ayrıca, Kubernetes RBAC (Role-Based Access Control) kullanırken, object kavramlarıyla karşılaşacaksınız.

Kubernetes Custom Resources Nedir?

Kubernetes, pods, deployments, secrets, configmaps ve daha fazlası gibi bir dizi native API resource ile birlikte gelir.

Örneğin, bir pod object deploy ettiğinizde, belirtilen container’ları içeren bir pod oluşturur.

Peki ya kendi API resource’unuzu oluşturmak isterseniz?

Diyelim ki “backup” adında bir resource’a ihtiyacınız var ve bu backup object deploy edildiğinde, etcd backup’ı yapıp S3’e yüklemelidir.

Şanslıyız ki, Kubernetes oldukça genişletilebilir ve kullanıcıların kendi resource’larını oluşturarak temel Kubernetes API’leri ile entegre etmelerine olanak tanır. Kubernetes’te belirli bir işlemi gerçekleştirmek için kendi custom API’nizi geliştirirseniz, buna custom resource diyebilirsiniz.

Not: Custom resource oluşturmak için, custom resource’u yöneten bir controller implement etmeniz gerekir.

İşte backup için bir custom object specification’ın nasıl görüneceğine dair bir örnek. Bu object’i deploy ettiğinizde, kullanıcı tarafından geliştirilen custom controller, backend’de istenen işlemi gerçekleştirir.

apiVersion: sezer.in/v1
kind: Backup
metadata:
  name: my-backup
spec:
  etcdEndpoint: http://etcd:2379
  s3Bucket: my-bucket
  s3Region: us-west-2

Kubernetes Manifests

Genellikle Kubernetes YAML dosyalarına manifest denir. Bu dosyalar, Deployment, Service, ConfigMap, Secret gibi bir veya daha fazla Kubernetes object’in specifications’ını içerir.

Aşağıdaki görselde, bir Pod ve Service object’in tanımlandığı bir Kubernetes manifest dosyası örneği gösterilmektedir. Bu manifest’i çalıştırdığınızda, hem pod hem de service object oluşturulacaktır.

image 13

Manifest dosyasındaki object sayısı için bir üst limit var mıdır?

Hayır, ancak varsayılan boyut limiti 1MB’dir. Yine de, manifest dosyalarını kullanmayı tercih ediyorsanız, bakım ve okunabilirliği kolaylaştırmak için dosya başına object sayısını yönetilebilir bir seviyede tutmanız önerilir.

Sonuç

Bu yazıda, Kubernetes object, resources, custom resources ve aralarındaki farkları inceledik. Kubernetes’i tam anlamıyla öğrenmek istiyorsanız, bu temel bilgiler çok önemlidir.

İlgilenirseniz Kustomize ile Kubernetes Manifestlerinizin Yönetimini Mükemmelleştirin – Kustomize 101 yazıma göz gezdirebilirsiniz.