linux

Kubernetes集群概览与搭建指南

2024年4月18日 / 0评论

在当今云原生技术的蓬勃发展中，容器编排平台已成为现代应用部署的主流选择之一。而在众多容器编排平台中，Kubernetes（简称K8s）以其强大的功能和广泛的社区支持成为首选。本篇博客将介绍Kubernetes的基本概念以及如何通过kubeadm工具搭建Kubernetes集群。

1. Kubernetes基本概念

Kubernetes集群主要由控制节点（Master）和工作节点（Node）构成，每个节点上安装着不同的组件。

Master组件：

  • ApiServer： 资源操作的唯一入口，提供认证、授权、API注册和发现等机制。
  • Scheduler： 负责集群资源调度，按照预定的调度策略将Pod调度到相应的Node节点上。
  • ControllerManager： 负责维护集群的状态，例如程序部署安排、故障检测、自动扩展、滚动更新等。
  • Etcd： 负责存储集群中各种资源对象的信息。

Node组件：

  • Kubelet： 负责维护容器的生命周期，通过控制Docker，来创建、更新、销毁容器。
  • KubeProxy： 负责提供集群内部的服务发现和负载均衡。
  • Docker： 负责节点上容器的各种操作。

除此之外，Kubernetes还有一些重要概念：

  • Pod： Kubernetes的最小控制单元，容器都是运行在Pod中的，一个Pod中可以有1个或多个容器。
  • Controller： 控制器，通过它来实现对Pod的管理，例如启动Pod、停止Pod、伸缩Pod的数量等等。
  • Service： Pod对外服务的统一入口，用于维护同一类的多个Pod。
  • Label： 标签，用于对Pod进行分类，同一类Pod会拥有相同的标签。
  • NameSpace： 命名空间，用来隔离Pod的运行环境。

下面，以部署一个nginx服务来说明kubernetes系统各个组件调用关系：
首先要明确，一旦kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中
一个nginx服务的安装请求会首先被发送到master节点的apiServer组件
apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上
在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer
apiServer调用controller-manager去调度Node节点安装nginx服务
kubelet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod
pod是kubernetes的最小操作单元，容器必须跑在pod中至此，
一个nginx服务就运行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理
这样，外界用户就可以访问集群中的nginx服务了

2. Kubernetes集群环境搭建

2.1 前置知识点

目前生产部署Kubernetes集群主要有两种方式：kubeadm和二进制包。

  • kubeadm： 提供快速部署Kubernetes集群的工具，屏蔽了很多细节，适合快速搭建（本文使用这种方式安装）官方地址：https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/
  • 二进制包： 手动部署每个组件，更容易可控，利于学习和后期维护。

2.2 kubeadm部署方式介绍

kubeadm工具通过两条指令完成一个Kubernetes集群的部署：

  1. kubeadm init：创建一个Master节点。
  2. kubeadm join：将Node节点加入到当前集群中。

2.3 安装要求

在开始之前，部署Kubernetes集群机器需要满足以下几个条件：

  • 一台或多台机器，操作系统为CentOS7.x-86_x64。
  • 硬件配置：2GB或更多RAM，2个CPU或更多CPU，硬盘30GB或更多。
  • 集群中所有机器之间网络互通，可以访问外网，需要拉取镜像。
  • 禁止swap分区。

2.4 最终目标

在所有节点上安装Docker和kubeadm，并完成以下步骤：

  1. 部署Kubernetes Master。
  2. 部署容器网络插件。
  3. 部署Kubernetes Node，将节点加入Kubernetes集群。
  4. 部署Dashboard Web页面，可视化查看Kubernetes资源。

2.5 准备环境

为了方便管理，我们先进行环境初始化，包括检查操作系统版本、主机名解析、时间同步、关闭防火墙等操作。

角色IP地址组件
master192.168.17.131docker，kubectl，kubeadm，kubelet
node1192.168.17.132docker，kubectl，kubeadm，kubelet
node2192.168.17.133docker，kubectl，kubeadm，kubelet
1）检查操作系统的版本
cat /etc/redhat-release

2）主机名解析配置

在 /etc/hosts 文件中添加如下内容，以便节点之间可以通过主机名通信。

192.168.17.131 master
192.168.17.132 node1
192.168.17.133 node2

3）禁用 SELinux

