Win a copy of Terraform in Action this week in the Cloud forum!

Aly Saleh

Author
+ Follow
since Sep 08, 2021
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
2
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Aly Saleh

Hi Kumar,

Thanks for your questions! I will try to give you brief answers to them, and I will highlight if deeper research from your side is needed especially when the questions may not have enough context.

#1: It depends on your application architecture. The most common approach is 1 container/pod and multiple pods/node, however, this approach assumes your app follows micro/macro services architecture or is very similar to that. Other approaches such as single container/pod/node can be useful when you have a monolithic app. I rarely see a solid use case for multi-container in a single pod, if we exclude the side-car container architecture, we will not find that many use cases for a pod with multiple containers.

#2: Load balancing happens on different layers, it depends on your network architecture and which types of load balancers that you use. API Gateways does mean to do load balancing. In typical AWS architecture, you either go with NLB (layer 3) or ALB (layer 7). Kubernetes itself has its own logic to route requests to the right k8s service but we can’t consider it a load balancer.
You need either AWS LB or another external LB, or to deploy a load balance inside your cluster.

#3: Kubernetes does not have a built-in option for that, you need to deploy a service to do that, either Redis pods, or a similar solution.

#4: Ideally you delegate these services to a service mesh like Istio.



2 months ago
Hi Greg,

Thank you for sharing your question about the book and service meshes. In our book, we do not cover service mesh, not because they are not important, but because we believe they are not essential best practices for production, and the majority of companies using K8s are not utilizing service meshes to avoid operational complexity.

When it comes to service mesh, I would recommend doing an analysis whether you need it or not based on your application architecture and needs, if you come with a positive decision about service mesh, then you still need to evaluate Istio against simpler options such as Envoy, because Istio is more complex and you may not need all of the features that provide (always think about the cost of operations when you introduce new technology to your stack).

Cheers!
Aly
2 months ago
Hi SM,

Congrats on your transition to DevOps! It is an excellent decision.

Kubernetes is a cornerstone in DevOps and Cloud world, and you definitely should learn it. I can't give you an exact learning path for DevOps, but Kubernetes should be something that you should learn immediately after public cloud foundations and general CICD knowledge.

As for our book, It is one of few books that were written based on real-life experiences from real projects on productions, and it has very essential knowledge for any DevOps and cloud engineer who will be dealing with production on K8s. However, it is not an introductory book to K8s, and to gain the full benefit from the book (which by the way covers other areas for DevOps like IaC with Terraform) is to go through beginners guide at https://kubernetes.io/ then start reading the book.


Best of Luck!

-Aly
2 months ago
Thank you, M.Khalid for your nice words! We hope you like the book.

The motivation to write a full book about this topic is mainly coming from the authors' experience and learned lessons (hard lessons). Murat and I went through good and bad experiences dealing with Kubernetes in production over the past few years, so we found that a book about this topic will save a lot of time for others who are starting their production journey with Kubernetes.

We have to admit that Kubernetes is like a monster when you use it for your production workloads, starting from cost management, security, resources management, updateability, disaster recovery, and high availability and uptime. Each of these areas has its own challenges with k8s, and our book provides a guide through these areas and is equipped with best practices hands-on and design ideas that are coming from our world-class engineering.
2 months ago
Hi Omer,

Although Kubernetes is considered one of the advanced topics in the cloud technologies domain, it is also becoming the defacto platform for deployments, and as a software engineer, you will deal with it in a way or another. My advice is to try to build your knowledge about the public cloud besides your main job in software development, start by learning the foundation of a public cloud such as AWS, Azure, or GCP, and then containers and K8s. I would say basic knowledge is enough unless your company requires advanced knowledge. You can install Minikube locally and try to do few deployments to it, and get the feel of containers and k8s deployments. The official Kubernetes documentation has good (https://kubernetes.io/docs/tutorials/kubernetes-basics/) for beginners, I recommend going through them.


Cheers,

Aly
2 months ago
Hi German,

We use EKS in our book "Kubernetes in Production Best Practices", but the book is not about EKS, we used it because we needed our users to use one of the common managed k8s services, but there is nothing specific to EKS. The best practices and design guidelines, and even most of the implementations are transferable to any other k8s distribution.


Cheers,

Aly
2 months ago
Hi Greg,

Your question was my motivation to start writing my book when I tried to answer it a year ago. There is no short answer to the question, however, I covered the foundational best practices that are common for most of the applications types that are running on k8s (especially SaaS apps).

As you mentioned one of the most challenging areas for SaaS apps is multi-tenant management and isolation. From my experience which I summarized in chapter 2 in my book is your strategy in handling your cluster decomposition. There are two main approaches here, first is the hard isolation which you can gain by hosting each tenant on its own cluster, this approach is more secure but less common due to cost and operational overhead reasons, the other approach is using a shared cluster with soft isolation using namespaces, this approach is the most common one but it requires hardening cluster security by enabling cluster RBAC across the cluster and at namespace-level, in addition to enforcing resources limits/quotas per namespace and down to the pod-level, adding network policies with Calico to block communication between namespaces by default, and finally having a policy gateway.
In addition to the security best practices mentioned in chapter 6 of the book, such as deploying Falco for security runtime monitoring, executing automated security tests, and periodically scan the cluster for security misconfiguration or vulnerabilities.
2 months ago
I am Aly co-author of “Kubernetes in Production Best Practices”. I am looking forward for your questions about this book during this week.

Cheers!
3 months ago