Articles

When you’re running a relatively small cluster, you might get away with having no structure in place for it. But with time, your cluster will inevitably scale to dozens of pods and hundreds of containers. If you keep running them carefree, you’ll deal with a mess sooner rather than later. Here’s your golden ticket to get out of this chaos: Kubernetes namespace.

By keeping your cluster organized with namespaces, labels, and annotations, you’ll avoid the performance, maintenance, and security issues that come together in a package with the lack of control over the deployed objects and services.

Source de l’article sur DZONE

Any typical enterprise-grade application deployed on Kubernetes comprises several API resources that need to be deployed together. For example, the WordPress application, which is one of the example applications available on the Kubernetes GitHub repository, includes:

  • a wordpress frontend pod,
  • a wp-pv-claim persistent volume claim mounted to the frontend pod,
  • a wordpress-mysql MySQL database pod,
  • a mysql-pv-claim persistent volume claim mounted to the MySQL database pod,
  • two persistent volumes: wordpress-pv-1 and wordpress-pv-2 to serve the persistent volume claims,
  • services for the database and frontend pods.

Application (or app) is not a native construct in Kubernetes. However, managing applications is the primary concern of the developers and operations. Application delivery on Kubernetes involves upgrading, downgrading, and customizing the individual API resources. Kubernetes allows you to restrict the spread of your application resources through namespaces such that you can deploy an entire app in a namespace that can be deleted or created. However, a complex application might consist of resources spread across namespaces, and in such cases answering the following questions might be a challenge:

Source de l’article sur DZONE

In this blog post, we will follow up the "Linux Namespaces and Go Don’t Mix" post, and we will show how the problem mentioned in the previous post was resolved in the recent release of Go 1.10.

Problem

To recap, the main problem was that the Go runtime did not allow us to safely change a local state of an OS thread ("M" in the Go notation) scheduling a goroutine, even if the thread had been locked with runtime.LockOSThread.

Source de l’article sur DZONE