hi,
from what i understand when let`s say a deployment is created from yaml,kubectl translate the content in json and send it to api server.Than that deployment is created and the information about that deployment is stored in etcd.is it stored in api server as well?
When i create a service,this service is created by kubelet and controller?
| lelunicu
July 15 |
- | - |
hi,
from what i understand when let`s say a deployment is created from yaml,kubectl translate the content in json and send it to api server.
Yes
Than that deployment is created and the information about that deployment is stored in etcd.is it stored in api server as well?
Storing it is creating it. Once the API server verifiers that the deployment is valid, that you have permission and quota to create it, etc, it is stored. Etcd is the database we use, but it’s an implementation detail. Better to just think of it as " the API server stored it".
After that, API clients are notified of the new deployment and they “actuate” it.
When i create a service,this service is created by kubelet and controller?
Kubelet does not participate in services. There are distinct service controllers, just like deployment. On nodes we call that controller kube-proxy.
From what you written the services are created by controllers.right?
In nodeport service case,this service is replicated in every node where run pods(in deployment case).
In loadbalancer or ingress service case,this service will run outside the nodes.
From what you written the services are created by controllers.right?
You’re really stuck on the idea of “create”, and I fear that we are going in circles because of it. I’m going to define 2 words with REALLY SPECIFIC meanings, and we should keep thoise in mind:
- To “create” something in the Kubernetes API means that someone sends a “create” API call to the apiserver. That might be
kubectl create
orkubectl apply
or otherkubectl
commands or custom code. That usually means an HTTP POST operation to a specific resource URL. The request payload might be JSON or proto, or might come from a YAML or other file. Once the API server validates the request, the (possibly modified) request is saved in the API server’s database (etcd usually) and that “object” is “created”. The API call returns a success code.
That alone doesn’t actually do much - no containers are running, no networks are routed, etc.
- To “actuate” something means that someone became aware of a change in the API (the “desired state”) and takes actions to make that happen. This almost always means one or more controllers get a WATCH notification from the API server. Sometimes “actuation” means doing work, like running containers on a node, and sometimes it means doing other API calls, like a Deployment creating ReplicaSets and ReplicaSets creating Pods.
So to answer your question: Someone “creates” a Service in the API. That usually means a human, but it could be any API client. It is “actuated” by controllers. A Service is just a set of rules telling controllers what result we want, it is not telling them how to achieve that result. A Service does not really “run” but I think you mean to ask where it is implemented.
As in the other thread, the answer is “it depends”. In most implementations, it involves some on-node networking tricks - iptables, IPVS, eBPF, etc. But it COULD be implemented in a different way, as long as the desired result is achieved.
Again, there are lots of recorded talks on this, with all the details you could ever want, and more.
Tim