k8s 03: etcd and API server

I can now deploy a pod via the kubelet directly after the previous entry.

It just look for specific directory to update the pod status.
This time, I deploy etcd and API server.
– etcd holds all the cluster information.
– API server is the center piece of Kubernetes, according to the official document “Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane”.

I’m aiming to make something like this image:

Prepare etcd

1. install etcd
As stated before, etcd is kind of databse. I specify local /work/etcd-data directory to store this database. etcd server is listening the request on port 2379 by default. Reference: https://github.com/etcd-io/etcd/releases

 

Prepare API server

1. install API server

Install API server. And in the systemd configuration file, pass the url of etcd server(in this case port 2379 on localhost – http://127.0.0.1:2379).

2. confirm API server
Let’s check if API server is working correctly.
API server listens requests on port 8080 for non-secure request, so we can throw a request to http://127.0.0.1:8080 in this case.

 

Prepare Kubelet

1. Modify Kubelet

At this moment, kubelet looks at specified directory. But I want kubelet to look at API server now. So I need to create a config file and modify the systemd file to load it.

Now, I can check the API server if the node is correctly registered.

 

Launch Test Pod

1. Create a test Pod manifest

So all the components are in place, and I should be able to request API server to launch a pod now. All I need to do is just send a manifest to API server. Take note that, at this moment there is no scheduler yet, so API server needs to know which node to run the pod(even though there is only one node available). Otherwise it goes to something like this:

2. Send a request to API server

The request to API server needs to be in JSON format, which is different from above YAML file. I’m using python here to send that request. I’m using non-secure port(using http) this time, so authentication and authorization wouldn’t be taken place. But admission control is still in place, and it can be disabled by passing the flag when it starts(of course it’s only for development and test purpose though).

3. Check the status

The request seems succeeded, so I can ask API server for the status. And of course I can send a GET request to pod IP address to check if Nginx is working.