K8s学习（二）Kubernetest的资源管理及五大资源介绍-Toy模板网

这篇具有很好参考价值的文章主要介绍了K8s学习（二）Kubernetest的资源管理及五大资源介绍。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

前言

本文是k8s学习系列文章，前后串起来是一个完整的课程（学习笔记），本文记录k8s的资源管理方式及五大类资源的具体管理命令，看完本文基本上就能实现k8s的基本操作，可以独立部署小型项目了。
前期文章连接：
从零开始搭建kubernetes集群环境（虚拟机/kubeadm方式）

1.kubernetes的资源管理

k8s学习资源,k8s学习,kubernetes,docker
总结：学习kubernetes的核心，就是学习如何对集群上的Pod、Pod控制器、Label标签、Service、存储等各种资源进行操作。

系统资源查看

通过kubectl api-resources命令可以查看系统中所有资源，如下图，注意资源类型缩写一列内容，本文后续kubectl命令操作的资源有的用缩写名，跟用全名一样的。
k8s学习资源,k8s学习,kubernetes,docker

2.资源管理方式

命令式对象管理：直接使用命令去操作kubernetes资源

kubectl命令的语法如下：kubectl [命令] [资源类型] [资源名称] [参数]
如 kubectl run nginx-pod --image=nginx:1.17.1 --port=80
命令有很多，老规矩，查看帮助吧 kubectl--help

命令式对象配置：通过命令配置和配置文件去操作kubernetes资源
kubectl create/patch -f nginx-pod.yaml
nginx-pod.yaml是指定的配置文件，具体内容后面实战部分会有，莫急
声明式对象配置：通过apply命令和配置文件去操作kubernetes资源
kubectl apply -f nginx-pod.yaml

问题：乍一看好像后两种方式不好区分，同样是创建一个k8s资源，使用 kubectl create 和使用 kubectl apply有什么区别呢？
区别有两点：
（1）kubectl create命令可创建新资源。因此，如果再次运行该命令，则会抛出错误，因为资源名称在名称空间中是唯一的。
（2）kubectl apply命令将配置应用于资源。如果资源不在那里，那么它将被创建。 kubectl apply命令可以第二次运行，如果资源存在就执行更新，相当于kubectl patch操作

以上三种资源管理方式，命令式对象管理直接操作资源对象，适用于测试环境，操作简单，但是只能操作活动对象且难以审计、跟踪；命令式对象配置操作对应配置文件，可以审计跟踪，但是项目较大时配置文件管理麻烦；声明式对象配置支持目录操作，但是意外情况下不好调式。
（没关系，这里只是学习原理，生产环境还是界面管理工具的，比如我公司用的kuboard）

3.资源管理实战

3.1 Namespace

k8s系统中Namespace资源是用了实现多套环境的资源隔离或者多租户的资源隔离。默认情况下k8s集群中所有Pod资源都是可以相互访问的，但是实际中如果不想让两个Pod之间相互干扰可以将两个Pod划分到不同的namespace下。
k8s通过将集群内部的资源分配到不用的namespace中，形成逻辑上的“组”，方便不同组的资源可以隔离使用和管理。如果将不同的Namespace交给不同租户进行管理，这样就实现了多租户的资源隔离。此时还能结合kubernetes的资源配额机制，限定不同租户能占用的资源，例如CPU使用量、内存使用量等等，来实现租户可用资源的管理。

kubernetes在集群启动之后，会默认创建几个namespace，查看命令如下图所示： k8s学习资源,k8s学习,kubernetes,docker

命令式对象管理，命令示例如下：

kubectl get namespace   #查看所有的命名空间,同kubectl get ns
kubectl get namespace default  #查看指定的命名空间default
kubectl get ns default -o wide #指定命名空间的输出格式，还有-o json，-o yaml格式
kubectl describe namespace default #查看default命名空间的详情
kubectl create namespace dev  #创建命名空间
kubectl delete ns dev    #删除命名空间

命令式对象配置方式如下：

新建ns-dev.yaml配置文件，内容如下：

apiVersion: v1
kind: Namespace
metadata:
  name: dev

通过命令式对象配置进行创建和删除

kubectl create -f ns-dev.yaml
kubectl delete -f ns-dev.yaml

3.2 Pod

Pod是kubernetes集群进行管理的最小单元，可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。kubernetes在集群启动之后，集群中的各个组件也是以Pod方式运行的，可以通过下面的命令查看：
k8s学习资源,k8s学习,kubernetes,docker

命令式对象管理，应用示例如下：

kubectl run (Pod的名称) [参数]   #创建并运行Pod,如kubectl run nginx --image=nginx:1.17.1 --port=80 --namespace=dev
# --image 指定Pod的镜像
# --port 指定端口
# --namespace 指定namespace
kubectl get pods -n dev  #查询名称为dev的namespace下的所有Pod的基本信息
kubectl describe pod nginx -n dev #查看名称为dev的namespace下的Pod的名称为nginx的详细信息
kubectl get pods [-n dev] -o wide  #可以查询到Pod的IP
curl 10.244.2.7:80    #访问Nginx的Pod,ip每次都先查询一下，可能发生变化
kubectl delete pod nginx -n dev #删除Nginx的Pod

命令式对象配置方式只是配置文件内容不一样，命令是相同的，不在列举（搜可得，后续详情文章会详解）：

