「kuberctl」- 批量处理Ingress资源

问题描述
在我们将Ingress Controller组件从Traefik替换为Nginx后,我们迎来壹个新任务 – 替换所有Ingress资源中的 kubernetes.io/ingress.class 注解,将其设置为nginx 参数。
那么多Ingress资源肯定要批量替换,而不是挨个手动替换。
解决办法
这里我们就要用到 kubectl path 命令。批量替换脚本如下:

for ns in $(kubectl get namespaces -o jsonpath='{.items..metadata.name}’)
do
echo “############## NAMESPACE: ${ns} ##############”
for ingress in $(kubectl get -n $ns ingresses.extensions -o jsonpath='{.items..metadata.name}’)
do
# 为了防止命令出错,这里只打印将执行的命令,以进行预览
echo kubectl patch -n $ns ingresses.extensions $ingress –type merge -p \”{“metadata”: {“annotations”: {“kubernetes.io/ingress.class”: “nginx”}}}’\’
# 如果要执行命令,请取消下一行注释
# kubectl patch -n $ns ingresses.extensions $ingress –type merge -p ‘{“metadata”: {“annotations”: {“kubernetes.io/ingress.class”: “nginx”}}}’
done
done

附加内容
Batch and Bulk Operations
A bulk operation is a single-target operation that can take a heterogeneous list of business objects. A batch operation includes multiple target operations that each can take a homogeneous or heterogeneous list of business objects.
这就是使用Batch Processing词组,而不使用Bulk Processing词组的原因。
参考文献
kubectl Cheat Sheet/[……]

READ MORE

「KUBERNETES-OBJECTS」- PersistentVolume, PersistentVolumeClaim

解决方案
PV + PVC 是我们早期最常用的方法,也是我们入门时学习使用的数据持久化方法;
持久化数据存储:Persistent Volume PV 是集群内的资源,没有命名空间;PVC 则是命名空间内的资源;
使用步骤如下: 1)PV 非命名空间资源,因此需要集群管理员定义 PV 资源,它是对存储的抽象; 2)然后,开发者通过 PVC 资源来引用该 PV 资源, 3)最后,在 Pod 的 Volumes 中引用 PVC 资源;
注意事项: 1)如果使用 PVC 资源,则必须定义 PV 资源; 2)PVC 与 PV 是对应绑定的。如果已经有 PVC 绑定到 PV 对象,则其他 PVC 对象不能再绑定到该 PV 对象; 3)虽然 PV 不能共享,但是多个 POD 能够绑定到同个 PVC 以实现存储空间共享;


apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
– ReadWriteOnce
hostPath:
path: “/mnt/data”


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
– ReadWriteOnce
resources:
requests:
storage: 3Gi


apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
– name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
containers:
– name: task-pv-container
image: nginx
ports:
– containerPort: 80
name: “http-server”
volumeMounts:
– mountPath: “/usr/share/nginx/html”
name: task-pv-st[……]

READ MORE

「Kubernetes」- StorageClass, PersistentVolumeClaim

问题描述
storage classes允许管理员定义各种所需的存储类。对于开发人员来说,storage classes可以抽象存储类型,并方便开发人员直接使用PVC,而无需关心存储本身。
解决方案
1)参考 StorageClass + PersistentVolumeClaim 笔记,获取驱动配置示例。
2)在 PVC 中,使用存储类来自动分配存储:

cat > storageclass-testing.yaml <<EOF

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-claim
spec:
storageClassName: nas-client-provisioner
accessModes:
– ReadWriteMany
resources:
requests:
storage: 1Mi

apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
– name: task-pv-storage
persistentVolumeClaim:
claimName: test-claim
initContainers:
– name: touch-file
image: busybox
command: [“touch”, “/srv/pv-test/test-file.txt”]
volumeMounts:
– mountPath: “/srv/pv-test/”
name: task-pv-storage
containers:
– name: busybox
image: busybox
command: [‘sh’, ‘-c’, ‘echo The app is running! && sleep 3600’]
volumeMounts:
– mountPath: “/srv/pv-test/”
name: task-pv-storage
EOF

kubectl apply -f storageclass-testing.yaml

# 检查 NFS 存储是否存在 test-file.txt 文件

on Minnikube
minikube中有默认的存储类,该存储类定义了一个默认的PV provisioner,这意味这当PVC创建时,k8s会自动创建一个相应的PV来忙组该PVC。 查看minikube的[……]

READ MORE

「KUBERNETES-OBJECTS」- 常见错误及问题

Multi-Attach error for volume “pvc-xxx” Volume is already exclusively attached to one node and can’t be attached to another
Steps to recover from on-prem K8s cluster volume multi attach error
kubectl delete pod –force –grace-period=0 或者,工作节点突然离线;
原因分析
我们猜测是因为:集群状态未得到及时更新,导致集群认为存储还在被使用,而无法继续使用;
解决方案

# 如果是节点离线,可以考虑删除节点;

# 或者,删除 VolumeAttachment 对象
kubectl get volumeattachment
kubectl delete VolumeAttachment xxxxxxx[……]

READ MORE

「Kubernetes」- 容器交换数据

