Pod是一组紧密关联的容器集合,支持多个容器在一个Pod中共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式完成服务,是Kubernetes调度的基本单位。Pod的设计理念是 每个Pod都有一个唯一的IP Pod具有如下特征:
Namespace(命名空间)是对一组资源和对象的抽象集合,比如可以用来将系统内部的对象划分为不同的项目组或者用户组。常见的pod、service、replicaSet和deployment等都是属于某一个namespace的(默认是default),而node, persistentVolumes等则不属于任何namespace。 常用namespace操作:
# 查询所有namespaces
kubectl get namespace
# 创建namespace
kubectl create namespace ns-name
# 删除namespace
kubectl delete namespace ns-name
删除命名空间时,需注意以下几点:
Events是否属于namespace取决于产生events的对象。
Node是Pod真正运行的主机,可以是物理机也可以是虚拟机。Node本质上不是Kubernetes来创建的, Kubernetes只是管理Node上的资源。为了管理Pod,每个Node节点上至少需要运行container runtime(Docker)、kubelet和kube-proxy服务。 常用node操作:
# 查询所有node
kubectl get nodes
# 将node标志为不可调度
kubectl cordon $nodename
# 将node标志为可调度
kubectl uncordon $nodename
taint(污点) 使用kubectl taint命令可以给某个Node节点设置污点,Node被设置上污点之后就和Pod之间存在了一种相斥的关系,可以让Node拒绝Pod的调度执行,甚至将Node已经存在的Pod驱逐出去。每个污点的组成:`key=value:effect`,当前taint effect支持如下三个选项:
常用命令如下:
# 为节点node0设置不可调度污点
kubectl taint node node0 key1=value1:NoShedule
# 将node0上key值为key1的污点移除
kubectl taint node node0 key-
# 为kube-master节点设置不可调度污点
kubectl taint node node1 node-role.kubernetes.io/master=:NoSchedule
# 为kube-master节点设置尽量不可调度污点
kubectl taint node node1 node-role.kubernetes.io/master=PreferNoSchedule
容忍(Tolerations) 设置了污点的Node将根据taint的effect:NoSchedule、PreferNoSchedule、NoExecute和Pod之间产生互斥的关系,Pod将在一定程度上不会被调度到Node上。 但我们可以在Pod上设置容忍(Toleration),意思是设置了容忍的Pod将可以容忍污点的存在,可以被调度到存在污点的Node上。
Service是对一组提供相同功能的Pods的抽象,并为他们提供一个统一的入口,借助 Service 应用可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级。 Service通过标签(label)来选取后端Pod,一般配合ReplicaSet或者Deployment来保证后端容器的正常运行。 service 有如下四种类型,默认是ClusterIP:
另外,也可以将已有的服务以Service的形式加入到Kubernetes集群中来,只需要在创建 Service 的时候不指定Label selector,而是在Service创建好后手动为其添加endpoint。
默认情况下容器的数据是非持久化的,容器消亡以后数据也会跟着丢失,所以Docker提供了Volume机制以便将数据持久化存储。Kubernetes提供了更强大的Volume机制和插件,解决了容器数据持久化以及容器间共享数据的问题。 Kubernetes存储卷的生命周期与Pod绑定
目前Kubernetes主要支持以下Volume类型:
PersistentVolume(PV)是集群之中的一块网络存储。跟 Node 一样,也是集群的资源。PersistentVolume (PV)和PersistentVolumeClaim (PVC)提供了方便的持久化卷: PV提供网络存储资源,而PVC请求存储资源并将其挂载到Pod中。 PV的访问模式(accessModes)有三种:
不是每一种存储都支持这三种方式,像共享方式,目前支持的还比较少,比较常用的是 NFS。在PVC绑定PV时通常根据两个条件来绑定,一个是存储的大小,另一个就是 访问模式。 PV的回收策略(persistentVolumeReclaimPolicy)也有三种
一般情况下我们不需要手动创建Pod实例,而是采用更高一层的抽象或定义来管理Pod,针对无状态类型的应用,Kubernetes使用Deloyment的Controller对象与之对应。其典型的应用场景包括:
常用的操作命令如下:
# 生成一个Deployment对象
kubectl run www --image=10.0.0.183:5000/hanker/www:0.0.1 --port=8080
# 查找Deployment
kubectl get deployment --all-namespaces
# 查看某个Deployment
kubectl describe deployment www
# 编辑Deployment定义
kubectl edit deployment www
# 删除某Deployment
kubectl delete deployment www
# 扩缩容操作,即修改Deployment下的Pod实例个数
kubectl scale deployment/www --replicas=2
# 更新镜像
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
# 回滚操作
kubectl rollout undo deployment/nginx-deployment
# 查看回滚进度
kubectl rollout status deployment/nginx-deployment
# 启用水平伸缩(HPA - horizontal pod autoscaling),设置最小、最大实例数量以及目标cpu使用率
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
# 暂停更新Deployment
kubectl rollout pause deployment/nginx-deployment
# 恢复更新Deployment
kubectl rollout resume deploy nginx
更新策略 `.spec.strategy` 指新的Pod替换旧的Pod的策略,有以下两种类型
Deployment和ReplicaSet两者之间的关系
Deployments和ReplicaSets是为无状态服务设计的,那么StatefulSet则是为了有状态服务而设计,其应用场景包括:
支持两种更新策略:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。