VMware Enterprise PKS (Deep Dive)

VMware Enterprise PKS ile günümüzde tatmin edici müşteri deneyimleri sunan işletmeler, deneyim yerine ürün sunan işletmelere göre çok daha başarılıdırlar. Müşteri deneyimi sunmak uygulama otomasyonunun ötesine geçer. Örneğin müşterileri bir taksi tutabilecekleri bir yere yönlendirmek için bir uygulama oluşturan şirket eski iş yapma yöntemlerine göre bir yazılım çözümü sağlar. Ancak müşterinin A noktasından B noktasına kişisel bir sürüş talep edebileceği bir çözüm sınırsız olasılıklarla sonuçlanır, çünkü bu model müşteri ve sürücüleri birbirine bağlayan bir platform oluşturur. Tatmin edici müşteri deneyimi sunan uygulama ve servisler için ölçeklenebilir, stabil ve güvenilebilir bir altyapıya sahip olmanız gerekir.

Gelişen internet altyapısı, akıllanan cihazlar ve birbirinden fazla seçenek ile müşterilerin kişisel ihtiyaç ve beklentileri artık eskisinden çok daha hızlı bir şekilde değişmektedir. Bu kadar değişkenin tetiklendiği yazılım ve servisler evreninde artık daha gelişmiş ve daha çevik altyapılara ihtiyaç duyulmaktadır.

Geleneksel yazılım geliştirme süreçlerinde;

• Yazılımın teslim edilmesi yaklaşık 6 ile 12 ay sürebilir. Bu kadar uzun bir döngü içerisinde yazılım gereksinimlerinin değişme riski oldukça fazladır. Buna ek olarak yazılım gereksinimlerinin yanlış yorumlandığı proje sonunda anlaşılabilir.
• Yazılım hazır olduğunda operasyon ekibine teslim edilir. Operasyon ekibi yazılımı konumlandırır ve yönetir fakat uygun eğitim ve dokümantasyon olmadan operasyon ekibi yazılımı geliştirmeyi ve yönetmeyi zor bulabilir.
• Geleneksek yazılımlar manuel olarak tek bir VM ya da sunucu üzerinden dağıtılır. Ve bunlar genel olarak ölçeklenebilir olarak tasarlanmamıştır. Tek seçenek daha yüksek performans elde etmek için CPU, disk ve belleği artırmaktır.
• Yazılım geliştiriciler kendi bilgisayarları ya da başka iş istasyonları üzerinde uygulamayı geliştirmeye başlar ve sonrasında testler yapıldıktan sonra yazılımı üretim ortamına taşırlar. Her ortam farklı yazılım kütüphaneleri ve yapılandırmaları içerir ve bu ortamlar için ilgili yazılım gereksinimlerin sağlanması gerekir. Bu tarz ortamlar yazılımın bir ortamda çalışıp diğerinde neden çalışmadığını belirlemede yazılım geliştiriciler için sorunlara neden olur.

Günümüz yazılım geliştirme süreçlerinde;

• Minimum uygulanabilir bir ürün (MVP-Minimum Viable Product) bir-iki haftalık geliştirme döngüleriyle gösterebilmektedir. Müşteriler bir sonraki geliştirme döngüsü gereksinimleri için anında geri bildirim verilebilir. Bu yöntem kesin ihtiyaçları karşılayamayacak bir ürün için aylarca harcama yapmayı önler.
• DevOps uygulama geliştiricileri ile altyapı operatörleri arasındaki uyum eksikliğinin giderilmesi için ortaya çıkmıştır. Geleneksel yazılım geliştirme süreçlerinde geliştiriciler üretim ortamına çıktıktan sonra uygulamanın nasıl çalıştığı konusunda sorumluluk alıyor ve altyapı operatörleri uygulamayı otomatikleştirmek için kodlama teknikleri öğrenip, uyguluyorlardı.
• Yazılım üretmenin statik bir görev olmadığı farkına varılmasıyla entegrasyon ve dağıtım dinamik bir süreç haline geliyor. (CI-Continuous Integration ve CD-Continuous Delivery/Deployment) Sürekli entegrasyon ürünün sık sık otomatik olarak oluşturulması ve test edilmesi anlamına geliyor. Örnek vermek gerekirse geliştirici bir hatayı düzeltir ve kodu kontrol ederse bu işlem otomatik olarak fark edilir bir derleme ya da test hemen başlatılır. CD (Continuous Delivery/Deployment) ise otomatik olarak bazen insan müdahalesi bile olmadan güncellemeleri dağıtarak dağıtım kavramını bir adım daha öteye götürmektedir.

