Kubernetes学习之基础概念
本文章目录
kubernetes特性
kubernetes集群架构与组件
一、kubernetes集群架构
二、集群组件
三、ubernetes集群术语
深入理解Pod对象
一、Pod容器分类
基础容器
初始化容器
业务容器
二、Pod实现机制
三、镜像拉取策略
1.kubernetes镜像拉取参数
2.镜像拉取策略配置的位置
3.如何查看镜像拉取参数
4.kubernetes部署Pod时,碰到需要登录的harbor镜像仓库怎么办?
四、资源限制
1.Pod和Container的资源请求和限制
2.资源限制字段在YAML中的位置
3.测试一下资源限制
五、重启策略
1.重启策略的参数
2.重启策略参数所在位置
六、健康检查
1.健康检查的2种类型
2.Probe支持以下3种检查方法
3.健康检查字段在YAML中的位置
七、调度约束
1.创建一个Pod内部实现的原理
2.kubectl get pod实现原理
3.调度约束
Deployment控制器
一、Pod与controller的关系
二、deployment功能与应用场景
三、YAML字段解析
四、扩容缩容(手动)
五、控制器中Deployment和ReplicaSet的关系
1.deployment利用replicaSet实现控制Pod副本数原理
2.deployment利用replicaSet实现滚动升级的原理
3.kubernetes权威指南中对deployment利用replicaSet实现滚动升级原理的解释
4.Pod升级策略
5.暂停和恢复deployment的部署操作,以完成复杂的修改
kubernetes特性
- 自我修复：在节点故障时重新启动失败的容器,替换和重新部署,保证预期副本数量;杀死健康检查失败的容器,并且在为准备好之前不会处理客户端请求,确保线上服务不中断
- 弹性伸缩：使用命令、UI或者资源利用率或者请求数自动快速扩容和缩容;业务低峰时回收资源,提高资源利用率,这些资源让其他程序去用
- 自动部署和回滚：k8s采用滚动更新策略更新应用,一次更新一个pod,而不是瀑布式的更新所有,如果更新过程中出现问题,将回滚更改,确保升级不影响业务
- 服务发现和负载均衡：k8s为多个容器提供一个统一的访问入口(内部IP地址和一个DNS名称)，并且负载均衡关联的所有容器,使得用户不用考虑容器IP的问题
- 机密和配置管理：管理机密数据和应用程序配置,而不需要把铭感数据暴露在镜像里,提高敏感数据安全性,并可以将一些常用的配置存储在k8s中,方便应用程序使用
- 存储编排：挂载外部存储系统,无论是来自本地存储、公有云，还是网络存储(NFS、GlusterFS、Ceph)都作为集群资源的一部分使用,极大提高存储使用灵活性
- 批处理：提供一次性任务,定时任务；满足批量数据处理和分析的场景
kubernetes集群架构与组件
一、kubernetes集群架构
二、集群组件
Master节点组件
kube-ApiServer:集群的统一入口,各组件的协调者,以RESTful API提供接口服务,所有对象资源的增删改查和监听操作都交给ApiServer处理后在提交给Etcd存储
kube-Controller-Manager:处理集群中常规后台任务,一个资源对应一个控制器,而ControllerManager就是负责管理这些控制器的
kube-Scheduler:根据调度算法为新创建的pod选择一个Node节点,可以任意部署, 可以部署在同一个节点上,也可以部署在不同节点上
etcd:分布式键值存储系统,用于保存集群状态数据,比如pod、service等对象信息
Node节点组件
kubelet:kubelet是Master在Node节点上的一个agent,管理本机运行容器的生命周期,比如创建容器、pod挂载数据卷、下载secret、获取容器和节点状态等工作
kube-proxy:
在Node节点实现pod网络代理,维护网络规则和4层负载均衡工作
三、kubernetes集群术语
Pod
- 最小部署单元
- 一个容器的集合
- 一个pod中的容器共享网络命名空间
- pod是短暂的
Controller部署和管理pod
- ReplicaSet:确保预期的pod副本数量
- Deployment:无状态应用部署(比如Web)
- DaemonSet:确保所有Node上都运行同一个pod
- job:一次性任务
- cronjob:定时任务(比如定时同步数据)
Service:暴露应用让外部可以访问并对Pod做负载均衡
- 防止pod失联
- 定义一组Pod访问策略
Label:label标签,附加到某个资源上;在k8s中所有的资源的关联和筛选都是通过标签做的,比如查询某个资源就可以通过标签去查询
Namespace::命名空间,是k8s中逻辑的概念,将对象逻辑上隔离;将大部分的资源可以进行隔离,从而抽象出一个多租户的能力,就是每个用户访问某个命名空间 ;可以针对你的团队,或者项目创建不同的命名空间,这样管控就比较容易了
深入理解Pod对象
一、Pod容器分类
1. infrastructure Container:基础容器
作用:维护整个Pod网络空间(容器名是:pause-amd64的容器,有很多,它是与pod一 一对应的,每个pod都对应一个这个容器)
2.initContainers:初始化容器
优先于业务开始执行
应用场景:
- 可能在部署业务容器之前需要做一些初始化操作,那就可以用到initContainer这个容器,它会优先于业务容器执行的,只有这个容器执行完之后,才会往下执行业务容器,比如先检测数据库容器是否准备好,如果准备好在启动业务容器,不然的话业务容器会报错
- 等待其他关联组件正确运行(例如数据库或某个后台服务)
- 基于环境变量或模板生成配置文件
- 从远程数据库获取本地所需配置,或者将自身注册到某个中央数据库中
- 下载相关依赖包.或者对系统进行一些预配置报错
3.Containers:业务容器
就是部署你业务的容器,比如java程序容器
二、Pod实现机制
k8s之所以能实现一个独立的系统存在,主要利用的Linux的namespace命名空间隔离和cgroup做资源限制来实现的
三、镜像拉取策略
1.kubernetes镜像拉取参数
- ifNotPresent: 默认值,镜像在宿主机上不存在时才拉取
- always: 每次创建pod都会重新拉取一次镜像
- never： Pod永远不会主动去拉取镜像
2.镜像拉取策略配置位置
3.如何查看镜像拉取参数
$kubectl get deploy/nginx-deployment -o yaml |grep imagePull #查看这个参数的配置 imagePullPolicy： ifNotPresent
4.kubernetes部署Pod时,碰到需要登录的harbor镜像仓库怎么办?
1)dockerlogin登录
docker login 192.168.31.61 #需要在随便一台机器登录一下harbor仓库
2)查看登录信息
cat .docker/config.js #登录之后会在这里生成登录信息
3)根据登录信息生成64的解码
cat .docker/config.json|base64 -w 0
4)写一个yaml,把解码的64秘钥写进去,根据yaml创建一个k8s资源
5)创建k8s秘钥资源
6)查看这个secret资源是否生成了
还有一种方法:
kubectl create secret docker-registry registry-pull-secret --docker-server=10.255.20.6 --docker-username=admin -docker-password=harbor12345 --docker-email=admin@ctnrs.com -n ms
7)在yaml文件中配置上这个secret(凭据)
#根据上图,去192.168.31.61的仓库中下载镜像,用上面那个凭证
四、资源限制
1.Pod和Container的资源请求和限制
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
#limits是对容器使用资源的总限制(上限),就是这个容器使用的资源不能超过limits
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
#requests是对容器分配的资源
注意:k8s对pod 的CPU限制用docker run中的--cpu-shares,mem是用--memory实现
2.资源限制字段在YAML中的位置
3.测试一下资源限制
1)创建yaml并根据yaml创建pod
一个pod里有2个容器,一个25M两个就是50M
2)创建Pod
$ kubectl apply -f resources-limit.yaml
pod/frontend created
3)查看运行在哪个节点上
可以看到pod是运行在node01节点的
4)查看pod资源占情况
kubectl describe nodes node01 #pod是部署在node01节点的
五、重启策略
1.重启策略的参数
- Always:终止退出后,总是重启容器(默认策略)
- OnFailure:当容器异常退出(退出状态码非0)时才重启容器
- Never：当容器终止退出从不重启容器
2.重启策略参数所在位置
六、健康检查
1.健康检查的2种类型
- livenessProbe:如果检查失败,将杀死容器.然后根据Pod的restartPolicy参数来操作,如果restartPolicy是Always那就重启.
- readinessProbe:如果检查失败,kubernetes会吧Pod从service endpoints中剔除
2.Probe支持以下3种检查方法
- httpGet:发送http请求,返回200-400范围状态码为成功
- exec:执行shell命令返回状态码是0为成功
- tcpSocket:发起TcpSocket建立成功
3.健康检查字段在YAML中的位置
initialDelaySeconds: 5:指容器启动5s后开始健康检查
periodSeconds: 5:表示5秒执行一次健康检查
七、调度约束
1.创建一个Pod内部实现的原理
1)用户创建Pod命令
2)APIserver接收到创建pod的请求,apiserver将状态(创建Pod的参数)写入ETCD中
3)scheduler通过watch获取到ETCD中创建的Pod的事件,scheduler通过调度算法选出这个Pod应该创建到哪台Node节点,并更新到ETCD中
4)kubelet通过watch从ETCD中获取应该在本机创建的Pod,将Pod通过docker run 启动,并将状态(这个Pod是running还是error状态)更新到ETCD中
2.kubectl get pod实现原理
给apiserver发送这个请求,然后apiserver在etcd中获取这些信息,返回给客户端展现
3.调度约束
Deployment控制器
一、Pod与controller的关系
- controller:在集群中管理和运行容器
- 通过label-selector相关联
- Pod是通过控制器实现应用的运维;如伸缩、滚动升级等
二、deployment功能与应用场景
1.功能
- 部署无状态应用
- 管理Pod和ReplicaSet
- 具有上线部署、副本设定、滚动升级、回滚等功能
- 提供声明式更新,例如只更新一个新的Image,可以针对性的修改yaml中的某个字段进行更新
三、YAML字段解析
apiVersion: apps/v1 #api的版本 kind: Deployment #你要创建的资源是什么,比如deployment或者service metadata: #资源的元数据,也就是基本信息 name: nginx-deployment #你这个deployment叫什么名字 namespace: default #你这个deployment的命名空间,因为k8s是靠命名空间隔离的 spec: replicas: 3 #deployment是用来控制pod的,这里就是控制pod的副本数,让pod一直以3个副本运行 seletor: #选择器,用来关联哪一组pod 进行控制 matchLabels: app: nginx #deployment控制标签为 app: nginx的pod进行控制 --------------------------------------#以这里为分隔,上面属于控制器,用来控制pod,下面为被控制对象(pod) template: metadata: #pod的元数据.也就是基本信息 labels: #标签,deployment控制器就是根据标签找到对应的pod进行控制 app: nginx #具体的标签名字,上面的deployment控制器就是根据app: nginx这个标签找到这个pod 关联并进行控制的 spec: containers: #这里就是具体pod里的容器具体的配置,一个pod由一个或者多个容器组成,比如deployment控制器中定义的replicas: 3就是让这个pod一直保持3个容器进行运行,3个容器都一样的,高可用的意思 - name: nginx #容器的名称 image: nginx:latest #容器的镜像 ports: #内部的端口,环境变量等都是在container下面进行配置的 - containersPort: 80
四、扩容缩容(手动)
假如原来3个副本,设置--replicas=10就是扩容
假如原来3个副本,设置--replicas=1就是缩容
五、控制器中Deployment和ReplicaSet的关系
1.deployment利用replicaSet实现控制Pod副本数原理
2.deployment利用replicaSet实现滚动升级的原理
①如果触发滚动升级,会新建一个replicaSet,并用新镜像启动Pod
②新replicaSet下的如果成功启动一个Pod,就杀掉原来replicaSet中的一个Pod
③直到新replicaSet下3个Pod全部起来,老的RS中为0个Pod,service就会完全切换到新的replicaSet
3.kubernetes权威指南中对deployment利用replicaSet实现滚动升级原理的解释
从上图可以看到,老的RS已经为0个Pod,新的为3个Pod,所以service已经完全切换到新的RS了
4.Pod升级策略
- recreateh(重建):设置spec.stratedy.type=Recreate,表示deployment在更新Pod时,会先杀掉所有正在运行的Pod,然后创建新的Pod
- RollingUpdate(滚动更新):设置spec.straedy.type=RollingUpdate ,表示deployment会以滚动更新的方式逐个更新Pod,可以通过maxUnavaliable和maxSurge两个参数控制滚动更新的过程,详细见kubernetes权威指南Pod的升级和回滚章节
5.暂停和恢复deployment的部署操作,以完成复杂的修改
作用:对于一次复杂的deployment配置修改,为了避免频繁触发deployment的更新操作,可以先暂停deployment的更新操作,然后进行配置修改,在恢复deployment,一次性触发完整的更新操作,就可以避免不必要的deployment更新操作了
1)通过kubectl rollout pause暂停deployment的更新
kubectl rollout pause deployment/nginx-deployment
2)然后修改deployment的镜像信息
kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
3)查看deployment的历史记录,发现并没有触发新的deployment部署操作
4)在暂停deployment部署之后,可以根据需要进行任意次数的配置更新，如更新容器的资源限制
5)恢复这个deployment的部署操作
kubectl rollout resum deployment nginx-deployment
6)最后,可以看到一个新的replicaSet被创建出来了
