Author Archives: vmknowledge

Cehennem’in Dümeni

Evet başlık biraz Hollywood filmleri gibi oldu, başrolde Harrison Ford beklentisi 🙂 ancak bu makalede tek anlatmak istediğim K8s üzerine uygulama yönetimi için kullanılan araçlardan biri olan Helm‘e bir giriş yapmak.

Helm, Kubernetes için geliştirilmiş bir paket yöneticisi, uygulamaları K8s üzerine kurmak, güncellemek, gerektiğinde silmek, bunları paylaşmak için kullanılıyor.

Linux kullanıcıları için Centos’da yum, Ubuntu’da apt gibi veya Docker Hub gibi herkesin paylaşıp uygulamaları kuracağı bir repo’su var Helm Hub. Helm paket formatına chart deniyor.

K8s üzerinde bir uygulama kurmak için öncelikle bir deployment.yaml, uygulamayı dışarıdan erişilebilir kılmak için service.yaml dosyasına ek olarak belki birtakım değerleri değişkenlerle set etmek için variable.yaml , configMap ve secrets bilgilerine ihtiyacımız olacak , işte Helm bize bütün bunların birleştirerek bir şablon oluşturmamızı ve bunun güncellenebilir, tekrar kullanılabilir, hatta paylaşabilir kılıyor.

Read the rest of this entry

RKE ile Kubernetes Kurulumu

Akşamın 11:00’i tam Star Trek Enterprise izlerken aklımda dolaşan RKE ile bu K8s kurulumu nasıl yapılıyor diye bir bakamak istedim.

Çok iyi bilmiyorum RKE’yi fakat K8s kurulumu için çok yöntem olduğunu biliyorum kubeadm, kubesprey, kops her birinin farklılıkları mevcut, destekledikleri hyperscaler adledilen sağlayıcılara göre, K8s Control Plane’i HA kurmalarına göre, otomasyon araçları kullanmaları ve birbirlerini kapsadıklarına göre.

RKE nedir diye baktığımda, bu opsiyonların üzerine daha basit, daha hızlı bir kurulum sağladığını söylüyor, sadece tek bir çalıştırılabilirle ki adı “rke” yeterli, fakat sizden tek istediği şey, modern bir Linux dağıtımı ve yine modern bir Docker dağıtımı, RKE eski modayı sevmiyor 🙂

Daha hızlı bir kurulum çünkü Rancher tüm servisleri Dockerize yapmış, bilenler için aynı Openstack Kolla-Ansible ile Openstack kurmak gibi. İlgili imajları cluster.yaml oluşturduğunuzda “system image” kısmında görebilirsiniz.

Hemen mayalamaya başlıyorum macOS üzerinde RKE için , makinemi workstation olarak kabul edin. Yine bu makine üzerinde K8s’i yönetmek için kubectl ve üzerine Rancher UI kurmak için aynı zamanda helm’de kurulu olduğunu varsayın.

Vahrics-MacBook-Pro:~ vahricmuhtaryan$ brew install rke
Vahrics-MacBook-Pro:~ vahricmuhtaryan$ rke -version
rke version v1.1.1

Bu kuracağım K8s kümesini HA mode’da kurmaya çalışacağım, fazlası için buraya (Implementation Notes) bakabilirsiniz.

Read the rest of this entry

Certificate is not always cause vCloud Director WebMKS Console “disconnect” issue

vCloud Director VM Console or WebMKS disconnect issue is not always about certificate, IP address of console proxy and port or Chrome issue 🙂

Don’t forget vCloud Director will try to establish connection to vSphere hosts via port tcp 902, check your firewall and connectivity first.

To debug, check the console-proxy file under the /opt/vmware/vcloud-director/logs folder.

For remember ;

  • global.properties file will help you to check out console proxy and vCD IP address, if you are using vCD Appliance there is always single IP address will be !
  • global.properties file will help you to check the port of console-proxy
  • if you are using load balancer in front of vCD, for console proxy there is an option like consoleproxy.external.address to describe LB IP address

VM

vCD 9.7, vCloud Director Appliance, Database High Availability ve repmgr

vCloud Director 9.5 ile beraber “vCD Cell” leri artık birer appliance olarak OVF formatında indirip kurabiliyorduk. Gereksinimler arasında dışarıdan ortak bir veritabanına (MSSQL ve PostgreSQL) , paylaşımlı disk alanına (NFS) ve birde mesaj kuyruk uygulamasına (RabbitMQ) gereksinim vardı.

vCD 9.7 ile beraber MSSQL veritabanı için artık ileride opsiyon dışı kalacağı ve OVF formatında gelen yeni vCD appliance üzerinde PostgreSQL gömülü olarak geldiği, hatta yedeklilik veya yüksek devamlılık kapsamında desteğinin olduğu yayınlandı (Bakınız sayfa 7) hatta ve hatta MSSQL’den PostgreSQL’e göç dahi mevcut.

Not : Zaten yıllardır VMware’in inatla Windows üzerine vCenter, MSSQL ve Oracle gibi DB zorlamalarının nedenini anlayamamış, halada standart işler için ekstra bir özelliğini kullanmayıp MSSQL ısrarında olup, maliyetten şikayet eden firmaları anlayamadığım gibi !

Daha önceki Linux üzerine yapılan vCD Cell kurulumlarında iki adet sertifika yaratmanız gerekiyordu, biri UI diğeride Proxy Console için, şimdi ise biz kurulumu vCD Appliance olarak yapacağımızdan self-signed sertifikalar üretilmiş gelecek, sadece UI ve PC için değil aynı zamanda vCD’nin PostgreSQL’e yine sertifika ile bağlanacak, sonra bu sertifikaları elinizdeki bir sertifika otoritesi tarafından imzalanmış olanla değiştirebileceğiz.

Read the rest of this entry

BGP ve NSX-T T0 Router’ı Provider Router’a Bağlamak

NSX-T ile beraber dinamik routing protokollerindede, yapıdada bir sadeleşme oldu. Artık OSPF veya IS-IS gibi protokoller, Logical Router Control VM’ler yok. Tek haşır neşir olacağımız BGP ve VRF ki VRF’lede bizim görünürde aktif olarak üzerinde yaptığımız bir şey yok.

Sistemciler için kısa bir özet geçelim BGP hakkında ;

*Not: Belirtilenlerin genel olarak BGP’i anlamak, birtakım terimlerden uzak kalmamak için yazılmıştır.
*Not : Aşağıdaki resimler açıklamalarda kullanılacaktır.

Resim 1
Read the rest of this entry

Daha yeni, daha yardım sever :) , GUI’si değişmiş :( , yeni Policy API’li NSX-T 2.4.1

Her versiyon yapılan GUI değişiklikleri aslında çok da iyi bişey değil gibi geliyor bana, insan bir interface’e alışıyor sonra birden hersey değişiyor, sizde kendinizi yeniden adapte etmek zorunda kalıyorsunuz.

Daha önceden NSX-T Manager ile üç adet Controller kuruyorduk, artık bu iki rolü birleştirmişler 😀 Artık bir VM kardayız. NSX-T Manager’ı kurduğunuzda ilk controller’ıda kurmuş oluyorsunuz.

Eksikleri anında görüp 🙂 sizi yönlendirmeye başlıyor, örneğin elimizde üç adet NSX-T Controller olması lazım bunu için hemen “Deploy Nodes” ‘a basıyoruz, bizi hemen yeni ekleyeceğimiz ekrana yönlendiriyor.

Read the rest of this entry

1500 MTU NSX-T Ortamında BAŞınıza Nasıl Dert AÇAbilir kİ ?!

Evet, daha önceki makalelerimde belirttiğim, ama böylede çalışıyor dediğim MTU konusunda baltayı taşa nasıl vurmuş olduğumu göstermek istedim.

Güzel güzel ping atabilirkene 1600 – 1500 sadece 100 birimlik bir fark fregmantasyonda nasıl bu kadar derin etki yapabilirdi ki ?

Bunu okuyan networkçü arkadaşlarımın aklından neler geçiyor acaba, hepsinde bin tane MTU problemi hikayesi vardır !

yum update sizlere ömür …

Gördüğünüz gibi “yum update” sırasında network bağlantı hatları alıyorsunuz, metadata dosyalarının index ve checksum dosyasını tutan repomd.xml’i bile indiremiyorum !!

Şimdi gerekli MTU değerini düzeltelim bakalı neler oluyor 😀

Hersey istediğimiz gibi …

NSX-T Edge Node kendi üzerinde enkapsülasyon yaptığı için bağlı olduğu vSwitch’de ilgili VSS veya VDS’de ve üzerinde koştuğu ESXi host’un bağlı olduğu switch port’larda MTU 9000 olarak set edilmeli ki bu tip durumlarla karşılaşılmasın.

VM

PKS’e (Pivotal Container Service) Başlarken

Çılgınlığın hali -Container-, adı ise -Kubernetes-, namı değer K8s.
Google Borg system dediler, Yunancadan çevirisi “helmsman of a ship” dediler, development CNCF’e verildi, CNCF’ide TMSF’e benzetiyorum bir zamanların Apache Software Foundation’ı gibi parlıyor.

Herkes tuttu bir yerinden, Public Cloud Sağlayıcıları AKS, EKS, GKE sonra Rackspace, DigitalOcean’lar sonra Heptio, Platform9, Rancher Lab gibi firmalar derken rakip yazılımlar bile örneğin Docker “App Scheduler” olarak “Swarm” mı yoksa “K8s” mi kullanacaksın diye soruyor, Mesosphere DC/OS benimle K8s kur diyor, bana göre PaaS dediğimiz Cloud Foundry, Openshift’ler bile tam kalbine koydular K8s kendilerinin benzer yapıları olmasına rağmen. Yani K8s bir rockstar, herkeste onunla resim çektirmek istiyor diyebiliriz.

PaaS servislerini inceleyen, bilen, kullananlar aslında şu soruyu sorabilirler kendilerine 😀 K8s’in yapıpta CF/PCF’nin, Openshift’in yapamadığı nedir diye ?! Angela Chin’e de soruyorlar bu soruyu dakka 18:30.

Read the rest of this entry

Kısa Kısa NSX-T Datacenter Tasarım, Kurulum, Ortamın Hazırlanması

Öncelikle bu makaleyi okurken eğer takıldığınız bişey olur ise bir önceki makaleye bir göz atmanızı tavsiye ederim.

Bu makalenin sonunda NSX-T için gerekli olan ortamı hazırlamış ve bir sonraki adıma geçmek için yani T0 Router, T1 Router, Provider ile BGP, Distributed veya Edge FW, Load Balancer , Logical Switch , PKS , vCD testlerine hazır hale geleceksiniz.

Hemen başlayalım ….

Fiziksel alt yapıdan başlarsak, “underlay” bağımsız sadece çalışır ip bağlantısı ve doğru mtu değerleri ile (ki yanlış MTU değerlerindede çalışıyor 😀 ) hatta başka bir SDN yapısı üzerine bile NSX-T kurulup çalıştırabilirsiniz.

Underlay olarak dizayn bağımsız bir şekilde en son networkcülerin hayali Layer 3 (Leaf and Spine) veya eski yöntemlerle Layer 2 tabanlı MLAG veya Cisco ACI üzerinde bile koşabilir. Okumak isterseniz Layer 2/3 ve NSX on Cisco ACI dökümanına ilgili linklerden ulaşabilirsiniz.

Read the rest of this entry

Virtual Cloud Network ve NSX Datacenter (NSX-T)

Bu makalenin amacı sadece ve sadece pratik olarak NSX-T hakkında bilgi vermek, şu ana kadar NSX-T ile uğraşmamış, yeni uğraşacaklar veya NSX-V bilgisi olanlar, NSX-V ile arasındaki farkları bilmek isteyenler için flash hızında ne olup, ne bittiğini neyi nasıl ne şekilde yapılabileceği bununla beraber yine sadece NSX-T hakkında değil ama NSX-T ile beraber kullanacağınız bir takım gereksinimler içinde bilgiler buluyor olacaksınız.

Hemen başlayalım, VMware için “Virtual Cloud Network”  NSX tabanlı sadece NSX-T değil birden fazla bileşen içeren bir yapı ki bu bileşenler NSX Datacenter (NSX-T/NSX-V), SD-WAN, App Defence, NSX Cloud ve Hybrid Connect.

VMware için bu kol oldukça önemli, bunu Saurabh Shah’ın VMworld NET1549BU oturumunda dediği gibi ; 
    -Bu VMware için bir geçiş, ana işi sanallaştırma ve belli başlı networking özelliklerine sahip olan bir firmadan, müşterilerin networking konusunda yaşadığı önemli zorlukları adresleyecek ve dijital dönüşümü destekleyecek bir network çözüm firmasına doğru olan geçiş.

Bu aynı zamanda benim gibi sistemci arkadaşlarım ve networkçü arkadaşlarım içinde benzer geçişlerin olacağını ve bununda hızlanacağının göstergesi. Bizlerde değişeceğiz, sistemcilerin daha çok BGP, VRF bilmemiz gerekecek, networkcü arkadaşların NSX özelinde ilgili bileşenleri bilmek, kendilerini python, ansible, terraform hatta AWS, Azure özellinde geliştirmeleri gerekecek, iki gurup yeri gelecek ileride birleşecek.

Read the rest of this entry