Cloud-Native (Bulut Tabanlı) Uygulamalar

Esnek olarak tasarlanan bu mimaride uygulamalar arıza ve kesintiler göz ününde bulundurularak tasarlanıp, ağ veya veritabanı kesintilerini tolere edecek şekilde üretilmişlerdir. Bu mimariler genel olarak microservice mimari üzerine kurulmuştur. Her micro servis sistemin belirli kısımlarından sorumlu olmalıdır. Örnek olarak uygulama kullanıcı arayüzü, sipariş ve ürün hizmetler ile birlikte farklı servislere bölünmüştür. Her hizmetin kendi veritabanı vardır. Bu mimariye göre her hizmet birbirinden bağımsız olarak ölçeklendirilebilir. Örneğin yoğun zamanlarda sipariş hizmetinin ölçeklendirilmesi gerekebilir. (Yılbaşı, sevgililer günü gibi)

Bağımlılıklar uygulama ile birlikte paketlenir ve uygulamalar TCP/UDP üzerinden iletişim kurar.

Aşağıdaki örnek bir konteynır iş akışında

• Kaynak kodu ve bağımlı olduğu kütüphane üzerinden bir image yaratılır
• Yaratılan bu image kayıt servisi üzerine gönderilir.
• Kayıt servisi üzerinden yeni bir image alınır.
• Alınan yeni image üzerinden konteynır yaratılmış olur.

Container Engine

Konteynır sisteminin yüklü olduğu işletim sistemi üzerinde bir arka plan servisi olarak çalışır. Kullanıcı bir konteynırın çalışmasını istediğinde container engine image registry üzerinden bir konteynır imajı alır ve bir servis olarak çalıştırır. Konteynır oluşturulması, durdurulması ve silinmesi gibi temel iş yüklerini yönetir. Docker en yaygın kullanılan Container Engine’dır.

Kubernetes Mimarisi

Docker ile konteynırlar tek bir konteynır host üzerinden yönetilir çoklu konteynır hostların üzerinden çoklu konteynırları yönetmek pek çok probleme neden olmaktadır.

Kubernetes konteynır hostları yöneten bir orkestrasyon katmanı sağlar.

• Çok sayıda konteynırın yönetilmesi
• Konteynırların tekrardan başlatılması
• Konteynırların ölçeklendirilmesi
• Network ve yük dengelemenin sağlanması

Kubectl; Kubernetes API komut satırı CLI arabirimidir.

Kubernetes Master VM;

• API Server; Kubernetes bağlantı noktasıdır.
• Etcd; Sistemin mevcut durumunu ve ayarlarını saklayan depolama alanıdır.
• Controller Manager; API serverı izleyen ve gerekli işlemleri yapan birimdir.
• Scheduler; Node VM’ler arasında POD’ları dengeler.

Kubernetes Node VM;

• Kubelet; API server tarafından kendisine atanan işleri izler.
• Kubeproxy; Konteynırlara trafiği yönlendirmek için network kurallarını yapılandırır.
• Docker; Kubelet tarafından istenilen POD’ları çalıştır.

Pod

Pod bir ya da birden çok konteynır setidir. Kubernetes içerisinde çalışan en küçük birimdir. Konteynırlar Pod ile birlikte yaşar ve ölür.

Kubernetes iş akışı

• Kaynak kod ve kütüphane üzerinden bir imaj yaratılır.
• Yaratılan imaj registry üzerine gönderilir.
• Kubernetes bir Pod çalıştırmak için bu imajı çağırır.
• Scheduler bir node VM üzerine Pod’u atar.
• Kubelet Pod’u kabul eder.
• Docker image registry üzerinden imajı alır.
• Docker Pod içerisinde konteynır servisini başlatır.

VMware Enterprise PKS Mimarisi

