Many applications hosted in a Docker container need a volume to store data on or to read from. The data can’t be stored in the Docker container itself because the data will be lost after a restart or when the container crashes. Persistent Storage has an independent lifecycle of a Pod. This blogposts shows the most used possibilities to use persistent storage using Kubernetes on Azure.
This blogpost was not possible without the help of Andreas Lindeboom, my Xebia colleague of XITA. Thanks!
In case of problems with a node of a Kubernetes cluster you probably want to read the logfiles on a Node of the Kubernetes Cluster, as described here. This Kubernetes cluster is created with Azure Container Service (ACS).
When using multiple Kubernetes clusters on Azure Container Service, I see people executing the az acs kubernetes get-credentials command every time they need to reconnect to a different cluster. This works, but is not needed. You can do it easier.
I was getting a bit tired of typing the kubectl command everytime. To solve this and only type k instead of kubectl, it’s possible to add an alias to Windows.
What if you can configure your infrastucture with a process that requests your SSL Certificates automatic. Not only this, but this process registeres the certificates in your infrastructure also. There is more. The process also requests new versions of certificates every 30 days so the certificate will not expire. All of this, complely automated. It’s even completely free! You or your traditional ops department won’t believe this is possible.
Enter the new world of infrastructure: Kube-Lego, ofcourse hosted on Kubernetes.
Now I hear you think: “This is to good to be true. It must be hard to configure”. The configuration is really easy actually, as you will see in this blogpost.
Logging in .NET Core 2 is made really easy.
There is a generic logger implementation which logs to the Console and to Application Insights by default. You only have to configure the instrumentationkey like this: