k8s学习
概念
集群类
集群表示由一个Master和很多Node组成的K8s集群,其中Master指的是集群的控制节点,除Master以外的都是Node,用于进行工作负载
命名空间
命名空间用于多租户的资源隔离,典型的思路是给每个租户分配一个命名空间,每个命名空间相互独立,也即他们相互之间是不可视的,每个k8s集群安装完成之后,Master会自动创建两个命名空间,一个default一个kube-system,用户创建的资源如果没有指定命名空间的话,就会放在default里,而系统相关的资源对象如网络组件等,被安装在kube-system空间中。
给每个租户创建一个命名空间来隔离的同时,也可以通过命名空间来对租户进行资源配额管理
Service
k8s里的Service具有一个全局唯一的虚拟ClusterIP地址,且在Service的整个生命周期中都不会改变,客户端可以通过虚拟IP地址+服务的端口号直接访问该服务,再通过集群的DNS服务,就可以实现从Service Name到ClusterIP的DNS映射功能
Pod
每个Pod都有一个被称为“根容器”的Pause容器,除此之外还有一个或多个紧密相关的用户业务容器
Pod里的多个业务共享Pause容器的IP和Pause容器挂载的Volume,这样即简化了密切关联的业务容器之间的通信问题也很好的解决了他们之间的文件共享问题
与Service相似,k8s为每个Pod分配唯一的IP地址,一个Pod中的多个容器共享Pod IP
Pod IP和Pod里的容器的端口就组成了Endpoint,代表此Pod里的这个服务进程(容器)的对外通信地址
Deployment
用于给无状态服务建模,进行Pod部署,Deployment通过Label Selector来设定哪些容器在Pod中运行,还可以设定Pod的副本数量以及Pod或Node损坏时恢复用的Pod模板
由于Pod有被迁移的可能(Node出现问题或Pod出现问题的时候,k8s会根据模板重新部署Pod),所以Pod的IP就有变化的可能,为了保证集群里的其他Service能正确进行通信,Deployment部署之后会产生一个管理Pod的Service,这个Service的Label选择器和Pod的是一样的,而且Service的IP固定,所以不管Pod是否被重新创建,其他Service只要访问该Service的IP+端口就可以直接访问
标签
每种资源都可以定义自己的Label,通过Label Selector,我们可以设定某个Service包含哪些Pod
各种IP
k8s里面有三种IP,分别是Service的Cluster IP;Pod的Pod IP;Node的Node IP
Cluster IP,也即Service IP是虚拟IP,他只能用于集群内部通信,也就是说不同的Service之间的通信就可以通过Cluster IP来实现
Pod IP,就是k8s给Pod分配的IP地址,集群内不同的Pod之间访问,或同一个Pod内部不同容器之间的访问就可以通过Pod IP
Node IP,是真实存在的物理网络,是集群里节点的物理网卡的IP地址,集群外的节点访问集群内的某个节点时就需要通过Node IP来通信
Job
用于给批处理应用建模,其中有两个控制并发数的参数:completions和parallelism
completions表示需要运行的任务总数
parallelism表示并发运行的个数
与Deployment不同的是,Job生成的Pod副本是不能自动重启的,对应Pod副本的restartPolicy都被设置为Never,因此,当对应的Pod副本都执行完成时,相应的Job也就完成了控制使命。
存储类
Volume
Volume(存储卷),Volume被定义在Pod上,被一个Pod里的多个容器挂载到具体的文件目录下,Volume与 Pod的生命周期相同,但与容器的生命周期不相关,当容器终止或者重启时,Volume中的数据也不会丢失
Volume的使用方法很简单,举例来说,若我们要给之前的Tomcat Pod增加一个名为datavol的Volume,并将其挂载到容器的/mydata-data目录下,则只对Pod的定义文件做如下修正即可
template:
metadata:
labels:
app: app-demo
tier: frontend
spec:
volumes: //
-name: datavol //
emptyDir: {} //
containers:
-name: tomcat-demo
image: tomcat
volumeMounts: //
-mountPath: /mydata-data //
name:datavol //
Kubernetes提供了非常丰富的Volume类型供容器使用,例如临时目录、宿主机目录、共享存储等,下面对其中一些常见的类型进行说明。
emptyDir
一个emptyDir是在Pod分配到Node时创建的。从它的名称就可以看出,它的初始内容为空,并且无须指定宿主机上对应的目录文件,因为这是Kubernetes自动分配的一个目录,当Pod从Node上移除时, emptyDir中的数据也被永久移除。emptyDir的一些用途如下。
◎ 临时空间,例如用于某些应用程序运行时所需的临时目录,且无须永久保留。
◎ 长时间任务执行过程中使用的临时目录。
◎ 一个容器需要从另一个容器中获取数据的目录(多容器共享目录)。
hostPath
hostPath为在Pod上挂载宿主机上的文件或目录,通常可以用于以下几方面。
◎ 在容器应用程序生成的日志文件需要永久保存时,可以使用宿主机的高速文件系统对其进行存储。
◎ 需要访问宿主机上Docker引擎内部数据结构的容器应用时,可以通过定义hostPath为宿主机/var/lib/docker目录,使容器内部的应用可以直接访问Docker的文件系统。
其他类型的Volume
◎ iscsi:将iSCSI存储设备上的目录挂载到Pod中。
◎ nfs:将NFS Server上的目录挂载到Pod中。
◎ glusterfs:将开源GlusterFS网络文件系统的目录挂载到Pod 中。
◎ rbd:将Ceph块设备共享存储(Rados Block Device)挂载到 Pod中。
◎ gitRepo:通过挂载一个空目录,并从Git库克隆(clone)一个 git repository以供Pod使用。
◎ configmap:将配置数据挂载为容器内的文件。
◎ secret:将Secret数据挂载为容器内的文件。
PV
Persistent Volume(简称PV),表示由系统动态创建(dynamically provisioned)的一个存储卷,可以被理解成Kubernetes集群中某个网络存储对应的一块存储,它与Volume类似,但PV并不是被定义在Pod上的,而是独立于Pod之外定义的。
我们知道,Kubernetes支持的存储系统有多种,那么系统怎么知道从哪个存储系统中创建什么规格的PV存储卷呢?这就涉及StorageClass与PVC。
StorageClass
StorageClass用来描述和定义某种存储系统的特征
StorageClass 有几个关键属性: provisioner、parameters和reclaimPolicy
简单地说,provisioner代表了创建PV的第三方存储插件,parameters是创建PV时的必要参数,reclaimPolicy则表明了PV回收策略,回收策略包括删除或则保留。
PVC(PV Claim)
PVC正如其名,表示应用希望申请的PV规格,其中重要的属性包括 accessModes (存储访问模式)、 storageClassName (用哪种StorageClass来实现动态创建)及resources(存储的具体规格)。
metadata:
name: claim1
********
spec:
accessModes:
- ReadWriteOnce
storageClassName: standard
resources:
requests:
storage: 30Gi
********
有了以StorageClass与PVC为基础的动态PV管理机制,我们就很容易管理和使用Volume了,只要在Pod里引用PVC即可达到目的
spec:
containers:
- name: myapp
****************
****************
****************
volumes:
-name: tomcatedata
persistentVolumeClaim:
claimName: claim1
常用指令
查看pod
kubectl get pods
注意这条指令仅显示属于default命名空间的资源对象,想看其他空间的需要加入–namespace
kubectl get pods --namespace=development
查看集群中有多少个node
kubctl get nodes
输出
NAME STATUS ROLES AGE VERSION
k8s-node-1 Ready <none> 350d v1.14.0
查看某个node的详细信息
kubectl describe node k8s-node-1