PKS, VMware SDDC mimarisi ile entegre bir konteynır hizmet paketi sağlar. Micro servis mimarisi için gerekli olan tüm araçları eksiksiz olarak enterprise seviyede sunar.

VMware Enterprise PKS iş akışı

• PKS CLI bir cluster yaratılması için PKS API’yi çağırır.
• PKS API yaratılacak olan Master ve Worker VM’ler için BOSH ile iletişime geçer.
• Cluster yaratıldıktan sonra Kubernetes CLI aracılığı ile Kubernetes cluster’a direkt olarak erişilir.

VMware Enterprise PKS katmanları

BOSH

BOSH yüksek miktarda yazılım ve servisi ölçeklendirilebilir ve dağıtabilir. BOSH, VMware Enterprise PKS mimarisi üzerinde gerekli olan güncelleme, performans izleme, kurtarma gibi ihtiyaç duyulan yaşam döngüsü yönetimini sağlar. VMware vSphere, Google Cloud Platform, Amazon Web Services EC2, Microsoft Azure, OpenStack ve Alibaba Cloud gibi çoklu IaaS sağlayıcılarının tamamını destekler.

BOSH Bileşenleri

Director; CLI arayüzü ile birlikte BOSH dağıtımlarını ve yönetimini sağlayan ana API’dır. Kullanıcı isteklerini ve sistem olaylarını yanıtlayan ana bileşenlerden biridir. Tanımlanmış olan görevleri kuyruğa ekler.

Health Monitör; BOSH dağıttığı her VM’in sağlığını izler. Agent’lar üzerinden sağlık durumunu alır gerektiğinden e-posta ile bildirimler gönderir. VM’ler üzerinde çalışan hizmetler hatalıysa ve agent’a erişilemiyorsa hizmetleri tekrardan başlatır ve VM’leri tekrardan oluşturur.

CPI (Cloud Provider Interface); Director’ün stemcells (Embedded Linux yada Windows imajı) VM ve diskler oluşturmak, yönetmek için IaaS katmanı ile iletişim kuran API’dir.

NATS; Kontrol ve komutlar için gerekli olan bir mesajlaşma sistemidir. BOSH hizmetleri aralarında iletişim kurmak için bu veri yolunu kullanır.

UAA (User Account and Authentication); BOSH için gerekli olan SAML ve LDAP gibi kimlik doğrulama hizmetlerini sunar.

CredHub; Parolalar, sertifikalar, yetkiler SSH anahtarları, RSA anahtarları gibi kimlik bilgilerini yönetir. Sertifika ve anahtarları ile birlikte kimlik bilgilerini oluşturur ve depolar.

PostgreSQL; BOSH VM içerisinde çalışan dahili veritabanıdır.

Blobstore; Stemcell ve derlenmiş paketleri depolar.

Agent; BOSH dağıtmış olduğu her VM için bir agent kullanır. Agent Director talimatlarını dinler ve yerine getirir. Örneğin VM üzerinde bir MySQL servisi kurulup yapılandırılacaksa bu servis için gerekli olan paketleri nasıl yapılandıracağı ile ilgili gerekli talimatları alır ve yerine getirir.

VMware Enterprise PKS içerisinde Kubernetes

CFCR (Cloud Foundry Container Runtime) Kubernetes’in BOSH tarafından piyasaya sunulmuş halidir. (Kubo olarakta bilinir) BOSH kullanarak yüksek erişilebilirliğe sahip Kubernetes kümelerinin oluşturulup yönetilmesini sağlar. Kubernetes’in açık kaynak standartlarını kullanır.

Kubernetes Master Node

NOT: Mavi bileşenler standard Kubernetes bileşenleridir. Gri olanlar ise PKS tarafından eklenmiş olan ek bileşenlerdir.

Kube API Server; Kubernetes ile etkileşimi sağlayan arayüzdür.

Kube Controller Manager; dağıtımları ve servisleri yöneten denetleyicidir.

Kube Scheduler; Worker Node’lar üzerinde çalışan Pod’ları zamanlar.

Etcd; tüm ayarları tutan key-value veritabanıdır.

NCP; NSX-T ile Kuberbetes’i entegre eden NSX Container eklentisidir.

BOSH DNS; BOSH VM’ler arasındaki dahili BOSH hostnamelerini çözen DNS servisidir.

