k8s

基于 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.

kubernetes 从1.23.x 升级到 1.24.x k8s 在1.24.x之后的版本放弃了和 docker 的兼容，使用 containerd 作为底层的容器，直接参照官方文档的资料进行更新就会报错。因为你没有安装 containerd，所以要安装 containerd 并配置才能正确的升级 k8s 我用的是CentOS7.9的版本，因此以下操作都是在CentOS下操作。 Master 节点操作 1.升级 kubeadm 1yum install -y kubeadm-1.24.2-0 --disableexcludes=kubernetes 2kubeadm version 3kubeadm upgrade plan 4sudo kubeadm upgrade apply v1.24.2 2.安装 containerd 1yum install containerd.io -y 2containerd config default > /etc/containerd/config.toml 3vim /var/lib/kubelet/kubeadm-flags.env 修改 kubeadm-flags.env 变量： 1KUBELET_KUBEADM_ARGS="--pod-infra-container-image=k8s.gcr.io/pause:3.6 --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock" 3.升级 kubelet 1yum install -y kubelet-1.24.2-0 kubectl-1.24.2-0 --disableexcludes=kubernetes 2systemctl daemon-reload && systemctl restart containerd && systemctl restart kubelet 查看状态：

编写 kubernetes 资源描述文件 1. 部署一个应用 1apiVersion: apps/v1 #与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本 2kind: Deployment #该配置的类型，我们使用的是 Deployment 3metadata: #译名为元数据，即 Deployment 的一些基本属性和信息 4 name: nginx-deployment #Deployment 的名称 5 labels: #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解 6 app: nginx #为该Deployment设置key为app，value为nginx的标签 7spec: #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用 8 replicas: 1 #使用该Deployment创建一个应用程序实例 9 selector: #标签选择器，与上面的标签共同作用，目前不需要理解 10 matchLabels: #选择包含标签app:nginx的资源 11 app: nginx 12 template: #这是选择或创建的Pod的模板 13 metadata: #Pod的元数据 14 labels: #Pod的标签，上面的selector即选择包含标签app:nginx的Pod 15 app: nginx 16 spec: #期望Pod实现的功能（即在pod中部署） 17 containers: #生成container，与docker中的container是同一种 18 - name: nginx #container的名称 19 image: nginx:1.

k8s manual expansion We find k8s-master node.Input the Command： expand 1kubectl scale --replicas=3 deploy my-test-deploy shrink 1kubectl scale --replicas=1 deploy my-test-deploy trouble cleaning get resource list 1kubectl get deployment 2kubectl get pods 3kubectl get nodes 4# exists in the namespace 5kubectl api-resources --namespaced=true 6# not exists in the namespace 7kubectl api-resources --namespaced=false show info 1kubectl describe pod my-test-pod 2kubectl describe deployment my-test-pod exec container 1kubectl exec -ti my-test-pod /bin/bash

k8s 调度过程 执行滚动升级 修改 deployment.yml 文件，追加 rollingUpdate 1# 部署应用 2apiVersion: apps/v1 3kind: Deployment 4metadata: 5 name: jobcher-blog-deployment 6 labels: 7 app: jobcher-blog 8spec: 9 replicas: 3 10 selector: 11 matchLabels: 12 app: jobcher-blog 13 minReadySeconds: 10 #准备10s 14 strategy: 15 type: RollingUpdate 16 rollingUpdate: 17 maxUnavailable: 1 #更新期间不少于3-1 18 maxSurge: 1 #更新期间不超过3+1 19 template: 20 metadata: 21 labels: 22 app: jobcher-blog 23 spec: 24 containers: 25 - name: jobcher-blog-pod 26 image: hub.

k8s 本地联调神器 kt-connect 转载自 Bboysoul’sBlog k8s 集群内部的服务网络怎么和我们本地网络打通。kt-connect 就是用来解决这个问题的 使用方法 下载安装什么的都很简单，一个二进制而已 1https://github.com/alibaba/kt-connect 如果你安装好了，那么直接使用下面的命令使用就好了 1sudo ktctl connect 当然也可以指定配置文件 1sudo ktctl --kubeconfig ~/.kube/local connect 执行完成之后，这个集群的所有svc都可以直接在本地解析，当然直接 ping pod 的 ip 也是可以的

OpenELB：云原生负载均衡器插件 OpenELB 是一个开源的云原生负载均衡器实现，可以在基于裸金属服务器、边缘以及虚拟化的 Kubernetes 环境中使用 LoadBalancer 类型的 Service 对外暴露服务。 在 Kubernetes 中安装 OpenELB 1kubectl apply -f https://raw.githubusercontent.com/openelb/openelb/master/deploy/openelb.yaml 查看状态 1kubectl get po -n openelb-system 使用 kubectl 删除 OpenELB 1kubectl delete -f https://raw.githubusercontent.com/openelb/openelb/master/deploy/openelb.yaml 1kubectl get ns 配置 OpenELB 1kubectl edit configmap kube-proxy -n kube-system 2 3# 修改 网卡 4ipvs: 5 strictARP: true 重启组件 1kubectl rollout restart daemonset kube-proxy -n kube-system 为 master1 节点添加一个 annotation 来指定网卡： 1kubectl annotate nodes master1 layer2.openelb.kubesphere.io/v1alpha1="192.168.0.2" 创建地址池 layer2-eip.yaml 1apiVersion: network.

kubernetes ansible 自动化部署 服务器规划 角色 IP 组件 k8s-master1 10.12.12.15 kube-apiserver kube-controller-manager kube-scheduler etcd k8s-master2 10.12.12.17 kube-apiserver kube-controller-manager kube-scheduler etcd k8s-02 10.12.12.22 kubelet kube-proxy docker etcd k8s-03 10.12.12.21 kubelet kube-proxy docker etcd load Balancer(master) 10.12.12.15 10.12.12.23(VIP) nginx keepalived load Balancer(backup) 10.12.12.17 nginx keepalived 系统初始化 关闭 selinux，firewalld 关闭 swap 时间同步 写 hosts ssh 免密（可选） etcd 集群部署 生成 etcd 证书 部署三个 ETC 集群 查看集群状态 部署 Masterß 生成 apiserver 证书 部署 apiserver、controller-manager 和 scheduler 组件 启动 TLS Bootstrapping 部署 Node 安装 Docker 部署 Kubelet 和 kube-proxy 在 Master 上运行为新 Node 颁发证书 授权 apiserver 访问 kubelet 部署插件（准备好镜像） Flannel Web UI CoreDNS Ingress Controller Master 高可用 增加 Master 节点（与 Master1 一致） 部署 nginx 负载均衡器 Nginx+Keepalived 高可用 修改 Node 连接 VIP