Kubernetes笔记 (2) - 资源对象、kubectl

Kubernetes集群将所有节点上的资源都整合到一个大的虚拟资源池里,以代替一个个单独的服务器。如果把集群类比为一台传统的服务器,那么Kubernetes(Master)就好比是操作系统内核,其主要职责在于抽象资源并调度任务,而Pod资源对象就是那些运行于用户空间中的进程。

资源对象

API Server提供了RESTful风格的编程接口,其管理的资源是Kubernetes API中的端点,用于存储某种API对象的集合。Pod、Deployment和Service等都是最常用的核心对象。

Pod资源对象

Pod资源对象是一种集合了一到多个应用容器、存储资源、专用IP及支撑容器运行的其他选项的逻辑组件,是Kubernetes的部署单元及原子运行单元。
Kubernetes的网络模型要求其各Pod对象的IP地址位于同一网络平面内(同一IP网段),可以将每个Pod对象想象成一个逻辑主机,类似常规的物理主机或VM,运行于同一个Pod对象中的多个进程也类似于物理机或VM上独立运行的进程。
不过,Pod对象中的各进程均运行于彼此隔离的容器中,并于各容器间共享两种关键资源:网络和存储卷

  • 网络:每个Pod对象都会被分配一个集群内专用的IP地址(PodIP),同一Pod内部的所有容器共享Pod对象的主机名、IP地址和端口等。因此,这些容器间可以通过本地回环地址进行通信。
  • 存储卷:还为Pod对象配置一组“存储卷”资源,这些资源可以共享给其内部的所有容器使用。

一个Pod对象代表某个应用程序的一个特定实例,如果需要扩展应用程序,就可以通过为此应用程序创建多个Pod实例来实现。

Controller资源对象

在工作节点甚至是调度器自身导致了运行失败时,Pod对象将会被删除;同样,资源耗尽或节点故障导致的回收操作也会删除相关的Pod对象。
Kubernetes使用Controller实现对一次性的(用后即弃)Pod对象的管理操作,例如,要确保部署的应用程序的Pod副本数量符合用户的设定,以及基于Pod模板来重建Pod对象等,从而实现Pod对象的扩缩容、滚动更新和自愈能力等。

Controller本身也是一种资源类型,它有着多种实现,其中与工作负载相关的实现如:

  • ReplicationController
  • Deployment
  • StatefulSet
  • DaemonSet
  • Jobs

也可统称它们为Pod控制器,控制器的定义通常由期望的副本数量、Pod模板和标签选择器(Label Selector)组成。它会根据标签选择器对Pod对象的标签进行匹配检查,所有满足选择条件的Pod对象都将受控于当前控制器并计入其副本总数,并确保此数目能够精确反映期望的副本数。

需要注意的是:在实际的应用场景中,在接收到的请求流量负载显著低于或接近于已有Pod副本的整体承载能力时,用户需要手动修改Pod控制器中的期望副本数量以实现应用规模的扩容或缩容。不过,若集群中部署了HeapSter或Prometheus一类的资源指标监控附件时,用户还可以使用“HorizontalPodAutoscaler”(HPA)计算出合适的Pod副本数量,并自动修改Pod控制器中期望的副本数以实现应用规模的动态伸缩,提高集群资源利用率。

Service资源对象

Service主要有三种常用类型:

  1. 仅用于集群内部通信的ClusterIP类型
  2. 接入集群外部请求的NodePort类型
  3. LoadBalancer类型
仅用于集群内部通信的ClusterIP类型

Pod对象重启或被重建后IP地址通常会发生变化,Service资源对象的作用便是在被访问的Pod对象与客户端之间添加一个有着固定IP地址的中间层,客户端向此地址发起访问请求后,相关的Service资源会负责将请求调度并代理至后端的Pod对象。Service IP是一种虚拟IP,也称为Cluster IP,它专用于集群内通信。

Service是“微服务”的一种实现,事实上它是一种抽象:通过规则定义出由多个Pod对象组合而成的逻辑集合,并附带访问这组Pod对象的策略。Service对象挑选、关联Pod对象的方式同Pod控制器一样,都是要基于Label Selector进行。

接入集群外部请求的NodePort类型