Blackbox; Uzak Syslog sunucularına günlükleri gönderir.

BOSH Agent; BOSH tarafından yönetilen tüm VM’ler üzerinde çalışır ve BOSH Director’e çalışan tüm job’ların detaylarını iletir.

Kubernetes Worker Node

NOT: Sarı olanlar standard Kubernetes bileşenleridir. Gri olanlar ise PKS tarafından eklenmiş olan ek bileşenlerdir.

Kubelet; Pod’ların içersinde konteynırların çalışmasını sağlar.

Kube-proxy; Pod’lar için gerekli olan TCP, UDP ve Load Balancing gibi network servislerini sağlar.

NSX kube-proxy; Sadece NSX-T ile birlikte Open vSwitch (OVS) kullanarak Kubernetes içerisinde kube-proxy genişleterek dağıtılmış bir load balancer hizmeti sağlar.

NSX Node Agent; Kubernetes API ile iletişime geçerek konteynır network arayüzünü yapılandırır ve yönetir.

BOSH DNS; BOSH Agent ile BOSH director üzerinden alına DNS kayıtlarını alır, izler ve çözümlenmesini sağlar.

BOSH Agent; Başlatma, durdurma ve izleme gibi işlemleri yönetir.

Blackbox; Günlük dosyalarını Syslog sunucusuna iletir.

PCF Ops Manager

PCF Ops Manager PKS platformunu konfigure eden ve dağıtan grafik arayüzüdür. Web tabanlı bu arayüz BOSH, Enterprise PKS ve Harbor’un dağıtımında ve konfigürasyonunda kullanılır. Operation Manager bir VM’dir. Her bileşen Ops Manager tarafından dağıtılır ama Ops Manager ile etkileşim içerisinde değildir. Örneğin Enterprise PKS Ops Manager ile dağıtılır ama Kubernetes cluster Ops Manager üzerinden değil PKS CLI üzerinden Enterprise PKS’ye bağlanılarak oluşturulur.

Ops Manager BOSH, PKS ve Harbor üzerinde yapılan değişikliklerin otomatik olarak yapılıp dağıtılmasını sağlar.

VMware Enterprise PKS Control Plane

Enterprise PKS kullanarak dağıtılmış olan Kubernetes cluster’ların yaşam döngüsünü yöneten ve PKS CLI aracılığı ile yönetilen arayüzdür.

• Cluster planlarının görüntülenmesi (Small, Medium ve Large gibi)
• Clusterlar hakkında bilgilerin görüntülenmesi
• Clusterların oluşturulması, ölçeklendirilmesi ve silinmesi
• NSX-T için network profillerinin yaratılması ve yönetilmesi
• Enterprise PKS BOSH tarafından dağıtılan bir VM’dir.

• Kubernetes cluster oluşturma ya da değiştirme gibi tüm istekler PKS API üzerinden geçer.
• PKS API sunucusu bir istek alır ve doğrulama için kimlik doğrulama token’nini UAA’ya iletir.
• Kimlik doğrulandıktan sonra eğer NSX-T kullanıyorsa NSX-T Proxy üzerinden NSX-T üzerine geçer. NSX-T Proxy aracı ile NSX-T API üzerinden gerekli nesneleri oluşturur, günceller ve bir BOSH yapılandırma dosyası oluşturur. Daha sonra NSX-T Proxy değişikliği ya da güncellemeyi tamamlamak için istekleri ODB üzerine iletir. Eğer Flannel kullanılıyorsa direkt olarak ODB (On-Demand Broker) üzerine geçer.

NOT: Enterprise PKS NSX-T alternatifi olarak Flannel’i de support eder.

• ODB istekleri CFCR Service Adaptör ile görüşerek BOSH üzerine güncellenmiş bir bildirim gönderir.
• BOSH kullanıcı isteğini tamamlamak için Kubernetes kümesini oluşturur veya günceller.

Cluster Plan

Kubernetes Cluster’ın büyüklüğünü tanımlayan ön tanımlı planlardır. Her plan master ve worker node adetlerini ve VM tiplerini belirler.

Harbor Registry Service

