Kubernetes Deployment File

Giri
Bazı notlarım şöyle

Deployment Nedir?
Açıklaması şöyle. Kaç tane Pod istediğimizi belirtiriz.

Although pods are the basic unit of computation in Kubernetes, they are not typically directly launched on a cluster. Instead, pods are usually managed by one more layer of abstraction: the deployment.
A deployment’s primary purpose is to declare how many replicas of a pod should be running at a time. When a deployment is added to the cluster, it will automatically spin up the requested number of pods, and then monitor them. If a pod dies, the deployment will automatically re-create it.

Pod ve Service Registry

Açıklaması şöyle

“Service” in Kubernetes serves the purpose of service discovery. If I deploy service with the name as name:shoppingcart-service and selector as app:shoppingcart-service-pod , all the pods having this as a label will be considered as a set of available pods for the shoppingcart-service .

The controller for the service selector continuously scans for pods that match its selector app:shoppingcart-service and then post any updates to an endpoint object also named shoppingcart-service. Kubernetes assigns this endpoint an IP address. The service is also associated with a DNS name.

Kubernetes provides in-built health check options, where it keeps a check on the health of all the available pods. If a pod is found unhealthy, it deregisters it from the list of service pods.

Örnek

Şöyle yaparız

apiVersion: extensions/v1beta1
kind: Deployment                                          # 1
metadata:
  name: sa-frontend
spec:
  selector:                                               # 2
    matchLabels:
      app: sa-frontend  
  replicas: 2                                             # 3
  minReadySeconds: 15
  strategy:
    type: RollingUpdate                                   # 4
    rollingUpdate: 
      maxUnavailable: 1                                   # 5
      maxSurge: 1                                         # 6
  template:                                               # 7
    metadata:
      labels:
        app: sa-frontend                                  # 8
    spec:
      containers:
        - image: rinormaloku/sentiment-analysis-frontend
          imagePullPolicy: Always                         # 9
          name: sa-frontend
          ports:
            - containerPort: 80

Açıklaması şöyle

1. Kind: A deployment.

2. Selector: Pods matching the selector will be taken under the management of this deployment.

3. Replicas is a property of the deployments Spec object that defines how many pods we want to run. So only 2.

4. Type specifies the strategy used in this deployment when moving from the current version to the next. The strategy RollingUpdate ensures Zero Downtime deployments.

5. MaxUnavailable is a property of the RollingUpdate object that specifies the maximum unavailable pods allowed (compared to the desired state) when doing a rolling update. For our deployment which has 2 replicas this means that after terminating one Pod, we would still have one pod running, this way keeping our application accessible.

6. MaxSurge is another property of the RollingUpdate object that defines the maximum amount of pods added to a deployment (compared to the desired state). For our deployment, this means that when moving to a new version we can add one pod, which adds up to 3 pods at the same time.

7. Template: specifies the pod template that the Deployment will use to create new pods. Most likely the resemblance with Pods struck you immediately.

8. app: sa-frontend the label to use for the pods created by this template.

9. ImagePullPolicy when set to Always, it will pull the container images on each redeployment.

Deployment Örnekleri

metadata/name Alanı

Kubernetes tarafından kullanılan deployment ismini belirtir

Örnek

Şöyle olsun

apiVersion : apps/v1
kind: Deployment
metadata:
  name: simple-app-deployment
...

Şöyle yaparız

kb get deployment
NAME			READY	UP-TO-DATE	AVAILABLE	AGE
simple-app-deployment	2/2	2		2		2m23s

spec/replicas Alanı

ReplicaSet Nedir
Açıklaması şöyle. spec/replicas altında belirtilir

Bir poddan kaç tane olacağını replicaset ile belirtiyoruz. İstediğiniz anda bir pod’u kesintisiz bir şekilde scale edebilir yada azaltabiliriz.

Örnek
Şöyle yaparız

apiVersion: apps/v1
kind: Deployment
metadata:
  name: springbootmongodb
  labels:
    app: springbootmongodb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springbootmongodb
  template:
    metadata:
      labels:
        app: springbootmongodb
    spec:
      containers:
      - name: springbootmongodb
        image: mytest/springbootmongodb
      - name: mongo
        image: mongo

Pod ile Docker imajını eşleştirmek için 

deployment tanımındaki spec/template/metadata/labels/app ile 

kind:Service tanımındaki spec/selector/app

alanları kullanılır

