读书笔记---kubernetes权威指南：从docker到kubernetes实践 第2章: Kubernetes实践指南_docker与kubernetes实践指南
赞
踩
以下内容来自
kubernetes权威指南:从docker到kubernetes实践纪念版
第2章 Kubernetes实践指南
2.1 Kubernetes安装与配置
kubeadm:适合初学安装
kubectl [command] [TYPE] [NAME] -o=<output_format>
-o=yaml:以yaml格式显示结果
kubectl exec -it pod-name -c container-name /bin/bash
kubectl logs -f pod-name -c container-name
Spec:是Pod中容器的详细定义
spec.containers[].volumeMounts[]:List，
挂载到容器内部的存储卷配置
spec.containers[].volumeMounts[].name:
引用Pod定义的共享存储卷的明策划嗯，需适用volumes[]部分定义
共享存储卷的名称
spec.containers[].volumeMounts[].mountPath:
存储卷在容器内Mount的绝对路径
spec.containers[].command[]:列表，容器的启动命令列表，如果不指定
就适用镜像打包时使用的启动命令
spec.containers[].ports[]:列表，容器需要暴露的端口号列表
spec.containers[].ports[].name:端口的名称
spec.containers[].ports[].containerPort:整型，容器需要监听的端口号
spec.volumes[]:列表，在该Pod上定义的共享存储卷列表
spec.volumes[].namme:字符串，共享存储卷的名称
会被containers[].volumeMounts[].name引用
volume类型包括:emptyDir,hostPath,configMap等
spec.volumes[].emptyDir:对象，类型为emptyDir的存储卷，与Pod同声明周期的
临时目录，其值为i空对想： emptyDir: {}
spec.volumes[].hostPath: hostPatch的存储卷,表示挂载Pod所在宿主机的目录，
通过volumes[].hostPath.path指定
spec.volumes[].hostPath.path: 字符查un，Pod所在主机的目录，被用于容器中mount的目录
spec.volumes[].configMap:对象，configMap的存储卷，
表示挂载集群预先定义的configMap对象到容器内部
spec.volumes[].livenessProbe:对象，pod内容器进行健康检查设置，
探测无响应，就会重启该容器
spec.restartPolict:字符串，Pod的重启策略，可选值为
Always,OnFailure,默认为Always
Always:Pod一旦停止，重启
OnFailure:Pod以非零码终止，重启（正常结束退出码为0）
spec.nodeSelector:对象，设置节点选择器表示将该Pod
调度到包含这些label的Node上，以key:value指定
spec.hostNetwork:布尔，是否使用主机网络模式，默认false
设置为true,表示容器使用宿主机网络，
不再使用Docker网桥，该Pod将无法在同一台
宿主机启动第二个副本
2.3.2 Pod的基本用法
什么时候将几个容器放在同一个Pod?
当几个容器紧耦合，需要组成整体对外提供服务，就应该
将这两个容器打包为一个Pod
2.3.3 静态Pod
含义:kubelet管理的仅存在于特定Node上的Pod，
不能通过API Server进行管理
创建方式:
1 配置文件:设置kubelet启动参数 --config
2 HTTP方式
设置kubelet启动参数: --manifest-url
定期从该URL地址下载Pod的定义文件
2.3.4 Pod容器共享Volume
同一个Pod的多哥容器可以共享Pod级别的存储卷，
多个容器各自进行挂载操作
用emptyDir作为目录
2.3.5 Pod的配置管理
配置与程序分丽
1 ConfigMap概述
作用:
1)生成容器内的环境变量
2)设置容器启动命令参数
3)以Volume形式挂载为容器内部文件或目录
本质: key:value，也可以用于表示完整文件的内容‘
kubectl create configmap命令行方式创建ConfigMap
kubectl get configmap XXX
kubectl describe configmap XXX
kubectl create configmap NAME --from-file=configile-files-dir
通过volumeMount使用ConfigMap
4 使用ConfigMap的限制条件
1)ConfigMap必须在Pod之前创建
2)处于相同Namespaces中的Pod可以引用
3)Pod对ConfigMap进行挂载，容器内部只能挂载为目录
2.3.6 在容器内获取Pod信息(Downware API)
1)环境变量:用于单个变量，可以将Pod信息和Container信息
注入容器内部
2)Volume挂载:将数组类信息生成为文件，挂载到容器内部
2.3.7 Pod生命周期和重启策略
Pending:创建Pod,但还有容器镜像没有创建
Running:Pod内所有容器已经创建，至少有一个容器处于运行状态
Succeeded:Pod内所有容器均成功执行退出，且不再重启
Failed:所有容器已退出，至少有一个容器瑞出为失败状态
Unknown:由于某种原因无法获取该Pod状态
重启策略:
Always:容器失效，kubelet自动重启
OnFailure:容器终止且退出码不为0，kubelet重启
Never:永不重启
重启间隔:2^n,最长5min
RC和DaemonSet:必须设置为Always,包正容器持续运行
Job:OnFailure或Never,容器执行完不再重启
kubelet:Pod失效时自动重启
2.3.8 Pod健康检查
LivenessProbe和ReadinessProbe
LivenessProbe探针:判断容器是否存活(running),
如果探测到不健康，杀掉该容器，
不包含LivenesProbe探针，认为返回值永远是Success
ReadinessProbe探针:判断容器是否启动完成(ready状态)，可以接收请求
探测失败，Pod状态将被修改
kubelet定期执行LivenessProbe探针诊断容器是否健康
三种实现方式:
1)ExecAction:容器内执行命令，如果命令返回码为0，表示容器健康
2)TCPSocketAction:通过Ip和端口执行TCP检查，
如果能建立TCP连接，则表明容器健康
3)HTTPGetAction:通过容器IP地址，端口号，路径调用HTTP Get方法，
如果响应状态码>=200,<400，则健康
initialDelaySeconds:启动容器后首次健康检查等待时间，单位s
timeoutSeconds:健康检查发送请求后等待响应的超时时间，单位s
2.3.9 玩转Pod调度
1 Deployment/RC:全自动调度
功能：自动部署一个容器应用的多份副本，维持指定副本量
2 NodeSelector:定向调度
通过Node标签和Pod的nodeSelector属性匹配
命令:
kubectl label nodes <node-name> <label-key>=<label-value>
例子:
kubectl label nodes k8s-node-1 zone=north
标签:限制Pod所在节点的方法
亲和性调度机制:
更具表打理
使用软限制，退而求其次运行pod
可定义规则描述Pod之间的亲和或互斥关系
组成:
节点亲和性:NodeAffinity
Pod亲和性:PodAffinity
实现原理：通过Pod标签而不是节点标签来实现
3 NodeAffinity: Node亲和性调度
作用:替换NodeSelector的调度策略
方式:
1 RequireDuringSchedulingIgnoredDuringExecution:
满足指定规则才可以调度Pod到Node上
2 PreferredDuringSchedulingIgnoredDuringExecution:
强调优先满足指定规则，软限制，多个优先级规则可设置权重和顺序
IgnoredDuringExecution:pod所在节点在Pod运行期间标签发生变化
不再符合该Pod的节点亲和性后，雄会忽略Node上
Label的变化
NodeAffinity支持In,NotIn,Exists,DoesNotExist,Gt,Lt
规则:
如果同时定义nodeSelector和nodeAffinity,则两个条件必须都满足
如果nodeAffinity指定多个nodeSelectorTerms,只需要其中一个
能够匹配成功
4 PodAffinity: Pod亲和与互斥调度策略
本质：对节点和Pod两个条件进行匹配
条件设置:
requiredDuringSchedulingIgnoreDuringExecution
preferredDuringSchedulingIgnoredDuringExeution
定义于PodSepc的affinity字段的podAffinity中
互斥性:podAntiAffinity
topologyKey:使用任何合法的标签Key赋值
5 Taints和Tolerations
Taint:让Node拒绝Pod的运行
除非能容忍，否则无法在这些Node上运行
命令:
kubectl taint nodes node1 key=value:NoSchedule
例子:
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"
6 DaemonSet:在每个Node上调度一个Pod
作用:管理每个Node上仅运行一份Pod的副本实例
适用:存储，日志，性能监控
7 Job:批处理调度
含义:并性启动多哥计算进程去处理一批工作，完成后，整个
批处理任务结束
模式:
1) Job Template Expansion模式:一个job对象对应待处理的工作
2) Queue with Pod Per Work Item:采用一个任务队列存放Work item
一个job去完成Work item, job会启动N个Pod,每个Pod对应一个工作
3) Queue with Variable Pod Count:采用任务队列存放
Work item,一个Job对象作为消费者去完成这些Work item
Job类型:
1) Non-parallel Jobs
一个Job只启动一个Pod,除非Pod异常，才会重启该Pod
2) Parallel Jobs with a fixed completion count
并行Job会启动多个Pod
3)Parallel Jobs with a worker queue
8 Crobjob:定时任务
格式:
Minutes Hours DayOfMonth Month DayOfWeek Year
*:匹配该域的任意值
/:表示起始时间开始触发，然后每隔固定时间触发一次
例子:
*/1 * * * *
9 自定义调度器
2.3.10 Init Container(初始化容器)
作用:等待其他关联组件运行，启动应用容器之前启动的容器
特点：仅运行一次就结束，而且必须成功执行完成后，才能继续执行
下一个容器
与应用容器的区别:
1)初始化容器先于应用容器完成
2)初始化容器可设置资源限制
2.3.11 Pod的升级和回滚
如果Pod是通过Deployment创建的，用户可以在运行时修改
Deployment的Pod定义或镜像名称；
更新错误，还可以通过回滚恢复
例子：设置镜像
kubectl set imagedeployment/nginx-deployment nginx=nginx:1.9.1
更新方法使用kubectl edit命令修改Deployment的配置
一旦镜像名发生修改，会触发滚动升级
kubectl rollout status可查看Deployment更新
升级包正服务不中断
更新策略：
spec.strategy指定Pod更新策略，支持
RollingUpdate(滚动升级):默认,逐个更新Pod
Recreate(重建):spec,strategy.type=Recreate,
会杀掉所有正在运行的Pod,然后创建新的Pod
spec.strategy.rollingUpdate.maxUnavailable:
指定更新过程中不可用Pod的最大值
spec.strategy.rollingUpdate.maxSurge:
指定更新Pod中Pod总数超过Pod期望部分的最大值
注意:
添加标签选择器无法向后兼容
P174
2 Deployment的回滚
kubectl rollout history deployment/nginx-deployment
3 暂停和恢复Deployment的部署操作，完成复杂的修改
先暂停Deployment,修改配置，再恢复Deployment
暂停命令:
kubectl rollout pause deployment/nginx-deployment
恢复:
kubectl rollout resume deploy nginx-deployment
4 使用kubectl rolling-update完成RC的滚动升级
kubectl rolling-update
5 其他管理对象的更新策略
1)DaemonSet的更新策略
OnDelete和RollingUpdate
OnDelete: DaemonSet的默认升级策略，删除
旧版本Pod，才会触发新建操作
RollingUpdate:旧版本的Pod将被自动杀掉
2) StatefulSet的更新策略
2.3.12 Pod的扩容和缩容
手动模式:执行kubectl scale对Deployment进行Pod
副本数量的设置
自动设置:根据性能指标或业务指标
命令:
kubectl scale deployment nginx-deployment --replicas 5
HPA(Horizontal Pod Autoscaler)
kubectl autoscale deployment php-apache --min=1 --max=10 --cpu-percent=50
kubectl get hpa
2.3.13 使用StatefuleSet搭建MongoDb集群
P 187
2.4 深入掌握Service
Service时Kubernetes最核心的，为一组具有相同功能的容器
应用提供统一入口地址，将请求负载
分发到后端各个容器
解释:
spec.type:字符查un，需要，Service的类型，指定Service
的访问方式，默认为ClusterIP
ClusterIP:虚拟服务Ip地址，可被集群内部Pod访问
NodePort:使用宿主机的端口，使客户通过Node
的IP和端口就可以访问服务
LoadBalancer:负载均衡器完成负载分发
spec.clusterIP:
status.loadBalancer.ingress:外部负载均衡器
status.loadBalancer.ingress.ip:外部负载均衡器的IP地址
status.loadBalancer.ingress.hostname:外部负载均衡器的主机名
2.4.2 Service基本用法
对外提供服务通过机制实现，最简单:
TCP/IP来监听IP和端口号实现
Pod的IP地址会发生变化
如果容器应用是分布式部署，在这些前端设置
负载均衡器实现请求分发，
Service就是解决这个问题的核心组件
关键字段:
ports:指定Service所需的虚拟端口号，由于与
Pod容器端口号不一样，再通过
targetPort指定后端Pod的端口号
selector:设置后端Pod所拥有的label
kubectl get svc
验证服务
curl 169.169.28.190:8081
[root@node-1 qaadmin]# curl 10.233.10.160:8777
{"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}}[root@node-1 qaadmin]#
Kubernetes两种负载分发策略:
1) RoundRobin:轮询，轮询将请求转发到后端各个pod上面，默认
2) SessionAffinity:基于客户端IP地址进行会话保持的模式，
之后从相同客户端发起的请求被转发到相同的Pod上