Harbor enterprise-class seviyesinde çalışan bir Registry Server’dır. Docker registry servisini genişleterek gelişmiş bir esneklik, güvenlik ve otomasyon katmanı sağlamaktadır. Docker imajları içerisinde kullanılmak üzere kurumsal bir registry havuzu oluşturmasını sağlar.

Bir VM olarak Ops Manager tarafından dağıtılır ve Web GUI üzerinden yönetilir.

• Harbor LDAP (Lightweight Directory Access Protocol) servisini projelere atayabilir ve entegre olabilir.
• UAA (Default User Account and Authentication) oturumunu Enterprise PKS ile paylaşabilir.
• RBAC (Role-based Access Control) ile kullanıcılar için proje tanımlı izinler tanımlayabilir.
• Vulnerability Scanning ile imajları düzenli olarak tarar ve kullanıcıları güvenlik açıkları konusunda uyarır. (Clair)
• İmaj orijinalliğini doğrular (Notary)
• Policy tabanlı imaj replikasyonu sağlar. (Multi registry, Load Balancing, HA, Multi-Cloud gibi)
• Web tabanlı GUI ile kolayca yönetilebilir.
• RESTful API desteği ile diğer sistemlere kolayca entegre olabilir.
• İmajları proje düzeyinde etiketleyebilir ve birbirinden izole edebilir.

Harbor RBAC rolleri;

Public; Kullanıcılar genel bir ayrıcalığa sahiptir. Projeleri diğer kullanıcılar ile paylaşabilir.

Private; Özel bir proje için yalnızca uygun ayrıcalıklarla atanırlar. Farklı roller ile projelere atanabilirler.

• Guest; Proje üzerinde salt okunur bir ayrıcalıktır.
• Developer; Proje için okuma ve yazma ayrıcalıklarını sahiptir.
• Project Admin; Okuma ve yazma ayrıcalıklarına ek olarak kullanıcı ekleme, çıkartma ve güvenlik taraması yapma gibi bazı yönetim ayrıcalıklarına sahiptir.

SysAdmin; Tüm yönetim ayrıcalıklarına sahiptir. Projeleri listeleyebilir, silebilir, kullanıcıyı yönetici olarak atayabilir, kullanıcıları silebilir ve güvenlik açığı tarama ilkesi için özel tanımlar girebilir.

Anonymous; Bir kullanıcı oturum açmadığında anonim kabul edilir. Özel projelere erişim izni yoktur ve genel projeler için sadece salt okunur erişime sahiptir.

Clair

İmajların güvenlik açığı içerip içermediğini doğrulamak için Clair servisini kullanır. Clair yapılandırılmış olan bir kaynak üzerinden doğrulamaları alarak veritabanını korur ve günceller. İmajlar manuel veya otomatik olarak tetiklenerek taranabilir. Proje özelinde güvenlik tarama ilkeleri atanabilir. Güvenlik açığı önem derecesine göre imajların kayıt defterinden alınması önlenebilir.

Clair tarafından kullanılan kaynaklar.

• Debian Security Bug Tracker
• Ubuntu CVE Tracker
• Red Hat Security Data
• Oracle Linux Security Data
• Alpine SecDB
• NIST

Enterprise PKS Management Console

EPMC vSphere ortamı üzerinde Enterprise PKS için merkezi bir dağıtım ve yönetim arayüzü sunar.

Merkezi olarak Ops Manager, Harbor, BOSH ve PKS dağıtım ve erişim bilgilerine erişebilirsiniz.

Oluşturmuş olduğunuz Kubernetes cluster ve node’larını görüntüleyebilir ve Dashboard için bağlantı parametrelerini alabilirsiniz.

VMware Enterprise PKS ile NSX-T Data Center

Logical Switching

Hostlar arasında GENEVE protokolü üzerinden L2 bağlantı sağlar. VM ve Pod’lar aynı logical switch üzerinde kullanıldığında hostlar arasında VM ve Pod’lar Overlay tünel üzerinden birbirlerine erişebilir.

Logical Routing

Hostlar arasında distributed routing sağlar.

Tier-0 Router (NSX Edge VM gerektirir)

• North/South trafiğini yönetir. (Logical Network to Outside Network)
• Logical ve fiziksel network arasında erişimi sağlar.
• Fiziksel routerlar ile BGP üzerinden dinamik routing erişimi sağlar.
• ECMP (Equal-cost Multi-path) desteği sağlar.

