Management operations of k8s resource configuration list

---

1. Resource allocation list

Kubernetes supports YAML and JSON formats to manage resource objects.
JSON format: mainly used for message transfer between api interfaces.
YAML format: used for configuration and management. YAML is a concise non-markup language with user-friendly content format and easy to read

1.1 Preliminary understanding of the important configuration items of svc in the resource list

Service yaml文件详解
 
apiVersion: v1
kind: Service
matadata:                                #元数据
  name: string                           #service的名称
  namespace: string                      #命名空间  
  labels:                                #自定义标签属性列表
    - name: string
  annotations:                           #自定义注解属性列表  
    - name: string
spec:                                    #详细描述
  selector: []                           #label selector配置，将选择具有label标签的Pod作为管理 
                                         #范围
  type: string                           #service的类型，指定service的访问方式，默认为 
                                         #clusterIp
  clusterIP: string                      #虚拟服务地址      
  sessionAffinity: string                #是否支持session
  ports:                                 #service需要暴露的端口列表
  - name: string                         #端口名称
    protocol: string                     #端口协议，支持TCP和UDP，默认TCP
    port: int                            #服务监听的端口号
    targetPort: int                      #需要转发到后端Pod的端口号
    nodePort: int                        #当type = NodePort时，指定映射到物理机的端口号
  status:                                #当spce.type=LoadBalancer时，设置外部负载均衡器的地址
    loadBalancer:                        #外部负载均衡器    
      ingress:                           #外部负载均衡器 
        ip: string                       #外部负载均衡器的Ip地址值
        hostname: string                 #外部负载均衡器的主机名

YAML syntax format:
●Case-sensitive
●Use indentation to indicate hierarchical relationship
●Do not support tab indentation, only use spaces for indentation
●The number of indented spaces is not important, as long as the elements of the same level are aligned on the left , usually indented with two spaces
at the beginning. Symbol characters are indented with one space, such as colon, comma, short horizontal bar (-), etc. "—"
means YAML format, the beginning of a file, used to separate files.
"# " means comment

View api resource version tags

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                  #如果是业务场景一般首选使用 apps/v1
batch/v1beta1             #带有beta字样的代表的是测试版本，不用在生产环境中
certificates.k8s.io/v1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
discovery.k8s.io/v1beta1
events.k8s.io/v1
events.k8s.io/v1beta1
extensions/v1beta1
flowcontrol.apiserver.k8s.io/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1
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

1.2 Manually write svc resource configuration

示例1：
编写service服务的资源清单
mkdir /opt/demo
cd demo/

vim nginx-server.yaml
 
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: default
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080
  selector:
    app: nginx
 
 
 
#创建资源对象
kubectl create -f nginx-server.yaml 
 
#查看创建的service
kubectl get svc

示例2：
cd demo/

vim nginx-deployment.yaml
apiVersion: apps/v1		#指定api版本标签
kind: Deployment		#定义资源的类型/角色，deployment为副本控制器，此处资源类型可以是Deployment、Job、Ingress、Service等
metadata:					#定义资源的元数据信息，比如资源的名称、namespace、标签等信息
  name: nginx-deployment	#定义资源的名称，在同一个namespace空间中必须是唯一的
  labels:				#定义Deployment资源标签
    app: nginx	
spec:					#定义deployment资源需要的参数属性，诸如是否在容器失败时重新启动容器的属性
  replicas: 3			#定义副本数量
  selector:				#定义标签选择器
    matchLabels:		#定义匹配标签
      app: nginx		#需与 .spec.template.metadata.labels 定义的标签保持一致
  template:				#定义业务模板，如果有多个副本，所有副本的属性会按照模板的相关配置进行匹配
    metadata:
      labels:           #定义Pod副本将使用的标签，需与 .spec.selector.matchLabels 定义的标签保持一致
        app: nginx
    spec:
      containers:				#定义容器属性
      - name: nginx				#定义一个容器名，一个 - name: 定义一个容器
        image: nginx:1.15.4		#定义容器使用的镜像以及版本
        ports:
        - containerPort: 80		#定义容器的对外的端口

//创建资源对象
kubectl create -f nginx-deployment.yaml

//查看创建的pod资源
kubectl get pods -o wide

kubectl get deployment.apps --show-labels

kubectl get pods --show-labels

kubectl describe deployment.apps

Note: The label name under the selector label selector must be consistent with the label name used by the pod copy under the template, so that the controller can determine which Pods are controlled. If they are inconsistent, resource creation will fail, and even if the creation is successful, the Pod will run
away

Supplement:
Detailed explanation of ports in k8s
Port
port is the port for accessing the service within the k8s cluster, 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 the service in the k8s cluster through nodeIP : nodePort can access a service from the outside.
● targetPort
targetPort is the port of the Pod. The traffic from the port or nodePort is load-balanced and forwarded to the targetPort of the back-end Pod through the kube-proxy reverse proxy, and finally enters the container.
● containerPort
containerPort is the port of the container inside the Pod, and targetPort is mapped to containerPort

1.3 Manually generate templates and write resource lists

(1) Generate a template

//kubectl run --dry-run=client 打印相应的 API 对象而不执行创建
kubectl run nginx-test --image=nginx --port=80 --dry-run=client
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client

//查看生成yaml格式
kubectl run nginx-test --image=nginx --port=80 --dry-run=client -o yaml
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml

//查看生成json格式
kubectl run nginx-test --image=nginx --port=80 --dry-run=client -o json
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client -o json

//使用yaml格式导出生成模板，并进行修改以及删除一些不必要的参数
kubectl run nginx-test --image=nginx --port=80 --dry-run=client -o yaml > nginx-test.yaml
kubectl create deployment nginx-deploy --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml  > nginx-deploy.yaml

vim nginx-test.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null     #删除
  labels:
    run: nginx-test
  name: nginx-test
spec:
  containers:
  - image: nginx
    name: nginx-test
    ports:
    - containerPort: 80
    resources: {
    
    }             #删除
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {
    
    }                    #删除


//将现有的资源生成模板导出
kubectl get svc nginx-service -o yaml

//保存到文件中
kubectl get svc nginx-service -o yaml > my-svc.yaml

//查看字段帮助信息，可一层层的查看相关资源对象的帮助信息
kubectl explain deployments.spec.template.spec.containers
或
kubectl explain pods.spec.containers

1.4 What should I do if writing yaml is too tiring?

●用 --dry-run 命令生成
kubectl run my-deploy --image=nginx --dry-run=client -o yaml > my-deploy.yaml

●用get命令导出
kubectl get svc nginx-service -o yaml > my-svc.yaml
或
kubectl edit svc nginx-service  #复制配置，再粘贴到新文件

1.5 Download the resource template from the official website

www.kubernetes.io