Shulou(Shulou.com)06/02 Report--

The basic operation command for command line resource creation / / creates a deployment resource object. (pod controller) [root@master ~] # kubectl run test-- image=httpd-- port=80-- replicas=2 / / delete controller: [root@master ~] # kubectl delete deployments. Test// deletes all pod: [root@master ~] # kubectl delete deployments. -- all / / View deployment resource object [root@master ~] # kubectl get deployments.// to see which node pod is running on [root@master ~] # kubectl get pod-o wide// View resource object [root@master ~] # kubectl get svc// mapped by service to view the details of a resource (service). [root@master ~] # kubectl describe svc test// Delete Resource object: [root@master ~] # kubectl delete services test// View deployment resource details: [root@master ~] # kubectl describe deployments. Test-web// view details of a pod: [root@master ~] # kubectl describe pod test-web-8697566669-52tq// View details of replicas [root@master ~] # kubectl get replicasets.replicas: and controller manager are both a controller / / edit a resource object (both servie,pod,namespace can be edited): [root@master ~] # kubectl edit deployments. Test-web / / Import (convert) the output information in json format into yaml format text: (and vice versa) [root@master ~] # kubectl get deployments. Capacity expansion and reduction of test-web-o json > test2.yaml service

Method 1: command line method:

1) create a deployment resource object: [root@master] # kubectl run test-- image=httpd-- port=80-- replicas=2 kubectl run-- generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. When Use kubectl run--generator=run-pod/v1 or kubectl create instead.deployment.apps/test created// returns, there will be a normal prompt (as shown above) indicating that the deployment controller will be removed in a future version and will be replaced by pod later. [root@master] # kubectl get deployments. -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORtest 2ax 2 2 2 68 s test httpd run=test

2) carry out capacity expansion operation

/ / expand the replica capacity of the resource object to 4: [root@master ~] # kubectl scale deployment test-- replicas=4deployment.extensions/test scaled

/ / check whether the expansion is successful:

[root@master] # kubectl get deployments. -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORtest 4ax 4 4 4 3m40s test httpd run=test

3) carry out the capacity reduction operation (same as the capacity expansion, it can be reduced)

/ / reduce the copy of the resource object to 3: [root@master ~] # kubectl scale deployment test-- replicas=3deployment.extensions/test scaled [root@master ~] # kubectl get deployments. -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORtest 3ax 3 3 3 7m14s test httpd run=test

Method 2: you can also use the edit editor:

/ / expand the number of copies of the deployment to 4: [root@master ~] # kubectl edit deployments. Test

/ / check the number of copies again, and the capacity has been expanded successfully: [root@master ~] # kubectl get deployments. Update and rollback of o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORtest 4ax 4 4 4 11m test httpd run=test service

1) build a private registry repository and upload custom images:

For a brief description of the process of building a private warehouse, please refer to the previous blog post and click on the link.

/ / Image rename: [root@master ~] # docker tag nginx:latest 172.16.1.30:5000/nginx:v1.0 [root@master ~] # docker tag nginx:latest 172.16.1.30:5000/nginx:v2.0 [root@master ~] # docker tag nginx:latest 172.16.1.30:5000/nginx:v3.0// upload Image: [root@master ~] # docker push 172.16.1.30:5000/nginx:v1.0 [root@master ~] # docker push 172.16.1.30:5000/nginx:v2.0 [root@master ~] # docker push 172.16.1.30:5000/nginx:v3.0

2) create a deployment:

[root@master] # kubectl run mynginx-- image=172.16.1.30:5000/nginx:v1.0-- replicas=4

/ / View the image version information: [root@master ~] # kubectl get deployments. -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORmynginx 4ax 4 4 4 4m51s mynginx 172.16.1.30:5000/nginx:v1.0 run=mynginx

# # if the pod is not working properly, the wrong train of thought:

1, view the details through the describe command. [root@master ~] # kubectl describe pod bdqn-web-7ff466c8f5-p6wcw 2, by viewing the log information of kubelet. [root@master ~] # cat / var/log/messages | grep kubelet

Update the mirror version of the service

/ / Update the image as nginx:v2.0 [root@master ~] # kubectl set image deployment mynginx mynginx=172.16.1.30:5000/nginx:v2.0deployment.extensions/mynginx image updated// to see if the update is successful: [root@master ~] # kubectl get deployments. -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORmynginx 4ax 4 4 4 11m mynginx 172.16.1.30:5000/nginx:v2.0 run=mynginx

You can see that the image has been updated successfully.

# method 2: you can also modify it through the edit editor:

/ / Update the image version to nginx:v3.0 [root@master ~] # kubectl edit deployments. Mynginx

/ / after saving and exiting (same as the vim editor), check the image version: [root@master ~] # kubectl get deployments. -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORmynginx 4ax 4 4 4 16m mynginx 172.16.1.30:5000/nginx:v3.0 run=mynginx

Perform a rollback mirror operation

/ / perform a rollback operation: [root@master ~] # kubectl rollout undo deployment mynginx deployment.extensions/mynginx rolled back [root@master ~] # kubectl get deployments. -o wide # you can see that the rollback operation has been successfully rolled back by NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORmynginx 4gambo 4418m mynginx 172.16.1.30:5000/nginx:v2.0 run=mynginx//: [root@master ~] # kubectl rollout undo deployment mynginx deployment.extensions/mynginx rolled back// view back Rolled image version: [root@master ~] # kubectl get deployments. -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORmynginx 4ax 4 4 4 20m mynginx 172.16.1.30:5000/nginx:v3.0 run=mynginx

You can clearly see that the default rollback operation of K8s is the same as that of the docker swarm cluster, only between the two versions.

Resource list of how resources are passed and created (yaml)

To create a resource list, you must know and remember the following must-write first-level fields:

ApiVersion: version of api kind: the type of resource object to be created metadata: metadata. (describes the basic information of the resource object) where the name field is a required field. Spec: describes the state expected by the user. The container and image fields are required fields, container- > image.status: the state where pod is now. (automatically generated with the running of the pod container) 1, check out all the versions of api: (each version has its own function, of course, you can add your own version) [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

2. Tools to help you write yaml files (explain):

Be sure to use familiarity. It's very useful.

/ / for example, to create a pod, which fields and corresponding versions and prompts are needed: [root@master ~] # kubectl explain pod

/ / check how the metadata field of the help deployment is written: [root@master ~] # kubectl explain deploy.metadata # some resource object names can be abbreviated or completed

It will give some corresponding subfields, such as name name, namespace namespace, and so on.

3, let's write a simple yaml file to deploy nginx

Tip: be sure to pay attention to the format (indentation) when writing yaml files

[root@master yaml] # vim nginx.yaml # Note that it ends with .yaml

Kind: Deployment # type is deploymentapiVersion: extensions/v1beta1 # corresponding version is v1beta1metadata: name: nginx-deploy # defines the name of the resource object spec: replicas: 2 # number of copies is 2 template: # define template metadata: labels: # define tags in the template The role of the tag is used to connect the service later using app: web-server spec: containers:-name: nginx # define the pod name (custom) image: nginx # specify the image / / run the yaml file: (there are two ways) [root@master yaml] # kubectl apply-f nginx.yaml # this method deployment.extensions/nginx-deploy created is recommended

Or:

[root@master yaml] # kubectl create nginx.yaml

/ / check whether pod is running successfully: [root@master yaml] # kubectl get pod NAME READY STATUS RESTARTS AGEnginx-deploy-56558c8dc7-pjdkk 1 117snginx-deploy-56558c8dc7-rxbpb 1 Running 0 117snginx-deploy-56558c8dc7-rxbpb 1 Running 0 117s// if you need to delete the resource object through the yaml file: [root@master yaml] # kubectl delete-f nginx.yaml deployment.extensions "nginx-deploy" deleted

This method is also commonly used, there is no need to manually delete the pod one by one.

4. Create a service resource object to associate the above deployment

The role of service is mainly used to provide a unified interface to access services. K8s cluster maintains the mapping relationship between service and endpoint.

/ / write the yaml file of service: [root@master yaml] # vim nginx-svc.yamlapiVersion: v1kind: Servicemetadata: name: nginx-svcspec: type: NodePort # defines the type of service as nodeport selector: # tag selector, which is used to associate deployment app: web-server # Note: the tag must have the same deployment tag Otherwise, you cannot associate ports: # define port-protocol: TCP # protocol for TCP port: 8080 # define port corresponding to cluster ip targetPort: 80 # define port in container nodePort: 30000 # port exposed to public network

/ / execute the yaml file:

[root@master yaml] # kubectl apply-f nginx-svc.yaml

Service/nginx-svc created

/ / View the information of service:

Explanation:

Service defaults to the type of Cluster ip. Cluster ip only supports access within the cluster, and each node in the cluster can access each other through this ip address.

The type of nodeport is the port exposed to the external network, which can be accessed through the host's ip address + mapped port.

/ / Test access to the nginx page:

Set up the master node to participate in the work:

As we know in the K8s architecture, the master nodes in the cluster do not participate in the work by default, so what should we do if we need master to participate in the work?

1) execute the following command to set the working status: [root@master yaml] # kubectl taint node master node-role.kubernetes.io/master-node/master untainted2) modify the above yaml file to change the number of copies to 3. [root@master yaml] # vim nginx.yaml kind: DeploymentapiVersion: extensions/v1beta1metadata: name: nginx-deployspec: replicas: 3 template: metadata: labels: app: web-server spec: containers:-name: nginx image: nginx3) re-execute yaml file: [root@master yaml] # kubectl apply-f nginx.yaml deployment.extensions/nginx-deploy configured4) verify that pods are assigned to master: (default is not assigned For master) [root@master yaml] # kubectl get pod-o wide

