PuppetConf 2016. Kubernetes for system administrators. Part 3

PuppetConf 2016. Kubernetes for system administrators. Part 1
PuppetConf 2016. Kubernetes for system administrators. Part 2

We take the Lobsters app and create a new image with new requirements. First, enter the deployment command $ kubectl apply –f deployments / lobsters.yaml and send the application to the cluster, which should perform rolling update update for each of the available application instances in accordance with the update policy. First, the system makes sure that each instance is operational, and then destroys them in the next set of containers.

Let’s see how it worked. To do this, we reload the site, and now the lack of white spots will make our marketer happy.

As a system administrator, you can say: “There are no HTTPS here, such sites are easy to hack, it’s dangerous!” How can this problem be solved? I think in its solution Kubernetes can act as a framework that allows the system administrator to implement a creative approach to work. It would be nice if I could declaratively say: “I want to get Let’s Encrypt certificate for this site, but I do not want to redeploy this container.” I want to do this within my capabilities, without resorting to the application development team for help. Kubernetes allows this, as it supports custom extensions.

I talked about kubectl, pods, deployments, services, but we also have custom types – custom resource types that can be obtained from Puppet. At Puppet, we can define new types, so that we can use this system for our work.
Let’s see how it looks in Kubernetes. First of all, we need an extension for certificates, this is how it looks. Here we have our own hightower.com namespace, in which the certified object is located.

We create a new extension in Kubernetes using the command $ kubectl create –f extensions / certificate.yaml, and the storage is automatically created in the backend and this state is managed.

The appearance of this new object requires me to use a new tool that tracks changes and takes action on the certificate object. That is, this tool in the background should interact with Let’s Encrypt and get a valid certificate. For this I use secret – I will show very quickly how this is done.

So, we need a new sub, and I will show what the difference is compared to the previous code. I am adding nginx to an existing container, so we don’t need to contact the development team. We continue to use HTTPS by simply placing the container at the very top of the existing hearth.

This container accepts HTTPS traffic and needs a configuration file to interact with the backend. I also need some certificates that nginx downloads from the file system, so environment variables don’t work here. I did not write nginx, so I can not get him to do this.

So I just add this container right inside the hearth and turn to two secrets.

The first and most important secret is the TLS certificate, which should come from Let’s Encrypt. I am not going to report Let’s Encrypt to my application, I am reporting it to my system. I want to control this abstraction. So now I have to create a config file for nginx. This is the main configuration file that looks like this.

Port 443 is specified here and SSL is enabled, which looks for these 2 files in the file system, captures traffic and sends it to the local host 127.0.0.1{000.

This is exactly what my application listens to. Now I will create configmap – the nginx configuration map using the following command.

Now, using the $ kubectl get configmaps command, I place the configmap “nginx” on the system with the same name as the disk.

Next, you need to create a secret, I remind you again – I want everything to be automated, and I do not want to interfere in the process of obtaining certificates. To do this, I am deploying a tool called “kube-cert-manager”, and here is the result.

We are trying to get a valid Let’s Encrypt certificate, which my browser will trust, and insert it into the backend as a secret. Therefore, for my hearth there will be no difference in the fact that we have supplemented its contents. If you remember, all this is done by creating a custom type in Puppet.

Perhaps this is a bad idea, but now I will try to start the controller, which will work in the background. We do not compile, we do not create providers, this daemon just works in the background and watches the changes. As soon as the certificate object appears, it receives it with Let’s Encrypt and inserts it into the system in real time without any delay. So, I use the following command.

This thing also has storage, so we can save everything we need. It takes a few seconds for the kube-cert-manager certification manager to start working.

The next thing we need to do is create a certificate object. This is what I define myself, this is my own scheme. I am creating a new thing that Kubernetes has not met up to this point, which says that I can get a certificate for the lobsters.com domain.

There is an email address and other information that is necessary for Let’s Encrypt to issue me a valid certificate. Let’s Encrypt will send me an exchange token to see if I really own this domain and I will need to apply this token to my DNS in Google Cloud. If the check passes, they will give me a real certificate, which I will insert into my file system. Let’s see how this works by entering the $ kubectl get pods command.

As you can see, the certificate manager is still working. Let’s see the detailed information about this process using the $ kubectl describe pods kube-cert-manager command, inserting the container name from the first line of code.

You see that the work is being done on schedule. At the moment, the server is creating a volume that, after checking and formatting, will be mounted on this server. While this process is ongoing, we can go further and finish our work.

I enter the kubectl create –f certificates / lobsters.yaml command and get the following result.

Next, I use a command that allows you to view the logs of several containers. I will highlight the one that relates to my object.

Now a DNS record is being created inside my cloud-based DNS server. If I refresh the page shown here, I will see a new exchange token with the extension .txt.

So, I received a token from Let’s Encrypt and now I verify that this DNS record has been distributed to all authorized servers before I tell Let’s Encrypt to check this text entry in my domain.

If this works, they will send me a valid certificate back. Real-time DNS demonstration is a bad idea. Yeah, we finally get the certificate. Let’s Encrypt noticed that the certificate disappeared from Kubernetes, and inserted it there. This is great, because now I already have a certificate request interface for everything that runs in Kubernetes.

To make sure everything is working correctly, I enter the $ kubectl get secrets command and we see one secret for lobsters.hightowerlabs.com.

Now I use the command $ kubectl delete secrets lobsters.hightowerlabs.com, because it is a declarative system, we do not delete the certificate object, but get rid of the secret associated with it located inside Kubernetes. As a result, we must make sure that when this element is deleted, the system will return the Let’s Encrypt certificate itself. This is very similar to what we do in Puppet, only here it happens online.

After making sure that everything works, we are redeploying our nginx application called “lobsters-secure”, which will ensure the security of the new domain. His image is similar to the previous version, but the difference is that we put nginx here. Nginx picks up the secrets link, then Kubernetes inserts it into the file system, as a result of which I get a valid certificate for a specific domain.

To do this, I enter the command $ kubectl apply –f deployments / lobsters-secure.yaml using the same name so that this command overwrites the existing state. Next, the $ kubectl get pods command is used, which shows that rolling rolling update is happening here now, as our definitions have changed.

After the update is completed, it is clear that the new definition is used for this application. I want to make sure the certificate is valid for our DNS name, for which I enter the command $ kubectl get svc and copy the IP address of the lobsters site.

By going to the Google Cloud tab, you can see that this address matches the address corresponding to the domain name lobsters.hightowerlabs.com. Now, if you type in the address bar of the browser lobsters.hightowerlabs.com, you can see that we have a valid certificate.

Thank you, that’s all I wanted to say in the Kubernetes for System Admins report.

A bit of advertising 🙂

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to your friends, cloud VPS for developers from $ 4.99, A unique analogue of entry-level servers that was invented by us for you: The whole truth about VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps from $ 19 or how to divide the server? (options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

Dell R730xd 2 times cheaper at the Equinix Tier IV data center in Amsterdam? Only here 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – from $ 99! Read about How to Build Infrastructure Bldg. class c using Dell R730xd E5-2650 v4 servers costing 9,000 euros for a penny?

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *