Vector vs Keyword Search: Why You Should Care
Search has been around for a while, to the point that it is now considered a standard requirement in many ...
Senior Machine Learning Engineer
Search has been around for a while, to the point that it is now considered a standard requirement in many ...
Senior Machine Learning Engineer
It’s no secret that B2B (business-to-business) transactions have largely migrated online. According to Gartner, by 2025, 80 ...
Sr. SEO Web Digital Marketing Manager
Twice a year, B2B Online brings together industry leaders to discuss the trends affecting the B2B ecommerce industry. At the ...
Director of Product Marketing & Strategy
This is Part 2 of a series that dives into the transformational journey made by digital merchandising to drive positive ...
Benoit Reulier &
Reshma Iyer
Get ready for the ride: online shopping is about to be completely upended by AI. Over the past few years ...
Director, User Experience & UI Platform
Remember life before online shopping? When you had to actually leave the house for a brick-and-mortar store to ...
Search and Discovery writer
If you imagine pushing a virtual shopping cart down the aisles of an online store, or browsing items in an ...
Sr. SEO Web Digital Marketing Manager
Remember the world before the convenience of online commerce? Before the pandemic, before the proliferation of ecommerce sites, when the ...
Search and Discovery writer
Artificial intelligence (AI) is no longer just the stuff of scary futuristic movies; it’s recently burst into the headlines ...
Search and Discovery writer
Imagine you are the CTO of a company that has just undergone a massive decade long digital transformation. You’ve ...
CTO @Algolia
Did you know that the tiny search bar at the top of many ecommerce sites can offer an outsized return ...
Director, Digital Marketing
Artificial intelligence (AI) has quickly moved from hot topic to everyday life. Now, ecommerce businesses are beginning to clearly see ...
VP of Product
We couldn’t be more excited to announce the availability of our breakthrough product, Algolia NeuralSearch. The world has stepped ...
Chief Executive Officer and Board Member at Algolia
The ecommerce industry has experienced steady and reliable growth over the last 20 years (albeit interrupted briefly by a global ...
CTO @Algolia
As an ecommerce professional, you know the importance of providing a five-star search experience on your site or in ...
Sr. SEO Web Digital Marketing Manager
Hashing. Yep, you read that right. Not hashtags. Not golden, crisp-on-the-outside, melty-on-the-inside hash browns ...
Search and Discovery writer
We’re just back from ECIR23, the leading European conference around Information Retrieval systems, which ran its 45th edition in ...
Senior ML Engineer
Your grandfather wears those comfy slipper-y shoes all day, every day, and they’re starting to get holes in ...
Sr. SEO Web Digital Marketing Manager
Jan 22nd 2022 engineering
We started using Kubernetes almost four years ago. We had new services to deploy, and even if we’re big users of bare metal machines, we needed more flexibility. Therefore, we decided to test and use Kubernetes on new systems. Two years later, most of our products are deployed on Kubernetes, following Kubernetes best practices. As more and more teams started to use it internally, we created an internal training. And today, we’re proud to make this training open source, so anyone can learn from it and contribute.
Two years into our implementation, we extracted eight practices from this training that we consider to be key for using Kubernetes correctly. We’re republishing these Kubernetes best practices as a blast from the past and to lay the foundation for future articles on how we and Kubernetes have grown over the last two years.
The container paradigm, and the way it’s implemented on Linux, wasn’t built with security in mind. It only exists to restrict resources, such as CPU and RAM, like the documentation of Docker explains. This implies that your container shouldn’t use the “root” user to run commands. Running a program in a container is almost the same as running a program on the host itself. If you are interested in knowing more, check this article to understand why.
Thus, add those lines on all your images to make your application run with a dedicated user. Replace “appuser” with a name more relevant for you.
ARG USER=appuser # set ${USER} to be appuser addgroup -S ${USER} && adduser -S ${USER} -G ${USER} # adds a group and a user of it USER ${USER} # set the user of the container WORKDIR /home/${USER} # set the workdir to be the home directory of the user
This can also be ensured at the cluster level with pod security policies.
Kubernetes sends the “SIGTERM” signal whenever it wants to gracefully stop a container. You should listen to it and react accordingly in your application (by closing connections, save a state, etc.) In general, following the twelve-factor app recommendations for your application is considered good practice. Also, don’t forget to configure terminationGracePeriodSeconds
on your pods. The default is 30 seconds, but your application might need more (or less) time to properly terminate.
Use declarative manifests so you can rollback your code and infrastructure efficiently. It means that your source versioning should be the source of truth of your manifests.
It implies that you only use kubectl apply
to update or create your Kubernetes resources, but also that you don’t use the latest
tag for your image containers. Each version of your containers should be unique, and using Git hashes is a good practice. When deploying a new version of your application, you should update the manifest by specifying a new version for the containers, then commit the manifest in your source control, and finally run kubectl apply
.
YAML is a tricky format. We use yamllint, because it supports multi-documents in a single file.
You can also use Kubernetes-specifics linters:
In Kubernetes 1.13, the --dry-run
option appeared on kubectl
which lets Kubernetes check your manifests without applying them. You can use this feature to check if your YAML files are valid for Kubernetes.
Liveness and readiness are ways for an application to communicate its health to Kubernetes. Configuring both helps Kubernetes handle your pods correctly, and react accordingly to state change.
The liveness probe is here to assess whether if a container is still alive; meaning, if the container is not in a broken state, a deadlock, or anything similar. From there, it can take decisions such as restarting it.
The readiness probe is here to detect if a container is ready to accept traffic, block a rollout, influence the Pod Disruption Budget (PDB), etc. It’s particularly useful when your container is set to receive external traffic by Kubernetes (most of the time, when it’s an API).
Usually, having the same probe for readiness and liveness is acceptable. In some cases though, you might want them to be different. A good example is a container running a single-threaded application that accepts HTTP calls (like PHP). Let’s say you have an incoming request that takes a long time to process. Your application can’t receive any other request, as it’s blocked by the incoming requests; therefore it’s not “ready”. On the other hand, it’s processing a request, therefore it’s “alive”.
Another thing to keep in mind, your probes shouldn’t call dependent services of your application. This prevents cascading failure.
Kubernetes lets you configure “requests” and “limits” of the resources for pods (CPU, RAM and disk). Configuring the “requests” helps Kubernetes schedule your pods more easily, and better pack workloads on your nodes.
Most of the time you could define "request" = "limit"
. But be careful, as your pod will be terminated if it goes above the limit
.
Unless your applications are designed to use multiple cores, it is usually a best practice to keep the CPU request at "1"
or below.
When you deploy an application with a lot of replicas, you most probably want them to be evenly spread across all nodes of the Kubernetes cluster. If you have all your pods running on the same node, and this node dies, this will kill all your pods. Specifying a pod anti-affinity for your deployments ensures that Kubernetes schedules your pods across all nodes.
A good practice is to specify a podAntiAffinity
on the hostname of the node:
apiVersion: apps/v1 kind: Deployment metadata: name: my-application spec: replicas: 2 selector: matchLabels: app: my-application template: metadata: labels: app: my-application spec: containers: - name: my-pod image: my-image:my-version affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - app: my-deployment topologyKey: kubernetes.io/hostname
Here we have a deployment “my-application” with two replicas, and we specify a podAntiAffinity
specification with a soft requirement (preferredDuringSchedulingIgnoredDuringExecution
, see here for more details), so we don’t schedule the pods on the same hostname (topologyKey: kubernetes.io/hostname
).
In Kubernetes, pods have a limited lifespan and can be terminated at any time. This phenomenon is called a “disruption”.
Disruptions can either be voluntary or involuntary. Involuntary disruptions means, as its name suggests, that it wasn’t something anyone could expect (a hardware failure for example). Voluntary disruptions are initiated by someone or something, like the upgrade of a node, a new deployment, etc.
Defining a “Pod Disruption Budget” helps Kubernetes manage your pods when a voluntary disruption happens. Kubernetes will try to ensure that enough that match a given selector are remains available at the same time. Specifying a PDB improves the availability of your services.
Four years ago, we used these fine defaults, and we apply them on all our apps in Kubernetes. We recommend you adapt your practices based on the specifics of your applications and workload.
You can find more details on these good practices on the dedicated section of the training.
Staff Software Engineer
Powered by Algolia Recommend