永久禁用 SELinux： 通过编辑 /etc/selinux/config 文件，设置 SELINUX=disabled。修改后需要重启。
临时禁用SELinux：setenforce 0

4）禁用firewalld服务

systemctl stop firewalld
systemctl disable firewalld

5）禁用swap分区

swap分区指的是虚拟内存分区，它的作用是物理内存使用完，之后将磁盘空间虚拟成内存来使用，启用swap设备会对系统的性能产生非常负面的影响，因此kubernetes要求每个节点都要禁用swap设备，但是如果因为某些原因确实不能关闭swap分区，就需要在集群安装过程中通过明确的参数进行配置说明

永久禁用：vim /etc/fstab 注释掉 /dev/mapper/centos-swap swap
临时禁用：swapoff -a

6）时间同步

yum install ntpdate
ntpdate time.windows.com

7）修改linux的内核参数

vim /etc/sysctl.d/kubernetes.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1

重新加载配置

sysctl -p

2.6 安装Docker和Kubernetes组件

通过配置国内镜像源，安装Docker和Kubernetes组件，并对kubelet进行设置，使其开机自启。

1）安装docker

切换镜像源

wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo

查看当前镜像源中支持的docker版本

yum list docker-ce --showduplicates

安装特定版本的docker-ce ，必须制定–setopt=obsoletes=0，否则yum会自动安装更高版本

yum install --setopt=obsoletes=0 docker-ce-18.06.3.ce-3.el7 -y

添加一个配置文件，Docker 在默认情况下使用Vgroup Driver为cgroupfs，而Kubernetes推荐使用systemd来替代cgroupfs

mkdir /etc/docker
vim /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
"registry-mirrors": ["https://n5jclonh.mirror.aliyuncs.com"]
}

启动dokcer

systemctl restart docker
systemctl enable docker

2）安装Kubernetes组件

由于kubernetes的镜像在国外，速度比较慢，这里切换成国内的镜像源
编辑/etc/yum.repos.d/kubernetes.repo,添加下面的配置

vim /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgchech=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

安装kubeadm、kubelet和kubectl

yum install kubeadm-1.23.6 kubelet-1.23.6 kubectl-1.23.6 -y

设置kubelet开机自启

systemctl enable kubelet

2.7 集群初始化

在Master节点上执行kubeadm init命令，创建集群，并在Node节点上执行kubeadm join命令将节点加入到集群中。

Master节点操作如下

kubeadm init \
	--apiserver-advertise-address=192.168.17.131 \
	--image-repository registry.aliyuncs.com/google_containers \
	--kubernetes-version=v1.23.6 \
	--service-cidr=10.96.0.0/12 \
	--pod-network-cidr=10.244.0.0/16

Node节点操作如下

kubeadm join 192.168.17.131:6443 --token o1jqdc.01ob5q4xlkiyjvdh --discovery-token-ca-cert-hash sha256:e1a5f52124b271d6f329cae45e30785c8caf0ccd684d0868bedfbb29d7667bac

在master上查看节点信息

kubectl get nodes
NAME         STATUS     ROLES                  AGE   VERSION
k8s-master   NotReady   control-plane,master   10m   v1.23.6
k8s-node1    NotReady   <none>                 30s   v1.23.6
k8s-node2    NotReady   <none>                 6s    v1.23.6

此时你会看到STATUS 为NotReady ，那是因为缺少网络组件，下面就介绍网络组件calico的安装配置

网络组件calico的安装配置（master节点）

wget https://calico-v3-25.netlify.app/archive/v3.25/manifests/calico.yaml
修改calico.yaml配置文件中CALICO_IPV4POOL_CIDR对应的值为kubeadm init初始化时指定的--pod-network-cidr值
kubectl apply -f calico.yaml

查看calico组件状态

kubectl get pod -n kube-system

再次查看nodes信息

kubectl get nodes

测试集群

部署nginx

kubectl create deployment nginx --image=nginx

暴露端口

kubectl expose deployment nginx --port=80 --type=NodePort

查看pod以及服务信息

kubectl get pod,svc

3. kubectl 命令使用大全

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

3.1 任意节点使用kubectl

master节点拷贝/etc/kubernetes/admin.conf文件到node节点

scp /etc/kubernetes/admin.conf  root@k8s-node1:/etc/kubernetes/
scp /etc/kubernetes/admin.conf  root@k8s-node2:/etc/kubernetes/

