Kubernet'ler - bulutu evcilleştirme

Bir işletmeye hizmet sağlamak için Linux kullanmak istediğinizde, bu hizmetlerin güvenli, dayanıklı ve ölçeklenebilir olması gerekir. Güzel sözler ama bunlarla ne demek istiyoruz?

'Güvenli', ister salt okunur erişim ister yazma erişimi olsun, kullanıcıların ihtiyaç duydukları verilere erişebileceği anlamına gelir. Aynı zamanda, hiçbir veri, onu görme yetkisi olmayan herhangi bir tarafa açıklanmaz. Güvenlik yanıltıcıdır: Her şeyi koruduğunuzu düşünebilirsiniz, ancak daha sonra boşluklar olduğunu anlayabilirsiniz. Bir projenin başlangıcından itibaren güvenlik içinde tasarlamak, daha sonra güçlendirmeye çalışmaktan çok daha kolaydır.

'Dayanıklı', hizmetlerinizin altyapıdaki arızaları tolere etmesi anlamına gelir. Arıza, artık herhangi bir diske erişemeyen ve verilere erişilemez hale gelen bir sunucu disk denetleyicisi olabilir. Veya arıza, artık iki veya daha fazla sistemin iletişim kurmasını sağlamayan bir ağ anahtarı olabilir. Bu bağlamda, "tek hata noktası" veya SPOF, hizmet kullanılabilirliğini olumsuz etkileyen bir hatadır. Esnek bir altyapı, SPOF içermeyen altyapıdır.

"Ölçeklenebilir", sistemlerin ani talep artışlarını zarafetle karşılayabilme yeteneğini tanımlar. Ayrıca sistemlerde ne kadar kolay değişiklik yapılabileceğini de belirler. Örneğin, yeni bir kullanıcı eklemek, depolama kapasitesini artırmak veya bir altyapıyı Amazon Web Services'ten Google Cloud'a taşımak, hatta şirket içinde taşımak.

Altyapınız bir sunucunun ötesine geçer geçmez güvenliği, dayanıklılığı ve ölçeklenebilirliği artırmak için pek çok seçenek vardır. Bu sorunların geleneksel olarak nasıl çözüldüğüne ve büyük uygulama bilişiminin çehresini değiştiren hangi yeni teknolojinin mevcut olduğuna bakacağız.

Bugün neyin mümkün olduğunu anlamak için, teknoloji projelerinin geleneksel olarak nasıl uygulandığına bakmak faydalı olacaktır. Eski günlerde, yani 10 yılı aşkın bir süre önce, işletmeler, uygulamalarının tüm bileşenlerini çalıştırmak için donanım satın alır veya kiralarlardı. WordPress web sitesi gibi nispeten basit uygulamaların bile birden çok bileşeni vardır. WordPress söz konusu olduğunda, Apache gibi bir web sunucusu ve PHP kodunu kullanmanın bir yolu ile birlikte bir MySQL veritabanına ihtiyaç vardır. Böylece bir sunucu kurarlar, Apache, PHP ve MySQL kurarlar, WordPress'i kurarlar ve yola koyulurlar.

Genel olarak, bu işe yaradı. O kadar iyi çalıştı ki bugün hala tam olarak bu şekilde yapılandırılmış çok sayıda sunucu var. Ancak mükemmel değildi ve daha büyük sorunlardan ikisi dayanıklılık ve ölçeklenebilirlikti.

Direnç eksikliği, sunucudaki herhangi bir önemli sorunun hizmet kaybına neden olacağı anlamına geliyordu. Açıkça feci bir arıza, web sitesinin olmaması anlamına gelirdi, ancak web sitesini etkilemeden planlanmış bakım yapmak için yer de yoktu. Apache için rutin bir güvenlik güncellemesinin yüklenmesi ve etkinleştirilmesi bile web sitesi için birkaç saniyelik kesinti gerektirecektir.