3.3 Label

Label的作用就是在资源上添加标识，用来对它们进行区分和选择。通过Label可以实现资源的多纬度分组，以便灵活、方便地进行资源分配、调度、配置和部署等管理工作。

Label的特点：

一个Label会以key/value键值对的形式附加到各种对象上，如Node、Pod、Service等。
一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。
Label通常在资源对象定义时确定，也可以在对象创建后动态的添加或删除。

一些常用的Label标签示例如下：
● 版本标签：“version”:”release”,”version”:”stable”。。。
● 环境标签：“environment”:”dev”,“environment”:”test”,“environment”:”pro”
● 架构标签：“tier”:”frontend”,”tier”:”backend”。。。

标签定义完毕之后，还要考虑到如何通过标签选择所需资源，这就要用到Label Selector，当前有两种筛选方式：

基于等式的Label Selector，比如name=slave或者env!=production。
基于集合的Label Selector，比如name in (master,slave)或者name not in (master,slave)

注意：
标签等号后面的值加不加引号都行; 标签的选择条件可以使用多个，此时将多个Label Selector进行组合，使用逗号（,）进行分隔即可

语法及应用示例

kubectl label pod nginx version=1.0 -n dev  #为名称Nginx的Pod资源打上标签version=1.0
kubectl label pod xxx key=value [-n 命名空间] --overwrite #如果标签key已经存在,加--overwrite参数更新资源的标签
kubectl get pod nginx -n dev --show-labels  #显示Nginx的Pod的标签
kubectl get pod -l version=2.0 -n dev --show-labels #筛选版本号是2.0的在名称为dev的namespace下的Pod
kubectl label pod xxx key- [-n 命名空间] #删除标签 key减号

3.4 Deployment

在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Deployment是一种Pod控制器，用于Pod的管理，确保Pod资源符合预期的状态，当Pod的资源出现故障的时候，会尝试进行重启或重建Pod。
在kubernetes中Pod控制器的种类有很多，本章节只介绍一种：Deployment。

语法及应用示例

kubectl create deployment nginx --image=nginx:1.17.1 -n dev #为e名称Nginx的Pod资源打上标签version=1.0
kubectl scale deployment nginx --replicas=4 -n dev #在名称为test的命名空间下根据名为nginx的deployment创建3个Pod
kubectl get deployment -n dev  #查看名称为dev的namespace下的deployment信息
kubectl describe deployment nginx -n dev  #查看deployment的详细信息
kubectl delete deployment nginx -n dev  #删除名为nginx的deployment

小知识1：kubectl run nginx --image=nginx --replicas=2 --port=80，创建一个名称为nginx的deployment, 新版本可能会反馈Flag --replicas has been deprecated, has no effect and will be removed in the future，并且只会创建一个Nginx容器实例。
小知识2：kubectl run nginx --image=nginx --replicas=2 --port=80，创建一个名称为nginx的deployment这个deployment中默认生成了对应的pod资源，如果删除其中的Pod,这个deployment会尝试创建一个新的Pod，这个特性也在新版本删除了，直接删除Pod就能删除成功了。

3.5 Service

kubernetes设计了Service来解决外部环境访问容器资源的问题。Pod资源可以提供具有高可用性的服务，虽然每个Pod都会分配一个单独的IP地址，但Pod的IP会随着Pod的重建产生变化，且Pod的IP仅仅是集群内部可见的虚拟的IP，外部无法访问。
Service可以看做是一组同类的Pod对外的访问接口，借助Service，应用可以方便的实现服务发现和负载均衡。
k8s学习资源,k8s学习,kubernetes,docker

3.5.1创建集群内部可访问的Service

语法：

kubectl expose deployment xxx --name=服务名 --type=ClusterIP --port=暴露的端口 --target-port=指向集群中的Pod的端口 [-n 命名空间]
#–type=ClusterIP会产生一个CLUSTER-IP，这个就是service的IP，在Service的生命周期内，这个地址是不会变化的

#暴露名为dev的namespace下的名为nginx的deployment，并设置服务名为svc-nginx
kubectl expose deployment nginx --name=svc-nginx --type=ClusterIP --port=80 --target-port=80 -n dev
#访问service的80端口，转发到Pod的80端口

kubectl get service -n dev #查看名为dev的命名空间的所有Service
curl ip:80  #在集群内通过master节点ip可以访问部署的nginx服务

3.5.2创建集群外部可访问的Service

语法：

kubectl expose deployment xxx --name=服务名 --type=NodePort --port=暴露的端口 --target-port=指向集群中的Pod的端口 [-n 命名空间]
#–type=NodePort参数会产生一个外部也可以访问的Service,

#例：暴露名为test的namespace下的名为nginx的deployment，并设置服务名为svc-nginx-1
kubectl expose deploy nginx --name=svc-nginx-1 --type=NodePort --port=80 --target-port=80 -n dev

此时外部环境可以通过master节点IP进行访问了，端口查询方法如下图：

k8s学习资源,k8s学习,kubernetes,docker
总结：以上就是kubernetes的Namespace/Pod/Deployment/Service资源的基本操作，学会这些操作就可以在集群中实现一个服务的简单部署和访问了。但是如果想更好的使用k8s,接下来需要深入学习这几种资源的细节和原理。文章来源地址https://www.toymoban.com/news/detail-795392.html