k8s

背景 已经2024年了， k8s已经更新到 1.30.x的版本了，但是还有很多公司还在使用1.17.9版本，那么我们今天就来手动安装一下1.17.9版本的k8s。 安装 我们在测试centos服务器192.168.40.1安装单节点 Kubernetes 集群（Master 节点）使用 kubeadm 是一个相对直接的过程。 前提条件 确保主机满足以下要求： 操作系统：CentOS 7.x 或更高版本 内存：至少 2 GB 内存 磁盘空间：至少 20 GB 磁盘空间 网络：至少 2 个网络接口 配置主机名和 IP 1sudo hostnamectl set-hostname k8s 2echo "192.168.40.1 k8s" | sudo tee -a /etc/hosts 更新系统 切换镜像源 1bash <(curl -sSL https://www.jobcher.com/ChangeMirrors.sh) 更新系统 1sudo yum update -y 禁用 SELinux 1sudo setenforce 0 2sudo sed -i --follow-symlinks 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config 禁用 Swap 1sudo swapoff -a 2sudo sed -i '/swap/d' /etc/fstab 修改 /etc/sysctl.

containerd 现在很多人说起容器都会说到docker，docker凭借镜像（images）快捷的部署，占领了极大的技术市场，docker公司将自己的核心依赖 Contanerd 捐给了 CNCF，这个就是contanerd的由来，containerd 在kubernetes在 v1.24之后的版本作为底层核心进行使用。 Containerd架构 可以看到 Containerd 仍然采用标准的 C/S 架构，服务端通过 GRPC 协议提供稳定的 API，客户端通过调用服务端的 API 进行高级的操作。 为了解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。 总体上 Containerd 被划分为两个子系统： Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。 Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。 其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。 总之，万物皆插件，插件就是模块，模块就是插件。 常用插件 Content Plugin : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。 Snapshot Plugin : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 graphdriver。 Metrics : 暴露各个组件的监控指标。 安装 卸载docker 首先要保证环境干净整洁，如果你有安装docker服务，需要先卸载docker，如果没有安装可以跳过

Argo cd 安装和部署 Argo CD 是一个为 Kubernetes 而生的，遵循声明式 GitOps 理念的持续部署（CD）工具。Argo CD 可在 Git 存储库更改时自动同步和部署应用程序 安装 前提：你已经安装好了 k8s 环境，我们将在国内的k8s环境下部署argocd 1k3s kubectl create namespace argocd 2kubectl apply -n argocd -f https://github.jobcher.com/gh/https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml 检查是否正常部署 1kubectl get po -n argocd 如果没有错误的情况下应该是全部都runnning，但是如果出现argocd-repo-server CrashLoopBackOff错误有以下解决途径： 使用以下补丁修补了部署。删除后，错误消失，repo 服务器可以启动。 1apiVersion: apps/v1 2kind: Deployment 3metadata: 4 name: argocd-repo-server 5spec: 6 template: 7 spec: 8 securityContext: 9 seccompProfile: 10 type: RuntimeDefault 如果出现argocd-dex-server imagepullbackoff错误有以下解决方法： 1docker pull ghcr.io/dexidp/dex:v2.37.0 2docker tag ghcr.io/dexidp/dex:v2.37.0 harbor/dexidp/dex:v2.37.0 3docker push harbor/dexidp/adex:v2.

简介 企业在上云之后，云计算基础设施支出不断创造新高，但 IT 团队却难以找到成本失控的源头，跟每一个业务沟通，所需要的资源都是必须的，降本增效无从谈起。 引入FinOps 的目标是在云上创造一种财务问责制度，每个业务团队需要根据 FinOps 团队的数据做出更加合理的配置、规划，从而在财务成本、业务稳定之间找到一种平衡。FinOps 并不是一次性、短暂的任务，而是在规划实施之后依旧需要进行持续管理，这要求企业必须设定明确的、持续的角色和责任，以保持对成本长期控制。 概念 建立对云成本的共识：企业中各个相关角色应该意识到云成本的重要性，并将成本管理纳入到决策过程中。通过提高成本意识，可以更好地控制和优化云资源的使用。 明确云成本管理的责任和角色：确定负责 FinOps 团队成员，建立相应责任制度。这样确保有专门人员负责云成本的监控、分析和优化，从而提高整体的财务管理效果。 提供培训和教育资源：培训企业成员了解成本管理的基本概念、工具和技术。这有助于增强团队的能力，使他们能够更好地理解和应对云成本挑战。 促进不同团队之间的合作：财务团队、开发团队和运维团队应该紧密合作，共同制定和实施成本管理策略。通过协作，可以更好地理解业务需求、优化资源配置，并确保成本管理策略与业务目标相一致。 利用自动化技术提高效率和准确性：通过采用自动化工具收集、分析和报告云成本数据。自动化还可以帮助实现实时监控和警报，以及自动化资源管理，从而提高成本管理的效率和准确性。 使用 kubecost 分析 Kubernetes 成本 接下来我们展开今天的具体内容，如何使用 kubecost 分析 Kubernetes 成本。 kubecost 是目前较优秀的开源 Kubernetes 成本分析工具，它提供了丰富的功能和仪表板，帮助用户更好地理解和控制其容器化工作负载的成本。 kubecost 目前支持 阿里云、AWS 等云厂商对接，它能够提供集群中命名空间、应用等各类资源成本分配，用户还可以基于这些信息在 Kubecost 中设置预算和警报，帮助运维和财务管理人员进一步实现成本管理。 安装 Kubecost 安装 Kubecost 建议使用 Helm 进行安装，使用以下命令： 1helm repo add kubecost https://kubecost.github.io/cost-analyzer/ 2helm repo update 3helm upgrade --install kubecost kubecost/cost-analyzer --namespace kubecost --create-namespace 几分钟后，检查以确保 Kubecost 已启动并运行： 1kubectl get pods -n kubecost 2# Connect to the Kubecost dashboard UI 3kubectl port-forward -n kubecost svc/kubecost-cost-analyzer 9090:9090 现在可以打开浏览器并指向 http://127.

基础配置 三台环境为centos7.9，以下配置需要在每台机器上执行 配置hosts解析 1cat >> /etc/hosts <<EOF 2192.168.2.23 node1 3192.168.2.24 node2 4192.168.2.25 node3 5EOF 关闭防火墙和selinux 1systemctl stop firewalld && systemctl disable firewalld 2setenforce 0 && sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config 分别在三个节点设置主机名 1hostnamectl set-hostname node1 2hostnamectl set-hostname node2 3hostnamectl set-hostname node3 配置主机时间同步 1systemctl restart chronyd.service && systemctl enable chronyd.service 配置免密登录 1ssh-keygen 2ssh-copy-id -i .ssh/id_rsa.pub node1 3ssh-copy-id -i .ssh/id_rsa.pub node2 4ssh-copy-id -i .ssh/id_rsa.pub node3 安装pip和ansible、git 1yum install python-pip ansible git -y 部署ceph集群 克隆存储库 这里我选择安装的是ceph nautilus版本

背景 使用 kubeadm 安装 kubernetes 集群非常方便，但是也有一个比较烦人的问题就是默认的证书有效期只有一年时间，所以需要考虑证书升级的问题 检查证书 由 kubeadm 生成的客户端证书默认只有一年有效期，我们可以通过 check-expiration 命令来检查证书是否过期： 1kubeadm alpha certs check-expiration 该命令显示 /etc/kubernetes/pki 文件夹中的客户端证书以及 kubeadm 使用的 KUBECONFIG 文件中嵌入的客户端证书的到期时间/剩余时间。 手动更新 kubeadm alpha certs renew 这个命令用 CA（或者 front-proxy-CA ）证书和存储在 /etc/kubernetes/pki 中的密钥执行更新。 高可用的集群，这个命令需要在所有控制面板节点上执行 具体执行 接下来我们来更新我们的集群证书，下面的操作都是在 master 节点上进行 备份节点 1$ mkdir /etc/kubernetes.bak 2$ cp -r /etc/kubernetes/pki/ /etc/kubernetes.bak 3$ cp /etc/kubernetes/*.conf /etc/kubernetes.bak 备份 etcd 数据目录 1$ cp -r /var/lib/etcd /var/lib/etcd.bak 执行更新证书的命令 1kubeadm alpha certs renew all --config=kubeadm.yaml 检查更新 1kubeadm alpha certs check-expiration 更新下 kubeconfig 文件 1kubeadm init phase kubeconfig all --config kubeadm.

Rook 云存储介绍和部署 Rook 将分布式存储软件转变为自我管理，自我缩放和自我修复的存储服务。它通过自动化部署，引导、配置、供应、扩展、升级、迁移、灾难恢复、监控和资源管理来实现。 Rook 使用基础的云原生容器管理、调度和编排平台提供的功能来履行其职责。 Rook 利用扩展点深入融入云原生环境，为调度、生命周期管理、资源管理、安全性、监控和用户体验提供无缝体验。 部署 使用 helm 部署 1helm init -i jimmysong/kubernetes-helm-tiller:v2.8.1 2helm repo add rook-alpha https://charts.rook.io/alpha 3helm install rook-alpha/rook --name rook --namespace rook-system 直接使用 yaml 文件部署 1kubectl apply -f rook-operator.yaml 不论使用那种方式部署的 rook operator，都会在 rook-agent 中看到 rook-agent 用户无法列出集群中某些资源的错误，可以通过为 rook-agent 的分配 cluster-admin 权限临时解决，详见 Issue 1472。 使用如下 yaml 文件创建一个 ClusterRoleBinding 并应用到集群中。 1kind: ClusterRoleBinding 2apiVersion: rbac.authorization.k8s.io/v1beta1 3metadata: 4 name: rookagent-clusterrolebinding 5subjects: 6 - kind: ServiceAccount 7 name: rook-agent 8 namespace: rook-system 9roleRef: 10 kind: ClusterRole 11 name: cluster-admin 12 apiGroup: "" 部署 rook cluster 创建完 rook operator 后，我们再部署 rook cluster。

基于 K8S 搭建 Ceph 分布式存储 前提 正常运行的多节点 K8S 集群，可以是两个节点也可以是更多。 每一个节点需要一个没有被分区的硬盘，最好大小一致不然会浪费。 没错其实就是一个要求，必须有集群才能进行容器管理，必须有硬盘才能做存储这些都是基础。 添加硬盘 主机 IP 磁盘 master01 10.12.12.51 SATA 20G master02 10.12.12.52 SATA 20G master03 10.12.12.53 SATA 20G worker01 10.12.12.54 SATA 20G worker02 10.12.12.55 SATA 20G 在 5 个节点都加 20g 存储 重启 k8s 节点 1kubectl cordon <节点> 2kubectl drain <节点> --ignore-daemonsets --delete-emptydir-data 3# 虚拟机重启后 4kubectl uncordon <节点> 查看新增存储 1fdisk -l 看到新增 20g 存储,不要格式化分区硬盘！！！ 1Disk /dev/sdb: 20 GiB, 21474836480 bytes, 41943040 sectors 2Disk model: QEMU HARDDISK 3Units: sectors of 1 * 512 = 512 bytes 4Sector size (logical/physical): 512 bytes / 512 bytes 5I/O size (minimum/optimal): 512 bytes / 512 bytes ROOK 自动创建 Rook 是一个开源的cloud-native storage编排, 提供平台和框架；为各种存储解决方案提供平台、框架和支持，以便与云原生环境本地集成。 Rook 将存储软件转变为自我管理、自我扩展和自我修复的存储服务，它通过自动化部署、引导、配置、置备、扩展、升级、迁移、灾难恢复、监控和资源管理来实现此目的。 Rook 使用底层云本机容器管理、调度和编排平台提供的工具来实现它自身的功能。 Rook 目前支持Ceph、NFS、Minio Object Store和CockroachDB。 Rook 使用Kubernetes原语使Ceph存储系统能够在Kubernetes上运行。 下载 1git clone https://github.

Kubernetes — 探针和生命周期 用于判断容器内应用程序是否已经启动。 存活（Liveness）探针 用于探测容器是否运行，如果探测失败，kubelet 会根据配置的重启策略进行相应的处理，若没有配置探针该返回值默认为 success 就绪（Readiness）探针 用于探测容器内的程序是否健康，如果返回值为 success，那么代表这个容器已经完全启动，并且程序已经是可以接受流量的状态 启动（Startup）探针 用于探测容器是否启动，如果配置了 startup 就会先禁止其他探测，直到它成功，成功后将不在运行探测 Pod 检测方式 ExecAction：在容器执行一个命令，返回值为 0，则认为容器健康 TCPSocketAction：通过 TCP 连接检查容器是否联通，通的话，则认为容器正常 HTTPGetAction：通过应用程序暴露的 API 地址来检查程序是否正常的，如果状态码为 200-400 之间，则认为容器健康 gRPCAction：通过 gRPC 的检查机制，判断容器是不是正常 StartupProbe 启动探针 有时候，会有一些现有的应用在启动时需要较长的初始化时间。 要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。 技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对糟糕情况下的启动时间。 1ports: 2 - name: liveness-port 3 containerPort: 8080 4 hostPort: 8080 5 6livenessProbe: 7 httpGet: 8 path: /healthz 9 port: liveness-port 10 failureThreshold: 1 11 periodSeconds: 10 12 13startupProbe: 14 httpGet: 15 path: /healthz 16 port: liveness-port 17 failureThreshold: 30 18 periodSeconds: 10 幸亏有启动探测，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据restartPolicy来执行进一步处置。

Kubernetes — 开放标准（OCI、CRI、CNI、CSI、SMI、CPI）概述 什么是 Kubernetes 开放标准？— K8s 开放标准简介 开放标准有助于和补充像 Kubernetes 这样的系统，Kubernetes 是用于编排容器的事实上的标准平台。开放标准定义了实施 Kubernetes 的最佳实践，并在支持此实施方面发挥着至关重要的作用。开放标准由开源 Kubernetes 社区而非某个特定供应商制定，以确保更高的效率、避免供应商锁定以及更轻松地将其他软件集成到技术堆栈中。 OCI 容器开放接口规范，由多家公司共同组成于 2015 年 6 月成立的项目（Docker, Google, CoreOS 等公司），并由 Linux 基金会运行管理，旨在围绕容器格式和运行时制定一个开放的工业化标准，目前主要有两个标准文档：容器运行时标准 （runtime spec）和 容器镜像标准（image spec） OCI 是一个开放的治理结构，其明确目的是围绕容器格式和运行时创建开放的行业标准。 它提供了必须由容器运行时引擎实现的规范。两个重要的规格是： runC：种子容器运行时引擎。大多数现代容器运行时环境都使用 runC 并围绕这个种子引擎开发附加功能。 这种低级运行时用于启动容器的各种工具，包括 Docker 本身。 OCI 规范：关于如何运行、构建和分发容器的映像、运行时和分发规范。 虽然 Docker 经常与容器技术同步使用，但社区一直致力于 OCI 的开放行业标准。 Image-Spec image-spec 定义了如何构建和打包容器镜像。 本规范的目标是创建可互操作的工具，用于构建、传输和准备要运行的容器映像。 Runtime-Spec runtime-spec 指定容器的配置、执行环境和生命周期。 这概述了如何运行在磁盘上解压的“文件系统包(filesystem bundle)”。概括地说，OCI 实现会下载一个 OCI 映像，然后将该映像解压缩到一个 OCI 运行时文件系统包中。 Distribution-Spec Distribution-Spec 提供了一个标准，用于一般内容的分发，特别是容器图像的分发。它是 OCI 项目的最新补充。 实现分发规范的容器注册表为容器映像提供可靠、高度可扩展、安全的存储服务。 客户要么使用云提供商实施、供应商实施，要么使用分发的开源实施。 CRI CRI（Container Runtime Interface）：容器运行时接口，提供计算资源。​ ​kubernetes1.

k8s 部署插件 Kubernetes 是高度可配置且可扩展的。因此，大多数情况下， 你不需要派生自己的 Kubernetes 副本或者向项目代码提交补丁，本文会介绍几种常用的 k8s 插件，如果大家喜欢的话，希望大家点赞支持。 1. Flannel 网络插件 Flannel是由 go 语言开发，是一种基于 Overlay 网络的跨主机容器网络解决方案，也就是将TCP数据包封装在另一种网络包里面进行路由转发和通信，Flannel 是 CoreOS 开发，专门用于 docker 多主机互联的一个工具，简单来说，它的功能是让集群中的不同节点主机创建的容器都具有全局唯一的虚拟IP地址 主要功能： 为每个 node 分配 subnet，容器将自动从该子网中获取 IP 地址 当有 node 加入到网络中时，为每个 node 增加路由配置 下载并安装 1wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml 2kubectl apply -f kube-flannel.yml 如果 yml 中的"Network": 10.244.0.0/16和kubeadm init xxx --pod-network-cidr不一样，就需要修改成一样的。不然可能会使得Node间Cluster IP不通。 2. Ingress Controller Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管 下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例： Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。 Ingress 控制器 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。

kubernetes 存储 k8s 支持多种途径的多种类型的存储。例如 iSCSI,SMB,NFS，以及对象存储。都是不同类型的部署在云上或者自建数据中心的外部存储系统。k8s 上的所有存储都被称作卷 CSI 容器存储接口 CSI 是 k8s 存储体系中一部分，是一个开源项目，定义了一套基于标准的接口，从而使容器能够以一种统一的方式被不同的容器编排的工具使用。可以将插件称为provisioner 持久化 持久化卷 （pv） 持久化卷申请 （pvc） 存储类 （sv） PV 代表 k8s 的存储，pvc 代表的是许可证，赋予 pod 访问 pv 的权限。cs 使分配过程是动态的。 使用 iSCSI 操作存储 iscsi 卷能将 iSCSI (基于 IP 的 SCSI) 卷挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除，iscsi 卷的内容在删除 Pod 时会被保留，卷只是被卸载。 这意味着 iscsi 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 iSCSI 的一个特点是它可以同时被多个用户以只读方式挂载。 这意味着你可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 上使用它。 不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载。不允许同时写入。 创建 iscsi-pv.yaml iscsi-pvc.yaml iscsi-pv.yaml 1apiVersion: v1 2kind: PersistentVolume 3metadata: 4 name: iscsi-pv 5spec: 6 capacity: 7 storage: 500Gi 8 accessModes: 9 - ReadWriteOnce 10 iscsi: 11 targetPortal: 10.