Örnek

Şöyle yaparız. Deployment alanında kullanılacak container belirtiliyor. imaj ismi marounbassam/hello-spring

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: hello-world
        visualize: "true"
    spec:
      containers:
      - name: hello-world-pod
        image: marounbassam/hello-spring
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  labels:
    visualize: "true"
  name: hello-world-service
spec:
  selector:
    app: hello-world
  ports:
  - name: http
    protocol: TCP
    port: 8080
    targetPort: 8080
  type: ClusterIP

İki tane pod elde ederiz

+---------------------+
| hello-world-service |
|                     |
|    10.15.242.210    |
+---------O-----------+
          |
          +-------------O--------------------------O
                        |                          |
              +---------O-----------+    +---------O-----------+
              |        pod 1        |    |        pod 2        |
              |                     |    |                     |
              |     hello-world     |    |     hello-world     |
              +---------------------+    +---------------------+

containers

Açıklaması şöyle

describes the container’s specification like the name, the image and the exposed port.

containers/livenessProbe

Açıklaması şöyle

Among its many components, the Kubelet ensures that the containers are running and replaced with a healthy instance, anytime it goes down. This is detected using two properties:

- Liveness Check: An endpoint indicating that the application is available. The Kubelet uses liveness probes to know when to restart a container.

- Readiness Check: The Kubelet uses readiness probes to know when a container is ready to start accepting traffic.

Örnek

Şöyle yaparız

apiVersion: apps/v1 
kind: Deployment
...
        livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 5
        readinessProbe:  
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

containers/imagePullPolicy Alanı

Açıklaması şöyle.

The default pull policy is IfNotPresent which causes the kubelet to skip pulling an image if it already exists. If you would like to always force a pull, set it to Always

Açıklaması şöyle.

This option comes in handy if you deploy your application too often (Typical use case is CI/CD).

Örnek

Şöyle yaparız. Burada  webcenter/activemq isimli registry'den activemq eğer zaten indirilmemişse, indiriliyor.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: queue
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: queue
    spec:
      containers:
      - name: web
        image: webcenter/activemq:5.14.3
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 61616
        resources:
          limits:
            memory: 512Mi

Örnek
Şöylee yaparız

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
    - name: image-name
      image: my-image:0.0.1
      imagePullPolicy: Always # <<--here

containers/readinessProbe

Örnek

Şöyle yaparız

apiVersion: v1
kind: Namespace
metadata:
  name: demo-ns
---
apiVersion: v1
kind: Pod
metadata:
  name: worker
  namespace: demo-ns
  labels:
    app: nine-to-five
spec:
  containers:
    - name: nine-to-five
      image: nine-to-five:1.0.0
      ports:
        - name: health-check
          containerPort: 5000
          hostPort: 5000
      readinessProbe:
        tcpSocket:
          port: health-check
        initialDelaySeconds: 5
        failureThreshold: 2
        timeoutSeconds: 3
        periodSeconds: 10
      livenessProbe:
        tcpSocket:
          port: health-check
        initialDelaySeconds: 15
        failureThreshold: 2
        timeoutSeconds: 3
        periodSeconds: 20

containers/resources

Şöyle yaparız

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world2-deployment
  labels:
    app: hello-world2
spec:
  selector:
    matchLabels:
      app: hello-world2
  replicas: 2
  template:
    metadata:
      labels:
        app: hello-world2
    spec:
      containers:
      - name: hello-world2
        image: bhargavshah86/kube-test:v0.1
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: 256Mi
            cpu: "250m"
          requests:
            memory: 128Mi
            cpu: "80m"

sshpass komutu - Login To SSH Server

-e seçeneği

Örnek

Şöyle yaparız

sshpass -V
export SSHPASS=$CI_USER_PASS
sshpass -e scp -o StrictHostKeyChecking=no
  target/gitlab-ci-demo.jar gitlab-ci@167.172.188.139:/home/gitlab-ci

sshpass -e ssh -tt -o StrictHostKeyChecking=no
  gitlab-ci@167.172.188.139 sudo mv /home/gitlab-ci/gitlab-ci-demo.jar /opt/java/webapps

sshpass -e ssh -tt -o StrictHostKeyChecking=no
  gitlab-ci@167.172.188.139 sudo systemctl restart gitlab-ci-demo.service

-p seçeneği

Örnek
Şöyle yaparız

sshpass -p $pass scp  ...