Direnç sorunu, 'yüksek kullanılabilirlik kümeleri' oluşturularak büyük ölçüde çözüldü. İlke, web sitesini çalıştıran iki sunucuya sahip olmaktı ve bunlardan birinin arızalanması web sitesinin kapanmasına neden olmayacak şekilde yapılandırılmıştı. Sağlanan hizmet, bireysel sunucular olmasa bile dirençliydi.

Eğik nokta efekti

Ölçeklenebilirlik sorunu biraz daha zordur. Diyelim ki WordPress siteniz ayda 1.000 ziyaretçi alıyor. Bir gün Radyo 4'te veya Kahvaltı TV'de işinizden bahsedilir. Aniden, 20 dakika içinde bir aydan fazla ziyaretçi alırsınız. Hepimiz web sitelerinin 'çöktüğü' hikayelerini duyduk ve genellikle nedeni budur: ölçeklenebilirlik eksikliği.

Dayanıklılığa yardımcı olan iki sunucu, tek bir sunucunun yapabileceğinden daha yüksek bir iş yükünü yönetebilir, ancak bu yine de sınırlıdır. Zamanın yüzde 100'ünde iki sunucu için ödeme yapacaksınız ve çoğu zaman ikisi de mükemmel çalışıyordu. Muhtemelen tek başına sitenizi yönetebilir. Ardından John Humphrys, Today'de işletmenizden bahseder ve yükün üstesinden gelmek için 10 sunucuya ihtiyacınız olur - ama yalnızca birkaç saatliğine.

Hem dayanıklılık hem de ölçeklenebilirlik sorununa daha iyi çözüm bulut bilgi işlemdi. Amazon Web Services (AWS) veya Google Cloud'da bir veya iki sunucu örneği (uygulamalarınızı çalıştıran küçük sunucular) kurun ve örneklerden biri herhangi bir nedenle başarısız olursa, otomatik olarak yeniden başlatılır. Otomatik ölçeklendirmeyi doğru bir şekilde ayarlayın ve Mr Humphrys web sunucusu örneklerinizdeki iş yükünün hızla artmasına neden olduğunda, iş yükünü paylaşmak için ek sunucu örnekleri otomatik olarak başlatılır. Daha sonra, faiz düştükçe, bu ek örnekler durdurulur ve yalnızca kullandığınız kadar ödersiniz. Mükemmel… yoksa öyle mi?

Bulut çözümü, geleneksel bağımsız sunucudan çok daha esnek olsa da, hâlâ sorunlar var. Çalışan tüm bulut örneklerini güncellemek kolay değildir. Bulut için geliştirme yapmanın da zorlukları vardır: geliştiricilerinizin kullandığı dizüstü bilgisayar bulut örneğine benzer olabilir ancak aynı değildir. AWS'ye bağlı kalırsanız Google Cloud'a geçiş yapmak karmaşık bir iştir. Ve herhangi bir nedenle, bilgi işlemlerinizi Amazon, Google veya Microsoft'a devretmek istemediğinizi varsayalım.

Kapsayıcılar, uygulamaları tüm bağımlılıklarıyla birlikte her yerde çalıştırılabilen tek bir pakete sarmak için bir araç olarak ortaya çıktı. Docker gibi kapsayıcılar, geliştiricilerinizin dizüstü bilgisayarlarında bulut örneklerinizde çalıştıkları gibi çalışabilir, ancak kapsayıcı sayısı arttıkça bir kapsayıcı filosunu yönetmek giderek daha zor hale gelir.

Cevap, konteyner düzenlemesidir. Bu, odaklanmada önemli bir değişikliktir. Daha önce, iş yüküne hizmet verebilmemiz için, ister fiziksel ister sanal olsun, yeterli sunucumuz olduğundan emin olduk. Bulut sağlayıcıların otomatik ölçeklendirmesini kullanmak yardımcı oldu, ancak biz hala örneklerle uğraşıyorduk. Yük dengeleyicileri, güvenlik duvarlarını, veri depolamayı ve daha fazlasını manuel olarak yapılandırmamız gerekiyordu. Kapsayıcı orkestrasyonu ile tüm bunlar (ve çok daha fazlası) halledilir. İstediğimiz sonuçları belirliyoruz ve kapsayıcı düzenleme araçlarımız gereksinimlerimizi karşılıyor. Nasıl yapılmasını istediğimizi değil, ne yapılmasını istediğimizi belirtiriz.

