mirror of
https://github.com/ION606/learn.git
synced 2026-05-14 21:06:56 +00:00
50 lines
2.2 KiB
Markdown
50 lines
2.2 KiB
Markdown
|
# Communicating with the Master Node
|
||
|
|
### Format
|
||
|
|
a request must be in `YAML` format and has:
|
||
|
|
1. apiVersion
|
||
|
|
- the api version
|
||
|
|
|
||
|
|
2. kind
|
||
|
|
- the kind of thing this is referring to (Service, Deployement, etc)
|
||
|
|
|
||
|
|
3. metadata
|
||
|
|
- name of component
|
||
|
|
- matchLabels (labels)
|
||
|
|
* this is like a tag for that component to be matched by `selectors`
|
||
|
|
* this is ONLY used by selectors ONE LAYER UP (i.e. service --> deployement/pods)
|
||
|
|
|
||
|
|
4. spec (specification)
|
||
|
|
- any configurations you might need (selector, port, etc)
|
||
|
|
- this will be `kind` specific
|
||
|
|
- this section will be expanded on down below
|
||
|
|
|
||
|
|
5. status
|
||
|
|
- this is automatically generated by kubernetes
|
||
|
|
★ for example, if you put `replicas: 2` under `spec`, kubernetes will add a status that lets it know that only 1 state is currently running, then continuously update it as new replicas are added or removed, change the number of replicas accordingly
|
||
|
|
- kubernetes gets this data from the `etcd` and compares it to your request
|
||
|
|
★ YAML is horrid, so consider using a tool like [https://yamlchecker.com/](https://yamlchecker.com/)
|
||
|
|
|
||
|
|
|
||
|
|
## The Spec Field
|
||
|
|
This gets it's own section because it can contain so many things. For example:
|
||
|
|
|
||
|
|
### Pod Blueprints
|
||
|
|
* stored in the `template` field, these are the blueprints for the pods
|
||
|
|
* these will have their own `spec` and `metadata` fields in them
|
||
|
|
* like nested configuration files as pods need their own configuration "files" inside of the **deployement**'s configuration file
|
||
|
|
|
||
|
|
### Selectors
|
||
|
|
* tells the deployement what `label` to match
|
||
|
|
* this is ONLY used by selectors ONE LAYER DOWN (i.e. deployement/pods --> service)
|
||
|
|
|
||
|
|
### Ports
|
||
|
|
* the **service** has a port where it is accessible at
|
||
|
|
- this is the `port` variable
|
||
|
|
* the **service** also needs a protocol which it is accessible by
|
||
|
|
- this is the `protocol` variable
|
||
|
|
* the **service** also needs to know what port the pod to be contacted is listening on
|
||
|
|
- this is the `targetPort` variable
|
||
|
|
* the **pod** has a port it is listening on
|
||
|
|
- this is the `containerPort` variable
|
||
|
|
|
||
|
|
*Note: these files are ***declarative***, so for example if you specify there must be 3 replicas, kubernetes will try to ensure there are three replicas*
|