Tips for managing containers & designing microservices for failure

#todayilearned #kubernetes #microservices #architecture

TL;DR notes from articles I read today.

Curate a set of Docker base images for your container because these base images can be reused as many apps share dependencies, libraries, and configurations. Docker Hub and Google Container Registry have thousands of pre-configured base images for download.
However, don’t trust arbitrary base images. always use a vulnerability scanner - incorporate static analysis into your pipeline and run it for all your containers. If you do find a vulnerability, rebuild your base image and don’t just patch it, then redeploy the image as immutable.
Optimize your base image, starting with the leanest most viable one and build your packages on that to reduce overheads, to build faster, use less storage, pull images faster, and minimize the potential surface of attack.
Use only one (parent) process per container. As a rule, each container should have the same lifecycle as the app itself.
Avoid embedding secrets inside containers, even if you keep the images private. For security, use Kubernetes Secrets objects to store sensitive data outside containers, use the Secrets abstraction to expose them as mounted volumes inside containers or as environmental variables.

Full post here, 7 mins read

70% of the outages are caused by changes in code. Reverting code is not a bad thing. Implementing change management strategies and automatic rollouts become crucial.
Architectural patterns and techniques like caching, bulkheads, circuit breakers, and rate-limiters can help build reliable microservices.
Self-healing can help recover an application. You should add extra logic to your application to handle edge cases.
Failover caching can help during glitches and provide the necessary data to your application.
You should use a unique idempotency key for each of your transactions to help with retries.
You can protect resources and help them to recover with circuit breakers. Circuit breakers usually close after a certain amount of time, giving enough space for underlying services to recover.
Use chaos engineering methods to test.

Full post here, 11 mins read

Figuring out how to connect to a service is easy and available out of the box with Kubernetes. You get configuration information from the runtime environment without it having to be hardcoded in the application.
Kubernetes ensures reliability and availability for your applications by providing elasticity through ReplicaSets, which control the number of app replicas that should run at any time.
As Kubernetes run many replicas of the containerized application and auto-scales too, logging and monitoring become even more important than usual scenarios. And for this purpose, it has observability built-in. An important thing to note is that you must store your logs outside the container to ensure they are persistent across different runs.
Kubernetes is resilient. It ensures that your specified number of pod replicas are consistently deployed across the cluster. This automatically handles any possible node failures.

Full post here, 12 mins read