Ev laboratuvar\u0131n\u0131zda Kubernetes projelerinizi g\u00fcvenli ve eri\u015filebilir k\u0131lmak ister misiniz? Bu rehber, Kubernetes DNS ve SSL sertifika y\u00f6netiminin inceliklerini s\u0131f\u0131rdan \u00f6\u011frenmenizi, uygulamal\u0131 \u00f6rneklerle kendi ortam\u0131n\u0131zda g\u00fcvenli ve istikrarl\u0131 bir altyap\u0131 olu\u015fturman\u0131z\u0131 sa\u011flayacak. \u0130\u00e7 a\u011f\u0131n\u0131zda sorunsuz hizmet ke\u015ffi ve d\u0131\u015f d\u00fcnyaya a\u00e7\u0131lan uygulamalar\u0131n\u0131z i\u00e7in otomatik SSL yap\u0131land\u0131rmas\u0131 ile projelerinizi bir \u00fcst seviyeye ta\u015f\u0131y\u0131n.<\/p>\n
Modern uygulama geli\u015ftirmenin ve da\u011f\u0131t\u0131m\u0131n\u0131n temel ta\u015flar\u0131ndan biri olan Kubernetes, esnekli\u011fi ve \u00f6l\u00e7eklenebilirli\u011fiyle ev laboratuvarlar\u0131 i\u00e7in de vazge\u00e7ilmez bir ara\u00e7 haline gelmi\u015ftir. Ancak, bu g\u00fc\u00e7l\u00fc platformun t\u00fcm potansiyelini kullanabilmek i\u00e7in a\u011f ve g\u00fcvenlik temellerini do\u011fru bir \u015fekilde anlamak ve yap\u0131land\u0131rmak hayati \u00f6neme sahiptir. \u00d6zellikle DNS (Domain Name System) ve SSL\/TLS (Secure Sockets Layer\/Transport Layer Security) sertifikalar\u0131, uygulamalar\u0131n\u0131z\u0131n hem kendi i\u00e7lerinde sorunsuz ileti\u015fim kurabilmesi hem de d\u0131\u015f d\u00fcnyaya g\u00fcvenli bir \u015fekilde sunulabilmesi i\u00e7in olmazsa olmazd\u0131r. Ev laboratuvar\u0131 ortam\u0131nda bile olsa, bu konularda yap\u0131lan do\u011fru yap\u0131land\u0131rmalar, geli\u015ftirme s\u00fcre\u00e7lerinizi h\u0131zland\u0131r\u0131r, hata ay\u0131klama s\u00fcresini azalt\u0131r ve en \u00f6nemlisi, uygulamalar\u0131n\u0131z\u0131n g\u00fcvenli\u011fini art\u0131r\u0131r.<\/p>\n
Peki, ev laboratuvar\u0131nda bu konular neden bu kadar kritik? D\u00fc\u015f\u00fcn\u00fcn ki bir mikro hizmet mimarisi kurdunuz. Her bir hizmetin birbiriyle konu\u015fmas\u0131 gerekiyor. Bu durumda, bir hizmetin di\u011ferini bulabilmesi i\u00e7in bir t\u00fcr “rehber”e ihtiyac\u0131n\u0131z var. \u0130\u015fte Kubernetes’in dahili DNS servisi (CoreDNS) bu rehber rol\u00fcn\u00fc \u00fcstlenerek hizmet ke\u015ffini otomatize eder. Uygulamalar\u0131n\u0131z\u0131n isimleriyle birbirlerini bulabilmesi, IP adreslerini ezberleme veya manuel konfig\u00fcrasyon yapma zorunlulu\u011funu ortadan kald\u0131r\u0131r. Bu, geli\u015ftiriciler i\u00e7in b\u00fcy\u00fck bir kolayl\u0131k sa\u011flarken, ayn\u0131 zamanda uygulaman\u0131n daha dinamik ve esnek olmas\u0131n\u0131 sa\u011flar. Bir hizmetin IP adresi de\u011fi\u015fse bile, di\u011fer hizmetler onu ismiyle bulmaya devam edebilir.<\/p>\n
\u00d6te yandan, d\u0131\u015f d\u00fcnyaya a\u00e7t\u0131\u011f\u0131n\u0131z web uygulamalar\u0131n\u0131z i\u00e7in g\u00fcvenlik, asla g\u00f6z ard\u0131 edilmemesi gereken bir konudur. Bir web uygulamas\u0131n\u0131n kullan\u0131c\u0131 verilerini g\u00fcvenli bir \u015fekilde iletmesi, taray\u0131c\u0131 ile sunucu aras\u0131ndaki ileti\u015fimin \u015fifrelenmesiyle m\u00fcmk\u00fcnd\u00fcr. \u0130\u015fte burada SSL\/TLS sertifikalar\u0131 devreye girer. Bir ev laboratuvar\u0131nda bile olsa, ki\u015fisel projelerinizi veya denemelerinizi yay\u0131nlarken, kullan\u0131c\u0131lar\u0131n taray\u0131c\u0131lar\u0131nda “g\u00fcvenli ba\u011flant\u0131” simgesini g\u00f6rmeleri, hem sizin projenize olan g\u00fcveni art\u0131r\u0131r hem de veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc sa\u011flar. Manuel sertifika olu\u015fturma ve y\u00f6netme s\u00fcre\u00e7leri zaman al\u0131c\u0131 ve hataya a\u00e7\u0131k olabilirken, Kubernetes’teki ara\u00e7lar (\u00f6rne\u011fin Cert-Manager) bu s\u00fcreci tamamen otomatikle\u015ftirebilir. Bu, \u00f6zellikle s\u00fcrekli de\u011fi\u015fen veya k\u0131sa \u00f6m\u00fcrl\u00fc test ortamlar\u0131nda b\u00fcy\u00fck bir avantajd\u0131r. K\u0131sacas\u0131, Kubernetes ev laboratuvar\u0131n\u0131zda a\u011f ve g\u00fcvenli\u011fin temellerini sa\u011flam atmak, hem verimlili\u011finizi art\u0131racak hem de projelerinizin gelecekteki \u00f6l\u00e7eklenebilirli\u011fi ve g\u00fcvenli\u011fi i\u00e7in sa\u011flam bir zemin haz\u0131rlayacakt\u0131r.<\/p>\n
Kubernetes ortam\u0131nda uygulamalar\u0131n birbirini bulabilmesi, yani “hizmet ke\u015ffi”, modern da\u011f\u0131t\u0131k sistemlerin en temel gereksinimlerinden biridir. Bu ke\u015fif mekanizmas\u0131, genellikle DNS (Domain Name System) \u00fczerinden sa\u011flan\u0131r. Kubernetes, ClusterIP, NodePort, LoadBalancer gibi \u00e7e\u015fitli servis tipleriyle uygulamalar\u0131n\u0131z\u0131 d\u0131\u015f d\u00fcnyaya a\u00e7arken, bu servislerin ve dolay\u0131s\u0131yla arkas\u0131ndaki Pod’lar\u0131n birbirleriyle ve di\u011fer servislerle isim \u00fczerinden ileti\u015fim kurabilmesini sa\u011flar. Geleneksel olarak, her Pod veya servis, dinamik olarak atanan bir IP adresine sahiptir ve bu IP adresleri de\u011fi\u015febilir. IP adreslerine do\u011frudan ba\u011f\u0131ml\u0131 olmak, uygulamalar\u0131n esnekli\u011fini ve dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 ciddi \u015fekilde k\u0131s\u0131tlar. \u0130\u015fte bu noktada Kubernetes’in DNS servisi devreye girerek bu ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 ortadan kald\u0131r\u0131r.<\/p>\n
Kubernetes’in ge\u00e7mi\u015f s\u00fcr\u00fcmlerinde CoreDNS’in sa\u011flad\u0131\u011f\u0131 hizmet ke\u015ffi mekanizmas\u0131, basit\u00e7e servis isimlerini IP adreslerine d\u00f6n\u00fc\u015ft\u00fcrmekle kalmaz, ayn\u0131 zamanda farkl\u0131 namespace’lerdeki servisler i\u00e7in de tam nitelikli alan adlar\u0131 (FQDN – Fully Qualified Domain Name) sa\u011flar. \u00d6rne\u011fin, \u015eimdi bir \u00f6rnekle bu durumu peki\u015ftirelim. Diyelim ki bir web uygulaman\u0131z ( <\/code><\/p>\n Bu Service tan\u0131m\u0131n\u0131 uygulad\u0131\u011f\u0131n\u0131zda, Kubernetes k\u00fcmeniz i\u00e7inde \u0130nternet \u00fczerindeki her t\u00fcrl\u00fc ileti\u015fimde g\u00fcvenlik, art\u0131k bir l\u00fcks de\u011fil, bir zorunluluktur. Ev laboratuvar\u0131n\u0131zda bile olsa, d\u0131\u015f d\u00fcnyaya a\u00e7t\u0131\u011f\u0131n\u0131z web uygulamalar\u0131n\u0131z\u0131n HTTPS protokol\u00fc \u00fczerinden g\u00fcvenli bir ba\u011flant\u0131 sunmas\u0131 hem veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc korur hem de kullan\u0131c\u0131lar\u0131n\u0131za g\u00fcven verir. Kubernetes ortam\u0131nda SSL\/TLS sertifikalar\u0131n\u0131 y\u00f6netmek, ba\u015flang\u0131\u00e7ta karma\u015f\u0131k g\u00f6r\u00fcnebilir ancak do\u011fru ara\u00e7larla bu s\u00fcre\u00e7 tamamen otomatize edilebilir. Bu b\u00f6l\u00fcmde, Kubernetes uygulamalar\u0131n\u0131z i\u00e7in SSL\/TLS sertifikalar\u0131n\u0131 nas\u0131l sa\u011flayaca\u011f\u0131m\u0131z\u0131 ve y\u00f6netece\u011fimizi ad\u0131m ad\u0131m inceleyece\u011fiz.<\/p>\n Kubernetes'te SSL\/TLS sertifikalar\u0131n\u0131 genellikle iki ana bile\u015fen kullanarak y\u00f6netiriz: Bir Ingress Controller<\/a> ve bir sertifika y\u00f6netim arac\u0131 olan Cert-Manager<\/a>. Ingress Controller (\u00f6rne\u011fin Nginx Ingress Controller), d\u0131\u015far\u0131dan gelen HTTP\/HTTPS trafi\u011fini Kubernetes i\u00e7indeki servislere y\u00f6nlendiren bir katmand\u0131r. SSL\/TLS sonland\u0131rmas\u0131n\u0131 (termination) genellikle Ingress Controller yapar, yani \u015fifreli trafi\u011fi \u00e7\u00f6zer ve \u015fifresiz olarak arka u\u00e7 servislerine iletir. Cert-Manager ise bu Ingress Controller'\u0131n kullanaca\u011f\u0131 SSL\/TLS sertifikalar\u0131n\u0131 otomatik olarak sa\u011flay\u0131p yenileyen g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. Genellikle Let's Encrypt gibi \u00fccretsiz bir Sertifika Yetkilisi (CA) ile entegre \u00e7al\u0131\u015farak sertifika alma ve yenileme s\u00fcre\u00e7lerini basitle\u015ftirir.<\/p>\n Ev laboratuvar\u0131n\u0131zda bir web uygulamas\u0131n\u0131 yay\u0131nlarken SSL\/TLS sertifikas\u0131 sa\u011flaman\u0131n ad\u0131mlar\u0131 genellikle \u015fu \u015fekildedir:<\/p>\n Bu ad\u0131mlar\u0131n tamamlanmas\u0131yla birlikte, Cert-Manager otomatik olarak Let's Encrypt ile ileti\u015fime ge\u00e7ecek, alan ad\u0131n\u0131z i\u00e7in bir sertifika talebinde bulunacak, alan ad\u0131 sahipli\u011fini do\u011frulayacak ve sertifikay\u0131 al\u0131p Kubernetes Secret olarak saklayacakt\u0131r. Ingress Controller da bu Secret'\u0131 kullanarak HTTPS trafi\u011fini sonland\u0131racakt\u0131r. Bu s\u00fcre\u00e7 tamamen otomatiktir ve sertifikalar\u0131n\u0131z\u0131n s\u00fcresi dolmadan \u00f6nce otomatik olarak yenilenir.<\/p>\n \u015eimdi bir \u00f6rnek Ingress kayna\u011f\u0131na bakal\u0131m. Bu \u00f6rnekte, <\/code><\/p>\n Bu YAML dosyas\u0131, Cert-Manager'\u0131n \u015eimdiye kadar Kubernetes'te DNS ve SSL'in temel kavramlar\u0131n\u0131 ve bile\u015fenlerini ayr\u0131 ayr\u0131 ele ald\u0131k. Ancak, bu teknolojileri ev laboratuvar\u0131n\u0131zda bir araya getirerek ger\u00e7ek bir uygulama i\u00e7in nas\u0131l u\u00e7tan uca bir \u00e7\u00f6z\u00fcm olu\u015fturabiliriz? Bu b\u00f6l\u00fcmde, pop\u00fcler bir i\u00e7erik y\u00f6netim sistemi olan WordPress'i ev laboratuvar\u0131 Kubernetes k\u00fcmemize da\u011f\u0131tarak, \u00f6zel bir alan ad\u0131 \u00fczerinden eri\u015filebilir hale getirece\u011fiz ve tam otomatik SSL\/TLS sertifikas\u0131 sa\u011flayaca\u011f\u0131z. Bu vaka analizi, teorik bilgileri pratik bir senaryoya d\u00f6n\u00fc\u015ft\u00fcrmenize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n Hedefimiz: Bir WordPress uygulamas\u0131n\u0131 WordPress i\u00e7in bir MySQL veritaban\u0131na ihtiyac\u0131m\u0131z var. Kal\u0131c\u0131 depolama i\u00e7in <\/code><\/p>\n Yukar\u0131daki YAML dosyas\u0131n\u0131 uygulayarak MySQL veritaban\u0131n\u0131 ve ona ba\u011fl\u0131 servisi da\u011f\u0131t\u0131n. <\/code><\/p>\n Bu YAML dosyas\u0131n\u0131 uygulayarak WordPress uygulamas\u0131n\u0131 ve ClusterIP servisini da\u011f\u0131t\u0131n. \u015eimdi s\u0131ra, <\/code><\/p>\n Bu Ingress kayna\u011f\u0131n\u0131 uygulad\u0131\u011f\u0131n\u0131zda, Cert-Manager otomatik olarak Bu ad\u0131mlar\u0131 tamamlad\u0131ktan sonra, taray\u0131c\u0131n\u0131zdan Kubernetes'te DNS ve SSL\/TLS'in temel kurulumlar\u0131n\u0131 anlad\u0131ktan sonra, ev laboratuvar\u0131n\u0131z\u0131 daha da optimize etmek ve karma\u015f\u0131k senaryolara haz\u0131rlamak i\u00e7in baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve p\u00fcf noktalar\u0131 bulunmaktad\u0131r. Bu b\u00f6l\u00fcmde, performans, g\u00fcvenlik ve y\u00f6netim kolayl\u0131\u011f\u0131 a\u00e7\u0131s\u0131ndan k\u00fcmenizi nas\u0131l geli\u015ftirebilece\u011finizi inceleyece\u011fiz.<\/p>\n CoreDNS, esnek bir eklenti mimarisine sahiptir ve <\/code><\/p>\n Modern web uygulamalar\u0131n\u0131n vazge\u00e7ilmez bir par\u00e7as\u0131 olan mobil uyumluluk, ev laboratuvar\u0131n\u0131zda geli\u015ftirdi\u011finiz projeler i\u00e7in de ge\u00e7erlidir. Kubernetes'in kendisi HTML \u00fcretmez ancak da\u011f\u0131tt\u0131\u011f\u0131n\u0131z uygulamalar mobil uyumlu olmal\u0131d\u0131r. \u0130\u015fte k\u00fc\u00e7\u00fck bir CSS media query \u00f6rne\u011fi, web uygulaman\u0131z\u0131n farkl\u0131 ekran boyutlar\u0131na nas\u0131l adapte olabilece\u011fini g\u00f6sterir:<\/p>\nkube-dns<\/code> kullan\u0131l\u0131rken, g\u00fcn\u00fcm\u00fczde standart olarak CoreDNS<\/a> tercih edilmektedir. CoreDNS, esnekli\u011fi, performans\u0131 ve eklenti tabanl\u0131 mimarisi sayesinde Kubernetes ortamlar\u0131nda hizmet ke\u015ffi i\u00e7in ideal bir \u00e7\u00f6z\u00fcmd\u00fcr. CoreDNS, bir Kubernetes k\u00fcmesi i\u00e7inde kube-system<\/code> namespace’inde bir Pod olarak \u00e7al\u0131\u015f\u0131r ve t\u00fcm Pod’lara varsay\u0131lan DNS sunucusu olarak tan\u0131t\u0131l\u0131r. Bir Pod, ba\u015fka bir servise eri\u015fmek istedi\u011finde, DNS sorgusu yapar ve CoreDNS bu sorguya ilgili servisin ClusterIP’si ile yan\u0131t verir. Bu sayede, uygulamalar IP adresi yerine anlaml\u0131 isimlerle birbirleriyle ileti\u015fim kurabilirler.<\/p>\nmy-service.my-namespace.svc.cluster.local<\/code> gibi bir isimle ba\u015fka bir namespace’deki bir servise eri\u015febilirsiniz. svc.cluster.local<\/code> k\u0131sm\u0131, k\u00fcmenin varsay\u0131lan DNS sonekidir. Kendi ev laboratuvar\u0131n\u0131zda birden fazla uygulama veya mikro hizmet \u00e7al\u0131\u015ft\u0131rmak istedi\u011finizde, CoreDNS’in sa\u011flad\u0131\u011f\u0131 bu kolayl\u0131k, a\u011f yap\u0131land\u0131rmas\u0131yla u\u011fra\u015fmak yerine uygulama geli\u015ftirme ve da\u011f\u0131t\u0131m\u0131na odaklanman\u0131z\u0131 sa\u011flar.<\/p>\nfrontend-app<\/code>) ve bu uygulaman\u0131n kulland\u0131\u011f\u0131 bir veritaban\u0131 (backend-db<\/code>) servisiniz var. Her iki servis de farkl\u0131 Pod’larda \u00e7al\u0131\u015f\u0131yor olabilir. frontend-app<\/code>‘in backend-db<\/code>‘ye eri\u015fmesi i\u00e7in IP adresini bilmesine gerek yoktur; sadece ismini bilmesi yeterlidir:<\/p>\n\napiVersion: v1\nkind: Service\nmetadata:\n name: backend-db\n labels:\n app: backend-db\nspec:\n selector:\n app: backend-db\n ports:\n - protocol: TCP\n port: 5432\n targetPort: 5432\n type: ClusterIP\n<\/pre>\nbackend-db.default.svc.cluster.local<\/code> (varsay\u0131lan namespace'deyseniz backend-db<\/code> de yeterlidir) ad\u0131nda bir DNS kayd\u0131 olu\u015fur. frontend-app<\/code> Pod'unuz, backend-db<\/code> DNS ad\u0131n\u0131 \u00e7\u00f6z\u00fcmleyerek veritaban\u0131 servisine kolayca ula\u015fabilir. Bu, Kubernetes'in i\u00e7indeki hizmet ke\u015ffinin ne kadar basit ve etkili oldu\u011funu g\u00f6sterir. Ev laboratuvar\u0131n\u0131zda karma\u015f\u0131k a\u011f yap\u0131land\u0131rmalar\u0131 yerine, uygulama geli\u015ftirmenize ve test etmenize odaklanman\u0131z\u0131 sa\u011flar. CoreDNS'in esnek yap\u0131s\u0131 sayesinde, DNS \u00e7\u00f6z\u00fcm\u00fc i\u00e7in \u00f6zel gereksinimleriniz oldu\u011funda bile kolayca yap\u0131land\u0131rma yapabilirsiniz.<\/p>\nEv Laboratuvar\u0131nda Kubernetes Uygulamalar\u0131 \u0130\u00e7in SSL\/TLS Sertifikalar\u0131n\u0131 Nas\u0131l Y\u00f6netebiliriz?<\/h2>\n
\n
my-app.example.com<\/code> alan ad\u0131 i\u00e7in Cert-Manager taraf\u0131ndan otomatik olarak bir SSL\/TLS sertifikas\u0131 sa\u011flanacak ve bu sertifika kullan\u0131larak my-app-service<\/code> adl\u0131 servise trafik y\u00f6nlendirilecektir:<\/p>\n\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n name: my-app-ingress\n annotations:\n kubernetes.io\/ingress.class: \"nginx\"\n cert-manager.io\/cluster-issuer: \"letsencrypt-prod\" # ClusterIssuer ad\u0131n\u0131z\nspec:\n tls:\n - hosts:\n - my-app.example.com\n secretName: my-app-tls # Sertifikan\u0131n saklanaca\u011f\u0131 Secret ad\u0131\n rules:\n - host: my-app.example.com\n http:\n paths:\n - path: \/\n pathType: Prefix\n backend:\n service:\n name: my-app-service\n port:\n number: 80\n<\/pre>\nletsencrypt-prod<\/code> adl\u0131 ClusterIssuer<\/code>'\u0131 kullanarak my-app.example.com<\/code> i\u00e7in bir sertifika almas\u0131n\u0131 ve bunu my-app-tls<\/code> adl\u0131 bir Secret'a kaydetmesini sa\u011flar. Ingress Controller, bu Secret'\u0131 kullanarak gelen HTTPS trafi\u011fini sonland\u0131r\u0131r. Bu yap\u0131land\u0131rma ile, ev laboratuvar\u0131n\u0131zdaki uygulamalar\u0131n\u0131za g\u00fcvenli ve \u015fifreli eri\u015fim sa\u011flamak i\u00e7in \u00f6nemli bir ad\u0131m\u0131 atm\u0131\u015f olursunuz. Unutmay\u0131n, bu kurulumu yaparken kulland\u0131\u011f\u0131n\u0131z alan ad\u0131n\u0131n do\u011fru bir \u015fekilde DNS \u00e7\u00f6z\u00fcm\u00fc yapmas\u0131 ve Kubernetes Ingress Controller'\u0131n\u0131z\u0131n d\u0131\u015far\u0131dan eri\u015filebilir olmas\u0131 gerekmektedir.<\/p>\nGer\u00e7ek D\u00fcnya Senaryosu: Ev Laboratuvar\u0131nda U\u00e7tan Uca DNS ve SSL Kurulumu<\/h2>\n
Senaryo: WordPress Uygulamas\u0131n\u0131 \u00d6zel Alan Ad\u0131 ve HTTPS ile Yay\u0131nlama<\/h3>\n
wordpress.homelab.com<\/code> gibi kendi se\u00e7ti\u011fimiz bir alan ad\u0131 \u00fczerinden yay\u0131nlamak ve bu alan ad\u0131na Let's Encrypt taraf\u0131ndan sa\u011flanan otomatik SSL sertifikas\u0131 ile g\u00fcvenli HTTPS eri\u015fimi sa\u011flamak. Bu, ev a\u011f\u0131m\u0131z d\u0131\u015f\u0131ndan bile eri\u015filebilir olacak.<\/p>\n1. Ad\u0131m: \u00d6n Ko\u015fullar ve Temel Kurulumlar<\/h4>\n
\n
ClusterIssuer<\/code> (\u00f6rne\u011fin letsencrypt-prod<\/code> veya letsencrypt-stag<\/code>) tan\u0131mlanm\u0131\u015f olmal\u0131.<\/li>\nwordpress.homelab.com<\/code> gibi bir alan ad\u0131n\u0131z olmal\u0131 ve bu alan ad\u0131n\u0131n DNS kayd\u0131 (A kayd\u0131), ev a\u011f\u0131n\u0131z\u0131n d\u0131\u015f IP adresini i\u015faret etmeli. Ev a\u011f\u0131n\u0131zda port y\u00f6nlendirme (port forwarding) yaparak 80 ve 443 numaral\u0131 portlar\u0131 Kubernetes Ingress Controller'\u0131n\u0131z\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 sunucuya y\u00f6nlendirmelisiniz. E\u011fer statik bir IP'niz yoksa, Dinamik DNS (DDNS) servislerini kullanabilirsiniz.<\/li>\n<\/ul>\n2. Ad\u0131m: WordPress ve MySQL Da\u011f\u0131t\u0131m\u0131<\/h4>\n
PersistentVolume<\/code> ve PersistentVolumeClaim<\/code> kullanaca\u011f\u0131z.<\/p>\n\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: mysql-pv-claim\n labels:\n app: wordpress\nspec:\n accessModes:\n - ReadWriteOnce\n resources:\n requests:\n storage: 5Gi\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: wordpress-mysql\n labels:\n app: wordpress\nspec:\n selector:\n matchLabels:\n app: wordpress\n tier: mysql\n strategy:\n type: Recreate\n template:\n metadata:\n labels:\n app: wordpress\n tier: mysql\n spec:\n containers:\n - image: mysql:5.7\n name: mysql\n env:\n - name: MYSQL_ROOT_PASSWORD\n value: YOUR_ROOT_PASSWORD # G\u00fc\u00e7l\u00fc bir \u015fifre belirleyin\n - name: MYSQL_DATABASE\n value: wordpress\n - name: MYSQL_USER\n value: wordpress\n - name: MYSQL_PASSWORD\n value: YOUR_WORDPRESS_PASSWORD # G\u00fc\u00e7l\u00fc bir \u015fifre belirleyin\n ports:\n - containerPort: 3306\n name: mysql\n volumeMounts:\n - name: mysql-persistent-storage\n mountPath: \/var\/lib\/mysql\n volumes:\n - name: mysql-persistent-storage\n persistentVolumeClaim:\n claimName: mysql-pv-claim\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: wordpress-mysql\n labels:\n app: wordpress\nspec:\n ports:\n - port: 3306\n selector:\n app: wordpress\n tier: mysql\n clusterIP: None # Headless servis olarak ayarla\n<\/pre>\nYOUR_ROOT_PASSWORD<\/code> ve YOUR_WORDPRESS_PASSWORD<\/code> alanlar\u0131n\u0131 kendi g\u00fc\u00e7l\u00fc \u015fifrelerinizle de\u011fi\u015ftirin.<\/p>\n3. Ad\u0131m: WordPress Uygulamas\u0131n\u0131n Da\u011f\u0131t\u0131m\u0131<\/h4>\n
\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: wp-pv-claim\n labels:\n app: wordpress\nspec:\n accessModes:\n - ReadWriteOnce\n resources:\n requests:\n storage: 5Gi\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: wordpress\n labels:\n app: wordpress\nspec:\n selector:\n matchLabels:\n app: wordpress\n tier: frontend\n strategy:\n type: Recreate\n template:\n metadata:\n labels:\n app: wordpress\n tier: frontend\n spec:\n containers:\n - image: wordpress:latest\n name: wordpress\n env:\n - name: WORDPRESS_DB_HOST\n value: wordpress-mysql\n - name: WORDPRESS_DB_USER\n value: wordpress\n - name: WORDPRESS_DB_PASSWORD\n value: YOUR_WORDPRESS_PASSWORD # MySQL \u015fifresiyle ayn\u0131 olmal\u0131\n - name: WORDPRESS_DB_NAME\n value: wordpress\n ports:\n - containerPort: 80\n name: wordpress\n volumeMounts:\n - name: wordpress-persistent-storage\n mountPath: \/var\/www\/html\n volumes:\n - name: wordpress-persistent-storage\n persistentVolumeClaim:\n claimName: wp-pv-claim\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: wordpress\n labels:\n app: wordpress\nspec:\n ports:\n - port: 80\n selector:\n app: wordpress\n tier: frontend\n type: ClusterIP\n<\/pre>\nWORDPRESS_DB_PASSWORD<\/code> de\u011ferinin MySQL \u015fifrenizle e\u015fle\u015fti\u011finden emin olun.<\/p>\n4. Ad\u0131m: Ingress ve Cert-Manager ile SSL Yap\u0131land\u0131rmas\u0131<\/h4>\n
wordpress.homelab.com<\/code> alan ad\u0131m\u0131z\u0131 WordPress servisine y\u00f6nlendirmeye ve otomatik SSL sa\u011flamaya geldi.<\/p>\n\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n name: wordpress-ingress\n annotations:\n kubernetes.io\/ingress.class: \"nginx\"\n cert-manager.io\/cluster-issuer: \"letsencrypt-prod\" # Daha \u00f6nce tan\u0131mlad\u0131\u011f\u0131n\u0131z ClusterIssuer ad\u0131\n nginx.ingress.kubernetes.io\/force-ssl-redirect: \"true\" # T\u00fcm HTTP trafi\u011fini HTTPS'e y\u00f6nlendir\nspec:\n tls:\n - hosts:\n - wordpress.homelab.com\n secretName: wordpress-tls-secret # Sertifikan\u0131n saklanaca\u011f\u0131 Secret\n rules:\n - host: wordpress.homelab.com\n http:\n paths:\n - path: \/\n pathType: Prefix\n backend:\n service:\n name: wordpress\n port:\n number: 80\n<\/pre>\nwordpress.homelab.com<\/code> i\u00e7in Let's Encrypt'ten bir sertifika talep edecek. Talep ba\u015far\u0131l\u0131 olursa, sertifika wordpress-tls-secret<\/code> adl\u0131 bir Kubernetes Secret olarak saklanacak ve Nginx Ingress Controller bu sertifikay\u0131 kullanarak HTTPS trafi\u011fini sonland\u0131racakt\u0131r. Ayr\u0131ca, nginx.ingress.kubernetes.io\/force-ssl-redirect: \"true\"<\/code> anotasyonu sayesinde t\u00fcm HTTP istekleri otomatik olarak HTTPS'e y\u00f6nlendirilecektir.<\/p>\nSonu\u00e7<\/h4>\n
https:\/\/wordpress.homelab.com<\/code> adresine gitti\u011finizde, WordPress kurulum sihirbaz\u0131n\u0131 HTTPS \u00fczerinden g\u00fcvenli bir \u015fekilde g\u00f6rmelisiniz. Bu senaryo, ev laboratuvar\u0131n\u0131zda bir uygulaman\u0131n hem dahili hizmet ke\u015ffi (WordPress'in MySQL'i bulmas\u0131) hem de d\u0131\u015f d\u00fcnyaya g\u00fcvenli bir \u015fekilde a\u00e7\u0131lmas\u0131 (HTTPS ile) i\u00e7in DNS ve SSL\/TLS'in nas\u0131l entegre edildi\u011fini g\u00f6stermektedir. Bu vaka analizi, kendi projelerinizde benzer yap\u0131land\u0131rmalar\u0131 uygulaman\u0131z i\u00e7in size sa\u011flam bir temel sunar.<\/p>\n\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve Optimizasyonlar: Ev Laboratuvar\u0131n\u0131z\u0131 G\u00fc\u00e7lendirin<\/h2>\n
\u00d6zel CoreDNS Yap\u0131land\u0131rmalar\u0131 ve DNS Politikalar\u0131<\/h3>\n
Corefile<\/code> ad\u0131 verilen bir ConfigMap \u00fczerinden yap\u0131land\u0131r\u0131l\u0131r. Ev laboratuvar\u0131n\u0131zda, varsay\u0131lan CoreDNS yap\u0131land\u0131rmas\u0131n\u0131n \u00f6tesine ge\u00e7meniz gerekebilir:<\/p>\n\n
ad.homelab.local<\/code> gibi \u00f6zel bir alan ad\u0131n\u0131z varsa, CoreDNS'i bu alan ad\u0131n\u0131n sorgular\u0131n\u0131 belirli bir i\u00e7 DNS sunucusuna (\u00f6rne\u011fin bir dnsmasq<\/code> sunucusu veya pfSense \u00fczerindeki DNS Resolver) iletecek \u015fekilde yap\u0131land\u0131rabilirsiniz. Bu sayede, Kubernetes i\u00e7indeki Pod'lar, d\u0131\u015f DNS sunucusunu do\u011frudan bilmeden bu kaynaklara eri\u015febilir.<\/li>\nhosts<\/code> eklentisi ile bu t\u00fcr statik e\u015flemeleri kolayca yapabilirsiniz.<\/li>\ndnsPolicy<\/code> alan\u0131 ile kontrol edilebilir. ClusterFirst<\/code> (varsay\u0131lan) CoreDNS'i kullan\u0131rken, Default<\/code> Pod'un \u00e7al\u0131\u015ft\u0131\u011f\u0131 d\u00fc\u011f\u00fcm\u00fcn DNS yap\u0131land\u0131rmas\u0131n\u0131 kullan\u0131r. None<\/code> ise tamamen \u00f6zel bir DNS yap\u0131land\u0131rmas\u0131na izin verir (dnsConfig<\/code> alan\u0131 ile birlikte). \u00d6rne\u011fin, belirli bir Pod'un sadece d\u0131\u015f bir DNS sunucusunu kullanmas\u0131n\u0131 istiyorsan\u0131z dnsPolicy: None<\/code> ve dnsConfig<\/code> kullanarak bu Pod'un DNS sunucular\u0131n\u0131 ve arama alanlar\u0131n\u0131 \u00f6zelle\u015ftirebilirsiniz.<\/li>\n<\/ul>\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: my-custom-dns-pod\nspec:\n containers:\n - name: busybox\n image: busybox\n command: [\"sh\", \"-c\", \"echo 'Hello from custom DNS pod!' && sleep 3600\"]\n dnsPolicy: None # Varsay\u0131lan DNS politikas\u0131n\u0131 devre d\u0131\u015f\u0131 b\u0131rak\n dnsConfig:\n nameservers: # \u00d6zel DNS sunucular\u0131\n - 8.8.8.8\n - 8.8.4.4\n searches: # \u00d6zel arama alanlar\u0131\n - mydomain.com\n - example.com\n options:\n - name: ndots\n value: \"2\"\n<\/pre>\nWildcard Sertifikalar ve \u00d6zel CA'lar<\/h3>\n
\n
app1.homelab.com<\/code>, app2.homelab.com<\/code>) kullan\u0131yorsan\u0131z, her biri i\u00e7in ayr\u0131 ayr\u0131 sertifika almak yerine *.homelab.com<\/code> i\u00e7in tek bir wildcard sertifika alabilirsiniz. Bu, y\u00f6netim y\u00fck\u00fcn\u00fc \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r. Let's Encrypt wildcard sertifikalar\u0131 i\u00e7in DNS01 challenge y\u00f6ntemini gerektirir, yani Cert-Manager'\u0131n DNS sa\u011flay\u0131c\u0131n\u0131z\u0131n API'si ile etkile\u015fime ge\u00e7ebilmesi gerekir.<\/li>\nMobil Uyumlu HTML ve Responsive Tasar\u0131m<\/h3>\n
\n