Kubernete olun

Kubernetes (ku-ber-net-eez) günümüzün önde gelen konteyner düzenleme aracıdır ve Google'dan gelmiştir. Devasa ölçekli BT altyapılarının nasıl çalıştırılacağını bilen varsa, Google bilir. Kubernetes'in kökeni, arama motoru, Gmail, Google Haritalar ve daha fazlası dahil olmak üzere Google'ın uygulamalarının çoğunu çalıştırmak için hala kullanılan dahili bir Google projesi olan Borg'dur. Borg, Google 2015'te bununla ilgili bir makale yayınlayana kadar bir sırdı, ancak makale, Borg'un Kubernetes'in arkasındaki ana ilham kaynağı olduğunu açıkça ortaya koydu. 

Borg, Google'ın veri merkezlerindeki bilgi işlem kaynaklarını yöneten ve Google'ın hem üretim hem de diğer uygulamalarını donanım arızası, kaynak tükenmesi veya aksi halde bir kesintiye neden olabilecek diğer sorunlara rağmen çalışır durumda tutan bir sistemdir. Bunu, bir Borg "hücresini" oluşturan binlerce düğümü ve bunlar üzerinde çalışan kapları dikkatle izleyerek ve yükteki sorunlara veya dalgalanmalara yanıt olarak kapları gerektiği gibi başlatıp durdurarak yapar.

