Kubernetes-initial experience of Google distributed container Technology

Kubernetes-initial experience of Google distributed container Technology

Kubernetes is an open-source container Cluster Management System of Google. The four features of the distributed service framework written a few days ago mentioned that a good distributed service framework needs to be implemented.

Service configuration management. Including service discovery, Server Load balancer, and service dependency management.
Inter-service scheduling and lifecycle management.

Kubernetes includes some of the above features, and the recently launched Container Engine is based on Kubernetes. Therefore, we have made some attempts and experiences on Kubernetes recently.

Running Environment

Kubernetes is currently in a fast iteration stage, and its related ecosystem (such as docker and etcd) is also developing rapidly. This also means that there is no version suitable for beginners to use smoothly, the various documents on the Internet (including official documents) and the latest releases may lag or be unsuitable to some extent. Therefore, you may encounter various details during use, in addition, the problems encountered by these new versions may not be found on the Internet.

Kubernetes is not designed to be bound to the Google Cloud platform, but for the above reasons, to reduce unnecessary obstacles, we recommend using GCE as the runtime environment for the first attempt (although GCE is a charged environment ). By default, five GCE instances are created in the cluster STARTUP script. After the test, you must delete the instances in time. To avoid waste, you can reduce minions and select the f1-micro for the instance type. For billing, A f1-micro instance runs for about $50 a month, so using GCE to test Kubernetes does not incur much cost if it is enabled only during testing.

Pods and Replication Controller

The basic unit of Kubernetes is pods, which defines a set of related containers. Kubernetes has the advantage of defining a replicationController to deploy the same module to any number of containers and is automatically managed by Kubernetes. For example, if an apache pod is defined and 100 replicas are started through replicationController, the system automatically starts 100 apache containers in all available minions after the pod is created. In addition, when the container or server is unavailable, Kubernetes automatically starts a new container to keep the total number of containers unchanged, making it easy and easy to manage a large system.

Service microservice

After the deployment problem is solved, a major challenge in distributed services is service discovery (or addressing ), the front-end module accessed by the user needs to access the backend resources in the system or other internal services. When an internal service is dynamically deployed to different nodes through replicationController, in addition, the aforementioned dynamic switching feature still exists. How can front-end applications discover and access these services? Another highlight feature of Kubernetes is service, which is the proxy abstraction of a pod service pool. The current implementation method is defined by a fixed virtual IP address and port, in addition, internal services can access services through proxies distributed on all nodes.

Kubernetes configurations are stored in an etcd (similar to ZooKeeper) distributed configuration service. Why does service discovery not be implemented through etcd? Tim's judgment is more about decoupling Kubernetes systems from specific configuration services. Service discovery is the internal business logic of each system. Therefore, if you use etcd, the logic of the Business Code is coupled with etcd, which may lead to a lot of architects being discouraged.

Although the etcd is not coupled, services deployed in Kubernetes must obtain the service address through the environment variables in the container. Although the environment variables are simple, they also have many drawbacks, such as the inconvenience of dynamic changes. In addition, the current implementation of the service is to redirect the virtual IP address to the final pod through iptables. The author also mentioned the limitations of iptables targeting, which is not suitable for implementation of large-scale services.

Summary

In general, Kubernetes provides amazing capabilities. The design of pod, replicationController, and service is very simple and practical. However, if you want to migrate services to Kubernetes immediately, you need to change the environment. In addition, despite the health check mechanism provided by Kubernetes, the demanding availability required by the service production environment has not been fully verified.

Installation instructions

Simple installation instructions for Kubernetes cluster are as follows. For more information, see.

Prerequisites

In a 64bit linux environment, it is best to stay in the region to avoid timeout or reset issues when accessing google cloud. In addition, create a Google Cloud account to ensure that the instances and Cloud Storage functions are available;

Installation Steps

1. Install the go language environment (optional, required if you need to compile the code)

2. Install the Google cloud sdk

1. $ Curl https://sdk.cloud.google.com | bash
2. $ Gcloud auth login

Complete authorization and logon as prompted

3. Install the binary version of etcd (V0.4.6), decompress the package, and add the directory to the PATH.

4. Install the latest relase binary version of kubernetes (V0.5.1)

Modify cluster/gce/config-default.sh, primarily by modifying the following fields to save resources.

1. MASTER_SIZE = f1-micro
2. MINION_SIZE = f1-micro
3. NUM_MINIONS = 3

Run in the kubernetes directory

1. $ Cluster/kube-up.sh

Done is displayed after successful execution.

5. Test pod

The preceding script starts the service defined in examples/monitoring. If you try to start other pods, such as starting a tomcat Cluster

1. {
2. "Id": "tomcatController ",
3. "Kind": "ReplicationController ",
4. "ApiVersion": "v1beta1 ",
5. "DesiredState ":{
6. "Replicas": 2,
7. "ReplicaSelector": {"name": "tomcatCluster "},
8. "PodTemplate ":{
9. "DesiredState ":{
10. "Manifest ":{
11. "Version": "v1beta1 ",
12. "Id": "tomcat ",
13. "Containers ":[{
14. "Name": "tomcat ",
15. "Image": "tutum/tomcat ",
16. "Ports ":[
17. {"ContainerPort": 8080, "hostPort": 80}
18. ]
19. }]
20. }
21. },
22. "Labels": {"name": "tomcatCluster "}}
23. },
24. "Labels ":{
25. "Name": "tomcatCluster ",
26. }
27. }

The pod tomcat image can be obtained through the Docker Hub Registry https://registry.hub.docker.com/search

1. $ Cluster/kubectl. sh create-f tomcat-pod.json

After the creation is successful, you can use cluster/kubectl. sh get pods to view its minion and ip address, which can be accessed through curl or a browser (enable GCE firewall port settings ).

Define another service

1. {
2. "Id": "tomcat ",
3. "Kind": "Service ",
4. "ApiVersion": "v1beta1 ",
5. "Port": 8080,
6. "ContainerPort": 8080,
7. "Labels ":{
8. "Name": "tomcatCluster"
9. },
10. "Selector ":{
11. "Name": "tomcatCluster"
12. }
13. }

Save as tomcat-service.json

1. $ Cluster/kubectl. sh create-f tomcat-service.json

Check the ip address and port after the service is started. Because the service is an internal ip address, you can test and verify the service through curl on GCE.

1. $ Cluster/kubectl. sh get services

6. Disable cluster

1. Cluster/kube-down.sh

This article permanently updates the link address: