This document is aimed at users who have worked through some of the examples, and who want to learn more about using kubectl to manage resources such as pods and services. Users who want to access the REST API directly, and developers who want to extend the Kubernetes API should refer to the api conventions and the api document.
When you create a resource such as pod, and then retrieve the created resource, a number of the fields of the resource are added. You can see this at work in the following example:
$ cat > /tmp/original.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: foo
image: busybox
restartPolicy: Never
EOF
$ kubectl create -f /tmp/original.yaml
pods/original
$ kubectl get pods/original -o yaml > /tmp/current.yaml
pods/original
$ wc -l /tmp/original.yaml /tmp/current.yaml
51 /tmp/current.yaml
9 /tmp/original.yaml
60 total
The resource we posted had only 9 lines, but the one we got back had 51 lines.
If you diff -u /tmp/original.yaml /tmp/current.yaml
, you can see the fields added to the pod.
The system adds fields in several ways:
metadata.uid
is set synchronously. (Read more about metadata).status.hostIP
is set only after the pod has been scheduled. This often happens fast, but you may notice pods which do not have this set yet. This is called Late Initialization. (Read mode about status and late initialization ).spec.containers[0].imagePullPolicy
always defaults to IfNotPresent
in api v1.spec.containers[0].resources.limits.cpu
may be defaulted to 100m
on some clusters, to some other value on others, and not defaulted at all on others.
The API will generally not modify fields that you have set; it just sets ones which were unspecified.You can browse auto-generated API documentation at the project website or on github.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。