We deploy Kubernetes on the desktop in minutes with MicroK8s
- Tutorial
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 predlaget utility Minikube . 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 full list of extensions can be obtained with the command
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 executing the command
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:
After that, the welcome page of Django 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
10 February 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 full list of extensions can be obtained with the command
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-containerdetermines 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 executing the command
microk8s.kubectl get all. 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
After that, the welcome page of Django 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
10 February 2019