node节点配置环境变量

echo "export KUBECONFIG=/etc/kubernetes/admin.conf "  >>~/.bash_profile 
source  ~/.bash_profile

3.2 kubectl命令自动补全

yum install bash-completion -y
source  /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >>~/.bashrc

3.3 未完待续…

4. pod

4.1 pod创建

使用命令行的方式创建pod

kubectl run --help

使用yaml文件的方式创建pod

1）可手写yaml文件

yaml语法：https://www.runoob.com/w3cnote/yaml-intro.html

yaml pod语法：可参考：https://cloud.tencent.com/developer/article/1478634 ，也可以使用下面的命令查看

kubectl explain pods  
kubectl explain pod.kind   #kind可替换上面查到的值

2）可基于已有的pod生成yaml文件 

kubectl run nginx --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml >nginx.yaml  #--dry-run 模拟运行，并不会真的创建一个pod ， --dry-run=client输出信息少 ，--dry-run=server输出信息多， -o yaml以yaml文件的格式输出--dry-run=server输出信息内容很多

应用配置文件，创建pod

kubectl apply -f nginx.yaml
或
kubectl create -f nginx.yaml

4.2 pod探针

K8S 提供了 3 种探针:

  • ReadinessProbe
  • LivenessProbe
  • StartupProbe（这个 1.16 版本增加的）

在 Kubernetes 中 Pod 是最小的计算单元，而一个 Pod 又由多个容器组成，相当于每个容器就是一个应用，应用在运行期间，可能因为某也意外情况致使程序挂掉。

那么如何监控这些容器状态稳定性，保证服务在运行期间不会发生问题，发生问题后进行重启等机制，就成为了重中之重的事情，考虑到这点 kubernetes 推出了活性探针机制。

有了存活性探针能保证程序在运行中如果挂掉能够自动重启，但是还有个经常遇到的问题，比如说，在 Kubernetes 中启动 Pod，显示明明 Pod 已经启动成功，且能访问里面的端口，但是却返回错误信息。还有就是在执行滚动更新时候，总会出现一段时间，Pod 对外提供网络访问，但是访问却发生 404，这两个原因，都是因为 Pod 已经成功启动，但是 Pod 的的容器中应用程序还在启动中导致，考虑到这点 Kubernetes 推出了就绪性探针机制。

  1. LivenessProbe： 存活性探针，用于判断容器是不是健康，如果不满足健康条件，那么 Kubelet 将根据 Pod 中设置的 restartPolicy （重启策略）来判断，Pod 是否要进行重启操作。LivenessProbe 按照配置去探测 ( 进程、或者端口、或者命令执行后是否成功等等)，来判断容器是不是正常。如果探测不到，代表容器不健康（可以配置连续多少次失败才记为不健康），则 kubelet 会杀掉该容器，并根据容器的重启策略做相应的处理。如果未配置存活探针，则默认容器启动为通过（Success）状态。即探针返回的值永远是 Success。即 Success 后 pod 状态是 RUNING
  2. ReadinessProbe： 就绪性探针，用于判断容器内的程序是否存活（或者说是否健康），只有程序(服务)正常， 容器开始对外提供网络访问（启动完成并就绪）。容器启动后按照 ReadinessProbe 配置进行探测，无问题后结果为成功即状态为 Success。pod 的 READY 状态为 true，从 0/1 变为 1/1。如果失败继续为 0/1，状态为 false。若未配置就绪探针，则默认状态容器启动后为 Success。对于此 pod、此 pod 关联的 Service 资源、EndPoint 的关系也将基于 Pod 的 Ready 状态进行设置，如果 Pod 运行过程中 Ready 状态变为 false，则系统自动从 Service 资源 关联的 EndPoint 列表中去除此 pod，届时 service 资源接收到 GET 请求后，kube-proxy 将一定不会把流量引入此 pod 中，通过这种机制就能防止将流量转发到不可用的 Pod 上。如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint 列表。kube-proxy 也将有概率通过负载机制会引入流量到此 pod 中。
  3. StartupProbe: StartupProbe 探针，主要解决在复杂的程序中 ReadinessProbe、LivenessProbe 探针无法更好的判断程序是否启动、是否存活。进而引入 StartupProbe 探针为 ReadinessProbe、LivenessProbe 探针服务。

(★) ReadinessProbe 与 LivenessProbe 的区别

  • ReadinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。
  • LivenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。

(★) StartupProbe 与 ReadinessProbe、LivenessProbe 的区别

如果三个探针同时存在，先执行 StartupProbe 探针，其他两个探针将会被暂时禁用，直到 pod 满足 StartupProbe 探针配置的条件，其他 2 个探针启动，如果不满足按照规则重启容器。

另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而 StartupProbe 探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。

(★) 正确的 ReadinessProbe 与 LivenessProbe 与 StartupProbe 使用方式：

LivenessProbe 和 ReadinessProbe 和 StartupProbe 都支持下面三种探测方法：

  • ExecAction：在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。
  • HTTPGetAction：通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法，如果响应的状态码大于等于 – 200 且小于 400，则认为容器 健康。
  • TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检 查，如果能够建立 TCP 连接，则表明容器健康。

(★) 探针属性：

  • initialDelaySeconds：容器启动后要等待多少秒后就探针开始工作，单位“秒”，默认是 0 秒，最小值是 0
  • periodSeconds：执行探测的时间间隔（单位是秒），默认为 10s，单位“秒”，最小值是 1
  • timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”，最小值是 1
  • successThreshold：探针检测失败后认为成功的最小连接成功次数，默认为 1s，在 Liveness 探针中必须为 1s，最小值为 1s。
  • failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod 会被标记为未就绪，默认为 3s，最小值为 1s

(★) 探针探测结果有以下值：

  • Success：表示通过检测。
  • Failure：表示未通过检测。
  • Unknown：表示检测没有正常进行。

Tips：在 StartupProbe 执行完之后，其他 2 种探针的所有配置才全部启动，相当于容器刚启动的时候，所以其他 2 种探针如果配置了 initialDelaySeconds，建议不要给太长。

(★) 使用示例：

1）通过 exec 方式做健康探测

apiVersion: v1
kind: Pod
metadata:
    name: liveness-exec
    labels:
        app: liveness
spec:
    containers:
        - name: liveness
          image: busybox
          args: #创建测试探针探测的文件
              - /bin/sh
              - -c
              - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
          LivenessProbe:
              initialDelaySeconds: 10 #延迟检测时间
              periodSeconds: 5 #检测时间间隔
              exec: #使用命令检查
                  command: #指令，类似于运行命令sh
                      - cat #sh 后的第一个内容，直到需要输入空格，变成下一行
                      - /tmp/healthy #由于不能输入空格，需要另外声明，结果为sh cat"空格"/tmp/healthy

2）通过 HTTP 方式做健康探测

apiVersion: v1
kind: Pod
metadata:
    name: liveness-http
    labels:
        test: liveness
spec:
    containers:
        - name: liveness
          image: test.com/test-http-prober:v0.0.1
          LivenessProbe:
              failureThreshold: 5 #检测失败5次表示未就绪
              initialDelaySeconds: 20 #延迟加载时间
              periodSeconds: 10 #重试时间间隔
              timeoutSeconds: 5 #超时时间设置
              successThreshold: 2 #检查成功为2次表示就绪
              httpGet:
                  scheme: HTTP
                  port: 8081
                  path: /ping

3）通过 TCP 方式做健康探测

apiVersion: v1
kind: Pod
metadata:
    name: liveness-tcp
    labels:
        app: liveness
spec:
    containers:
        - name: liveness
          image: nginx
          LivenessProbe:
              initialDelaySeconds: 15
              periodSeconds: 20
              tcpSocket:
                  port: 80

4.3 pod生命周期

https://kubernetes.io/zh-cn/docs/concepts/containers/container-lifecycle-hooks/

5. 资源调度

5.1 标签和选择器

https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/labels/

5.2 Deployment（适用于无状态服务）

deployment==>replicaset（replication升级版）==>pod

特性：

  • 声明式的更新管理：用户只需要声明最终的状态，Deployment会自动完成滚动更新。
  • 快速的版本回滚：可以迅速回滚到历史版本的Deployment。
  • 比例扩展：可以很容易地进行应用的扩展操作。
  • 无状态的运行：每个副本之间相互独立，适用于无状态应用。

适用于：

  • 不需要永久本地存储的应用。
  • 拥有中断容忍能力、快速更新的需求。
  • 实例之间完全独立的应用。

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/

