前言
阶段性容器内容学习总结
本文旨在记录近期在尚硅谷学习的容器相关知识的总结。充当错题集的作用,为日后回头复习做些许功课。
上接 kubernetes(1)——kubeadm搭建集群
一、Deployment简介
多副本能力
扩容、缩容
自愈
故障迁移
二、截图详情
1> 多副本能力
kubectl create deployment mydep --image=nginx --replicas=5
相关yaml文件,在yaml中修改replicas的值也可以进行扩缩容
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: mydep
name: mydep
spec:
replicas: 5
selector:
matchLabels:
app: mydep
template:
metadata:
labels:
app: mydep
spec:
containers:
- image: nginx
name: nginx
2> 扩容、缩容
界面端操作
3> 自愈
某个pod发生故障后,Deployment会自动重启pod
将在Node1 节点上的mydep容器停掉,deployment会自动再重抬一个容器
4> 故障迁移
####四个mydep pod,其中三个在node2服务器上,一个在node1上
将node1服务器关机,服务器在宕机五分钟之后在node2上新建了一个mydep的pod,并把在node1上的pod tag上 'Terminating'
kubectl set image deployment/my-dep nginx=nginx:1.16.1 --record
kubectl rollout status deployment/my-dep
# 修改 kubectl edit deployment/my-dep
5> 版本滚动升级
在现有pod数上,用新版本镜像新建相同数量的pod,新建的pod启动成功一个就删掉一个老的pod,直至版本更替完毕。
视频内容、没有滚动升级成功
6> 版本回滚
和滚动升级一样,用老版本的镜像新建相同数量的pod,新建的pod启动成功一个删掉一个老pod,知道版本更替完毕。
视频内容、没有滚动升级成功
#历史记录
kubectl rollout history deployment/my-dep
#查看某个历史详情
kubectl rollout history deployment/my-dep --revision=2
#回滚(回到上次)
kubectl rollout undo deployment/my-dep
#回滚(回到指定版本)
kubectl rollout undo deployment/my-dep --to-revision=2
2. Service
1> ClusterIP
kubectl expose deployment my-dep --port=8000 --target-port=80 --type=ClusterIP
apiVersion: v1
kind: Service
metadata:
labels:
app: my-dame
name: my-dame
spec:
ports:
- port: 8000
protocol: TCP
targetPort: 80
selector:
app: my-dame
type: ClusterIP
2> NodePort
kubectl expose deployment my-dep --port=8000 --target-port=80 --type=NodePort
apiVersion: v1
kind: Service
metadata:
labels:
app: my-dame
name: my-dame
spec:
ports:
- port: 8000
protocol: TCP
targetPort: 80
selector:
app: my-dame
type: NodePort
ClusterIP和NodePort 的区别:
ClusterIP只能在集群内部访问,NodePort 会随机开放一个端口,从而使集群外也可以访问,可暴露到公网使用。
Nodeport 随机开放的端口范围:30000-32767 之间
3> Ingress
//service 层网络
一个集群内部署多个服务,每个服务下有多个pod, 给每个服务(pod集合)建立一个service。在被调用相关服务时,对应的service负责向辖区范围内的pod分发,从而实现各个部分的负载均衡。
//Ingress层网络
首先,Ingress位于service上层,外部请求进入后,Ingress根据所被配置的规则进行分析,将各个请求分发到下面对应的service层。
PS:如果Ingress处理不了直接返回不往下分发(404)。
Service得到Ingress分发下来的内容后返回对应内容。
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.47.0/deploy/static/provider/baremetal/deploy.yaml
#修改镜像
vi deploy.yaml
#将image的值改为如下值:
registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/ingress-nginx-controller:v0.46.0
# 检查安装的结果
kubectl get pod,svc -n ingress-nginx
# 最后别忘记把svc暴露的端口要放行
三、kubernetes相关概念
以下引自第四版权威指南,为了方面查阅在此加以巩固记录
Service功能、特性
Service是分布式集群架构的核心,一个Service对 象拥有如下关键特征。
◎ 拥有唯一指定的名称(比如mysql-server)。
◎ 拥有一个虚拟IP(Cluster IP、Service IP或VIP)和端口号。
◎ 能够提供某种远程服务能力。
◎ 被映射到提供这种服务能力的一组容器应用上。
Service的服务进程目前都基于Socket通信方式对外提供服务,比如Redis、Memcache、MySQL、Web Server,或者是实现了某个具体业务 的特定TCP Server进程。虽然一个Service通常由多个相关的服务进程提 供服务,每个服务进程都有一个独立的Endpoint(IP+Port)访问点,但 Kubernetes能够让我们通过Service(虚拟Cluster IP +Service Port)连接 到指定的Service。有了Kubernetes内建的透明负载均衡和故障恢复机 制,不管后端有多少服务进程,也不管某个服务进程是否由于发生故障 而被重新部署到其他机器,都不会影响对服务的正常调用。更重要的 是,这个Service本身一旦创建就不再变化,这意味着我们再也不用为 Kubernetes集群中服务的IP地址变来变去的问题而头疼了。
Pod 和 Service 所实现的隔离功能
容器提供了强大的隔离功能,所以有必要把为Service提供服务的这 组进程放入容器中进行隔离。为此,Kubernetes设计了Pod对象,将每个 服务进程都包装到相应的Pod中,使其成为在Pod中运行的一个容器 (Container)。为了建立Service和Pod间的关联关系,Kubernetes首先给 每个Pod都贴上一个标签(Label),给运行MySQL的Pod贴上 name=mysql标签,给运行PHP的Pod贴上name=php标签,然后给相应的 Service定义标签选择器(Label Selector),比如MySQL Service的标签 选择器的选择条件为name=mysql,意为该Service要作用于所有包含 name=mysql Label的Pod。这样一来,就巧妙解决了Service与Pod的关联 问题。
Pod概念
Pod运行在一个被称为节点 (Node)的环境中,这个节点既可以是物理机,也可以是私有云或者公 有云中的一个虚拟机,通常在一个节点上运行几百个Pod;其次,在每 个Pod中都运行着一个特殊的被称为Pause的容器,其他容器则为业务容 器,这些业务容器共享Pause容器的网络栈和Volume挂载卷,因此它们 之间的通信和数据交换更为高效,在设计时我们可以充分利用这一特性 将一组密切相关的服务进程放入同一个Pod中;最后,需要注意的是, 并不是每个Pod和它里面运行的容器都能被映射到一个Service上,只有 提供服务(无论是对内还是对外)的那组Pod才会被映射为一个服务。
集群内容管理
Kubernetes将集群中的机器划分为一个Master和 一些Node。在Master上运行着集群管理相关的一组进程kube-apiserver、 kube-controller-manager和kubescheduler,这些进程实现了整个集群的资 源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功 能,并且都是自动完成的。Node作为集群中的工作节点,运行真正的应 用程序,在Node上Kubernetes管理的最小运行单元是Pod。在Node上运 行着Kubernetes的kubelet、kube-proxy服务进程,这些服务进程负责Pod 的创建、启动、监控、重启、销毁,以及实现软件模式的负载均衡器。
最后,看看传统的IT系统中服务扩容和服务升级这两个难题,以及 Kubernetes所提供的全新解决思路。服务的扩容涉及资源分配(选择哪 个节点进行扩容)、实例部署和启动等环节,在一个复杂的业务系统 中,这两个难题基本上靠人工一步步操作才得以解决,费时费力又难以 保证实施质量。
在Kubernetes集群中,只需为需要扩容的Service关联的Pod创建一个 RC(Replication Controller),服务扩容以至服务升级等令人头疼的问 题都迎刃而解。在一个RC定义文件中包括以下3个关键信息。
◎ 目标Pod的定义。
◎ 目标Pod需要运行的副本数量(Replicas)。
◎ 要监控的目标Pod的标签。
在创建好RC(系统将自动创建好Pod)后,Kubernetes会通过在RC 中定义的Label筛选出对应的Pod实例并实时监控其状态和数量,如果实 例数量少于定义的副本数量,则会根据在RC中定义的Pod模板创建一个 新的Pod,然后将此Pod调度到合适的Node上启动运行,直到Pod实例的 数量达到预定目标。这个过程完全是自动化的,无须人工干预。有了 RC,服务扩容就变成一个纯粹的简单数字游戏了,只需修改RC中的副 本数量即可。后续的服务升级也将通过修改RC来自动完成。
四、遇到个问题
在2-5版本滚动升级模块,按照硅谷视频、文档以及官方文档操作的时候,回显:
error: unable to find container named “nginx”
开始我以为是硅谷视频文件有段时间、kub版本叠替的原因,就找到对应官方文档
deployment文档说明
但和硅谷视频描述一致,就想着是不是服务器重启后导致哪个进程环节出了问题,就找了下相关日志,但日志里报的只是一串 unable to find container…,然后就想是不是命令行
kubectl set image deployment/my-dame nginx=nginx:1.16.1 --record
里的左nginx没有指定版本(当时昏了头,没指定其实就是lastest)
然后就把已经建了的deployment内容删除,重建了个nginx的image集群,结果还是一样的问题
找到的一条不是太相关的内容
后来在朋友圈发了相关的牢骚后,已经从事该方面工作一段时间的老哥给说了下,他给的建议升级就用yaml文件,每升级一次就新建上个新的yaml。回滚就用上之前的yaml。
总结
提示:这里对文章进行总结:
有状态应用使用 StatefulSet 部署,无状态应用使用 Deployment 部署