K
Q

Elastic Kubernetes Service AWS Deployment process to avoid down time

3/14/2020

Its been a month I have started working on EKS AWS and up till now successfully deployed by code. The steps which I follow for deployment are given below:

  1. Create image from docker terminal.
  2. Tag and push to ECR AWS.
  3. Create the deployment "project.json" and service file "project-svc.json".
  4. Save the above file in "kubectl/bin" path and deploy it with following commands below.
  5. "kubectl apply -f projectname.json" and "kubectl apply -f projectname-svc.json".
  6. So if I want to deployment the same project again with change, I push the new image on ECR and delete the existing deployment by using "kubectl delete -f projectname.json" without deleting the existing service and deploy it again using command "kubectl apply -f projectname.json" again.

Now, I'm in confusing that after I delete the existing deployment there is a downtime until I apply or create the deployment again. So, how to avoid this ? Because I don't want the downtime actually that is the reason why I started to use the EKS. And one more thing is the process of deployment is a bit long too. I know I'm missing something can anybody guide me properly please?

The project is on .NET Core and if there is any simplified way to do deployment using Visual Studio please guide me for that also.

Thank You in advance!

-- Fahad
amazon-web-services
docker
eks
kubernetes

Similar Questions

How to get OIDC provider (keycloak)configuration with the endpoint details?
kudeadm k8s cluster on azure
In Istio, service to service communication, does Kubernetes service required to setup?
kubernetes resources and controllers

2 Answers

3/14/2020

There is actually no need to delete your deployment. Just need to update the desired state (the deployment configuration) and let K8s do its magic and apply the needed changes, like deploying a new version of your container.

If you have a single instance of your container, you will experience a short down time while changes are applied. If your application supports multiple replicas (HA), you can enjoy the rolling upgrade feature.

Start by reading the official Kubernetes documentation of a Performing a Rolling Update.

-- Eldad Assis
Source: StackOverflow
3/15/2020

You only need to use the delete/apply if you are changing (And if you have) the ConfigMap attached to the Deployment. Is the only change you do is the "image" of the deployment - you must use the "set-image" command.

Kubectl let you change the actual deployment image and it does the Rolling Updates all by itself and with 3+ pods you have the minimum chance for downtime. Even more, if you use the --record flag, you can "rollback" to your previous image with no effort because it keep track of the changes.

You also have the possibility to specify the "Context" too, with no need to jump from contexts.

You can go like this:

kubectl set image deployment DEPLOYMENT_NAME DEPLOYMENT_NAME=IMAGE_NAME --record -n NAMESPACE

OR Specifying the Cluster

kubectl set image deployment DEPLOYEMTN_NAME DEPLOYEMTN_NAME=IMAGE_NAME_ECR -n NAMESPACE --cluster EKS_CLUSTER_NPROD --user EKS_CLUSTER --record

As an Eg:

kubectl set image deployment nginx-dep nginx-dep=ecr12345/nginx:latest -n nginx --cluster eu-central-123-prod --user eu-central-123-prod --record

The --record is what let you track all the changes, if you want to rollback just do:

kubectl rollout undo deployment.v1.apps/nginx-dep

More documentations about it here:

Updating a deployment https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment

Roll Back Deployment https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment

-- b4ld
Source: StackOverflow