Kubernetes(K8s)从入门到精通系列之十三:软件负载平衡选项

这篇具有很好参考价值的文章主要介绍了Kubernetes(K8s)从入门到精通系列之十三:软件负载平衡选项。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、软件负载平衡选项

当设置具有多个控制平面的集群时,可以通过将 API Server 实例置于负载均衡器后面并在运行 kubeadm init 以便新集群使用它时使用 --control-plane-endpoint 选项来实现更高的可用性。

当然,负载均衡器本身也应该具有高可用性。这通常是通过向负载均衡器添加冗余来实现的。为此,需要建立一个管理虚拟 IP 的主机集群,每个主机都运行一个负载均衡器实例,以便始终使用当前持有 vIP 的主机上的负载均衡器,而其他主机则处于备用状态。

在某些环境中,例如在具有专用负载平衡组件(例如由某些云提供商提供)的数据中心中,此功能可能已经可用。如果不是,可以使用用户管理的负载平衡。在这种情况下,在引导集群之前需要进行一些准备。

由于这不是 Kubernetes 或 kubeadm 的一部分,因此必须单独处理。在以下部分中,我们给出了对某些人有效的示例,当然还有可能有数十种其他可能的配置。

二、keepalived and haproxy

为了从虚拟 IP 提供负载平衡,keepalived 和 haproxy 的组合已经存在很长时间了,并且可以被认为是众所周知且经过充分测试的:

  • keepalived 服务提供由可配置的健康检查管理的虚拟 IP。由于虚拟 IP 的实现方式,协商虚拟 IP 的所有主机都需要位于同一 IP 子网中。
  • haproxy 服务可以配置为简单的基于流的负载平衡,从而允许 TLS 终止由其背后的 API 服务器实例处理。

此组合可以作为操作系统上的服务运行,也可以作为控制平面主机上的静态 Pod 运行。两种情况下的服务配置是相同的。

三、keepalived配置

keepalived 配置由两个文件组成:服务配置文件和健康检查脚本,该脚本将定期调用以验证持有虚拟 IP 的节点是否仍在运行。

假定这些文件位于 /etc/keepalived 目录中。但请注意,某些 Linux 发行版可能会将它们保留在其他地方。以下配置已成功用于 keepalived 版本 2.0.17:

! /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
    router_id LVS_DEVEL
}
vrrp_script check_apiserver {
  script "/etc/keepalived/check_apiserver.sh"
  interval 3
  weight -2
  fall 10
  rise 2
}

vrrp_instance VI_1 {
    state ${STATE}
    interface ${INTERFACE}
    virtual_router_id ${ROUTER_ID}
    priority ${PRIORITY}
    authentication {
        auth_type PASS
        auth_pass ${AUTH_PASS}
    }
    virtual_ipaddress {
        ${APISERVER_VIP}
    }
    track_script {
        check_apiserver
    }
}

bash 变量样式中有一些占位符需要填写:

  • ${STATE} 对于一台主机来说是 MASTER,对于所有其他主机来说是 BACKUP,因此虚拟 IP 最初将分配给 MASTER。
  • ${INTERFACE} 是参与虚拟IP协商的网络接口,例如eth0。
  • 对于所有 keepalived 集群主机,${ROUTER_ID} 应该相同,但在同一子网中的所有集群中是唯一的。许多发行版将其值预先配置为 51。
  • 控制平面节点上的 ${PRIORITY} 应高于备份节点上的 ${PRIORITY}。因此 101 和 100 分别就足够了。
  • 对于所有 keepalived 集群主机,${AUTH_PASS} 应该相同,例如42
  • ${APISERVER_VIP} 是 keepalived 集群主机之间协商的虚拟 IP 地址。

上面的 keepalived 配置使用健康检查脚本 /etc/keepalived/check_apiserver.sh 负责确保在持有虚拟 IP 的节点上 API Server 可用。该脚本可能如下所示:

#!/bin/sh

errorExit() {
    echo "*** $*" 1>&2
    exit 1
}

curl --silent --max-time 2 --insecure https://localhost:${APISERVER_DEST_PORT}/ -o /dev/null || errorExit "Error GET https://localhost:${APISERVER_DEST_PORT}/"
if ip addr | grep -q ${APISERVER_VIP}; then
    curl --silent --max-time 2 --insecure https://${APISERVER_VIP}:${APISERVER_DEST_PORT}/ -o /dev/null || errorExit "Error GET https://${APISERVER_VIP}:${APISERVER_DEST_PORT}/"
fi

bash 变量样式中有一些占位符需要填写:

  • ${APISERVER_VIP} 是 keepalived 集群主机之间协商的虚拟 IP 地址。
  • ${APISERVER_DEST_PORT} Kubernetes 将通过其与 API 服务器通信的端口。

四、haproxy配置

haproxy 配置由一个文件组成:服务配置文件,假定驻留在 /etc/haproxy 目录中。但请注意,某些 Linux 发行版可能会将它们保留在其他地方。以下配置已成功用于 haproxy 版本 2.1.4:

# /etc/haproxy/haproxy.cfg
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    log /dev/log local0
    log /dev/log local1 notice
    daemon

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 1
    timeout http-request    10s
    timeout queue           20s
    timeout connect         5s
    timeout client          20s
    timeout server          20s
    timeout http-keep-alive 10s
    timeout check           10s

#---------------------------------------------------------------------
# apiserver frontend which proxys to the control plane nodes
#---------------------------------------------------------------------
frontend apiserver
    bind *:${APISERVER_DEST_PORT}
    mode tcp
    option tcplog
    default_backend apiserver

#---------------------------------------------------------------------
# round robin balancing for apiserver
#---------------------------------------------------------------------
backend apiserver
    option httpchk GET /healthz
    http-check expect status 200
    mode tcp
    option ssl-hello-chk
    balance     roundrobin
        server ${HOST1_ID} ${HOST1_ADDRESS}:${APISERVER_SRC_PORT} check
        # [...]

同样,bash 变量样式中有一些占位符可以扩展:

  • ${APISERVER_DEST_PORT} Kubernetes 将通过其与 API 服务器通信的端口。
  • ${APISERVER_SRC_PORT} API Server 实例使用的端口
  • ${HOST1_ID} 第一个负载平衡 API Server 主机的符号名称
  • ${HOST1_ADDRESS} 第一个负载平衡 API Server 主机的可解析地址(DNS 名称、IP 地址)
  • 额外的服务器线路,每个负载平衡的 API 服务器主机各一条

五、选项 1:在操作系统上运行服务

为了在操作系统上运行这两个服务,可以使用各自发行版的包管理器来安装软件。如果它们将在不属于 Kubernetes 集群的专用主机上运行,​​那么这是有意义的。

现在安装了上述配置,可以启用并启动服务。在最近的基于 RedHat 的系统上,systemd 将用于此目的:

# systemctl enable haproxy --now
# systemctl enable keepalived --now

服务启动后,现在可以使用 kubeadm init 引导 Kubernetes集群。

六、选项 2:将服务作为静态 Pod 运行

如果 keepalived 和 haproxy 将在控制平面节点上运行,则可以将它们配置为作为静态 Pod 运行。这里所需要做的就是在引导集群之前将相应的清单文件放置在 /etc/kubernetes/manifests 目录中。在引导过程中,kubelet 会启动进程,以便集群在启动时可以使用它们。这是一个优雅的解决方案,特别是使用堆叠控制平面和 etcd 节点中描述的设置。

对于此设置,需要在 /etc/kubernetes/manifests 中创建两个清单文件(首先创建目录)。

keepalived 的清单 /etc/kubernetes/manifests/keepalived.yaml:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  name: keepalived
  namespace: kube-system
spec:
  containers:
  - image: osixia/keepalived:2.0.17
    name: keepalived
    resources: {}
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        - NET_BROADCAST
        - NET_RAW
    volumeMounts:
    - mountPath: /usr/local/etc/keepalived/keepalived.conf
      name: config
    - mountPath: /etc/keepalived/check_apiserver.sh
      name: check
  hostNetwork: true
  volumes:
  - hostPath:
      path: /etc/keepalived/keepalived.conf
    name: config
  - hostPath:
      path: /etc/keepalived/check_apiserver.sh
    name: check
status: {}

haproxy 的清单 /etc/kubernetes/manifests/haproxy.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: haproxy
  namespace: kube-system
spec:
  containers:
  - image: haproxy:2.1.4
    name: haproxy
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: localhost
        path: /healthz
        port: ${APISERVER_DEST_PORT}
        scheme: HTTPS
    volumeMounts:
    - mountPath: /usr/local/etc/haproxy/haproxy.cfg
      name: haproxyconf
      readOnly: true
  hostNetwork: true
  volumes:
  - hostPath:
      path: /etc/haproxy/haproxy.cfg
      type: FileOrCreate
    name: haproxyconf
status: {}

请注意,这里需要再次填写占位符:${APISERVER_DEST_PORT} 需要保持与 /etc/haproxy/haproxy.cfg 中相同的值(见上文)。