ClusterIP仅对集群内部开放,外部访问集群可通过NodePort,根据某个Node的IP和端口(NodePort)接入请求,并将其代理至相应的Service对象的Cluster IP上的服务端口,而后由Service对象将请求代理至后端的Pod对象的PodIP及应用程序监听的端口。这种请求需要经过两次转发。

LoadBalancer类型

NodePort会部署于集群中的每一个节点,只能访问到指定Node上的Service,如果存在集群外部的LoadBalancer,即可将用户请求负载均衡至集群中的部分或者所有节点。LoadBalancer通常是由Cloud Provider自动创建并提供的软件负载均衡器,也可以是由管理员手工配置的硬件设备。

K8S部署应用程序的基本过程

容器技术使得部署程序时不再需要直接更改主机环境,而K8S又使得创建和运行容器的操作不必再关注其主机位置,并在一定程度上赋予了它动态扩缩容及自愈的能力,从而让用户从主机、系统及应用程序的维护工作中解脱出来。

部署某个应用程序时,用户首先要向API Server请求创建一个Pod控制器,由控制器根据镜像等信息向API Server请求创建出一定数量的Pod对象,并由Master之上的调度器指派至选定的工作节点以运行容器化应用。此外,用户一般还需要创建一个具体的Service对象以便为这些Pod对象建立起一个固定的访问入口,从而使得其客户端能够通过其服务名称或ClusterIP进行访问。
API Server的客户端工具有kubectl和Dashboard。

kubectl的基础使用

Kubernetes API(API Server)是管理其各种资源对象的唯一入口,它提供了一个RESTful风格的CRUD(Create、Read、Update和Delete)接口用于查询和修改集群状态,并将结果存储于集群状态存储系统etcd中。
用户可以通过kubectl访问API Server来操作Kubernetes的各种资源对象。

创建资源对象

kubectl run nginx-deploy --image=nginx:1.12 --replicas=1

这样的命令创建了一个名为nginx-deploy的deployment控制器资源,然后由这个资源来根据指定的镜像名称、副本数量来负责pod的创建。

查看资源对象
kubectl get命令用于查看资源对象

~ kubectl get namespaces
NAME              STATUS   AGE
default           Active   23h
kube-node-lease   Active   23h
kube-public       Active   23h
kube-system       Active   23h
~ kubectl get pods
NAME           READY   STATUS    RESTARTS   AGE
myapp          1/1     Running   0          14h
nginx-deploy   1/1     Running   0          14h

Kubernetes系统的大部分资源都隶属于某个Namespace对象,缺省的名称空间为default,若需要获取指定Namespace对象中的资源对象的信息,则需要使用-n或--namespace指明其名称

打印资源对象的详细信息
kubectl get -o {yaml|josn}kubectl describe命令都能够打印出指定资源对象的详细描述信息.
kubectl get -o {yaml|josn}可以查看资源对象的用户期望状态(Spec)和现有的实际状态(Status),比如查看default namespaces下所有pods的状态信息并输出为yaml格式:

~ kubectl get pods -n default -o yaml  

kubectl describe命令可以显示资源的event、controller等信息。

~ kubectl describe pods myapp

打印容器中的日志信息
命令格式为:

kubectl logs [-f] [-p](POD|TYPE/NAME) [-c CONTAINER][options]

可打印指定Pod内指定容器的日志,如果Pod内只有一个容器,则容器名可省略,-f可用于持续监控日志输出。

在容器中执行命令
命令格式为:

kubectl exec [-p](POD|TYPE/NAME) [-c CONTAINER][options] -- [COMMAND]

删除资源对象
kubectl delete命令可以删除资源对象,但对于受控于控制器的对象来说,删除之后其控制器可能会重建出类似的对象,例如,Deployment控制器下的Pod对象在被删除时就会被重建。
有些资源类型(如Pod),支持优雅删除的机制,它们有着默认的删除宽限期,可以在命令中使用--grace-period选项或--now选项来覆盖默认的宽限期。

学习资料

《Kubernetes实战进阶》 马永亮著

posted @ 2021-04-02 22:06  zhixin9001  阅读(36)  评论(0编辑  收藏  举报