#kubernetes
9 posts

Why Kubernetes is the new application server

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.
Read more

Why Kubernetes is the new application server

  • 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

Tips for building and managing containers

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.
Read more

Tips for building and managing containers

  • 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

The two most important challenges with an API gateway when adopting Kubernetes

Encourage a diversity of implementations for consolidated tooling that supports architectural flexibility. However, take advantage of a consolidated underlying platform and offer a ‘buffet’ of implementation options rather than allowing developers to build bespoke ones for better security.
Read more

The two most important challenges with an API gateway when adopting Kubernetes

  • When building an API gateway using a microservices pattern that runs on Kubernetes, you must think about scaling the management of hundreds of services and their associated APIs and ensuring the gateway can support a broad range of microservice architectures, protocols and configurations across all layers of the edge stack.
  • The challenges of managing the edge increase with the number of microservices deployed, which also means an increased number of releases, so it is best that you avoid a centralized approach to operations and let each team manage their services independent of other teams’ schedules.
  • Encourage a diversity of implementations for consolidated tooling that supports architectural flexibility. However, take advantage of a consolidated underlying platform and offer a ‘buffet’ of implementation options rather than allowing developers to build bespoke ones for better security. This is a more manageable and scaleable approach too.

Full post here, 5 mins read

Kubernetes deployment strategies

The standard for Kubernetes is rolling deployment, replacing pods of previous versions with the new one without cluster downtime. Kubernetes probes new pods for readiness before scaling down old ones, so you can abort deployment without bringing down the cluster.
Read more

Kubernetes deployment strategies

  • The standard for Kubernetes is rolling deployment, replacing pods of previous versions with the new one without cluster downtime. Kubernetes probes new pods for readiness before scaling down old ones, so you can abort deployment without bringing down the cluster.
  • In a recreate deployment, all old pods are killed at once and replaced with new ones.
  • A blue/green or red/black deployment offers both old and new versions together with users having access only to green (old version) while your QA team applies test automation to the blue (new version). Once the blue passes, the service switches over and scales down the green version.
  • Canary deployments are similar to blue/green but use a controlled progressive approach, typically when you want to test new functionality on the backend or with a limited subset of users before a full rollout.
  • Dark deployments or A/B testing are similar to canary deployment but used for front-end rather than backend features.

Full post here, 5 mins here

Will Kubernetes fall into the “shiny things” trap?

New & shiny can also mean immature. Developers must be cautious about excessive reliance on new technologies. Do not ask simply how to leverage Kubernetes at scale, ask how to use a single abstraction to cover Kubernetes.
Read more

Will Kubernetes fall into the “shiny things” trap?

  • New & shiny can also mean immature.
  • Developers must be cautious about excessive reliance on new technologies.
  • Do not ask simply how to leverage Kubernetes at scale, ask how to use a single abstraction to cover Kubernetes, on-premises visualization and the entire IT landscape.
  • To be cloud-native, you may need to rewrite your existing tech as containerized microservices.
  • Build your version for full compatibility with other vendors instead of complete portability and abstraction across environments.

Full post here, 6 mins read