Kubernetes'in kendisi, Google'ın GIFEE ('Google'ın Herkes İçin Altyapısı') girişiminden doğmuştur ve Borg'un Google dışında yararlı olabilecek daha arkadaş canlısı bir sürümü olacak şekilde tasarlanmıştır. 2015 yılında Cloud Native Computing Foundation'ın (CNCF) kurulmasıyla Linux Foundation'a bağışlanmıştır.

Kubernetes, konteynerleştirilmiş uygulamalarınızı ve hizmetlerinizi "bildirdiğiniz" bir sistem sağlar ve uygulamalarınızın bu bildirimlere göre çalışmasını sağlar. Programlarınız depolama veya yük dengeleyiciler gibi dış kaynaklar gerektiriyorsa Kubernet'ler bunları otomatik olarak sağlayabilir. Yükteki değişikliklere ayak uydurmak için uygulamalarınızı yukarı veya aşağı ölçeklendirebilir ve hatta gerektiğinde tüm kümenizi ölçeklendirebilir. Programınızın bileşenlerinin nerede çalıştıklarını bilmelerine bile gerek yok: Kubernetes, uygulamalara "wp_mysql"e bağlanabilmeleri ve otomatik olarak doğru kaynağa bağlanabilmeleri için dahili adlandırma hizmetleri sağlar.'

Nihai sonuç, uygulamalarınızı tek bir makineden şirket içi sistemler rafına ve herhangi bir büyük bulut sağlayıcısında çalışan bulut tabanlı sanal makine filolarına kadar herhangi bir altyapı üzerinde çalıştırmak için kullanılabilecek bir platformdur. ve yapılandırma. Kubernetes sağlayıcıdan bağımsızdır: istediğiniz yerde çalıştırın.

Kubernet'ler güçlü bir araçtır ve zorunlu olarak karmaşıktır. Genel bir bakışa geçmeden önce, Kubernetes'te kullanılan bazı terimleri tanıtmamız gerekiyor. Konteynerler, yukarıda tartışıldığı gibi tek uygulamaları çalıştırır ve bölmeler halinde gruplanır. Bölme, aynı ana bilgisayarda birlikte dağıtılan ve bazı kaynakları paylaşan, birbiriyle yakından bağlantılı kapsayıcılar grubudur. Bir bölmedeki kaplar bir ekip olarak çalışır: uygulama kapsayıcısı ve uygulama için özel ayarlara sahip bir günlük kapsayıcısı gibi ilgili işlevleri yerine getirirler.

Dört temel Kubernetes bileşeni; API Sunucusu, Zamanlayıcı, Denetleyici Yöneticisi ve etcd adlı dağıtılmış bir yapılandırma veritabanıdır. API Sunucusu, Kubernetes'in merkezinde yer alır ve tüm yönetim istekleri için birincil uç nokta görevi görür. Bunlar, programlayıcı gibi diğer Kubernetes bileşenleri, komut satırı veya web tabanlı gösterge panoları aracılığıyla yöneticiler ve kapsayıcılı uygulamaların kendileri dahil olmak üzere çeşitli kaynaklar tarafından oluşturulabilir. İstekleri doğrular ve etcd'de saklanan verileri günceller.

Zamanlayıcı, kaynak gereksinimleri, herhangi bir donanım veya yazılım kısıtlaması, iş yükü, son tarihler ve daha fazlası gibi kısıtlamaları dikkate alarak çeşitli bölmelerin hangi düğümlerde çalışacağını belirler.

Denetleyici Yöneticisi kümenin durumunu izler ve kümeyi istenen duruma getirmek için API Sunucusu aracılığıyla bölmeleri başlatmaya veya durdurmaya çalışır. Ayrıca bazı dahili bağlantıları ve güvenlik özelliklerini de yönetir.

Her düğüm, API sunucusuyla iletişim kuran ve genellikle Docker kullanarak kapları yöneten bir Kubelet işlemini ve küme içinde ağ proxy'sini ve yük dengelemeyi yöneten Kube-Proxy'yi çalıştırır.

Etcd dağıtılmış veritabanı sistemi, adını Linux sistemlerinde sistem yapılandırma bilgilerini tutmak için kullanılan /etc klasöründen ve genellikle bir arka plan programı sürecini belirtmek için kullanılan 'd' sonekinden alır. etcd'nin hedefleri, anahtar/değer verilerini dağıtılmış, tutarlı ve hataya dayanıklı bir şekilde depolamaktır.

API sunucusu, tüm durum verilerini etcd'de tutar ve aynı anda birçok örneği çalıştırabilir. Zamanlayıcı ve denetleyici yöneticisi yalnızca bir etkin örneğe sahip olabilir, ancak hangi çalışan örneğin ana olduğunu belirlemek için bir kiralama sistemi kullanır. Tüm bunlar, Kubernetes'in tek bir hata noktası olmaksızın Yüksek Kullanılabilirlik düzeyine sahip bir sistem olarak çalışabileceği anlamına gelir.

Hepsini bir araya koy

Peki bu bileşenleri pratikte nasıl kullanırız? Aşağıda, Kubernet'leri kullanarak bir WordPress web sitesi kurmaya bir örnek verilmiştir. Bunu gerçekten yapmak isteseydiniz, muhtemelen dümen tablosu adı verilen önceden tanımlanmış bir tarif kullanırdınız. Bir dizi yaygın uygulama için kullanılabilirler, ancak burada bir WordPress sitesini Kubernetes üzerinde çalışır duruma getirmek için gerekli adımlardan bazılarına bakacağız.

İlk görev, MySQL için bir şifre tanımlamaktır:

kubectl create secret generic mysql-pass --from-literal=password=YOUR_PASSWORD

kubectl, komutu doğrulayacak ve ardından şifreyi etcd'de saklayacak olan API Sunucusu ile konuşacaktır. Hizmetlerimiz YAML dosyalarında tanımlanmıştır ve şimdi MySQL veritabanı için bir miktar kalıcı depolamaya ihtiyacımız var.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

Spesifikasyon çoğunlukla kendi kendini açıklayıcı olmalıdır. Ad ve etiket alanları, bu depolamaya Kubernetes'in diğer bölümlerinden, bu durumda WordPress kapsayıcımızdan atıfta bulunmak için kullanılır.

Depolamayı tanımladıktan sonra, önceden tanımlanmış depolamaya işaret ederek bir MySQL örneği tanımlayabiliriz. Bunu, veritabanının kendisini tanımlama takip eder. Bu veritabanına, Kubernetes içinde kolay başvuru için bir ad ve etiket veriyoruz.

Şimdi WordPress'i çalıştırmak için başka bir kaba ihtiyacımız var. Kapsayıcı dağıtım belirtiminin bir kısmı şöyledir:

kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  strategy:
    type: Recreate

"Yeniden Oluştur" strateji türü, uygulamayı oluşturan kodlardan herhangi birinin değişmesi durumunda çalışan örneklerin silinip yeniden oluşturulacağı anlamına gelir. Diğer seçenekler arasında, yeni örnekleri döngüye sokabilme ve mevcut örnekleri birer birer kaldırabilme, hizmetin bir güncellemenin dağıtımı sırasında çalışmaya devam etmesini sağlama yer alır. Son olarak, WordPress'in kendisi için PHP kodu ve Apache'den oluşan bir hizmet ilan ediyoruz. Bunu bildiren YAML dosyasının bir kısmı:

metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: LoadBalancer

Hizmet türünü LoadBalancer olarak tanımlayan son satırı not edin. Bu, Kubernetes'e hizmeti Kubernetes dışında kullanılabilir hale getirme talimatı verir. Bu satır olmadan, bu yalnızca dahili bir "Yalnızca Kubernetes" hizmeti olacaktır. Ve bu kadar. Kubernet'ler artık bu YAML dosyalarını neyin gerekli olduğunun bir beyanı olarak kullanacak ve kümeyi "istenen" duruma getirmek için gerektiği şekilde bölmeleri, bağlantıları, depolamayı vb. kuracak.

Bu, zorunlu olarak Kubernetes'e yalnızca üst düzey bir genel bakış olmuştur ve sistemin birçok ayrıntısı ve özelliği çıkarılmıştır. Otomatik ölçeklendirme (bir kümeyi oluşturan bölmeler ve düğümler), cron işleri (konteynırları bir programa göre başlatma), Giriş (HTTP yük dengeleme, yeniden yazma ve SSL boşaltma), RBAC (rol tabanlı erişim kontrolleri) konularını gözden geçirdik. , ağ politikaları (güvenlik duvarı) ve çok daha fazlası. Kubernetes son derece esnek ve son derece güçlüdür: herhangi bir yeni BT altyapısı için ciddi bir rakip olmalıdır.  

Kaynaklar

Docker'a aşina değilseniz buradan başlayın: https://docs.docker.com/get-started (yeni sekmede açılır) .

Burada bir uygulamayı dağıtma ve ölçeklendirmeyle ilgili etkileşimli bir öğretici var: https://kubernetes.io/docs/tutorials/kubernetes-basics (yeni sekmede açılır) .

Kümenin nasıl oluşturulacağını öğrenmek için https://kubernetes.io/docs/setup/scratch (yeni sekmede açılır) bölümüne bakın .

https://tryk8s.com (yeni sekmede açılır) adresinde ücretsiz bir Kubernetes kümesiyle oynayabilirsiniz .

Son olarak, Google'ın Borg kullanımına ve bunun Kubernetes tasarımını nasıl etkilediğine dair mükemmel bir genel bakış içeren uzun, teknik bir makaleyi buradan inceleyebilirsiniz: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf/43438.pdf (yeni sekmede açılır) .

Tiger Computing hakkında daha fazlasını öğrenin (yeni sekmede açılır) .

• 2020'nin en iyi çevrimiçi bulut depolaması: ücretsiz, ücretli ve iş seçenekleri