Tier-1 Router (Tier-0 Router gerektirir)

• East/West trafiğini yönetir. (Logical Switch to Logical Switch)
• Farklı logical switchler arasında network erişimini sağlar.

NSX EDGE Node

• BGP ya da Static Routing üzerinden Tier-0 Router aracılığı ile harici networklere erişimi sağlar.
• Harici networkler ve mantıksal networkler için NAT, Load Balancing, Dynamic Routing ve Firewall gibi servisleri sağlar.
• HA için clustering sağlar. (Active-Active ya da Active-Standby)

Neden PKS ile NSX-T?

NSX-T PKS Enterprise üzerine tamamen entegre çalışmaktadır. PKS ile Overlay network için NSX-T kullanmak zorunda değilsiniz deployment esnasında zaten size Overlay network için 3 farklı alternatif sunmaktadır.

Kurumsal ve merkezi yönetim, otomasyon, güvenlik, tutarlılık ve daha gelişmiş bir yönetim platformu sunduğu için tercihinizi NSX-T üzerinde kullanmamız daha mantıklı olacaktır. İleride daha kolay büyüme, daha fazla servisle entegre olabilme ve daha kolay sorun çözebilmek istiyorsanız bu doğru bir tercih olacaktır.

Troubleshooting için NSX-T ile TraceFlow çıktısını aşağıda görebilirsiniz.

Enterprise PKS Network Deployment

PKS ortamı için NSX-T ya da Flannel’i tercih edebilirsiniz.

NSX-T Data Center (Automated NAT Deployment)

• Tier-0 Router bağlantısı EDGE Cluster üzerinden otomatik olarak yapılır
• Logical Switch otomatik olarak oluşturulur.
• Tier-1 Router otomatik olarak oluşturulur
• PKS Management network için Logical Switch otomatik olarak oluşturulur.
• Pod, Node ve Floating IP Pool otomatik olarak oluşturulur
• Tier-1 Router üzerine PKS Management Logical Switch atanır.
• Tier-1 Router ile Tier-0 Router bağlantısı yapılır
• Tier-0 Router üzerinde BOSH, PKS, Harbor ve Opsman için SNAT kuralları yazılır.

NOT: Yukarıdaki ayarların otomatik olarak yapılabilmesi için öncelikle EDGE Node/Cluster oluşturulması gerekmektedir.

NSX-T Data Center (Bring Your Own Topology)

• NSX-T üzerinde PKS Management Network için Logical Switch’i manuel oluşturulur.
• NSX-T üzerinde Pod, Node ve Floating IP Pool’lar manuel oluşturulur.
• Tier-0 Router ve Tier-1 Router manuel oluşturulur.
• PKS Management Network için Tier-1 bağlantısı manuel yapılır.
• NAT kuralları zorunlu değildir. NAT ya da No-NAT olarak deploy edilebilir.

Flannel Deployment

• PKS Management, Node ve Pod network belirtilir.
• Flannel kurulumu otomatik olarak yapılır
• Overlay network dağıtımı ve erişimi Flannel üzerinden yapılır
• vSphere Distributed Switch (VDS) yeterlidir. (MTU 9000 tavsiye edilir)

Fiziksel Topoloji

• vCenter üzerinde PKS Management, PKS Compute ve NSX-T Edge Node’lar için oluşturulmuş Cluster’lar (Tek cluster da olabilir ama Prod ortamlar için tavsiye edilen ayrı management ve compute cluster’lar üzerinde olmasıdır)
• Cluster’lar üzerinde aktif edilmiş DRS ve HA servisleri
• Compute cluster üzerinde sonrasında Availability Zone için kullanılacak olan Resource Pool’lar oluşturulmalıdır.

NOT: NSX-T kullanılacaksa overlay network için NSX-T sadece compute cluster üzerinde konfigure edilebilir.

Availability Zone

Pivotal tarafından Prod ortamlar için tavsiye edilen dağıtım şeklidir. Fiziksel olarak donanım altyapısını birbirinden ayırıp kesintileri önleyerek, yedekliliği en üst seviyeye çıkartır.

