yaml file details
- yaml file details
- 1. k8s supported file formats
- 2. YAML language format
- 3. View the api resource version label
- 4. Compile nginx-test.yaml resource configuration list
- 5. Create a service to provide external access and test
- 6. Explain k8s in detail
- 7. Create an instance after the yaml template is generated in the trial run
- 8. Export the yaml template generated from existing resources and save it as a file
- 9. explain: view field help information
- 10. Obtain a summary of the resource allocation list
1. k8s supported file formats
Kubernetes supports YAML and JSON formats to manage resource objects
JSON format: This is used for message passing between api interfaces
YAML format: used for configuration and management. YAML is a concise non markup language. The content format is user-friendly and easy to read
2. YAML language format
● case sensitive
● use indents to indicate hierarchical relationships
● Tab tab Tab indentation is not supported, only space indentation is used
● the number of indented spaces is not important, as long as the elements of the same level are aligned to the left. Usually, the beginning is indented by two spaces
● indent a space after the symbol character, such as colon, comma, short horizontal bar (-), etc
● "---" indicates YAML format, the beginning of a file, which is used to separate files
● "#" indicates a note
3. View the api resource version label
kubectl api-versions
[root@master ~]# kubectl api-versions admissionregistration.k8s.io/v1beta1 apiextensions.k8s.io/v1beta1 apiregistration.k8s.io/v1 apiregistration.k8s.io/v1beta1 apps/v1 apps/v1beta1 apps/v1beta2 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 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
For business scenarios, apps/v1 is generally preferred (apps/v1 provides API s from v1.9).
Before version k8s v1.16, extensions/v1beta1 was used. Since version v1.20, extensions/v1beta1 no longer provides Ingress resources.
The word beta represents the test version, which is not used in the production environment.
4. Compile nginx-test.yaml resource configuration list
4.1 preparation of resource allocation list
[root@master ~]# mkdir /opt/test
[root@master ~]# cd !$
cd /opt/test
[root@master test]# vim nginx-test.yaml
#Specifies the api version label
apiVersion: apps/v1
#Define the type / role of the resource, and deployment is the replica controller
#The resource types here can be Deployment, Job, progress, Service, etc
kind: Deployment
#Define metadata information of resources, such as resource name, namespace, label, etc
metadata:
#The name of the defined resource must be unique in the same namespace
name: nginx-test
lables:
app: nginx
#Define the parameter properties required by the deployment resource, such as whether to restart the container in case of container failure
spec:
#Define the number of copies
replicas: 3
#Define label selector
selector:
#Define matching labels
matchLabels:
#It shall be consistent with the label defined by. spec.template.metadata.labels
app: nginx
#Define a business template. If there are multiple replicas, the attributes of all replicas will be matched according to the relevant configuration of the template
template:
metadata:
#Define the label to be used by the Pod copy, which shall be consistent with the label defined in the previous. spec.selector.matchLabels
labels:
app: nginx
spec:
#Define container properties
containers:
#Define a container name, - Name: define a container
- name: nginx
#Defines the image and version used by the container
image: nginx:1.15.4
ports:
#Defines the external port of the container
- containerPort: 80
4.2 creating resource objects
kubectl create -f nginx-test.yaml
[root@master test]# kubectl create -f nginx-test.yaml deployment.apps/nginx-test created
4.3 viewing the created pod resources
kubectl get pods -o wide
[root@master test]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-test-9b644dcd5-fdvn6 0/1 ContainerCreating 0 4s <none> node02 <none> <none> nginx-test-9b644dcd5-j6cv7 0/1 ContainerCreating 0 4s <none> node01 <none> <none> nginx-test-9b644dcd5-pwrt2 0/1 ContainerCreating 0 4s <none> node02 <none> <none>
5. Create a service to provide external access and test
5.1 write nginx-svc-test.yaml
[root@master test]# vim nginx-svc-test.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
labels:
app: nginx
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
#The selector defined here should be the same as that defined by deployment
#The service relies on a tag selector to retrieve the nodes that provide the service
app: nginx
5.2 creating resource objects
kubectl create -f nginx-svc-test.yaml
[root@master test]# kubectl create -f nginx-svc-test.yaml service/nginx-svc created
5.3 viewing the created service
kubectl get svc
[root@master test]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.1.0.1 <none> 443/TCP 28h nginx-svc NodePort 10.1.101.27 <none> 80:32421/TCP 5s
5.4 access test
Enter nodeIP:nodePort in the browser to access
curl 192.168.122.11:32421
[root@master test]# curl 192.168.122.11:32421
<!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>
curl 192.168.122.12:32421
[root@master test]# curl 192.168.122.12:32421
<!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>
6. Explain k8s in detail
● port
Port is the k8s cluster's internal port for accessing the service, that is, the service can be accessed from the Node where the Pod is located through clusterIP:port
● nodePort
nodePort is the port for external access to k8s services in the cluster. A service can be accessed externally through nodeIP:nodePort
● targetPort
targetPort is the port of the Pod. Traffic from port or nodePort is forwarded to the targetPort of the backend Pod through Kube proxy reverse proxy load balancing, and finally enters the container.
● containerPort
containerPort is the port of the internal container of Pod, and targetPort is mapped to containerPort.
7. Create an instance after the yaml template is generated in the trial run
7.1 dry run: commissioning
Kubectl run -- dry run prints the corresponding API object without creating it
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run
[root@master test]# kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead. deployment.apps/dryrun-test created (dry run) [root@master test]# kubectl get pod,deploy No resources found.
--Dry run means that the command is not really executed during the trial run (test whether the command is correct), that is, the pod and deployment instances will not be created. The command can be really executed after removing this parameter.
7.2 viewing the generated yaml format
Use -- dry run for trial run without triggering the generation command, and then use - o yaml to view its yaml resource configuration list
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml
[root@master test]# kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
run: dryrun-test
name: dryrun-test
spec:
replicas: 3
selector:
matchLabels:
run: dryrun-test
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
run: dryrun-test
spec:
containers:
- image: nginx
name: dryrun-test
ports:
- containerPort: 80
resources: {}
status: {}
7.3 viewing the generated json format
Similarly, you can view the json configuration list generated by this command through - o json
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o json
[root@master test]# kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o json
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
{
"kind": "Deployment",
"apiVersion": "apps/v1",
"metadata": {
"name": "dryrun-test",
"creationTimestamp": null,
"labels": {
"run": "dryrun-test"
}
},
"spec": {
"replicas": 3,
"selector": {
"matchLabels": {
"run": "dryrun-test"
}
},
"template": {
"metadata": {
"creationTimestamp": null,
"labels": {
"run": "dryrun-test"
}
},
"spec": {
"containers": [
{
"name": "dryrun-test",
"image": "nginx",
"ports": [
{
"containerPort": 80
}
],
"resources": {}
}
]
}
},
"strategy": {}
},
"status": {}
}
7.4 main differences between yaml and json
● YAML uses space indentation, which is familiar to Python developers.
● JavaScript developers like JSON because it is a subset of JavaScript and can be interpreted and written directly in JavaScript. At the same time, JSON is declared in a simplified way. When using typical variable names without spaces, double quotes in keys are not required.
● there are many parsers that work well in all languages of YAML and JSON.
● in many cases, YAML's blank format can be viewed more easily because formatting requires a more user-friendly method.
● if there is no space visible or indent indicator in your editor, YAML's white space may be more compact and easier to view, but it may be difficult to edit manually.
● JSON serialization and deserialization are much faster, because the functions to be checked are significantly less than YAML, which makes smaller and lighter code able to handle JSON.
● a common misconception is that YAML requires less punctuation and is more compact than JSON, but this is completely wrong. Spaces are invisible, so it seems that there are fewer characters, but if you calculate the actual spaces is necessary to correctly interpret YAML and correct indentation, you will find that YAML actually needs more characters than JSON. JSON does not use spaces to represent hierarchies or groupings, and can be easily flattened by removing unnecessary spaces for more compact transmission.
7.5 exporting generation templates in yaml format
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > dryrun-test.yaml
[root@master test]# kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > dryrun-test.yaml kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead. [root@master test]# ls dryrun-test.yaml nginx-svc-test.yaml nginx-test.yaml
7.6 delete some unnecessary parameters
[root@master test]# vim dryrun-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
#Delete downlink
creationTimestamp: null
labels:
run: dryrun-test
name: dryrun-test
spec:
replicas: 3
selector:
matchLabels:
run: dryrun-test
#Delete downlink
strategy: {}
template:
metadata:
#Delete downlink
creationTimestamp: null
labels:
run: dryrun-test
spec:
containers:
- image: nginx
name: dryrun-test
ports:
- containerPort: 80
#Delete downlink
resources: {}
#Delete downlink
status: {}
7.7 creating instances using yaml templates
kubectl apply -f dryrun-test.yaml
[root@master test]# kubectl apply -f dryrun-test.yaml deployment.apps/dryrun-test created [root@master test]# kubectl get pod,deploy NAME READY STATUS RESTARTS AGE pod/dryrun-test-6c4ddc89bd-25lcm 1/1 Running 0 39s pod/dryrun-test-6c4ddc89bd-bbsnm 1/1 Running 0 39s pod/dryrun-test-6c4ddc89bd-rnmjk 1/1 Running 0 39s NAME READY UP-TO-DATE AVAILABLE AGE deployment.extensions/dryrun-test 3/3 3 3 39s
8. Export the yaml template generated from existing resources and save it as a file
8.1 --expose: view the yaml configuration list of existing resources
kubectl get deploy dryrun-test --export -o yaml
[root@master test]# kubectl get deploy dryrun-test --export -o yaml
Flag --export has been deprecated, This flag is deprecated and will be removed in future.
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"run":"dryrun-test"},"name":"dryrun-test","namespace":"default"},"spec":{"replicas":3,"selector":{"matchLabels":{"run":"dryrun-test"}},"template":{"metadata":{"labels":{"run":"dryrun-test"}},"spec":{"containers":[{"image":"nginx","name":"dryrun-test","ports":[{"containerPort":80}]}]}}}}
creationTimestamp: null
generation: 1
labels:
run: dryrun-test
name: dryrun-test
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/dryrun-test
spec:
progressDeadlineSeconds: 600
replicas: 3
revisionHistoryLimit: 10
selector:
matchLabels:
run: dryrun-test
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
run: dryrun-test
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: dryrun-test
ports:
- containerPort: 80
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
status: {}
8.2 save to file
kubectl get deploy dryrun-test --export -o yaml > export-test.yaml
[root@master test]# kubectl get deploy dryrun-test --export -o yaml > export-test.yaml Flag --export has been deprecated, This flag is deprecated and will be removed in future. [root@master test]# ls dryrun-test.yaml export-test.yaml nginx-svc-test.yaml nginx-test.yaml
9. explain: view field help information
You can view the help information of related resource objects layer by layer
kubectl explain deployments.spec.template.spec.containers
[root@master test]# kubectl explain deployments.spec.template.spec.containers
KIND: Deployment
VERSION: extensions/v1beta1
RESOURCE: containers <[]Object>
DESCRIPTION:
List of containers belonging to the pod. Containers cannot currently be
added or removed. There must be at least one container in a Pod. Cannot be
updated.
A single application container that you want to run within a pod.
FIELDS:
args <[]string>
Arguments to the entrypoint. The docker image's CMD is used if this is not
provided. Variable references $(VAR_NAME) are expanded using the
container's environment. If a variable cannot be resolved, the reference in
the input string will be unchanged. The $(VAR_NAME) syntax can be escaped
with a double $$, ie: $$(VAR_NAME). Escaped references will never be
expanded, regardless of whether the variable exists or not. Cannot be
updated. More info:
https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell
......
kubectl explain pods.spec.containers
[root@master test]# kubectl explain pods.spec.containers
KIND: Pod
VERSION: v1
RESOURCE: containers <[]Object>
DESCRIPTION:
List of containers belonging to the pod. Containers cannot currently be
added or removed. There must be at least one container in a Pod. Cannot be
updated.
A single application container that you want to run within a pod.
FIELDS:
args <[]string>
Arguments to the entrypoint. The docker image's CMD is used if this is not
provided. Variable references $(VAR_NAME) are expanded using the
container's environment. If a variable cannot be resolved, the reference in
the input string will be unchanged. The $(VAR_NAME) syntax can be escaped
with a double $$, ie: $$(VAR_NAME). Escaped references will never be
expanded, regardless of whether the variable exists or not. Cannot be
updated. More info:
https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell
......
10. Obtain a summary of the resource allocation list
● if there are no relevant resources, use the run command -- dry run option
kubectl run dryrun-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > dryrun-test.yaml
● if relevant resources are available, use the get command -- export option
kubectl get deploy dryrun-test --export -o yaml > export-test.yaml