You can see that it is evenly distributed to each node in the cluster to achieve load balancing.

Restore master node (do not work) [root@master yaml] # kubectl taint node master node-role.kubernetes.io/master= "": NoSchedulenode/master tainted// rerun the yaml file to see if pod will also be assigned to master[ root @ master yaml] # kubectl delete-f nginx.yaml deployment.extensions "nginx-deploy" deleted [root@master yaml] # kubectl apply-f nginx.yaml deployment.extensions/nginx-deploy created

Note: the pod above is already a new pod. Like docker swarm, the pod originally assigned to the master will still exist, but the generated pod will be randomly assigned to other nodes.

Specify the location of the node where pod is running

We know that pod is randomly assigned to nodes through the kube-proxy component, but what if we want to specify which node pod is running on?

Like docker swarm, we can do this by tagging nodes.

1) / define tag: [root@master yaml] # kubectl label nodes node01 test=123 # tag Custom node/node01 labeled// if you want to delete the tag: [root@master yaml] # kubectl label nodes node01 disktype-2) / / verify the node tag and display their tag status: [root@master yaml] # kubectl get nodes-- show-labels

If we look at the node01, we can see the tag just defined.

3) / modify yaml file: [root@master yaml] # vim nginx.yaml kind: DeploymentapiVersion: extensions/v1beta1metadata: nginx-deployspec: replicas: 6 template: metadata: labels: app: web-server spec: containers:-name: nginx image: nginx nodeSelector: # add node selector test: '123' # specify the tag you just customized If there are numbers, you need to enclose them in single or double quotes / / re-execute the yaml file: [root@master yaml] # kubectl apply-f nginx.yaml deployment.extensions/nginx-deploy configured4) / / to see if pod will run on the specified node01: [root@master yaml] # kubectl get pod-o wide

Note: the pod that was originally running on this node will be replaced.

-this is the end of this article. Thank you for reading-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.