• Skip to primary navigation
  • Skip to main content
Alexandre Vazquez
  • Home
  • TIBCO
    • TIBCO BusinessWorks
    • Flogo
    • TIBFAQS
  • Architecture
    • API
    • Security
    • Integration
    • Event Processing
  • Kubernetes
  • Monitoring
    • Observability
    • Prometheus
    • Log Aggregation
      • Loki
  • Service Mesh
    • Istio
  • Helm
  • Editorial
  • About Me

EKS Hybrid Series: Changing namespaces of serverless deployment

Published on 2020-10-25. Last Updated on 2022-05-09 by Alexandre Vazquez

Eks Hybrid Series: Changing Namespaces Of Serverless Deployment
Photo by Tanner Boriack on Unsplash

In the previous post of these series regarding how to set up a Hybrid EKS cluster making use of both traditional EC2 machines but also serverless options using Fargate, we were able to create the EKS cluster with both deployment fashion available. If you didn’t take a look at it yet, do it now!

https://medium.com/@alexandrev/hybrid-aws-kubernetes-cluster-using-eks-ec2-and-fargate-13198d864baa

At that point, we have an empty cluster with everything ready to deploy new workloads, but we still need to configure a few things before doing the deployment. First thing is to decide which workloads are going to be deployed using the serverless option and which ones will use the traditional EC2 option.

By default, all the workloads deployed on the namespaces default and kube-system as you can see in the picture below form the AWS Console:

Eks Hybrid Series: Changing Namespaces Of Serverless Deployment

So that means that all workloads from the default namespace and the kube-system namespace will be deployed in a serverless fashion. If that’s what you’d like perfect. But sometimes you’d like to start with a delimited set of namespaces where you’d like to use the serverless option and rely on the traditional deployment.

We can check that same information using eksctl and to do that we need to type the following command:

eksctl get fargateprofile --cluster cluster-test-hybrid -o yaml

The output of that command should be something similar of the information that we can see in the AWS Console:

- name: fp-default
 podExecutionRoleARN: arn:aws:iam::938784100097:role/eksctl-cluster-test-hybrid-FargatePodExecutionRole-1S12LVS5S2L62
 selectors:
 — namespace: default
 — namespace: kube-system
 subnets:
 — subnet-022f9cc3fd1180bb8
 — subnet-0aaecd5250ebcb02e
 — subnet-01b0bae6fa66ecd31

NOTE: If you don’t remember the name of your cluster you just need to type the command eksctl get clusters

So, this is what we’re going to do and to do that the first thing we need to do is to create a new namespace named “serverless” that is going to hold our serverless deployment and to do that we use a kubectl command as follows:

kubectl create namespace serverless

And now, we just need to create a new fargate profile that is going to replace the one that we have at the moment and to do that we need to make use again of eksctl to handle that job:

eksctl create fargateprofile --cluster cluster-test-hybrid --name fp-serverless-profile --namespace serverless

NOTE: We also can use not only namespace to limit the scope of our serverless deployment but also tags, so we can have in the same namespace workloads that are deployed using traditional deployment and others using serverless fashion. That will give us all the posibilities to design your cluster as you wish. To do that we will append the argument labels in a key=value fashion.

And we will get an output similar to this:

[ℹ] creating Fargate profile “fp-serverless-profile” on EKS cluster “cluster-test-hybrid”
[ℹ] created Fargate profile “fp-serverless-profile” on EKS cluster “cluster-test-hybrid”

If now we check the number of profiles that we have available we should get two profiles handling three namespaces (the ones that are managed by the default profile — default and kube-system — and the one — serverless — handled by the one we just created now)

We just will use the following command to delete the default profile:

eksctl delete fargateprofile --cluster cluster-test-hybrid fp-default

And the output of that command should be similar to this one:

[ℹ] deleted Fargate profile “fp-default” on EKS cluster “cluster-test-hybrid”

And after that, we have now ready our cluster with limited scope for serverless deployments. In the next post of the series, we will just deploy workloads on both fashions to see the difference between them. So, don’t miss the updates regarding this series making sure that you follow my posts, and if you’d like the article, or you have some doubts or comments, please leave your feedback using the comments below!

If you find this content interesting please think about making a contribution using the button below to keep this content updated and increased!


Related articles:

Eks Fargate: Hybrid Kubernetes Aws ClusterEKS Fargate: Hybrid Kubernetes AWS cluster Kubernetes Autoscaling: Learn How To Scale Your Kubernetes Deployments DynamicallyKubernetes Autoscaling: Learn How to Scale Your Kubernetes Deployments Dynamically Brown And Beige Weighing ScaleScale To Zero And From Zero in Your Kubernetes Cluster Integrating Istio With Bwce ApplicationsIntegrating Istio with BWCE Applications

Copyright © 2023 · Custom on Genesis Framework · WordPress · Log in