5.3 StatefulSet（适用于有状态服务）

特性：

  • 稳定的、唯一的网络标识符：每个Pod有一个顺序的编号，例如“app-0,app-1”，即使重新调度到其他节点上。
  • 稳定的、持久的存储：即使Pod被删除，相关联的存储卷也不会丢失，可以保证数据的持久性。
  • 有序地部署和扩展：Pods是按照顺序一个一个创建的。
  • 有序地终止和删除：当Pods被删除时也会按照逆顺序进行。
  • 有序地滚动更新：同样是逐一更新Pods的实例。
  • 灰度发布

适用于：

  • 需要持久存储的应用。
  • 有稳定网络标识需求的应用。
  • 顺序部署、扩展、删除和更新十分重要的应用。

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/

5.4 DaemonSet

DaemonSet 是一个确保全部或者某些节点（node）上必须运行一个 Pod的工作负载资源（守护进程），当有节点加入集群时， 也会为他们新增一个 Pod。

下面是常用的使用案例：

  • 集群守护进程，如Kured、node-problem-detector
  • 日志收集守护进程，如fluentd、logstash
  • 监控守护进程，如promethues node-exporter

通过创建DaemonSet 可以确保 守护进程pod 被调度到每个可用节点上运行。

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/

5.5 HPA (Horizontal Pod Autoscaling)

Kubernetes Horizontal Pod Autoscaler会根据资源的CPU 使用率，自动调整部署、复写控制器或复本集中的Pods 装置数量。这可协助您的应用程式水平扩展以满足增加的需求，或在不需要资源时缩减，从而释出节点供其他应用程式使用。当您设定目标CPU 使用率百分比时，Horizontal Pod Autoscaler 会扩展或缩减您的应用程式，以尝试满足该目标。

https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/

6. 服务发现

6.1 Service

https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/

是Kubernetes中一个抽象的概念，用于定义一组Pod的访问方式和网络访问规则。Service通常用于在内部网络中提供可靠的负载均衡机制，如将服务映射到固定的端口。
具体而言，Service可以将Pod集合作为一个整体来对外提供服务，使用Service的Cluster IP作为虚拟IP地址。当客户端访问此IP时，Kubernetes的Service负载均衡器将流量转发到与此Service相关联的Pod集合中的任意Pod。Service可以使用不同的负载均衡算法，如轮询和IP哈希等，可以与Kubernetes DNS服务结合使用，并通过标签选择器和端口映射提供丰富的筛选和路由选项。

在Kubernetes中，Service有多种实现方式。根据Service的类型不同，它们各自提供了不同的负载均衡策略和网络访问方式，可以选择最合适的实现方式来满足不同的需求。

以下是常见的Service类型：

  • ClusterIP：这是默认的Service类型。ClusterIP类型的Service为Pods提供了内部集群中的稳定连接。它使用 Kubernetes内部DNS解析来负载均衡服务后端的Pods，通过内部Cluster IP提供唯一固定的虚拟IP地址，从而在集群内提供了稳定、可靠的服务发现和负载均衡。(只在集群内部使用)
  • NodePort：此类型的Service会将外部流量转发到ClusterIP上，通常使用NodePort类型的Service来暴露外部服务。NodePort将Pod暴露在每个节点的IP地址和一个使用静态端口的外部IP地址上，创建NodePort Service后，Kubernetes会为 Service分配一个端口，通过访问指定的hostIP和NodePort可以直接访问服务。(测试用的多，暴露所有NodeIP：Port)
  • LoadBalancer：这种类型的Service适用于云平台中将某个服务暴露出来，由云服务商根据配置自动创建并配置负载均衡器。通过此方式，外部流量可以被平衡到集群内的各个节点(Workers)中，Kubernetes会调用云平台的负载均衡器API，并在云端创建负载均衡器，这些负载均衡器会自动路由到集群中的服务。
  • ExternalName：此类型的Service节点会将所有流量直接转发到某个预定义的外部服务。通常情况下，在集群内使用ExternalName Service类型，将某个外部服务作为集群内部服务的别名来使用，使得内部服务使用起来更加方便和简单。（返回定义的CNAME别名，可以配置为域名）

综上所述，Service提供了多种不同的实现方式，可以根据应用程序和网络策略的不同需求，灵活选择适合的Service类型来提供稳定和可靠的网络连接，以支持应用程序在Kubernetes中的顺畅运行。

扩展：基于service访问外部服务
Service不定义selector选择器，就不会自动创建endpoints，我们自己创建endpoints

6.2 Ingress

https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/

是一种Kubernetes资源对象，用于从集群外部公开HTTP和HTTPS路由，以便在单个IP上托管多个域。Ingress充当入口控制器，允许网络流量从外部进入集群，并将其路由到正确的Service上。

在Kubernetes中，Ingress控制器有多种实现方式，每种实现方式都针对不同的使用场景和需求，提供了不同的路由和负载均衡功能。

以下是常见的Ingress控制器实现方式：

  • Nginx Ingress Controller：Nginx是一种常见的Web服务器和反向代理服务器，并广泛用于生产环境中的Web应用程序中。Kubernetes社区提供了一个基于Nginx反向代理服务器的Ingress控制器，即Nginx Ingress Controller。Nginx Ingress Controller可以通过配置文件来指定路由规则，还可以使用Nginx的HTTP模块来提供负载均衡功能。
  • Istio Ingress Controller：Istio是一个流行的服务网格解决方案，在Kubernetes上提供了丰富的网络和负载均衡功能，其中包括通过Envoy代理来提供高效的Ingress控制器功能。Istio Ingress Controller可以通过定义路由规则和流量管理规则来帮助应用程序管理入口流量，同时支持使用TLS加密和认证来保护应用程序的安全性。
  • Traefik Ingress Controller：Traefik是另一个广受欢迎的开源反向代理和负载均衡器，也提供了Ingress控制器的实现方式。Traefik Ingress Controller使用负载均衡算法来均衡入口流量，并可以通过简单的配置文件来定义路由规则和流量管理规则。Traefik还提供了可视化界面以及自动SSL证书管理等功能，使得它成为了开发人员和运维人员的首选。

需要注意的是，每个Ingress控制器都有不同的性能和功能特点，选择正确的Ingress控制器可能需要考虑不同的因素，如部署环境、应用程序需求、扩展性和安全性等。

1）安装Ingress

helm  repo  add  ingress-nginx  https://kubernetes.github.io/ingress-nginx
helm search repo ingress-nginx
helm  pull ingress-nginx/ingress-nginx
tar -zxvf ingress-nginx-4.10.1.tgz 
cd ingress-nginx/

2）修改values.yaml配置文件，根据节点标签选择器nodeSelector指定安装Ingress-nginx的节点，我选择安装在k8s-node1

查看node节点标签

vim values.yaml

3）安装

kubectl create namespace ingress-nginx
helm  install  ingress-nginx -n ingress-nginx .

7. 配置与存储

7.1 配置管理

ConfigMaps：https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/

Secret：https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/

SubPath：https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#using-subpath

7.2 存储管理

Volumes：
1）emptydir：pod内容器间数据共享，不能持久化存储 https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#emptydir
2）hostpath：主机节点文件系统上的文件或目录挂载到你的 Pod 中 https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#hostpath

NFS：

PV和PVC：https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/

8. 高级调度

8.1 CronJob计划任务

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/cron-jobs/

8.2 初始化容器 initContainers

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/

8.3 污点和容忍

污点Taint、容忍Toleration：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/

8.4 亲和力 Affinity

NodeAffinity：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity

PodAffinity：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#an-example-of-a-pod-that-uses-pod-affinity

PodAntiAffinity：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity-weight

9. 身份认证与权限

9.1 认证

User Accounts

Service Accounts：https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/

9.2 授权

https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/

10. 运维管理

10.1 Helm包管理器

Helm 是查找、分享和使用软件构建 Kubernetes 的最优方式。

https://helm.sh/zh/

Helm的目标

Helm管理名为chart的Kubernetes包的工具。Helm可以做以下的事情：

  • 从头开始创建新的chart
  • 将chart打包成归档(tgz)文件
  • 与存储chart的仓库进行交互
  • 在现有的Kubernetes集群中安装和卸载chart
  • 管理与Helm一起安装的chart的发布周期

对于Helm，有三个重要的概念：

  1. chart 创建Kubernetes应用程序所必需的一组信息。
  2. config 包含了可以合并到打包的chart中的配置信息，用于创建一个可发布的对象。
  3. release 是一个与特定配置相结合的chart的运行实例。

