上一篇知识点是k8s使用方式的入门，主要对标的是非专业运营人员日常测试使用，比如Java开发测试运行后台程序等这些非正式使用场景。但是如果想要更深层的使用k8s仅仅的入门是不够的，本篇知识点来罗列k8s体系中“资源”的概念。
k8s体系中操作的主体统称叫做资源，常见的资源分为五种：
第一种：工作负载型资源，指的是Pod、Deployment、Job等
第二种：服务发现与负载均衡资源，指的是Service、Ingress等
第三种：配置与存储资源，指Volume、CSI、存储卷等
第四种：集群级的资源，Namespace、Node等
第五种：元数据资源，Pod模板等
当然这些只是常用的，还有一些使用频率很低的，大家在日后的使用中积累即可。不过无论那种资源，在k8s的正式使用中都不是像应用入门中那样使用命令草草了事的操作，而是普遍使用不同格式的配置文件。比如我们可以获取一个前面知识点用命令直接创建的资源它的配置文件，可以发现虽然是命令创建，但是它的配置是有默认值的，我们可以通过get命令查看，不要使用describe，该命令没有-o参数
[root@hdp1 ~]# kubectl get pod myapp-99f9c686c-npxtb -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2023-03-17T14:20:31Z"
generateName: myapp-99f9c686c-
labels:
pod-template-hash: 99f9c686c
run: myapp
name: myapp-99f9c686c-npxtb
namespace: default
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: myapp-99f9c686c
uid: 647ab3e4-57f7-4d26-a56e-da43d06753bc
resourceVersion: "101427"
selfLink: /api/v1/namespaces/default/pods/myapp-99f9c686c-npxtb
uid: 4b49dab2-ac98-42ad-8e56-85172cc03ef8
spec:
containers:
- image: nginx:1.14-alpine
imagePullPolicy: IfNotPresent
name: myapp
resources: {
}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-q6zw8
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
nodeName: hdp2
priority: 0
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {
}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
volumes:
- name: default-token-q6zw8
secret:
defaultMode: 420
secretName: default-token-q6zw8
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2023-03-17T14:20:31Z"
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: "2023-03-17T14:20:32Z"
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: "2023-03-17T14:20:32Z"
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: "2023-03-17T14:20:31Z"
status: "True"
type: PodScheduled
containerStatuses:
- containerID: docker://c8b085d8e0962d308a3aa82c8fb24baa336f9d707872884611d2b1bbb1aa6a33
image: nginx:1.14-alpine
imageID: docker-pullable://nginx@sha256:485b610fefec7ff6c463ced9623314a04ed67e3945b9c08d7e53a47f6d108dc7
lastState: {
}
name: myapp
ready: true
restartCount: 0
started: true
state:
running:
startedAt: "2023-03-17T14:20:31Z"
hostIP: 192.168.88.187
phase: Running
podIP: 10.244.1.17
podIPs:
- ip: 10.244.1.17
qosClass: BestEffort
startTime: "2023-03-17T14:20:31Z"
这些配置中有一些我们要特别关注，apiVersion是资源所处的组别和版本，默认为V1，既最核心的一级且版本为V1，组名省略。kind是资源类别。metadata是资源的元数据信息。spec是这个资源的希望拥有规格或者说是特性。status是该资源当前的状态，k8s会将status无限向spec靠拢，我们一般不对status做操作。大部分的资源均由这五个基础一级配置以及一级配置下的必备资源配置所构成。其中包含的详细配置后面会说道，大家这里只需要知道构成配置的大架子有那几块就行。
上面的用例中获取的是yaml格式的文件，但是资源的创建并不是全部依靠yaml格式的配置文件。比如apiVersion仅支持json格式，只是我们配置的时候k8s会把相关配置无损转换为yaml而已。我们可以查询当前集群支持那些组。
[root@hdp1 ~] kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
discovery.k8s.io/v1beta1
events.k8s.io/v1beta1
extensions/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1beta1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1
分组的好处是方便操作多个资源，但是尽量不要使用beta版本，这类组别非稳定版，常常会导致不同版本的组别允许的配置可能不一样。而稳定版会一致存在且不再做大的变动。
当然，对于整个k8s体系中资源应该有那些配置，也为我们提供了查询的文档
[root@hdp1 ~] kubectl explain pod
KIND: Pod
VERSION: v1
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is
created by clients and scheduled onto hosts.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec <Object>
Specification of the desired behavior of the pod. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status <Object>
Most recently observed status of the pod. This data may not be up to date.
Populated by the system. Read-only. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
[root@hdp1 ~] kubectl explain pod.metadata
KIND: Pod
VERSION: v1
RESOURCE: metadata <Object>
DESCRIPTION:
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
ObjectMeta is metadata that all persisted resources must have, which
includes all objects users must create.
FIELDS:
annotations <map[string]string>
Annotations is an unstructured key value map stored with a resource that
may be set by external tools to store and retrieve arbitrary metadata. They
are not queryable and should be preserved when modifying objects. More
info: http://kubernetes.io/docs/user-guide/annotations
clusterName <string>
The name of the cluster which the object belongs to. This is used to
distinguish resources with same name and namespace in different clusters.
This field is not set anywhere right now and apiserver is going to ignore
it if set in create or update request.
creationTimestamp <string>
CreationTimestamp is a timestamp representing the server time when this
object was created. It is not guaranteed to be set in happens-before order
across separate operations. Clients may not set this value. It is
represented in RFC3339 form and is in UTC. Populated by the system.
Read-only. Null for lists. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
deletionGracePeriodSeconds <integer>
Number of seconds allowed for this object to gracefully terminate before it
will be removed from the system. Only set when deletionTimestamp is also
set. May only be shortened. Read-only.
deletionTimestamp <string>
DeletionTimestamp is RFC 3339 date and time at which this resource will be
deleted. This field is set by the server when a graceful deletion is
requested by the user, and is not directly settable by a client. The
resource is expected to be deleted (no longer visible from resource lists,
and not reachable by name) after the time in this field, once the
finalizers list is empty. As long as the finalizers list contains items,
deletion is blocked. Once the deletionTimestamp is set, this value may not
be unset or be set further into the future, although it may be shortened or
the resource may be deleted prior to this time. For example, a user may
request that a pod is deleted in 30 seconds. The Kubelet will react by
sending a graceful termination signal to the containers in the pod. After
that 30 seconds, the Kubelet will send a hard termination signal (SIGKILL)
to the container and after cleanup, remove the pod from the API. In the
presence of network partitions, this object may still exist after this
timestamp, until an administrator or automated process can determine the
resource is fully terminated. If not set, graceful deletion of the object
has not been requested. Populated by the system when a graceful deletion is
requested. Read-only. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
finalizers <[]string>
Must be empty before the object is deleted from the registry. Each entry is
an identifier for the responsible component that will remove the entry from
the list. If the deletionTimestamp of the object is non-nil, entries in
this list can only be removed. Finalizers may be processed and removed in
any order. Order is NOT enforced because it introduces significant risk of
stuck finalizers. finalizers is a shared field, any actor with permission
can reorder it. If the finalizer list is processed in order, then this can
lead to a situation in which the component responsible for the first
finalizer in the list is waiting for a signal (field value, external
system, or other) produced by a component responsible for a finalizer later
in the list, resulting in a deadlock. Without enforced ordering finalizers
are free to order amongst themselves and are not vulnerable to ordering
changes in the list.
generateName <string>
GenerateName is an optional prefix, used by the server, to generate a
unique name ONLY IF the Name field has not been provided. If this field is
used, the name returned to the client will be different than the name
passed. This value will also be combined with a unique suffix. The provided
value has the same validation rules as the Name field, and may be truncated
by the length of the suffix required to make the value unique on the
server. If this field is specified and the generated name exists, the
server will NOT return a 409 - instead, it will either return 201 Created
or 500 with Reason ServerTimeout indicating a unique name could not be
found in the time allotted, and the client should retry (optionally after
the time indicated in the Retry-After header). Applied only if Name is not
specified. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency
generation <integer>
A sequence number representing a specific generation of the desired state.
Populated by the system. Read-only.
labels <map[string]string>
Map of string keys and values that can be used to organize and categorize
(scope and select) objects. May match selectors of replication controllers
and services. More info: http://kubernetes.io/docs/user-guide/labels
managedFields <[]Object>
ManagedFields maps workflow-id and version to the set of fields that are
managed by that workflow. This is mostly for internal housekeeping, and
users typically shouldn't need to set or understand this field. A workflow
can be the user's name, a controller's name, or the name of a specific
apply path like "ci-cd". The set of fields is always in the version that
the workflow used when modifying the object.
name <string>
Name must be unique within a namespace. Is required when creating
resources, although some resources may allow a client to request the
generation of an appropriate name automatically. Name is primarily intended
for creation idempotence and configuration definition. Cannot be updated.
More info: http://kubernetes.io/docs/user-guide/identifiers#names
namespace <string>
Namespace defines the space within each name must be unique. An empty
namespace is equivalent to the "default" namespace, but "default" is the
canonical representation. Not all objects are required to be scoped to a
namespace - the value of this field for those objects will be empty. Must
be a DNS_LABEL. Cannot be updated. More info:
http://kubernetes.io/docs/user-guide/namespaces
ownerReferences <[]Object>
List of objects depended by this object. If ALL objects in the list have
been deleted, this object will be garbage collected. If this object is
managed by a controller, then an entry in this list will point to this
controller, with the controller field set to true. There cannot be more
than one managing controller.
resourceVersion <string>
An opaque value that represents the internal version of this object that
can be used by clients to determine when objects have changed. May be used
for optimistic concurrency, change detection, and the watch operation on a
resource or set of resources. Clients must treat these values as opaque and
passed unmodified back to the server. They may only be valid for a
particular resource or set of resources. Populated by the system.
Read-only. Value must be treated as opaque by clients and . More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
selfLink <string>
SelfLink is a URL representing this object. Populated by the system.
Read-only. DEPRECATED Kubernetes will stop propagating this field in 1.20
release and the field is planned to be removed in 1.21 release.
uid <string>
UID is the unique in time and space value for this object. It is typically
generated by the server on successful creation of a resource and is not
allowed to change on PUT operations. Populated by the system. Read-only.
More info: http://kubernetes.io/docs/user-guide/identifiers#uids
当然要说明的是，用配置文件操作资源的时候不是每一项配置你都要写，只需要指定你需要的和必备的即可。比如我们创建一个pod你需要指定他必备的容器配置以及资源类别等
apiVersion: v1
kind: Pod
metadata:
name: pod-demo
namespace: default
labels:
app: myapp-test
spec:
containers:
- name: myapp01
image: nginx:1.14-alpine
- name: myapp02
image: busybox
command:
- "/bin/sh"
- "-c"
- "echo $date >> /usr/share/nginx/html/index.html; sleep 5"
在上面的配置清单示例中，横杠代表的是当前配置项他所接受的只是一个列表，而横杠是用来分隔元素的
使用配置文件创建资源使用create命令
[root@hdp1 ~] kubectl create -f myapp.yaml
pod/pod-demo created
[root@hdp1 ~] kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-99f9c686c-npxtb 1/1 Running 1 17h
pod-demo 0/2 ContainerCreating 0 17s
[root@hdp1 ~] kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-99f9c686c-npxtb 1/1 Running 1 17h
pod-demo 1/2 ImagePullBackOff 0 4m4s
[root@hdp1 ~] kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-99f9c686c-npxtb 1/1 Running 1 17h
pod-demo 2/2 Running 0 4m5s
这样我们就创建了一个拥有两个容器的Pod，并且我们可以查询它的当前配置
[root@hdp1 ~] kubectl describe pods pod-demo
Name: pod-demo
Namespace: default
Priority: 0
Node: hdp3/192.168.88.188
Start Time: Sat, 18 Mar 2023 15:38:34 +0800
Labels: app=myapp-test
Annotations: <none>
Status: Running
IP: 10.244.2.20
IPs:
IP: 10.244.2.20
Containers:
myapp01:
Container ID: docker://33821fb4d81fdf1f95d7ff4e92381f6b2b19d866e1035deaeac84f7f0c64c339
Image: nginx:1.14-alpine
Image ID: docker-pullable://nginx@sha256:485b610fefec7ff6c463ced9623314a04ed67e3945b9c08d7e53a47f6d108dc7
Port: <none>
Host Port: <none>
State: Running
Started: Sat, 18 Mar 2023 15:38:34 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-q6zw8 (ro)
myapp02:
Container ID: docker://3e95096049b216435d64a1ca268cccd5b207c6be164db64f24d08dbd52c33368
Image: busybox
Image ID: docker-pullable://busybox@sha256:5acba83a746c7608ed544dc1533b87c737a0b0fb730301639a0179f9344b1678
Port: <none>
Host Port: <none>
Command:
/bin/sh
-c
echo $date >> /usr/share/nginx/html/index.html; sleep 5
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
Started: Sat, 18 Mar 2023 15:47:16 +0800
Finished: Sat, 18 Mar 2023 15:47:21 +0800
Ready: False
Restart Count: 5
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-q6zw8 (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
default-token-q6zw8:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-q6zw8
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 10m default-scheduler Successfully assigned default/pod-demo to hdp3
Normal Pulled 10m kubelet, hdp3 Container image "nginx:1.14-alpine" already present on machine
Normal Created 10m kubelet, hdp3 Created container myapp01
Normal Started 10m kubelet, hdp3 Started container myapp01
Warning Failed 6m58s (x3 over 9m15s) kubelet, hdp3 Failed to pull image "busybox": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Warning Failed 6m58s (x3 over 9m15s) kubelet, hdp3 Error: ErrImagePull
Normal BackOff 6m18s (x5 over 9m15s) kubelet, hdp3 Back-off pulling image "busybox"
Warning Failed 6m18s (x5 over 9m15s) kubelet, hdp3 Error: ImagePullBackOff
Normal Pulling 6m3s (x4 over 10m) kubelet, hdp3 Pulling image "busybox"
Normal Created 6m2s kubelet, hdp3 Created container myapp02
Normal Pulled 5m4s (x3 over 6m2s) kubelet, hdp3 Successfully pulled image "busybox"
[root@hdp1 ~] curl 10.244.2.20:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
上面的例子中第二个容器会报错，我们需要查看它的日志，使用前面提到的losgs命令，不过这里重点是想说明，你想在外部操作Pod下的容器时需要-c参数才可表示某个容器
[root@hdp1 ~] kubectl logs pod-demo -c myapp02
/bin/sh: can't create /usr/share/nginx/html/index.html: nonexistent directory
当你想要进入k8s的某个容器时不止要使用-c，还要使用exec进入并且需要--
[root@hdp1 ~]# kubectl exec -it pod-demo -c myapp01 -- /bin/sh
/ #
同时删除某个资源的时候，也不再需要像之前命令行那样delete后面根资源名，你可以通过指定配置文件，将对应由此配置文件生成的资源删掉，这样的好处就在于可以复用配置，不需要每次需要一个新的Pod时候都从头到尾的写一个run。并且当你删除Pod的时候不会被容灾，因为配置清单定义出的泡的资源，如果没有添加控制器相关配置时它是一个自主式pod，没有对应的控制器，所以k8s不会去管pod的死活。
[root@hdp1 ~] kubectl delete -f myapp.yaml
到此本篇知识点就结束了，虽然只以Pod资源为例，说明资源清单的定义注意事项，但希望大家明白其他的资源定义也是大同小异的，大家可以去网上找一些其他资源定义的资源列表配置清单来深入学习。同时k8s整体上来说操作有三种方式，第一种是知识点15的纯命令行方式，第二种是本篇的命令式配置清单方式，第三种叫声明式配置清单方式。声明式的变动相当灵活，后面的知识点会讲到。这三种方式操作的时候，实际应用场景哪个方便用哪个即可。