We deploy Kubernetes on the desktop in minutes with MicroK8s
Getting started with Kubernetes is not always easy. Not everyone has the infrastructure necessary for deploying a full-fledged cluster of Kubernetes. For local work, Kubernetes offers the Minikube utility. Minikube is quite a simple and convenient tool, and there are several training courses on working with Minikube. But, nevertheless, you can’t say about Minikube that with the help of this utility, you can deploy Kubernetes environment in a few minutes.
Today I want to talk about the package MicroK8s , which, without exaggeration, allows you to deploy Kubernetes locally in a few minutes, and begin development. Even pre-installed Docker and Kubernetes are not required, since all inclusive. In the lesson offered to you, the deployment of the Django application in the local Kubernetes environment will be reviewed.
As a source, I followed the series of articles by Mark Gituma , which described similar work, but only with Minikube, and not with MicroK8s.
Yet there is one requirement that must be met before starting work. You need to have Snap installed, which in turn means that you need to have Linux installed.
Installation of MicroK8s is described in the manual on the site . However, this is just one line:
Further, it may be necessary to start the environment:
Next, you need to activate the extension. A complete list of extensions can be obtained with the
As you can now conclude on the list of extensions, you will have access to many services, including the dashboard and metrics.
Create a Dockerfile to create an image:
and the file with the necessary requirements.txt dependencies:
Let's collect an image. You do not need a pre-installed Docker, because It comes with MicroK8s:
If you are assembling an image of an earlier installed docker, it may be not enough for you to simply assemble the image, and also send it to the local registry, which also comes with MicroK8s, and works on port 32000:
Most likely this step will not be needed, but for completeness I pointed to it, and at the same time I paid your attention that you have a local docker registry.
The basic building block of Kubernetes is the Pod (Pod), in which the container runs (most often one but maybe several). Pods can be created by various means. But today we are interested in Deployment. The deployment describes the pattern by which Pods are created. Deployment is determined using configuration files in yml format. In the Deployment configuration, you specify the number of Pod replicas and the image from which this Pod and its replicas will be collected, as well as the port (port 8000 on which Django works from Dockerfile - no magic):
The depot loads on Wednesday with the command:
In parallel, you can run a command that will monitor the actions occurring during deployment:
Now you have several Pov with Django applications that you do not have access to. In order for Pody to communicate with each other and with the outside world, there is another abstraction - the Service. A service, like Deployment, is defined by a configuration file:
The selector
After downloading, the Service can be accessed at the internal network address. If you run the command
Having executed the curl command (or having opened the browser) we will receive a welcome Django page:
There are two commented lines in the Service configuration. If you uncomment them, the service will additionally be accessible from the external network via a random port in the range of 32000 and higher.
In order to get a permanent address for the Service, by which it will be possible to contact from the external network, MicroK8s offers a choice of two options 1) ingress and 2) istio. The easiest way to implement using ingress. If not yet activated, then you need to activate the ingress component:
After that, you can make sure that this component is installed and working by running the
The name default-http-backend is the predefined name in MicroK8s. It is for this name that you need to refer to this service in ingress configurations.
Ingress configurations let you know the configurations of a web server or a proxy server, and somewhere inside the system, they are. Therefore, they contain hosts, paths, and ports — all attributes that are well known:
The ingress configuration is loaded with the command:
Then the Django welcome page will be available at localhost / django
That's all for today.
Useful links:
1. github.com/apapacy/microk8s-tut
2. medium.com/@markgituma/kubernetes-local-to-production-with-django-2-docker-and-minikube-ba843d858817
apapacy@gmail.com
February 10, 2019
Today I want to talk about the package MicroK8s , which, without exaggeration, allows you to deploy Kubernetes locally in a few minutes, and begin development. Even pre-installed Docker and Kubernetes are not required, since all inclusive. In the lesson offered to you, the deployment of the Django application in the local Kubernetes environment will be reviewed.
As a source, I followed the series of articles by Mark Gituma , which described similar work, but only with Minikube, and not with MicroK8s.
Yet there is one requirement that must be met before starting work. You need to have Snap installed, which in turn means that you need to have Linux installed.
Installation of MicroK8s is described in the manual on the site . However, this is just one line:
sudo snap install microk8s --classic Further, it may be necessary to start the environment:
sudo microk8s.start Next, you need to activate the extension. A complete list of extensions can be obtained with the
microk8s.enable --help : dashboard, dns, gpu, ingress, istio, metrics-server, registry, storage. Immediately you can activate everything except gpu and istio, because the first of them requires a pre-installed driver, and the second essentially upgrades the environment and (personally, on my weak desktop) loads the system heavily. microk8s.enable dashboard dns ingress metrics-server registry storage As you can now conclude on the list of extensions, you will have access to many services, including the dashboard and metrics.
Create a Dockerfile to create an image:
FROM python:3-slim LABEL maintainer="mark.gituma@gmail.com" WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt RUN django-admin startproject mysite /app EXPOSE 8000 STOPSIGNAL SIGINT ENTRYPOINT ["python", "manage.py"] CMD ["runserver", "0.0.0.0:8000"] and the file with the necessary requirements.txt dependencies:
celery==4.1.0 Django==2.0 kombu==4.1.0 Let's collect an image. You do not need a pre-installed Docker, because It comes with MicroK8s:
microk8s.docker build django -t apapacy/tut-django:1.0.0 If you are assembling an image of an earlier installed docker, it may be not enough for you to simply assemble the image, and also send it to the local registry, which also comes with MicroK8s, and works on port 32000:
microk8s.docker tag apapacy/tut-django:1.0.0 localhost:32000/apapacy/tut-django:1.0.0 microk8s.docker push localhost:32000/apapacy/tut-django:1.0.0 Most likely this step will not be needed, but for completeness I pointed to it, and at the same time I paid your attention that you have a local docker registry.
The basic building block of Kubernetes is the Pod (Pod), in which the container runs (most often one but maybe several). Pods can be created by various means. But today we are interested in Deployment. The deployment describes the pattern by which Pods are created. Deployment is determined using configuration files in yml format. In the Deployment configuration, you specify the number of Pod replicas and the image from which this Pod and its replicas will be collected, as well as the port (port 8000 on which Django works from Dockerfile - no magic):
apiVersion: apps/v1beta2 kind: Deployment metadata: name: django labels: app: django spec: replicas: 2 selector: matchLabels: pod: django-container template: metadata: labels: pod: django-container spec: containers: - name: django-web image: localhost:32000/apapacy/tut-django:1.0.0 ports: - containerPort: 8000 The depot loads on Wednesday with the command:
microk8s.kubectl apply -f config/deployment.yml In parallel, you can run a command that will monitor the actions occurring during deployment:
watch microk8s.kubectl get all Now you have several Pov with Django applications that you do not have access to. In order for Pody to communicate with each other and with the outside world, there is another abstraction - the Service. A service, like Deployment, is defined by a configuration file:
kind: Service apiVersion: v1 metadata: name: django-service spec: selector: pod: django-container ports: - protocol: TCP port: 8000 # targetPort: 8001 type: ClusterIP # type: NodePort The selector
pod: django-container determines which Deployment will be serviced by the Service (the selector name “pod” is not predefined - this is just a label that must match). The service is loaded in the same way as Deployment: microk8s.kubectl apply -f config/service.yml After downloading, the Service can be accessed at the internal network address. If you run the command
microk8s.kubectl get all , you can see this address: service/django-service ClusterIP 10.152.183.156 none 8000/TCP 3h33m Having executed the curl command (or having opened the browser) we will receive a welcome Django page:
curl 10.152.183.156:8000 There are two commented lines in the Service configuration. If you uncomment them, the service will additionally be accessible from the external network via a random port in the range of 32000 and higher.
In order to get a permanent address for the Service, by which it will be possible to contact from the external network, MicroK8s offers a choice of two options 1) ingress and 2) istio. The easiest way to implement using ingress. If not yet activated, then you need to activate the ingress component:
microk8s.enable ingress After that, you can make sure that this component is installed and working by running the
microk8s.kubectl get all command. In the list of applications and services should appear several entries with the name default-http-backend . In particular, a service running on port 80 should appear: service/default-http-backend ClusterIP 10.152.183.42 none 80/TCP 179m The name default-http-backend is the predefined name in MicroK8s. It is for this name that you need to refer to this service in ingress configurations.
Ingress configurations let you know the configurations of a web server or a proxy server, and somewhere inside the system, they are. Therefore, they contain hosts, paths, and ports — all attributes that are well known:
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: tut-django annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: backend: serviceName: default-http-backend servicePort: 80 rules: - host: localhost http: paths: - path: /django backend: serviceName: django-service servicePort: 8000 The ingress configuration is loaded with the command:
microk8s.kubectl apply -f config/ingress.yml Then the Django welcome page will be available at localhost / django
That's all for today.
Useful links:
1. github.com/apapacy/microk8s-tut
2. medium.com/@markgituma/kubernetes-local-to-production-with-django-2-docker-and-minikube-ba843d858817
apapacy@gmail.com
February 10, 2019
Source: https://habr.com/ru/post/439734/