Serverless Mimaride Uygulama Deploy Etme

Serverless mimari, kullanıcının altyapıyı yönetmesine gerek kalmadan servis sağlayıcı tarafından çalıştırılan, kullanıcının kod yazdığı bir bulut bilişim türüdür.

Temel olarak Serverless, herhangi bir tür altyapı oluşturmak, sürdürmek, güncellemek, yükseltmek veya tedarik etmek zorunda kalmadan uygulamalar oluşturmak için bir yol sunar.

Bu yazımda sizlere serverless mimaride bir uygulamanın nasıl deploy edilebileceğinden bahsettim. Keyifli okumalar !

Serverless Uygulamalar

Serverless uygulamalar, bir route ve configuration tanımlanan ve bir YAML dosyasında oluşturulur ve dağıtılır. OpenShift Serverless kullanarak serverless bir uygulamayı dağıtmak için bir Knative Service.yamlnesnesi oluşturulmalıdır.

service.yaml örneği;

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello # uygulamanın ismi 
  namespace: default #uygulamanın kullandığı namespace ismi
spec:
  template:
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift # uygulamanın image'ı
          env:
            - name: RESPONSE # Örnek uygulama tarafından yazdırılan environment variable
              value: "Hello Serverless!"

Bir serverless uygulaması oluşturmanın 3 yolu vardır;

• OpenShift Container Platform web konsolundan bir Knative servisi oluşturulabilir.
• Knative (kn) CLI'yi kullanarak bir Knative servisi oluşturulabilir. (Bu adım için Knative CLI’ın yüklenip konfigüre edilmesi gerekir.)
• OpenShift (oc) CLI'yi kullanarak bir Knative nesnesini YAML dosyası olarak oluşturulup kullanılabilir.

Knative CLI üzerinden serverless uygulaması oluşturabilmek için kod örneği:

kn service create <service-name> --image <image> --tag <tag-value>

YAML kullanılarak serverless uygulaması oluşturabilmek için kod örneği:

YAML dosyasının bulunduğu dizine gidilerek aşağıdaki şekilde bir komut çalıştırılır.

oc apply -f <filename>

Init Container İçin Yapılandırma

Bir pod içerisinde birden fazla container çalıştırılabilir. Bunun en iyi örneği ise app containerlardan farklı olarak uygulama başlatılırken çalıştırılar init containerlardır. Init container, pod oluşturulduğunda app containerlardan önce oluşur yapması gereken işlemleri yapar ve sonra kapanır. Esas uygulama çalışmadan önce yapılması gereken bir işlev olduğu durumlarda kullanılırlar. Örneğin, bir uygulama çalışmadan önce güncelleme kontrolü yapılması gerekiyor olabilir ve bunu init container sayesinde gerçekleyebiliriz.

Not: Init containerlar uygulamanın başlama süresinin uzamasına sebep olabileceği için dikkatli kullanılmalıdır.

Örnek bir init container yapılandırması:

apiVersion: serving.knative.dev/v1
kind: Service
...
spec:
  template:
    spec:
      initContainers:
        - imagePullPolicy: IfNotPresent # image çekme politikası
          image: <image_uri> # init container için URL
          volumeMounts: # container dosya sistemi içinde mount edildiği konum
            - name: data
              mountPath: /data
...

Autoscaling (Otomatik Ölçeklendirme)

Knative Serving, uygulamalar için autoscaling sağlar. Örnek vermek gerekirse, eğer bir uygulama kullanıcıdan istek almıyorsa yani herhangi bir trafik yoksa Knative Serving uygulamayı 0’a ölçekleyebilir. Eğer sıfıra ölçeklenmesi istenmiyorsa min-scale değeri istenildiği şekilde ayarlanabilir.

Örnek bir min-scale yapılandırması:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0" # min scale sayısı
...

Eğer Knative CLI kullanılarak min-scale yapılandırılmak istenirse,

kn service create <service_name> --image <image_uri> --scale-min <integer>

Eğer bir uygulama için en fazla oluşturulacak replica sayısı (max-scale) belirlenmezse herhangi bir üst sınırı olmaz ve uygulamaya gelen istek sayısı arttıkça replica sayısında da artış görülür.

Örnek bir max-scale yapılandırması:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "10"
...

Eğer Knative CLI kullanılarak max-scale yapılandırılmak istenirse,

kn service create <service_name> --image <image_uri> --scale-max <integer>

Concurrency (Eş zamanlılık)

Bir uygulamaya gelen eşzamanlı istekler için bir limit uygulanabilir. Bu limitler soft limit veya hard limit olabilir.

Soft limit: Soft limit, hard limite bakılarak daha esnek olduğu söylenebilir. Örneğin uygulamada bir trafik yoğunluğu olduğu durumda belirlenen soft limit değerinde artış gerçekleştirilebilir.

Hard limit: Hard limit değerinin keskin sınırları vardır. Uygulamaya gelen trafik ne kadar artarsa artsın belirlenen hard limit seviyesinin üstüne çıkılamaz. Eğer bu seviyeye ulaşılırsa gelen istekler ara belleğe alınır ve limit değerinin düşmesi bekletilir. Boş kapasite sağlandığında ara bellekteki istekler devreye alınır.

Soft limit değeri için örnek yapılandırma:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "30"

Eğer Knative CLI kullanılarak soft limit yapılandırılmak istenirse,

kn service create <service_name> --image <image_uri> --concurrency-target <integer>

Hard limit değeri için örnek yapılandırma:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 50

Eğer Knative CLI kullanılarak hard limit yapılandırılmak istenirse,

kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

Concurrency Kullanımı:

Örneğin, bir uygulama için hard limit (containerConcurrency) değeri 10 ve target-utilization-percentage değeri 70 olarak ayarlanırsa;

• Bu uygulamanın replicalarında istek sayısı 7’ye ulaştığında yeni bir replika oluşturulur.
• İstek sayısı azaldıkça replica sayısında azalma gözlemlenir.

Örnek bir yapılandırma:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
...

Trafik Yönetimi

Trafik yönetimi, Knative üzerinde route’ın bir parçası olarak ele alınır. Bu sebeple trafik yönetimi için service.yaml altında route kısmını yapılandırmak gerekir. Uygulama yeni oluşturulduğunda default olarak bir traffic ayarına sahip değildir.

Trafik yönetimini ayarlayabilmenin 3 yolu vardır:

• Service.yaml içerisinde düzenleme yapılarak
• Knative CLI üzerinde — traffic komutu kullanılarak

kn service update <service_name> --traffic <revision>=<percentage>

• OpenShift Web Console üzerinden değiştirilerek

Örnek bir trafik yapılandırılması:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 50
  - tag: candidate
    revisionName: example-service-2
    percent: 50
  - tag: latest
    latestRevision: true
    percent: 0