问题描述
某些时候,我们需要两个容器能够交换数据(简单交换)
解决方案
如果一个 Pod 上运行了两个或多个容器,如果要交换数据,可以使用 emptyDir 类型的本地数据卷;
原理简述(概述 emptyDir 实现)
Kubernetes emptyDir is not the same as Docker’s volumes-from
在 Docker 中,通过 –volumes –volumes-from 选项,能够在容器间实现数据的共享。两个容器都能够向同个 Volume 写入数据,以此来实现数据共享。
在 Kubernetes 中,通过 emptyDir 类型的存储,来实现两个容器之间的数据共享。但 emptyDir 与 –volumes-from 的实现方式并不相同,Kubernetes 创建空目录(如其名),并将其挂载到容器中。
数据的创建与销毁
Alibaba Cloud Community/Kubernetes Volume Basics: emptyDir and PersistentVolume
当 Pod 创建时,emptyDir 得以创建; 当 Pod 销毁时,emptyDir 数据将被删除; 当 Pod 重启时,例如 CrashLoopBackOff 等等,emptyDir 的数据将被保留,而不会被删除;
配置案例
以下的两个容器挂载了同一个本地卷:

kind: Pod
apiVersion: v1
metadata:
name: sahrevol
spec:
containers:
– name: c1
image: centos:7
command:
– “sh”
– “-c”
– “whatever”
volumeMount:
– name: xchange
mountPath: /tmp/xchange
– name: c2
image: centos:7
command:
– “sh”
– “-c”
– “whatever”
volumeMount:
– name: xchange
mountPath: /tmp/data
volumns:
– name: xchange
emptyDir: {}

当创建容器后,可以到容器中查看挂载点;
当某个容器向 emptyDir 中写入数据后,另个容器能够查看到这些数据;
注意事项
如果节点关闭,或者节点进行维护,那本地数据会丢失;
所以大[……]

READ MORE

「Kubernetes」- 命名空间(Namespace)

6.3. Creating Namespaces to Avoid Name Collisions
通过命名空间解决应用冲突:

kubectl create namespace my-app
kubectl get namespace

默认由一个default命名空间,已经另外的两个自带的命名空间kube-system、kube-pulic,也可以使用清单文件创建:

kind: Namespace
apiVersion: v1
metadata:
name: my-app

不同命名空间的对象不会冲突。kube-system是系统管理员的命名空间,kube-public命名空间则用于保存集群上用户公开的对象。
基本操作

# namespace-demo.yaml
apiVersion: v1
kind: Namespace
metadata:
name: ns-demo
labels:
name: ns-demo

# 创建命名空间
kubectl create -f namespace-demo.yaml

# 查看命名空间
kubectl get namespaces

参考文献
创建k8s命名空间Namespaces kubenetes学习3–Namespace命名空间[……]

READ MORE

「Kubernetes」- 在 Pod 中,访问 Kubernetes API 接口,并控制访问权限

问题描述
在实际的应用场景中,我们的应用程序运行在集群中(以 Pod 的形式存在),并且该应用程序将在集群中进行创建资源、修改资源、删除资源等等操作。
在 Pod 中,访问 Kubernetes API 的方法有很多,而通过 Client Libraries(程序类库)是官方推荐的做法,也是我们接下来将要学习的方法。
该笔记将记录:在 Pod 中,通过 Client Libraries 访问 Kubernetes API(管理 Kubernetes 集群)的方法,以及相关问题的解决办法。
解决方案
接下来我们将介绍例如,如果创建 ServiceAccount 对应用程序进行访问控制,只允许其查看 Pod 资源(即查看 Pod 列表和详细信息)
第 1 步、创建 ServiceAccount 资源
而这其中最大的问题是,如何进行合理的授权,即对于既定的用户或应用程序,如何允许或拒绝特定的操作?—— 通过 ServiceAccount 实现。

# kubectl create serviceaccount myappsa

第 2 步、引用 ServiceAccount 资源
定义一个 Pod,使用为 myappsa 的 ServiceAccount 资源:

kubectl apply -f – <<EOF
kind: Pod
apiVersion: v1
metadata:
name: myapp
spec:
serviceAccountName: myappsa
containers:
– name: main
image: bitnami/kubectl:latest
command:
– “sleep”
– “infinity”
EOF

ServiceAccount 是种身份,而在 Pod 中引用 ServiceAccount 则是将这种身份赋予 Pod 实例。而接下来的任务是给 ServiceAccount 这种身份赋予各种权限 —— 具体的做法便是将各种角色(Role)绑定(RoleBinding)到这个身份(ServiceAccount)上。
第 3 步、创建 Role 资源
定义名为 podreader 的 Role 资源,并定义其能够进行的访问操作:

kubectl apply -f – <<EOF
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: podreader
rules:
– apiGroups: [“”]
resources: [“p[……]

READ MORE

「KUBERNETES-ADDONS」- 插件,扩展

问题描述
KUBERNETES-ADDONS
该笔记将记录:与集群“插件”相关(“插件”泛指用于扩展集群功能的组件,比如 cert-manager、Ingress Controller、Dashboard 等等)
解决方案
整理该部分笔记的原因如下: 1)学习常用将的 Kubernetes Cluster 插件的部署和使用方法,以积累经验; 2)在集群升级时,参考该部分笔记的目录,以检查是否有相关插件是否需要升级;
插件列表
Kubernetes Addons,官方给出的插件列表 kubernetes/cluster/addons at master · kubernetes/kubernetes · GitHub
kube-explorer,与 Kubernetes Dashboard 功能相仿,以后或许会添加更多新特性。 GitHub – cnrancher/kube-explorer: A portable explorer for Kubernetes, without any dependency.
网络插件 Cluster Networking | Kubernetes
DNS
Web UI (Dashboard)
Container Resource Monitoring
Cluster-level Logging[……]