该组合已成功地与示例中使用的版本一起使用。其他版本可能也可以工作,或者可能需要更改配置文件。

服务启动后,现在可以使用 kubeadm init 引导 Kubernetes 集群。文章来源地址https://www.toymoban.com/news/detail-630969.html

到了这里,关于Kubernetes(K8s)从入门到精通系列之十三:软件负载平衡选项的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Kubernetes(K8s)从入门到精通系列之十二:安装和设置 kubectl

    Kubernetes 命令行工具 kubectl, 让你可以对 Kubernetes 集群运行命令。 你可以使用 kubectl 来部署应用、监测和管理集群资源以及查看日志。 kubectl 版本和集群版本之间的差异必须在一个小版本号内。 例如:v1.27 版本的客户端能与 v1.26、 v1.27 和 v1.28 版本的控制面通信。 用最新兼容

    2024年02月14日
    浏览(45)
  • Kubernetes(K8s)从入门到精通系列之十:使用 kubeadm 创建一个高可用 etcd 集群

    默认情况下,kubeadm 在每个控制平面节点上运行一个本地 etcd 实例。也可以使用外部的 etcd 集群,并在不同的主机上提供 etcd 实例。 可以设置HA集群: 使用堆叠控制控制平面节点,其中 etcd 节点与控制平面节点共存 使用外部 etcd 节点,其中 etcd 在与控制平面不同的节点上运行

    2024年02月14日
    浏览(55)
  • Kubernetes(K8s)从入门到精通系列之十六:linux服务器安装minikube的详细步骤

    安装Docker的详细步骤,可以阅读博主下面这篇技术博客文章:

    2024年02月12日
    浏览(57)
  • Kubernetes(K8s)从入门到精通系列之五:K8s的基本概念和术语之应用类

    Service: Service指的是无状态服务,通常多个程序副本提供服务,在特殊情况下也可以是有状态的单实例服务,比如MySQL这种数据存储类的服务。 K8s里的Service具有一个全局唯一的虚拟ClusterIP地址,客户端可以通过这个虚拟IP地址+服务的端口直接访问该服务,再通过部署K8s集群的

    2024年02月14日
    浏览(64)
  • Kubernetes(K8s)从入门到精通系列之七:K8s的基本概念和术语之安全类

    开发的Pod应用需要通过API Server查询、创建及管理其他相关资源对象,所以这类用户才是K8s的关键用户。K8s设计了Service Account这个特殊的资源对象,代表Pod应用的账号,为Pod提供必要的身份验证。在此基础上,K8s实现和完善了基于角色的访问控制权限系统——RBAC(Role-Based Acce

    2024年02月15日
    浏览(66)
  • Kubernetes(K8s)从入门到精通系列之四:K8s的基本概念和术语之集群类

    集群表示一个由Master和Node组成的K8s集群。 Master指的是集群的控制节点。 在每个K8s集群都需要有一个或一组被称为Master的节点,来负责整个集群的管理和控制。 Master通常占据一个独立的服务器(在高可用部署中建议至少使用3台服务器),是整个集群的大脑。 在Master上运行以下

    2024年02月15日
    浏览(59)
  • Kubernetes(K8s)从入门到精通系列之三:K8s的基本概念和术语之资源对象概述

    K8s中的基本概念和术语大多是围绕资源对象(Resource Object)来说的,而资源对象在总体上可分为以下两类: 某种资源的对象,例如节点(Node)、Pod、服务(Service)、存储卷(Volume)。 与资源对象相关的事物与动作,例如标签(Label)、注解(Annotation)、命名空间(Namespace)、部署(Deployment)、

    2024年02月14日
    浏览(66)
  • K8S初级入门系列之十一-安全

        安全是K8S重要的特性,在K8S初级入门系列之四-Namespace/ConfigMap/Secret章节,我们已经已经了解了Namespace,Secret与安全相关的知识。本篇将梳理K8S在安全方面的策略。主要包括两个方面,API安全访问策略以及Pod安全策略。 在介绍安全前,我们先了解下用户和用户组的概念。

    2024年02月16日
    浏览(46)
  • 极速上手k8s,Kubernetes 从入门到摸鱼系列-理论篇

    大家好,我是比特桃!随着微服务架构越来越流行,大规模的微服务容器编排成了一件具有挑战的事情。在这次容器化云原生的发展中,Docker 成了容器化的赢家,而 Kubernetes 则成为了容器编排的赢家。k8s 是 Kubernetes 的简称,只因为 K 和 s 中间有8个字符。或许你还会看到 k3

    2024年02月13日
    浏览(57)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包