kubernetes（2）——deployment

前言

阶段性容器内容学习总结

本文旨在记录近期在尚硅谷学习的容器相关知识的总结。充当错题集的作用，为日后回头复习做些许功课。

---

上接 kubernetes（1）——kubeadm搭建集群

---

一、Deployment简介

kubernetes中文社区相关

 多副本能力
 扩容、缩容
 自愈
 故障迁移

---

---

二、截图详情

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。

总结

提示：这里对文章进行总结：

kubernetes`online-training

kubernetes工作负载资源文档

有状态应用使用  StatefulSet  部署，无状态应用使用 Deployment 部署