组件

Helm是一个可执行文件，执行时分成两个不同的部分：

Helm客户端：是终端用户的命令行客户端。负责以下内容：

  • 本地chart开发
  • 管理仓库
  • 管理发布
  • 与Helm库建立接口
    • 发送安装的chart
    • 发送升级或卸载现有发布的请求

Helm库：提供执行所有Helm操作的逻辑。与Kubernetes API服务交互并提供以下功能：

  • 结合chart和配置来构建版本
  • 将chart安装到Kubernetes中，并提供后续发布对象
  • 与Kubernetes交互升级和卸载chart

独立的Helm库封装了Helm逻辑以便不同的客户端可以使用它。

执行

Helm客户端和库是使用Go编程语言编写的

这个库使用Kubernetes客户端库与Kubernetes通信。现在，这个库使用REST+JSON。它将信息存储在Kubernetes的密钥中。 不需要自己的数据库。

如果可能，配置文件是用YAML编写的。

安装Helm

用二进制版本安装

每个Helm 版本都提供了各种操作系统的二进制版本，这些版本可以手动下载和安装。

  1. 下载 需要的版本
  2. 解压(tar -zxvf helm-v3.0.0-linux-amd64.tar.gz)
  3. 在解压目录中找到helm程序，移动到需要的目录中(mv linux-amd64/helm /usr/local/bin/helm)

配置命令自动补全功能

source <(helm completion bash)
echo "source <(helm completion bash)" >> ~/.bashrc

然后就可以执行客户端程序并 添加稳定仓库: helm help.

#在 Helm 中可以通过添加仓库源来使用公共的 chart 仓库,常用的命令有:

#添加官方稳定仓库
helm repo add stable https://charts.helm.sh/stable
#这会添加 id 为 stable 的仓库源。

#添加官方测试仓库
helm repo add incubator https://charts.helm.sh/incubator 
#这会添加 id 为 incubator 的测试仓库。

#查看已添加的仓库列表
helm repo list

#更新仓库本地缓存
helm repo update

#搜索 charts
helm search repo nginx

#安装 charts
helm install mynginx stable/nginx

#以上命令可以添加常用的公共 chart 仓库,并从中安装所需的 charts。
#也可以添加自定义的 chart 仓库源。

10.2 k8s集群监控

Prometheus

部署基于Prometheus的k8s监控：https://github.com/prometheus-operator/kube-prometheus

kubectl create -f manifests/setup/
kubectl apply -f manifests
kubectl get all -n monitoring

查看访问地址

kubectl  get svc -n monitoring

10.3 k8s集群日志管理

ELK=Elasticsearch+Kibana+Logstash

Daemonset（Filebeat）==收集日志==》Logstash数据收集/数据清洗==》Elasticsearch 数据存储 ==》Kibana数据展示

10.4 k8s可视化管理

  • kubernetes dashboard
  • kubesphere
  • rancher
  • kuboard

部署kubernetes dashboard

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
vim  recommended.yaml

创建一个账号dashboard-admin

vim dashboard-admin.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels: 
    k8s-app: kubernetes-dashboard
  name: dashboard-admin
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dashboard-admin-cluster-role
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: dashboard-admin
    namespace: kubernetes-dashboard

kubectl apply -f dashboard-admin.yaml

查看dashboard-admin账号token

kubectl describe serviceaccounts  dashboard-admin   -n kubernetes-dashboard 
kubectl describe secrets dashboard-admin-token-b7p9t -n kubernetes-dashboard

查看dashboard访问地址

kubectl get svc -n kubernetes-dashboard

访问：https://192.168.17.131:31046/

部署kubesphere （适合部署好k8s环境之后再安装这个，在此之前不要安装任何其他东西（监控、日志收集））

https://kubesphere.io/zh/docs/v3.4/

https://kubesphere.io/zh/docs/v3.4/quick-start/minimal-kubesphere-on-k8s/

打赏微海报分享

您可能也喜欢

如何为某些用户禁用 SSH 密码验证

2022年7月1日

部署SaltStack

2022年7月15日

[SOLVED]The Zabbix database version does not match current requirements.

2022年8月26日

留言

您的电子邮箱地址不会被公开。 必填项已用 * 标注