🍻 正在加载今日诗词....

Kubernetes学习之核心技术Service及Controller详解

阅读数： 次
原创 字数统计: 2.6k字   |   预计阅读时长≈ 9分钟

Kubernetes 学习之核心技术 Service 以及 Controller 详解

Kubernetes 核心技术 Service

image-20210113131400934

前言

前面我们了解到 Deployment 只是保证了支撑服务的微服务 Pod 的数量，但是没有解决如何访问这些服务的问题。一个 Pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的 IP 启动一个新的 Pod，因此不能以确定的 IP 和端口号提供服务。

要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。在 K8S 集群中，客户端需要访问的服务就是 Service 对象。每个 Service 会对应一个集群内部有效的虚拟 IP，集群内部通过虚拟 IP 访问一个服务。

在 K8S 集群中，微服务的负载均衡是由 kube-proxy 实现的。kube-proxy 是 k8s 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 kube-proxy 就越多，高可用节点也随之增多。与之相比，我们平时在服务器端使用反向代理作负载均衡，还要进一步解决反向代理的高可用问题。

Service 存在的意义

防止 Pod 失联【服务发现】

因为 Pod 每次创建都对应一个 IP 地址，而这个 IP 地址是短暂的，每次随着 Pod 的更新都会变化，假设当我们的前端页面有多个 Pod 时候，同时后端也多个 Pod，这个时候，他们之间的相互访问，就需要通过注册中心，拿到 Pod 的 IP 地址，然后去访问对应的 Pod

image-20201117093606710

定义 Pod 访问策略【负载均衡】

页面前端的 Pod 访问到后端的 Pod，中间会通过 Service 一层，而 Service 在这里还能做负载均衡，负载均衡的策略有很多种实现策略，例如：

  • 随机
  • 轮询
  • 响应比

image-20201117093902459

Pod 和 Service 的关系

这里 Pod 和 Service 之间还是根据 label 和 selector 建立关联的 【和 Controller 一样】

image-20201117094142491

我们在访问 service 的时候，其实也是需要有一个 ip 地址，这个 ip 肯定不是 pod 的 ip 地址，而是虚拟 IP vip

Service 常用类型

Service 常用类型有三种

  • ClusterIp：集群内部访问
  • NodePort：对外访问应用使用
  • LoadBalancer：对外访问应用使用，公有云

举例

我们可以导出一个文件 包含 service 的配置信息

1
kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml

service.yaml 如下所示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: web
status:
  loadBalancer: {}

如果我们没有做设置的话，默认使用的是第一种方式 ClusterIp，也就是只能在集群内部使用，我们可以添加一个 type 字段，用来设置我们的 service 类型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: web
  type: NodePort
status:
  loadBalancer: {}

修改完命令后，我们使用创建一个 pod

1
2
3
4
kubectl apply -f service.yaml

# 查看 service
kubectl get svc

然后能够看到，已经成功修改为 NodePort 类型了，最后剩下的一种方式就是 LoadBalanced：对外访问应用使用公有云

node 一般是在内网进行部署，而外网一般是不能访问到的，那么如何访问的呢？

  • 找到一台可以通过外网访问机器，安装 nginx，反向代理
  • 手动把可以访问的节点添加到 nginx 中

如果我们使用 LoadBalancer，就会有负载均衡的控制器，类似于 nginx 的功能，就不需要自己添加到 nginx 上

Kubernetes 控制器 Controller 详解

Statefulset

Statefulset 主要是用来部署有状态应用

对于 StatefulSet 中的 Pod，每个 Pod 挂载自己独立的存储，如果一个 Pod 出现故障，从其他节点启动一个同样名字的 Pod，要挂载上原来 Pod 的存储继续以它的状态提供服务。

无状态应用

我们原来使用 deployment，部署的都是无状态的应用，那什么是无状态应用？

  • 认为 Pod 都是一样的
  • 没有顺序要求
  • 不考虑应用在哪个 node 上运行
  • 能够进行随意伸缩和扩展

有状态应用

上述的因素都需要考虑到

  • 让每个 Pod 独立的
  • 让每个 Pod 独立的，保持 Pod 启动顺序和唯一性
  • 唯一的网络标识符，持久存储
  • 有序，比如 mysql 中的主从

适合 StatefulSet 的业务包括数据库服务 MySQL 和 PostgreSQL，集群化管理服务 Zookeeper、etcd 等有状态服务

StatefulSet 的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它，容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的。

使用 StatefulSet，Pod 仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供
高可靠性，StatefulSet 做的只是将确定的 Pod 与确定的存储关联起来保证状态的连续性。

部署有状态应用

无头service， ClusterIp：none

这里就需要使用 StatefulSet 部署有状态应用

image-20201117202950336

image-20201117203130867