Örneğin aşağıdaki örneğe göre Prod ortamda Kubernetes cluster’larınızı büyüklüklerine ya da önem derecesine göre farklı Availability Zone’lar arasında dağıtabilirsiniz.

Örneğin;

• İlk Kubernetes cluster tüm master ve worker node’ları birinci compute cluster üzerinde birinci availability zone üzerinde çalıştırmaktadır.
• İkinci Kubernetes cluster master ve birinci worker node birinci availability zone üzerinde ikinci ve üçüncü worker node ise ikinci ve üçüncü availability zone üzerinde dağıltılmışlar. (Sadece worker node’lar korunuyor)
• Üçüncü Kubernetes node ise master node HA aktif şekilde tüm availability zone’lar arasında eşit olarak dağıtılmış. (master ve worker node’lar korunuyor)

Genel notlarım;

• Eğer Windows Worker node’lar kullanacasınız şu an için Overlay network sadece Flannel üzerinde desteklenmektedir. Flannel üzerinde Windows Worker node geliştirmeleri ise şu an Beta sürecindedir. Plan 11,12,13 için Windows Worker Node’lar Flannel ile aktif edilebilir.
• NSX-T Edge Tier-0 Router üzerinde ve fiziksel router üzerinde mutlaka BGP konfigürasyonunu yapın. Static Routing ile uğraşmaktansa Dinamik Routing ile çok rahat edersiniz.
• Network olarak NSX-T kullanacak iseniz NSX EDGE Node’u Large olarak deploy ediniz.
• Lisanlama Pods ve CPU Core olmak üzere iki şekilde yapılmaktadır. Minumum 100 Core ya da 100 Pods olarak başlayabilirsiniz ve sonrasında 8 Core ve 50 Pod Add-On olarak büyüyebilirsiniz. Benim tercihim Core olarak lisanslamanın daha mantıklı olacağı yönünde, kullanılacak servis ve uygulamalar göre Core daha fazla Pod’a kaynak sağlayabilir bu da daha fazla konteynır çalıştırabileceğiniz anlamına geliyor. (1 Core 1–5 Pod gibi)

Enterprise PKS popüler birçok VMware dağıtımı ile entegre çalışabilir.

VMware vRealize Operation Manager

VMware vRealize Log Insight

VMware vRealize Automation ve vRealize Orchestrator

VMware VCF (VMware Cloud Foundation)

VMware Wavefront

Son olarak;

Kubernetes, Docker, Flannel ve diğer servislerin alternatifleri zaten Open-Source olarak mevcut neden bu platform için lisans ücreti ödeyim ki diyebilirsiniz. Gayet mantıklı bir soru fakat bu kadar büyük ve karmaşık yapıyı birbiri ile entegre etmek, yönetmek, dağıtmak, güncellemek ve tutarlılığını sağlamak hiç kolay değil.

Küçük bir örnek vermek gerekirse BOSH, PKS ve Harbor üzerinde yapmış olduğunuz ufak bir değişikliği Ops Manager üzerinden dakikalar içerinde tüm sisteme uygulayıp, dağıtabilirsiniz. Bu süreç içerinde yapılan tüm değişiklikler belirli kurallar ve uyumluluklar doğrultusunda sistem tarafından otomatik olarak yapılmaktadır. İnsan ve uygulama hatası neredeyse imkânsız düzeydir.

Tüm platform güncellemeleri paket olarak geçmektedir. Elle müdahale gerekmez. Tüm platforma belirli bir sıra ve uyumluluk ile dağıtılır.

Open-Source dünyasında destek için sadece genel kaynaklardan ve bloklardan yararlanabilirsiniz. Birinci elden erişebileceğiniz bir destek noktası yoktur. Kurumlar üzerinde bazı hukuksal düzenlemelerden dolayı Production ortamlarında Open-Source dünyası riskli olabilir.

Kısacası VMware PKS, Red Hat Openshift ya da Docker Enterprice bu platformaların hepsi kurumsal seviyede benzer ortak özelliklere sahipler fakat PaaS servisini profesyonel bir seviyede vermek istiyorsanız Enterprise-grade Kubernetes dağıtımlarından birini kullanmak zorundasınız.

Görüşmek üzere.