READ MORE

「Kubernetes」- 监控、告警

问题描述
在 Kubernetes 的环境中,不同的角色通常有不同的职责: 1)管理人员角色:如集群管理员、网络运营人员、或命名空间管理员等关注基础设施方面的工作人员。常见的问题可能有:节点是否健康?我们是否应该增设一个工作节点?集群的利用率是多少?用户的配额是否即将耗尽? 2)开发人员角色:主要考虑和操作他们的应用程序的上下文环境,在目前的微服务时代,他们可能要关心几个甚至十几个应用程序。例如,承担开发角色的工作人员可能会问:我是否为我的应用分配了足够的资源?我的应用应该扩展到多少个副本?我是否可以访问正确的卷,以及还有多少容量?是否有运行失败的应用,如果有,原因是什么?
该笔记将记录:在 Kubernetes Cluster 中,如何部署监控服务,以及常见问题处理,我们将集中介绍基础设施与应用程序层监控。
解决方案
最早,我们首先利用 Kubernetes 的存活探针和就绪探针来监测应用程序健康,但这种方式只是让 Kubernetes 感知应用状态的手段,并非集群监控。
接下来我们将讨论如何利用监视集群需要考虑的问题、相关方法、解决方案。
监控 = 收集 + 存储 + 展示 + 告警
指标收集
1)Heapster 2)Metrics Server => Metrics API 3)Kube State Metrics:How To Setup Kube State Metrics On Kubernetes Cluster
导出: Exporter
Kubernetes Event GitHub – resmoio/kubernetes-event-exporter
存储: 1)Prometheus 2)InfluxDB
展示: 1)Grafana
告警: 1)AlertManager
常见解决方案
容器监控: CRI Pod & Container Metrics | Kubernetes[……]

READ MORE

「Kubernetes」- 使用 Fluentd 收集日志