然后通过查看 pod，能否发现每个 pod 都有唯一的名称

image-20201117203217016

然后我们在查看 service，发现是无头的 service

1
kubectl get svc

image-20201117203245641

这里有状态的约定，肯定不是简简单单通过名称来进行约定，而是更加复杂的操作

  • deployment：是有身份的，有唯一标识
  • statefulset：根据主机名 + 按照一定规则生成域名

每个 pod 有唯一的主机名，并且有唯一的域名

  • 格式：主机名称.service 名称.名称空间.svc.cluster.local
  • 举例：nginx-statefulset-0.default.svc.cluster.local

DaemonSet

DaemonSet 即后台支撑型服务，主要是用来部署守护进程

长期伺服型和批处理型的核心在业务应用，可能有些节点运行多个同类业务的 Pod，有些节点上又没有这类的 Pod 运行；而后台支撑型服务的核心关注点在 K8S 集群中的节点(物理机或虚拟机)，要保证每个节点上都有一个此类 Pod 运行。节点可能是所有集群节点，也可能是通过 nodeSelector 选定的一些特定节点。典型的后台支撑型服务包括：存储、日志和监控等。在每个节点上支撑 K8S 集群运行的服务。

守护进程在我们每个节点上，运行的是同一个 pod，新加入的节点也同样运行在同一个 pod 里面

  • 例子：在每个 node 节点安装数据采集工具

image-20201117204430836

这里是不是一个 FileBeat 镜像，主要是为了做日志采集工作

image-20201117204810350

进入某个 Pod 里面，进入

1
kubectl exec -it ds-test-cbk6v bash

通过该命令后，我们就能看到我们内部收集的日志信息了

image-20201117204912838

Job 和 CronJob

一次性任务 和 定时任务

  • 一次性任务：一次性执行完就结束
  • 定时任务：周期性执行

Job 是 K8S 中用来控制批处理型任务的 API 对象。批处理业务与长期伺服业务的主要区别就是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job 管理的 Pod 根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同：单 Pod 型任务有一个 Pod 成功就标志完成；定数成功行任务保证有 N 个任务全部成功；工作队列性任务根据应用确定的全局成功而标志成功。

Job

Job 也即一次性任务

image-20201117205635945

使用下面命令，能够看到目前已经存在的 Job

1
kubectl get jobs

image-20201117205948374

在计算完成后，通过命令查看，能够发现该任务已经完成

image-20201117210031725

我们可以通过查看日志，查看到一次性任务的结果

1
kubectl logs pi-qpqff

image-20201117210110343

CronJob

定时任务，cronjob.yaml 如下所示

image-20201117210309069

这里面的命令就是每个一段时间，这里是通过 cron 表达式配置的，通过 schedule 字段

然后下面命令就是每个一段时间输出

我们首先用上述的配置文件，创建一个定时任务

1
kubectl apply -f cronjob.yaml

创建完成后，我们就可以通过下面命令查看定时任务

1
kubectl get cronjobs

image-20201117210611783

我们可以通过日志进行查看

1
kubectl logs hello-1599100140-wkn79

image-20201117210722556

然后每次执行，就会多出一个 pod

image-20201117210751068

删除 svc 和 statefulset

使用下面命令，可以删除我们添加的 svc 和 statefulset

1
2
3
kubectl delete svc web

kubectl delete statefulset --all

Replication Controller

Replication Controller 简称 RC，是 K8S 中的复制控制器。RC 是 K8S 集群中最早的保证 Pod 高可用的 API 对象。通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本。指定的数目可以是多个也可以是 1 个；少于指定数目，RC 就会启动新的 Pod 副本；多于指定数目，RC 就会杀死多余的 Pod 副本。

即使在指定数目为 1 的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有一个 Pod 在运行。RC 是 K8S 中较早期的技术概念，只适用于长期伺服型的业务类型，比如控制 Pod 提供高可用的 Web 服务。

Replica Set

Replica Set 检查 RS，也就是副本集。RS 是新一代的 RC，提供同样高可用能力，区别主要在于 RS 后来居上，能够支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数来使用

本文作者： LiJing
发布时间： 2021-01-13
最后更新： 2024-06-24
本文标题： Kubernetes学习之核心技术Service及Controller详解
本文链接： https://blog-yilia.xiaojingge.com/posts/137ec152.html
版权声明： 本作品采用 CC BY-NC-SA 4.0 许可协议进行许可。转载请注明出处！
知识共享许可协议
赏

谢谢你请我吃糖果

支付宝
微信
本站总访问量次 | 本站访客数人

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

喜欢看书、打代码、吃吃吃！我从没被谁知道，所以也没被谁忘记。在别人的回忆中生活，并不是我的目的。我只不过是自己一个人在努力罢了。