Giriş:
Malum Magnum ile OpenStack üzerinde kubernetes kümesi kaldırmak çok kolay. Sağladığı hız ve ölçekleme özellikleri gayet güzel:
- Master ölçekleme
- Worker ölçekleme / Worker otomatik ölçekleme (verdiğiniz sayıya kadar artış/artabilme)
- Öziyileşme(autohealing)
Bu ortamda bir küme ayağa kaldırdığınızda, podlarınızda kullanacağınız depolama ihtiyacı kubernetes içerisindeki cinder-csi-plugin (driver) sayesinde, üzerinde çalıştığı OpenStack kurulumunun cinder bileşeninden istenir ve onun tarafından sağlanır, yani podunuzun depolama alanı OpenStack tarafında bir volume olarak görünür.
Kubernetes version 1.36.2 için 1 Master 1 Worker düğümünden oluşan yeni ve sağlıklı kümemize bir bakalım.
(client) erdem@virtbase:~$ openstack --os-cloud=kolla-admin coe cluster list
+--------------------------------------+-------+---------+------------+--------------+-----------------+---------------+
| uuid | name | keypair | node_count | master_count | status | health_status |
+--------------------------------------+-------+---------+------------+--------------+-----------------+---------------+
| 63bf139b-4269-43ab-987a-cb3f09d46586 | k1362 | erdem | 1 | 1 | CREATE_COMPLETE | HEALTHY |
+--------------------------------------+-------+---------+------------+--------------+-----------------+---------------+
(client) erdem@virtbase:~$ openstack --os-cloud=kolla-admin coe cluster show 63bf139b-4269-43ab-987a-cb3f09d46586
+----------------------+--------------------------------------------------------------------------------------------------+
| Field | Value |
+----------------------+--------------------------------------------------------------------------------------------------+
| status | CREATE_COMPLETE |
| health_status | HEALTHY |
| cluster_template_id | 41ab5ef1-fc1c-4dca-9743-81b782c65296 |
| node_addresses | [] |
| uuid | 63bf139b-4269-43ab-987a-cb3f09d46586 |
| stack_id | kube-w2dkt |
| status_reason | None |
| created_at | 2026-07-20T20:49:59+00:00 |
| updated_at | 2026-07-20T20:55:33+00:00 |
| coe_version | v1.36.2 |
| labels | {'kube_tag': 'v1.36.2', 'availability_zone': 'nova', 'auto_scaling_enabled': 'False', |
| | 'auto_healing_enabled': 'False', 'master_lb_floating_ip_enabled': 'True'} |
| labels_overridden | {} |
| labels_skipped | {} |
| labels_added | {'availability_zone': 'nova', 'auto_scaling_enabled': 'False', 'auto_healing_enabled': 'False', |
| | 'master_lb_floating_ip_enabled': 'True'} |
| fixed_network | cd821f9f-fd5c-463c-bc4a-e6cda74d58e0 |
| fixed_subnet | 77eb74cd-b017-415c-9f1d-cbe2a59b4423 |
| floating_ip_enabled | True |
| faults | |
| keypair | erdem |
| api_address | https://192.168.1.81:6443 |
| master_addresses | [] |
| master_lb_enabled | True |
| create_timeout | 60 |
| node_count | 1 |
| discovery_url | |
| docker_volume_size | None |
| master_count | 1 |
| container_version | None |
| name | k1362 |
| master_flavor_id | 4cpu8ram |
| flavor_id | 4cpu8ram |
| health_status_reason | {'kube-w2dkt-5crpz-kbw2m.Ready': 'True', 'kube-w2dkt-default-worker-j2dpl-dltqw-w6v98.Ready': |
| | 'True', 'api': 'ok'} |
| project_id | 5efd985b9a2042cf98d60b0ca6fa55a3 |
+----------------------+--------------------------------------------------------------------------------------------------+kube-w2dkt-5crpz-kbw2m master düğümü ve kube-w2dkt-default-worker-j2dpl-dltqw-w6v98 hazır. Aşağıdaki şekilde bir storage class oluşturalım ve 5GB bir storage oluşturmaya çalışalım,busybox kullansın mesela, dosya adı da test.yaml olsun.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: csi-cinder-default
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: cinder.csi.openstack.org
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: cinder-pvc-demo
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: v1
kind: Pod
metadata:
name: cinder-pod-demo
spec:
containers:
- name: busybox
image: busybox:latest
command: [ "sleep", "3600" ]
volumeMounts:
- mountPath: /data
name: my-cinder-volume
volumes:
- name: my-cinder-volume
persistentVolumeClaim:
claimName: cinder-pvc-demokubectl apply -f test.yamlŞimdi bunun durumunu OpenStack tarafında kontrol edelim.
(client) erdem@virtbase:~$ openstack --os-cloud=kolla-admin volume list
+----------------------------------+----------------------------------+--------+------+-----------------------------------+
| ID | Name | Status | Size | Attached to |
+----------------------------------+----------------------------------+--------+------+-----------------------------------+
| 390c3236-9f59-4696-9f41- | pvc-c48ab519-1f8a-4a64-9baf- | in-use | 5 | Attached to kube-w2dkt-default- |
| f1d6ba2cf517 | 40e8afecec14 | | | worker-j2dpl-dltqw-w6v98 on |
...
+----------------------------------+----------------------------------+--------+------+-----------------------------------+Herşey başarılı.
Sorun:
Peki herşey başarılı ise sorun nedir? Aslında yukarıda sorunsuz çalıştığı durumu gördünüz. Sorun ise temelde aşağıdaki gibi görünüyor.
erdem@EWUL13:~/.kube/test$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-kube-controllers-6b4b6457d5-6dc98 1/1 Running 0 6m59s
kube-system calico-node-858qg 1/1 Running 0 6m4s
kube-system calico-node-h6l94 1/1 Running 0 6m59s
kube-system coredns-7d764666f9-m9htf 1/1 Running 0 7m48s
kube-system coredns-7d764666f9-v4kgm 1/1 Running 0 7m48s
kube-system etcd-kube-d9dxm-g4zsz-jzdtt 1/1 Running 0 8m48s
kube-system k8s-keystone-auth-2hk9q 1/1 Running 0 6m22s
kube-system kube-apiserver-kube-d9dxm-g4zsz-jzdtt 1/1 Running 0 8m7s
kube-system kube-controller-manager-kube-d9dxm-g4zsz-jzdtt 1/1 Running 1 (8m46s ago) 8m48s
kube-system kube-proxy-79mds 1/1 Running 0 6m4s
kube-system kube-proxy-vf7jz 1/1 Running 0 7m48s
kube-system kube-scheduler-kube-d9dxm-g4zsz-jzdtt 1/1 Running 1 (8m35s ago) 8m48s
kube-system openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh 1/6 CrashLoopBackOff 26 (22s ago) 7m
kube-system openstack-cinder-csi-nodeplugin-6hxpk 3/3 Running 0 6m4s
kube-system openstack-cinder-csi-nodeplugin-cd2kj 3/3 Running 0 7m
kube-system openstack-cloud-controller-manager-qt8rn 1/1 Running 0 6m35sYukarıda da gözlemlenebildiği gibi kube-system içerisindeki openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh bir şekilde çalışamıyor.
Peki describe dediğimizde event olarak ne göreceğiz
erdem@EWUL13:~/.kube/test$ kubectl -n kube-system describe pod openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh
...
Normal Started 7m2s (x2 over 7m5s) kubelet spec.containers{cinder-csi-plugin}: Container started
Warning BackOff 6m18s (x2 over 6m23s) kubelet spec.containers{csi-attacher}: Back-off restarting failed container csi-attacher in pod openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh_kube-system(1e2a5234-543c-45d2-ac28-287b24d782f0)
Warning BackOff 6m12s (x3 over 6m18s) kubelet spec.containers{csi-provisioner}: Back-off restarting failed container csi-provisioner in pod openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh_kube-system(1e2a5234-543c-45d2-ac28-287b24d782f0)
Warning BackOff 6m8s (x3 over 6m13s) kubelet spec.containers{csi-snapshotter}: Back-off restarting failed container csi-snapshotter in pod openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh_kube-system(1e2a5234-543c-45d2-ac28-287b24d782f0)
Normal Pulled 2m10s (x5 over 6m54s) kubelet spec.containers{csi-attacher}: Container image "registry.k8s.io/sig-storage/csi-attacher:v4.7.0" already present on machine and can be accessed by the pod
Warning BackOff 114s (x56 over 7m1s) kubelet spec.containers{cinder-csi-plugin}: Back-off restarting failed container cinder-csi-plugin in pod openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh_kube-system(1e2a5234-543c-45d2-ac28-287b24d782f0)Buradan birşey anlaşılmadı, logda ne var acaba.
erdem@EWUL13:~/.kube/test$ kubectl -n kube-system logs openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh -c cinder-csi-plugin
2026/07/18 22:33:21 Running command:
Command env: (log-file=, also-stdout=false, redirect-stderr=true)
Run from directory:
Executable path: /bin/cinder-csi-plugin
Args (comma-delimited): /bin/cinder-csi-plugin,-v=2,--endpoint=unix://csi/csi.sock,--cloud-config=/etc/kubernetes/cloud.conf,--cluster=e323bad7-a6ba-4e98-93ec-431197562841,--provide-node-service=false
2026/07/18 22:33:21 Now listening for interrupts
I0718 22:33:21.917078 12 driver.go:101] Driver: cinder.csi.openstack.org
I0718 22:33:21.917121 12 driver.go:102] Driver version: [email protected]
I0718 22:33:21.917127 12 driver.go:103] CSI Spec version: 1.8.0
I0718 22:33:21.917132 12 driver.go:104] Topology awareness: bool
...
I0718 22:33:21.919214 12 driver.go:165] Enabling node service capability: STAGE_UNSTAGE_VOLUME
I0718 22:33:21.919219 12 driver.go:165] Enabling node service capability: EXPAND_VOLUME
I0718 22:33:21.919223 12 driver.go:165] Enabling node service capability: GET_VOLUME_STATS
I0718 22:33:21.919333 12 openstack.go:168] InitOpenStackProvider configFiles: [/etc/kubernetes/cloud.conf]
I0718 22:33:21.919731 12 openstack.go:103] Global: ""
I0718 22:33:21.919760 12 openstack.go:106] Block storage opts: {0 false false false}
W0718 22:33:22.202321 12 main.go:127] Failed to GetOpenStackProvider : No suitable endpoint could be found in the service catalog.Failed to GetOpenStackProvider : No suitable endpoint could be found in the service catalog. Suçluyu bulduk, açıkça diyor ki "depolama alanı almak için gerekli endpointi katalogda bulamıyorum". İyi de cinder yüklü, çalışıyor. VMlerimiz gerekli depolama alanını alabiliyor. Kubernetes kümesine ne oluyor da alamıyor. Endpointlere bi bakalım.
(client) erdem@virtbase:~/vms/isos$ openstack --os-cloud=kolla-admin endpoint list
+------------------------+--------+--------------+-----------------+---------+-----------+-------------------------+
| ID | Region | Service Name | Service Type | Enabled | Interface | URL |
+------------------------+--------+--------------+-----------------+---------+-----------+-------------------------+
...
| 42d78b8108db49c08f4b6a | Test1 | cinder | block-storage | True | public | http://192.168.1.25:877 |
| 3fa87a4949 | | | | | | 6/v3 |
| 4a6b57cdf4ec4b5f8f19a6 | Test1 | cinder | block-storage | True | internal | http://10.10.22.25:8776 |
...
+------------------------+--------+--------------+-----------------+---------+-----------+-------------------------+Cinder mevcut, sorun yok, fakat service-type neden block-storage. Neden volume veya volumev3 olarak kayıtlı değil. Storage tarafında NFS kullandığımız yani Ceph kullanmadığımız için deployment zamanında tip farklı mı oluşmuş, ya da OpenStack Gazpacho versiyonunda tipler mı değişmiş. Yine de sorun olmaması lazım, biraz google... cinder csi plugin... Kod Burada ve arka tarafta "github.com/gophercloud/gophercloud/v2/openstack/blockstorage/v3/volumes" şeklinde bir kütüphane kullanıyor...
O zaman biraz daha google... gophercloud issues... Eski bir issue var, merge de almış, kapanmış... Daha Yeni 34. satırda görüyoruz ki 2025 Mart tarihli commit ile mevcut tipler aşağıdakiler.
- block-store
- volume
- volumev2
- volumev3
Bizim tip block-store değil block-storage. Peki bunlar değişmiş olabilir mi bu kadar zaman da bakalım... gophercloud v2... Evet degişmiş. Burada 405. ile 420. satır arasına bakarsak desteklenen 3 tip var.
- v1 volume
- v2 block-storage
- v3 block-storage
Yani bizim tip bu durumada uyuyor. O zaman neden doğru endpointe gidemiyoruz? Peki bizim cinder-csi-plugin versionumuz ne idi?
erdem@EWUL13:~/.kube/test/pods$ kubectl describe pods -n kube-system openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh | grep -i cinder-csi-plugin
cinder-csi-plugin:
Image: registry.k8s.io/provider-os/cinder-csi-plugin:v1.32.0
Image ID: registry.k8s.io/provider-os/cinder-csi-plugin@sha256:8dbc1d5c42c143d26ba7fea5ca36a38ab512983b7df16329b486421615381f96
/bin/cinder-csi-plugincinder-csi-plugin v1.32.0 üzerinden çok zaman geçmiş şuan versiyon 1.36.0. O zaman bizim cinder-csi-plugin hangi gophercloud versiyonu ile derlenmiş...
openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh podu içerisinde bulunan cinder-csi-plugin konteyneri bash sh vb şeyler içermiyor, o sebeple busybox ile debug modunda giriyoruz.
erdem@EWUL13:~/.kube/test/pods$ kubectl -n kube-system debug -it openstack-cinder-csi-controllerplugin-57466c4589-6xkcs --image=busybox --target=cinder-csi-plugin
Targeting container "cinder-csi-plugin". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-qzk85.
All commands and output from this session will be recorded in container logs, including credentials and sensitive information passed through the command prompt.
If you don't see a command prompt, try pressing enter.
/ #Şuan busybox içerisindeyiz. Aradığımız konteyner büyük ihtimalle /proc/1 in altında. Hatta dosya sistemi de /proc/1/root altında olması lazım. Buraya gittiğimizde cinder-csi-plugin konteynerinin / alanına gideceğiz, bin altına bi bakalım.
/ # cd /proc/1/root/
/proc/1/root # ls bin/
btrfs btrfs-find-root btrfs-map-logical btrfsck cinder-csi-plugin dmesg mount umount
btrfs-convert btrfs-image btrfs-select-super btrfstune csi-deps-check.sh findmnt udevadmcinder-csi-plugin koşulabilir dosyası burada, şimdi go komutlarıda nedendir anlamadığım bir şekilde çalışmadığından dolayı (konteyner içerisinde go yok ama go runner var), strings komutu ile cinder-csi-plugin koşulabilir dosyası içerisinde gophercloud ve openstack ile ilgili şeyleri arayalım.
/proc/1/root # cd bin/
/proc/1/root/bin # strings cinder-csi-plugin | grep -i "gophercloud" | grep -i openstack
...
github.com/gophercloud/gophercloud/v2/openstack/compute/v2/volumeattach.VolumeAttachmentResult.Extract
...
github.com/gophercloud/gophercloud/[email protected]/openstack/blockstorage/v3/volumes/urls.go
github.com/gophercloud/gophercloud/[email protected]/openstack/blockstorage/v3/volumes/results.go
github.com/gophercloud/gophercloud/[email protected]/openstack/identity/v2/tokens/requests.go
...Onlarca satır arasında yukarıdaki gibi bir kısım var, artık anlıyoruz ki bizim cinder-csi-plugin 1.32.0 versiyonumuz gophercloud 2.5.0 kullanılarak derlenmiş. Peki gophercloud 2.5.0 versiyonundaki tipler nedir? Hemen bakalım github üzerinden. Burada 398. ve 410. satırlar arasındaki görüyoruz ki sadece tipler aşağıkidaler:
- volume
- volumev2
- volumev3
Buraya kadar geldik. Artık eksik olan ne biliyoruz. Artık ana soru şuan "Biz bu tip endpointi oluşturursak ne olur?". Mevcut servisimizi bozmadan ve karıştırmadan deneyelim. Hem cinderv3 isimli tipi volumev3 olan bir servis oluşturalım ve hem de volumev3 endpointleri.
(client) erdem@virtbase:~$ openstack --os-cloud=kolla-admin service create --name cinderv3 --description "Cinder Volume Service V3" volumev3
(client) erdem@virtbase:~$ openstack --os-cloud=kolla-admin endpoint create --region Test1 volumev3 public http://192.168.1.25:8776/v3
(client) erdem@virtbase:~$ openstack --os-cloud=kolla-admin endpoint create --region Test1 volumev3 internal http://10.10.22.25:8776/v3
(client) erdem@virtbase:~$ openstack --os-cloud=kolla-admin endpoint list
+----------------------------------+--------+--------------+-----------------+---------+-----------+-------------------------------------------+
| ID | Region | Service Name | Service Type | Enabled | Interface | URL |
+----------------------------------+--------+--------------+-----------------+---------+-----------+-------------------------------------------+
...
| 42d78b8108db49c08f4b6a3fa87a4949 | Test1 | cinder | block-storage | True | public | http://192.168.1.25:8776/v3 |
| 4a6b57cdf4ec4b5f8f19a6ad85efe750 | Test1 | cinder | block-storage | True | internal | http://10.10.22.25:8776/v3 |
| 90d6c1de3b8b4bbfa4a2f440226e17f1 | Test1 | cinderv3 | volumev3 | True | internal | http://10.10.22.25:8776/v3 |
| 9ff94b75a93b4720a5a9c330fb64a589 | Test1 | cinderv3 | volumev3 | True | public | http://192.168.1.25:8776/v3 |
...
+----------------------------------+--------+--------------+-----------------+---------+-----------+-------------------------------------------+Bir sorun daha böylece çözüldü. Bir rollout restart ile openstack-cinder-csi-controllerplugin-5d966b8cd6-phcvh gider yenisi tertemiz yerine oturur.
Sonuç:
Günümüz bilgi işlem dünyasında kurulumları, yönetimleri, konfigürasyonları ve örneğimizde de olduğu gibi kubernetes kümeleri oluşturmayı otomatize ediyoruz. Otomatize ettiğimiz her bir parça, diğerlerinden bağımsız, farklı ve birçok zaman içeriğini tam anlamıyla bilmediğimiz başka bağımlılıkları da yanında getiriyor. Bütün bu katmanlar bizden soyutlanmış bir şekilde işliyorlar ve sorunsuz işledikleri sürece hiçbirşeyi fark bile etmiyoruz. Kullandığımız 1.32.0 versiyonunun üzerinden 17 ay geçmiş, sorunsuz çalışıyor olsa umrumuzda dahi olmayacak ve hatta 1.32.0'a bile gerçekten ihtiyacımız var mı bilmiyoruz. Sorunun kökten çözümü için burada da versiyonu 1.36.0'a götürmeyi denesek, acaba başka hangi bağımlılıklar hata verecek ve daha ne kadar derine dalıp birşeyleri değiştirmemiz gerekecek.
Neyse biz karmaşalarımızı otomatize etmeye devam edelim. Bu arada "If you automate a mess, you get an automated mess" temalı hızlıca okunabilir bir referans bırakıyorum aşağıya.
Referanslar:
Teşekkür:
Ana fotoğraf: Brian Kelly orijinaline Unsplash üzerinden ulaşabilirsiniz.