服务搭建流程概览
1)确定需要收集的日志及位置 2)搭建日志收集服务:Elasticsearch + Kibana + Fluentd 3)验证日志收集成功(能够查看)
集群环境概述
操作系统:CentOS Linux release 7.4.1708 (Core) 集群版本:Kubernetes v1.16.2 软件版本:Docker version 19.03.8
第一步、需要收集的日志
systemd
服务:docker.service kubelet.service 日志:systemd or /var/log
1)调整日志写入,参考 systemd-journald 笔记 原因:镜像(Fluentd)使用 fluent-plugin-systemd 收集日志,该插件默认到 /var/log/journal/ 收集日志(参考 path 参数),并且镜像的 systemd.conf 没有覆盖默认 path 参数。在 systemd 中,日志默认写入 /run/log/journal/ 目录。这就导致无法正常收集 docker.service kubelet.service 日志,同时经过实验验证,确实无法收集日志。
kubernetes components
组件:etcd、apiserver、controller-manager、proxy、scheduler、network plugin 日志:/var/log/containers/ or /var/log/pods/
无需调整,镜像 kubernetes.conf 已经从 /var/log/containers/*.log 读取日志。(在 containers 下的日志是到在 pods/ 下的日志的软链接。至于为什么要这么实现就不清楚了)
applictions
组件:应用程序的容器日志 日志:/var/lib/docker/containers/
第二步、搭建日志收集服务
我们的日志集群(Elasticsearch + Kibana)部署在 Kubernetes Cluster 外,而 Fluentd 以 DaemonSet 部署在集群中。
官方提供可直接使用的资源(fluentd-daemonset-elasticsearch-rbac.yaml),但是需要根据自己的需要调整。
#0 Elasticsearch + Kibana
这里略过 Elasticsearch Cluster 及 Kibana 部署过程,直接介绍 Fluentd 部署过程。
#1 Fluentd rbac
使用 ./fluentd-rbac.yaml 定义
#2 Fluentd service[……]

READ MORE

「Kubernetes Monitoring」- 通过 Metrics Server 服务,获取 Pod 资源占用

问题描述
Metrics Server 是在 Kubernetes Cluster 中的“容器资源指标源”,负责在集群中收集各种指标数据。当 Kubernetes Cluster 需要通过 HPA 或 VPA 进行自动调整时,它将调用 Metrics API 来获取相关的资源指标数据,而 Metrics API 的数据是由 Metrics Server 提供的。当然除了 Metrics Server 实现,还有已经废弃的 Heapster 实现。
在部署 Metrices Server 服务之后,我们能够通过 kubectl top 来查看容器的资源占用情况:

# kubectl top pod –all-namespaces –containers
NAMESPACE POD NAME CPU(cores) MEMORY(bytes)
kube-system calico-kube-controllers-65d7476764-w88x6 calico-kube-controllers 1m 10Mi
kube-system calico-node-jtfxz calico-node 19m 50Mi
kube-system calico-node-m9j8k calico-node 21m 48Mi
kube-system coredns-7ff77c879f-nbjs5 coredns 2m 6Mi
kube-system coredns-7ff77c879f-v626m coredns 2m 6Mi
kube-system etcd-k8scp-01 etcd 13m 40Mi
kube-system kube-apiserver-k8scp-01 kube-apiserver 31m 317Mi
kube-system kube-controller-manager-[……]

READ MORE

「KUBERNETES-ADDONS」- 云原生存储(Overview)

问题描述
该笔记将记录:与 Cloud Native Storage(云原生存储)相关的内容,以及相关问题的解决办法。
解决方案
NFS Provisioner
问题描述: 在 Kubernetes 中,Pod 与 PV 都能够直接挂载 NFS 存储,但是管理复杂(例如 NFS 目录规划与隔离);
解决方案: 通过 NFS Provisioner 服务,并借助 StorageClass 使得应用程序能够自动申请存储,而实现自动分配;
服务部署: 1)NFS Provisioner
Rook(Storage Orchestrator)
Rook/Documentation/Rook GitHub/rook/rook
我们常用的存储软件(比如 NFS、Ceph、EdgeFS、YugabyteDB 等等)并不具备(或仅具备部分)高可用、自愈、自动扩展等等特性;
Rook,是开源的云原生存储编排器,提供平台,框架,支持“多种本机存储解决方案”与“云原生环境”集成;
Rook 基于底层云原生平台对这些存储软件进行强化。通过使用“底层的云原生容器管理、调度、协调平台提供的”基础设施,来为存储服务添加自我管理、自我缩放、自愈的等等特性。它通过自动部署、引导、配置、部署、缩放、升级、迁移、灾难恢复,监控,资源管理来实现;
当前(03/09/2022)支持的存储解决方案(rook/README.md): 1)Ceph, Status=Stable: rook/rook: Storage Orchestration for Kubernetes 2)Cassandra, Status=Deprecated: rook/cassandra: The Rook storage provider for Cassandra 3)NFS, Status=Alpha: rook/nfs: Rook storage provider for NFS[……]

READ MORE

「ROOK-CEPH」- 云原生存储

该部分将记录:在 Kubernetes 中,如何部署 Rook 服务、底层使用 Ceph 存储、创建共享文件系统、挂载到 Pod 中等系列操作;
# 09/27/2019 我们现在使用的是 Ceph 存储,其出于 Stable 状态;
相关链接 Ceph Operator Helm Chart Ceph Common Issues
参考文献
GitHub/rook/rook/Documentation/k8s-pre-reqs.md Ceph Storage Quickstart[……]

READ MORE

「ROOK-CEPH」- 集群环境搭建(快速开始)

问题描述
该笔记将记录:在 Kubernetes Cluster 中,如何部署 Rook Ceph 存储,以及相关问题的解决办法;
通过 Helm Chart 部署
Ceph Cluster Helm Chart – Rook Ceph Documentation
有关更多详细信息,请参见「Ceph Examples」示例;
环境概述
对于生产环境,需要向集群添加额外的节点,用于存储节点,并向其中添加额外的存储设备,作为 Ceph OSD 设备;
对于生产环境,需要遵循 cluster.yaml 中的示例,而不是 cluster-test.yaml 文件,以便配置设备,而不是测试目录;
第一步、准备工作
在 Kubernetes 中,增加多个存储专用的 Worker 节点,并向这些 Worker 节点添加额外的存储磁盘;
第二步、服务部署

helm repo add rook-release https://charts.rook.io/release

# —————————————————————————– # 部署 Operator 实例

helm pull rook-release/rook-ceph –version 1.9.5 # rook-ceph-v1.9.5.tgz
helm show values ./rook-ceph-v1.9.5.tgz > rook-ceph-v1.9.5.helm-values.yaml

helm install rook-ceph \
–namespace rook-ceph –create-namespace \
./rook-ceph-v1.9.5.tgz -f rook-ceph-v1.9.5.helm-values.yaml \

# —————————————————————————– # 部署 Cluster 实例

helm pull rook-release/rook-ceph-cluster –version 1.9.5
helm show values ./rook-ceph-cluster-v1.9.5.t[……]

READ MORE

「ROOK-CEPH」- 管理 OSD 实例

添加 OSD 实例(增)
磁盘清理

DISK=”/dev/sdX”

# Zap the disk to a fresh, usable state (zap-all is important, b/c MBR has to be clean)
sgdisk –zap-all $DISK

# Wipe a large portion of the beginning of the disk to remove more LVM metadata that may be present
dd if=/dev/zero of=”$DISK” bs=1M count=100 oflag=direct,dsync

# SSDs may be better cleaned with blkdiscard instead of dd
blkdiscard $DISK

# Inform the OS of partition table changes
partprobe $DISK

删除 OSD 实例(删)
Rook Docs/Ceph OSD Management/Remove an OSD Ceph OSD Management – Rook Ceph Documentation
需要部署 Rook Toolbox 容器,然后进入容器对 Rook-Ceph Cluster 进行管理操作; 当通过 Helm 部署 Ceph 时,能够在 values.yaml 中指定是否安装 toolbox 服务;
在 Rook Ceph 中,需要手动执行 OSD 删除,而无法自动删除;
第一步、删除前确认工作
在删除前,需要进行如下确认: 1)当删除 OSD 实例后,磁盘具有足够空间来容纳数据; 2)确定剩余 OSD 及 PG 的健康状况,以用于数据重平衡; 3)不要一次删除太多 OSD 实例,并且等待重平衡结束; 4)如果 PG 全部为 active+clean 状态,并且未提示空间不足,则可以安全进行操作;
第二步、进行 OSD 删除
通过手动进行 OSD 清理操作:

# —————————————————————————– # 停止 Operator 运行

kubectl -n rook-ceph scale deployment rook-ceph-operator –replicas=0

# —————————————————————————– # 进入工具箱进行操作

C[……]

READ MORE

「ROOK-CEPH」- 服务升级

问题描述
该笔记将记录:我们升级 Rook Ceph 集群的方法,以及相关问题的解决办法;
解决方案
参考 Rook Ceph Documentation => Upgrade 文档,以获取关于升级过程的详细内容;
建议首先完成相关文档的阅读,然后再展开升级操作;
环境信息
Rook Ceph: 1.10.2 => 1.10.10 Kubernetes Cluster: 1.22.15
第一步、集群健康检查
Rook Ceph Documentation/Health Verification

# ——————————————————— # Pods all Running

# 确保如下命令无输出:
kubectl -n rook-ceph get pods –no-headers | grep -v -E ‘\sRunning\s|\sCompleted\s’

# ——————————————————— # Status Output

# 检查 HEALTH_OK,mon,mgr,mds,osd,rgw,pg 状态,确保出于正常:
TOOLS_POD=$(kubectl -n rook-ceph get pod -l “app=rook-ceph-tools” -o jsonpath='{.items[*].metadata.name}’)
kubectl -n rook-ceph exec -it $TOOLS_POD — ceph status

# ——————————————————— # Container Versions

# 检查容器版本,确保各组件当前版本一致:
kubectl -n rook-ceph get pod -o jsonpath='{range .items[*]}{.metadata.name}{“\n\t”}{.status.phase}{“\t\t”}{.spec.containers[0].image}{“\t”}{.spec.initContainers[0].image}{“\n”}{end}’

# ——————————————————— # Rook Volume Health

# 检查使用 Rook Ceph 的容器处于健康状态;
# 在升级过程中,业务容器依旧能够正常运行;

第二步、升级 Operator 服[……]

READ MORE

「ROOK-CEPH」- 常见问题处理

问题描述
该笔记将记录:与 Rook-Ceph 有关的问题,以及常见问题的解决办法;
解决方案
常见问题,参考 Rook Ceph Documentation/Troubleshooting 文档;
[SOLVED] …/globalmount: permission denied
cephfs mount failure.permission denied · Issue #9782 · rook/rook
问题描述:

# ls -l /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-9b3e9500-1903-41dd-8abc-4052b74d450b
ls: cannot access ‘globalmount’: Permission denied
total 4
d????????? ? ? ? ? ? globalmount
-rw-r–r– 1 root root 138 Mar 1 09:44 vol_data.json

解决方案:

# umount -lf /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-9b3e9500-1903-41dd-8abc-4052b74d450b/globalmount

[SOLVED] OSD Init Container 启动失败
ceph: failed to initialize OSD · Issue #8023 · rook/rook · GitHub Cluster unavailable after node reboot, symlink already exist · Issue #10860 · rook/rook · GitHub
问题描述
在 Rook Ceph 中,当节点重启后,OSD-<ID> Pod 的 Init Container 无法正常启动,提示如下错误:

# kubectl logs rook-ceph-osd-5-7f759955bc-9bqt4 -c activate

Running command: /usr/bin/ceph-bluestore-tool prime-osd-dir –dev /dev/sdb –path /var/lib/ceph/osd/ceph-5 –no-mon-config
Running command: /usr/bin/chown -R ceph:ceph /dev/sdb
Running command: /usr/bin/ln -[……]

READ MORE

「ROOK-CEPH」- 使用对象存储,S3 API,Object Storage,RGW

问题描述
该笔记将记录:在 Rook Ceph 中,使用对象存储的方法,以及相关问题的解决办法。
解决方案
该部分内容是针对我们的应用场景而整理的笔记,建议参考官方文档以获取详细说明: 1)Object Storage Overview – Rook Ceph Documentation 2)Bucket Claim – Rook Ceph Documentation 3)Object Store CRD – Rook Ceph Documentation 4)Object Store User CRD – Rook Ceph Documentation
流程概述
在 Rook Ceph 中,使用对象存储的流程如下: 1)创建 CephObjectStore 对象,该资源将启动 RGW 服务,以提供 S3 API 接口; 2)创建 StorageClass 对象,并关联到 CephObjectStore 对象; 3)创建 ObjectBucketClaim 对象,并指定其引用的 StorageClass 对象;
在实际的部署中,集群中已经存在 StorageClass ceph-bucket 对象,所以我们可以直接从(3)开始,即直接创建 Bucket 实例:
第一步、创建 Bucket 资源

cat > bucket-foo.yaml <<EOF
apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
name: ceph-bucket
spec:
bucketName: ceph-bkt-foo
storageClassName: ceph-bucket
EOF

kubectl apply -f bucket-foo.yaml

# 补充说明:
# 1)在 Dashboard 中,将看到新创建的 Bucket 名称;
# 2)bucketName 指定真正的 Bucket 名称;还有 generateBucketName 属性,建议阅读官方文档以了解两者区别;
# 3)同时,将自动创建 能够访问该 Bucket 的用户,其用户名是随机的;

第二步、获取访问信息

#config-map, secret, OBC will part of default if no specific name space mentioned
export AWS_HOST=$(kubectl -n default get cm ceph-bucket -o jsonpath='{.data.BUCKET_HOST}’)
export PORT=$(kubectl -n defa[……]

READ MORE

「Rook」- NFS(实验目的,云原生 NFS 存储)

问题描述
该笔记将记录:在 Kubernetes 中,如何部署 Rook 服务,底层使用 NFS 存储,以及常见问题解决方案;
解决方案
# 03/14/2022 今天我们测试部署 Rook NFS 组件,虽然出于 Alpha 状态,但是我们也仅仅是实验目的,并未在生产环境中使用;
Rook NFS v1.7(03/14/2022),建议阅读 NFS Docs/v1.7 文档以了解更多细节,这里我们仅记录适用于我们测试环境的部署过程。 Kubernetes HA Cluster 1.18.20, worker k8s-storage as dedicated storage node
环境要求
Kubernetes v1.16 or higher The desired volume to export needs to be attached to the NFS server pod via a PVC NFS client packages must be installed on all nodes where Kubernetes might run pods with NFS mounted.
关于存储: 1)简单的拓扑结构为 Normal Pod ⇒ Storage Class ⇒ NFS Server ⇒ PVC ⇒ PV (hostPath) 所以我们以 hostPath 方式来提供最终的存储; 2)通过专用的存储节点,即 Kubernetes Worker 但是不会向该节点调度 Pod 实例(通过 Taint 及 Namespace defaultTolerations 来实现);
准备工作

# Taint node,以专用于存储
kubectl taint nodes k8s-storage dedicated=storage:NoSchedule

# 开启 PodNodeSelector,PodTolerationRestriction 插件(不再细述)
kube-apiserver … –enable-admission-plugins=NodeRestriction,PodNodeSelector,PodTolerationRestriction …

STEP-01 Deploy NFS Operator

git clone –single-branch –branch v1.7.3 https://github.com/rook/nfs.git
cd nfs/cluster/examples/kubernetes/nfs
kubectl create -f crds.yaml
kubectl create -f operato[……]

READ MORE

「KUBERNETES-ADDONS」- DNS

ExternalDNS
kubernetes-sigs/external-dns: Configure external DNS servers (AWS Route53, Google CloudDNS and others) for Kubernetes Ingresses and Services
通过为 Service[type=LoadBalancer] 添加注解,ExternalDNS 将自动在云商中添加 DNS 解析;

# kubectl annotate service nginx “external-dns.alpha.kubernetes.io/hostname=nginx.example.org.”
# kubectl annotate service nginx “external-dns.alpha.kubernetes.io/ttl=10″[……]

READ MORE

「KUBERNETES」- 部署 PowerDNS、PowerDNS-Admin 服务

问题描述
在客户环境中需要部署我们的软件产品,但是客户的环境网络隔离,无法访问公网网;
但是我们的服务依赖于 DNS 解析,所以需要部署 DNS 服务,需要解决如下问题: 1)集群外部主机提供 DNS 解析服务:外部主机能够通过该 DNS 服务完成域名解析; 2)集群内部容器提供 DNS 解析服务:内部容器能够通过该 DNS 服务完成域名解析;
该笔记将记录:在 Kubernetes Cluster 中,部署 DNS Server 的方法,以及相关问题的解决办法;
解决方案
我们使用 PowerDNS 服务,其原因如下: 1)具有 PowerDNS Admin 图形化界面来管理 DNS 解析; 2)具有 Helm Chart 使其能够运行在 Kubernetes 中;
第一步、部署 PowerDNS 服务
halkeye-docker/powerdns: Dockerized, pgsql-enabled PowerDNS powerdns 0.4.0 · halkeye/halkeye
#1 初始化数据库
该容器并未提供数据库初始化功能,所以我们需要手动初始化数据库: 1)我们使用 PostgreSQL 数据库,需要创建数据库、用户、密码,并授权; 2)参考 Generic PostgreSQL backend/Default schema 文档,建表;
#2 部署容器服务

helm repo add halkeye https://halkeye.github.io/helm-charts/
helm repo update

helm pull halkeye/powerdns # powerdns-0.4.0.tgz
helm show values ./powerdns-0.4.0.tgz > powerdns-0.4.0.helm-values.yaml

vim powerdns-0.4.0.helm-values.yaml
…(1)修改 service.loadBalancerIP 参数:指定负载均衡地址;
…(2)修改 powerdns.postgres 参数:指定数据库信息;
…(3)修改 powerdns.api_key 参数:指定 HTTP API 凭证;

helm –namespace infra-dns \
install powerdns[……]

READ MORE

「Kubernetes」- 部署 Dashboard 服务(Kubernetes v1.14.0)

问题描述
通过 Web UI (Dashboard) 界面,能够对集群的资源进行管理、显示正在运行的应用,查看资源状态,查看集群信息。
该笔记将记录:在 Kubernetes Cluster 中,如何安装部署 Dashboard 服务,以及常见问题处理。
解决方案
实验环境:Kubernetes Cluster v1.14.0
第一步、安装服务
查看集群版本:

# kubectl version -o json | jq -r ‘.serverVersion.gitVersion’
v1.14.0

下载找到对应版本(如果无法下载,使用 ./dashboard-v2.0.0-beta1-recommended.yaml 文件):

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml

部署资源文件:

kubectl apply -f recommended.yaml

第二步、创建 Ingress 资源
为了访问 Dashboard 服务,需要创建 Ingress 资源:

cat > dashboard-ingress.yaml <<EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: kube-system
name: kubernetes-dashboard
spec:
rules:
– host: k8s-dashboard.example.com
http:
paths:
– path: /
backend:
serviceName: kubernetes-dashboard
servicePort: 443
EOF

kubectl apply -f dashboard-ingress.yaml

参考文献
kubernetes dashboard安装 Releases · kubernetes/dashboard[……]

READ MORE

「KUBERNETES」- Helm, The package manager for Kubernetes

问题描述
如果不想手写所有的 Kubernetes YAML 文件,如何通过命令行从仓库中查找一个包,然后下载并安装?
解决方案
通过 Helm 工具,其是 Kubernetes 的包管理器,其作用与 pip for Python、npm for Node.js、yum for CentOS 等等工具类似。
而 Kubernetes Charts 则是包,其与 RPM in CentOS、DEB in Debian 等等类似。
Kubernetes Charts 是预先配置的 Kubernetes 资源包。Helm 是管理 Kubernetes Charts 的工具。它将 Kubernetes 包定义为一系列清单文件和一些元数据。这些清单文件其实就是模板。Helm实例化包的时候,会给模板中的字段赋值。Helm 包被称 Chart。[……]

READ MORE

「Helm」- 安装(Debian、CentOS、Ubuntu)

问题描述
该笔记将记录:在 Kubernetes 中,HELM 安装配置,以及常见问题处理;
解决方案
# 03/24/2022 版本 3 与版本 2 存在较大差异,我们这里部署为 Helm 3 版本并进行相关测试;
Helm 2(废弃)
我们可以从源代码编译 Helm,或者从 GitHub 的发行页面下载(地址是 Bithub.com/kubernetes/helm releases), 解压归档文件,并将 he1m 可执行文件放入$PATH 目录。例如,在 MacOS 上可以通过如下步骤安装 Hemlv2.7.2:

# wget https: //storage.googleapis. com/kubernetes-helm/i
# helm-v2.7.2-darwin-amd64.tar.gz
# tar -xvf helm-v2.7.2-darwin-amd64.tar.gz
# mv darwin-amd64/64/usr/local/bin
# helm version

现在 he1m 命令已经加入了$PATH,可以利用它在 Kubernetes 集群上启动服务端组件 tiller。Minikube 为例:

# kubectl get nodes
# helm init
# kubectl get pods –all-namespaces | grep tiller

现在都设置好了,你可以开始从 100 多个包中挑选需要的进行安装;
Helm 3(推荐)
版本选择
版本与其支持的集群版本,参考 Helm Version Support Policy 文档,如下简记:

Helm Version Supported Kubernetes Versions
3)8.x 1.23.x – 1.20.x
3)7.x 1.22.x – 1.19.x
3)6.x 1.21.x – 1.18.x
3)5.x 1.20.x – 1.17.x
3)4.x 1.19.x – 1.16.x
3)3.x 1.18.x – 1.15.x
3)2.x 1.18.x – 1.15.x
3)1.x 1.17.x – 1.14.x
3)0.x 1.16.x – 1.13.x
2)16.x 1.16.x – 1.15.x
2)15.x 1.15.x – 1.14.x
2)14.x 1.14.x – 1.13.x
2)13.x 1.13.x – 1.12.x
2)12.x 1.12.x – 1.11.x

on Ubuntu/Debian

# curl https://baltocdn.com/helm/signing.asc | apt-[……]

READ MORE

「Helm」- 常用命令

常用命令
第一步、添加仓库

helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
helm repo add stable https://kubernetes-charts.storage.googleapis.com # 稳定版仓库

helm repo update # 从 Chart 仓库中,更新本地缓存的可用 Chart 信息;

第二步、搜索图表

helm search repo “<chart-name>”
helm search repo “haproxy” # 在仓库中搜索 haproxy
helm search repo -l “haproxy” # 查看所有版本

安装图表
kubernetes – How to install a specific Chart version – Stack Overflow

helm install “<name>” “<repo/chart-name>”

helm install “foo” “incubator/haproxy-ingress” # 生成的资源(比如Ingress、Service、Deployment等等)将会以foo-为前缀
helm install “foo” “incubator/haproxy-ingress” –version “v1.1.2” # 安装特定版本

helm pull “<repo/chart-name>” # 下载 Chart(将下载到当前目录)
helm install “foo” “foo-6.3.3.tgz” # 并从本地直接安装

helm install “foo” “incubator/haproxy-ingress” –set scName=xxxxxxx #[……]

READ MORE

「HEML」- 常见错误整理

#1 no repositories found
-「How do I enable the Incubator repository?」
环境信息

系统环境:
CentOS Linux release 7.5.1804 (Core)

软件版本:
Helm v3.0.0-beta.3

问题描述 执行helm repo update命令,产生Error: no repositories found. You must add one before updating错误。
问题原因 在下载并安装helm二进制程序之后,默认是没有任何配置文件的,因此也不存在仓库配置信息。
解决办法 官方的Helm的Git仓库为「GitHub/helm/charts」,该仓库用于提交Charts包,而包在`https://kubernetes-charts.storage.googleapis.com/’%E4%BB%93%E5%BA%93%E4%B8%AD%E3%80%82
手动添加仓库:

helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
helm repo add stable https://kubernetes-charts.storage.googleapis.com # 稳定版仓库

helm repo update # 从Chart仓库中,更新本地可用的Chart信息。

# helm search repo <char-name>
helm search repo haproxy[……]

READ MORE

「NGINX-INGRESS-CONTROLLER」- 模块交互

Nginx Ingress Controller 是否会自动加载 TLS 证书
Cert Manager 负责 Certificate 的续期,在续期成功后,Certificate 关联的 Secret 也将被更新;
我们的疑问是 Nginx Ingress 是否会自动加载新的 Secret 以使 TLS 更新,还需需要手动 reload 配置?
我们猜测 Nginx Ingress Controller 能够自动加载新的 Secret 内容,原因是:如果 Cert Manager 更新完 Secret,还需要 Reload Ingress 的话,那么 Cert Manager 需要适配各种 Ingress Controller 实现,来完成 reload 动作。如果不是这样的话,那么 Kubernetes 就要提供一种机制,让来通知 Ingress Controller 需要 reload 配置;
然后,根据 https://github.com/cert-manager/cert-manager/issues/1816#issuecomment-506509695 的只言片语,我们更加认为 Ingress Controller 应该自动检测 Secret 的变化;[……]

READ MORE

「Kubernetes」- 已被弃用的扩展(DEPRECATED EXTENSIONS)

Heapster
集群监控
kubernetes v1.16/cluster/addons/cluster-monitoring/README.md
已被弃用

Kubernetes Release Action Policy/Support
Kubernetes 1.11 Initial Deprecation No new features or sinks are added. Bugfixes may be made.
Kubernetes 1.12 Setup Removal The optional to install Heapster via the Kubernetes setup script is removed.
Kubernetes 1.13 Removal No new bugfixes will be made. Move to kubernetes-retired organization.

建议使用
Kubernetes Metrics Server
kubeless
Kubernetes Native Serverless Framework, Serverless
通过 Serverless 技术,将一段代码直接部署到服务器,然后便能通过 API 对该函数进行调用;
该项目已不再维护;[……]

READ MORE

「KUBERNETES-ADDONS」- kube-vip

更新配置

export VIP=172.31.253.120
export INTERFACE=eth0
export KVVERSION=v0.4.4

alias kube-vip=”docker run –network host –rm ghcr.io/kube-vip/kube-vip:$KVVERSION”

kube-vip manifest pod \
–interface $INTERFACE \
–address $VIP \
–controlplane \
–services \
–arp \
–enableLoadBalancer \
–leaderElection | tee /etc/kubernetes/manifests/kube-vip.yaml

补充说明: 1)建议记录执行的命令及其参数,已被后续更新时使用;
开启 Master 负载均衡
kube-vip/Architecture
通过 –enableLoadBalancer 选项,来生成 manifest 文件,将开启 Control Plane 负载均衡。
或者,修改 kube-vip.yaml 文件,添加 lb_enable: true 环境变量:


env:

– name: lb_enable
value: “true”

然后,在 Leader 中(即 VIP 所在节点)查看 IPVS 信息:

$ sudo ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.40:6443 rr
-> 192.168.0.41:6443 Local 1 4 0
-> 192.168.0.42:6443 Local 1 3 0
-> 192.168.0.43:6443[……]

READ MORE

「kube-vip」- 常见问题处理

slice bounds out of range … with capacity …
问题描述


time=”2022-07-10T02:46:25Z” level=info msg=”new leader elected: k8s120-cp122″
time=”2022-07-10T02:46:25Z” level=info msg=”Node [k8s120-cp122] is assuming leadership of the cluster”
I0710 02:46:31.051943 1 leaderelection.go:258] successfully acquired lease kube-system/plndr-cp-lock
time=”2022-07-10T02:46:31Z” level=info msg=”Node [k8s120-cp123] is assuming leadership of the cluster”
time=”2022-07-10T02:46:31Z” level=info msg=”Starting IPVS LoadBalancer”
panic: runtime error: slice bounds out of range [:12] with capacity 0

goroutine 45 [running]:
github.com/cloudflare/ipvs.NewIP(…)
/go/pkg/mod/github.com/cloudflare/ipvs@v0.0.0-20210114211356-96b2597859b3/ip.go:25
github.com/kube-vip/kube-vip/pkg/loadbalancer.NewIPVSLB(0x0, 0x0, 0x192b, 0x1a, 0x0, 0x0)
/src/pkg/loadbalancer/ipvs.go:53 +0x779
github.com/kube-vip/kube-vip/pkg/cluster.(*Cluster).vipService(0xc0000de080, 0x1dc0130, 0xc0000b2f00, 0x1dc0130, 0xc0000b2f40, 0x2920480, 0xc0001fd480, 0x0, 0x0, 0x1c281d8, …)
/src/pkg/cluster/service.go:81 +0x427
github.com/kube-vip/kube-vip/pkg/cluster.(*Cluster).StartCluster.func3(0x1dc0130, 0xc0[……]

READ MORE