Shulou(Shulou.com)06/01 Report--

How to carry out minikube deployment local mirror practice and K8s network architecture analysis, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

A K8s environment is built with minikube in the WSL2 of windows10, but every time it pulls the image is slow or even fails (the reason is well understood). The principle of this scheme is that first pull the image on the host to the local image, and then pull the local image by the K8s in the minikube virtual machine. This can solve the previous failure to pull the image, and can also improve the speed of pulling the image.

Two schemes

Build a private image warehouse docker registry on the host, and K8s pulls the image from the local host

Push the local image to minikube's private image repository, and K8s pulls the image from minikube's private image repository (K8s's local private image repository)

1. Build an image

A complete image usually contains the application itself, the operating system and, of course, the dependent software needed.

First prepare an application. Create a new text file, named app.py, and write the following to implement a simple web application:

From flask import Flaskimport socketimport osapp = Flask (_ _ name__) @ app.route ('/') def hello (): html = "Hello {name}!"\ "hostname: {hostname}" return html.format (name=os.getenv ("NAME", "world"), hostname=socket.gethostname () if _ _ name__ = "_ _ main__": app.run (host='0.0.0.0', port=8082)

In this code, a Web server is started using the Flask framework, and its only function is: if there is an environment variable "NAME" in the current environment, print it after "Hello", otherwise print "Hello world", and finally print out the hostname of the current environment.

The dependency file requirements.txt for this application exists in the same directory as app.py, and the content is as follows:

$cat requirements.txtFlask

To run such an application in a container, you need to make a container image. Docker uses the Dockerfile file to describe the process of building the image. In this article, the Dockerfile content is defined as follows:

The # FROM directive specifies that the basic image is python:3.6-alpine, which contains the Alpine Linux operating system and the python3.6FROM python:3.6-alpine# WORKDIR instruction to change the working directory to / appWORKDIR / app# ADD instruction to copy all the contents (app.py, requirements.txt) under the current directory to the ADD in the / app directory of the image. / app# RUN instruction runs pip command installs dependent RUN pip install-I https://pypi.tuna.tsinghua.edu.cn/simple-r requirements.txt# EXPOSE directive exposes port 8082 EXPOSE 808 ENV directive that is allowed to be accessed by the outside world sets environment variable NAMEENV NAME World# CMD directive sets the process in the container as: python app.py, that is, the startup command CMD of this Python application ["python", "app.py"]

Many instructions are used in this Dockerfile, including FROM, WORKDIR, ADD, RUN, EXPOSE, ENV and CMD. The specific meaning of the instruction has been written in the Dockerfile in the form of comments, which you can see. Usually, when we build an image, we rely on a basic image. The basic image contains some basic information. The new image we build based on the foundation will contain the contents of the basic image.

The CMD directive needs to be described in more detail. CMD specifies the process to be executed after python app.py is started for this container. CMD ["python", "app.py"] is equivalent to executing "python app.py" in the container.

In addition, when using Dockerfile, there is an ENTRYPOINT instruction. Both it and CMD are necessary parameters for the Docker container process to start, and the full execution format is "ENTRYPOINT CMD".

By default, Docker will provide you with an implicit ENTRYPOINT, namely: / bin/sh-c. So, when ENTRYPOINT is not specified, as in our case, the complete process running in the container is actually / bin/sh-c "python app.py", that is, the content of CMD is the parameter of ENTRYPOINT. It is based on this principle that the startup process of the Docker container is actually ENTRYPOINT, not CMD.

It is important to note that the instructions in Dockerfile are not all operations within the container. For example, ADD refers to copying the files in the current directory (that is, the directory where Dockerfile is located) to the directory in the specified container.

For more instructions that can be used in Dockerfile, refer to the official documentation:

Https://docs.docker.com/engine/reference/builder/#dockerfile-reference .

According to the previous description, the directory structure of our entire application should now be as follows:

$lsDockerfile app.py requirements.txt

Execute the following instructions to build the image:

$docker build-f / path/to/Dockerfile-t helloworld .Sending build context to Docker daemon 4.608kBStep 1 ADD 7: FROM python:3.6-alpine-- > 5e7f84829665Step 2 app 7: WORKDIR / app-- > Using cache-- > dbb4a00a8f68Step 3 dbb4a00a8f68Step 7: ADD. / app-- > fd33ac91c6c7Step 4 fd33ac91c6c7Step 7: RUN pip install-I https://pypi.tuna.tsinghua.edu.cn/simple-r requirements.txt-> Running in 6b82e863d802Looking in indexes: https://pypi.tuna.tsinghua.edu.cn/simpleCollecting Flask Downloading https://pypi.tuna.tsinghua.edu.cn/packages/f2/28/2a03252dfb9ebf377f40fba6a7841b47083260bf8bd8e737b0c6952df83f/Flask-1.1.2-py2.py3-none-any.whl (94 kB) Collecting click > = 5.1 Downloading https://pypi.tuna.tsinghua .edu.cn / packages/dd/c0/4d8f43a9b16e289f36478422031b8a63b54b6ac3b1ba605d602f10dd54d6/click-7.1.1-py2.py3-none-any.whl (82 kB) Collecting Jinja2 > = 2.10.1 Downloading https://pypi.tuna.tsinghua.edu.cn/packages/27/24/4f35961e5c669e96f6559760042a55b9bcfcdb82b9bdb3c8753dbe042e35/Jinja2-2.11.1-py2.py3-none-any.whl (126 kB) Collecting itsdangerous > = 0.24 Downloading https://pypi.tuna.tsinghua.edu.cn/packages/76/ae/44b03b253d6fade317f32c24d100b3b35c2239807046a4c953c7b89fa49e/itsdangerous-1.1.0-py2 .py3-none-any.whl (16 kB) Collecting Werkzeug > = 0.15 Downloading https://pypi.tuna.tsinghua.edu.cn/packages/cc/94/5f7079a0e00bd6863ef8f1da638721e9da21e5bacee597595b318f71d62e/Werkzeug-1.0.1-py2.py3-none-any.whl (298 kB) Collecting MarkupSafe > = 0.23 Downloading https://pypi.tuna.tsinghua.edu.cn/packages/b9/2e/64db92e53b86efccfaea71321f597fa2e1b2bd3853d8ce658568f7a13094/MarkupSafe-1.1.1.tar.gz (19 kB) Building wheels for collected packages: MarkupSafe Building wheel for MarkupSafe (setup.py): started Building wheel for MarkupSafe (setup.py): finished with status' done' Created wheel for MarkupSafe: filename=MarkupSafe-1.1.1-py3-none-any.whl size=12629 sha256=1f965945354a52423078c573deb1a8116965e67b2467c3640264d7f02058b06d Stored in directory: / root/.cache/pip/wheels/06/e7/1e/6e3a2c1ef63240ab6ae2761b5c012b5a4d38e448725566eb3dSuccessfully built MarkupSafeInstalling collected packages: click MarkupSafe, Jinja2, itsdangerous, Werkzeug, FlaskSuccessfully installed Flask-1.1.2 Jinja2-2.11.1 MarkupSafe-1.1.1 Werkzeug-1.0.1 click-7.1.1 itsdangerous-1.1.0Removing intermediate container 6b82e863d802-> d672a00c1a2fStep 5 MarkupSafe-1.1.1 Werkzeug-1.0.1 click-7.1.1 itsdangerous-1.1.0Removing intermediate container 6b82e863d802 7: EXPOSE 8083-> Running in b9b2338da3f3Removing intermediate container b9b2338da3f3-> e91da5a22e20Step 6 EXPOSE 7: ENV NAME World-> Running in d7e5d19f3eedRemoving intermediate container d7e5d19f3eed-- > 4f959f34d486Step 7 Running in d7e5d19f3eedRemoving intermediate container d7e5d19f3eed 7: CMD ["python" "app.py"]-- > Running in 99a97bedace0Removing intermediate container 99a97bedace0-> 3bc3e537ebb7Successfully built 3bc3e537ebb7Successfully tagged helloworld:latest

Among them, the function of-t is to add a Tag to the image, that is, to give a nice name. Docker build automatically loads the Dockerfile file in the current directory and then executes the instructions in the Dockerfile file in order.

After the above command is executed, a mirror image is generated. You can view it with the following instructions:

$docker image lsREPOSITORY TAG IMAGE ID CREATED SIZEhelloworld latest 3bc3e537ebb7 2 minutes ago 103MB

You can also view the meta-information of the image through docker inspect helloworld:latest.

The meta-information contains all the information about the image, including the tag of the image, build time, environment variables, and so on.

If the mirror is no longer needed, you can delete the mirror through docker image rm.

With the image, you can run the image to get the container with the following instructions.

$docker run-p 8082 helloworld * Serving Flask app "app" (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: off * Running on http://0.0.0.0:8082/ (Press CTRL+C to quit)

In the above command, there is nothing to write after the image name helloworld, because CMD has been specified in Dockerfile. Otherwise, I have to add the start command of the process to the end:

$docker run-p 8082 8082 helloworld python app.py

From now on, the container has started correctly, and we use the curl command to access the web application in the container through the IP and port number of the host.

$curl http://0.0.0.0:8082/Hello World! Hostname: 59b607239c3a

From the output, you can see the ID of the container, the image based on which the container was started, the processes in the container, the startup time and port mapping of the container, and the name of the container.

Using the docker inspect 59b607239c3a command, you can view the container's metadata, which is very rich.

2. K8s pulls the image 2.1 from the host private image warehouse to build the host private image warehouse. Sudo docker pull registrysudo docker run-d-p 5000 restart always 5000-v $(pwd): / var/lib/registry-- restart always-- name registry registry:22.2 verify that the private image warehouse curl http://127.0.0.1:5000/v2/_catalog2.3 pushes the image to the private image warehouse to restart the docker service to make the configuration effective: systemctl restart docker172.19.242.79 is the host ipmac configuration path: toolbar-> docker-> Preferences- > Daemon-> basic-> Insecure registries add a line: 172.19.242.79:5000sudo vim / etc/docker/daemon.json "insecure-registries": ["172.19.242.79 172.19.242.79:5000sudo vim"] "debug": true2.4 pushes to the image repository sudo docker tag helloworld 172.19.242.79:5000/flaskhelloworld # to mark the local image Put it into a warehouse sudo docker push 172.19.242.79:5000/flaskhelloworld # initially docker build-t directly into the designated (remote) warehouse can save the previous step of curl-X GET 172.19.242.79:5000/v2/_catalog2.5 configuration minikube and restart in order to enable the k8s in the minikube virtual machine to pull the host private image requires the above two configurations-registry-mirror and-insecure-registrysudo minikube start- -driver=none-- insecure-registry= "172.19.242.79 https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-v1.15.1.iso 5000"-- image-mirror-country cn\-- iso-url= https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-v1.15.1.iso\-- registry-mirror=https:// your registered aliyun acceleration address .mirror.aliyuncs.com2.6 deployment image and open service interface sudo kubectl create deployment flaskhelloworld-- image=172.19.242 .79: 5000/flaskhelloworldsudo kubectl expose deployment flaskhelloworld--type=LoadBalancer-- port=6789-- target-port=8082 sudo minikube service flaskhelloworld--url#sudo kubectl port-forward flaskhelloworld-6b7695c6df-5hclc 8888 url#sudo kubectl port-forward flaskhelloworld-6b7695c6df-5hclc 8082 # sudo kubectl create-f flaskhelloworld.yaml#sudo kubectl describe pod flaskhelloworld-pod#sudo kubectl port-forward flaskhelloworld-pod 8888:8080#sudo kubectl run flaskhelloworld--image=172.19.242.79:5000/flaskhelloworld-- port 3000#sudo kubectl expose pod flaskhelloworld--name flaskhelloworld-http-- type=LoadBalancer#sudo minikube service flaskhelloworld-http3, Pod, service in K8s, Ingress Network Architecture Analysis sudo minikube service flaskhelloworld |-| | NAMESPACE | NAME | TARGET PORT | URL | |- | |-| default | flaskhelloworld | 6789 | http://172.19.242.79:30792 | |-| -|-|? Opening service default/flaskhelloworld...???? through default browser Http://172.19.242.79:30792

The host information of each visit is different because after we deployments, we execute the

Kubectl scale-n default deployment flaskhelloworld-- replicas=3

The cluster has 3 pod

In Kubernetes, deploying a Deployment cannot be accessed externally, that is, if other applications want to access the deployed Deployment, they cannot find how to access it. Why? because Deployment is generally deployed with multiple copies, it may be distributed on different nodes, and the rebuilt Pod IP will also change, and the rerelease will also change, so there is no way to access which Pod regularly, even if it is fixed. Other Pod cannot be accessed. If you want multiple Pod to provide services, you must add a load balancer and provide an access entry. Only by accessing this unified entry can you forward it to multiple backend Pod. As long as you access this Cluster IP, you can forward it to the backend Pod.

Service

Service defines the logical collection of Pod and the policy to access it.

The introduction of Service provides service discovery and load balancing to solve the dynamic changes of Pod.

Use CoreDNS to resolve Service names

Sudo kubectl get servicesNAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGEflaskhelloworld LoadBalancer 10.98.106.240 6789:30792/TCP 31mflink-jobmanager ClusterIP 10.100.169.253 6123 8081/TCP 7d12hflink-jobmanager-rest NodePort 10.103.71.37 8081:30424/TCP 7d12hkubernetes ClusterIP 10.96.0.1 443/TCP 7d12h

Therefore, we can also use the cluster IP to access:

After services is exposed, it is necessary for users to visit, for example, to set up an e-commerce website for users to visit. Ingress is complementary to Service. Service mainly provides access within the cluster and can also expose a TCP/UDP port, while Ingress is mainly a layer 7 forwarding, that is, it provides a unified entry. As long as you visit Ingress Controller, you can forward all the projects you deploy. That is, all projects are accessed using a domain name.

To learn more about the network architecture, we can also directly use pod ip + port to access

Sudo kubectl get endpoints serviceName # View Service backend pods (corresponding to multiple endpoint in Kubernetes)

After reading the above, have you mastered the methods of minikube deployment local image practice and K8s network architecture analysis? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.