each configuration file has 3 parts
apiversion
kind
然后是：
1) metadata
2) specification
3) status（这个是kubernete自动生成的）
如果kubernete发现status和spec不一样，就进行self healing
attributes of "spec" are specific to the kind
Layers of Abstraction:
template:
template also has its own 'metadata' and 'spec' section
thsese configuration applies to a pod
blueprint for a pod
label and selectors:
the way connection is established is using labels andd selectors
metadata part contains labels
sepecification part contains selectors
在metadata中为一个component 比如deployment或者pod 一个key-value键值对
在这个例子是 app: nginx
这个label定义了这个component
然后pod会得到这个蓝图
we tell the deployment to connect or match all the labels with app：nginx
to create the connection
so this way deployment will know which pods belong to it
deployment有他自己的label
app:nginx
these two label are used by service selector
because service must know which pods are registerd with it
that connection is made through the selector of the label
个人理解...
ports:
service has ports
deployment has ports
这两个是match的
service的targetPort和deployment的containerport是match的
service有自己的port
service的port is where the service is accessiable at
if other service sends a request to nginx service here , it needs to send on port 80
the service need to know which service pod it should forward the request
that is the container port
how can we valid the service has the right ports?
kubectl describe service nginx-service
注意看end point
kuctl get pod -o wide
now you can see more columns there
如果想看status：
kubectl get deployment nginx-deployment -o yaml
kubectl get deployment nginx-deployment -o yaml > nginx-deployment-result.yaml
对比一下，前面的基本都是一样的
status中是kubernete自己添加上去的
