「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[……]
「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[……]
「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[……]
「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[……]
「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-[……]
「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[……]
「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[……]
「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[……]
「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[……]
「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 服[……]
「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 -[……]
「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[……]
「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[……]
「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″[……]
「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[……]
「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[……]
「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。[……]
「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-[……]
「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 #[……]
「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[……]
「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 的变化；[……]
「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 对该函数进行调用；
该项目已不再维护；[……]
「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[……]
「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[……]
「KUBERNETES-ADDONS」- kubeadm：集群部署工具
集群配置文件（kubeadm-config）
Kubernetes/kubeadm Configuration (v1beta3)
# kubeadm config print init-defaults > kubeadm-config.yaml
…
# kubeadm init –config=kubeadm-config.yaml –upload-certs
…
配置 BASH 补全
# 首先，需要安装 bash-complete 包，因为 kubectl 依赖于它。
apt-get install bash-completion # Debian
yum install bash-completion # CentOS
# 然后，启用 kubectl 补全
echo “source <($(which kubeadm) completion bash)” >> ~/.bashrc
source ~/.bashrc
参考文献
Kubeadm | Kubernetes[……]
「KUBERNETES-ADDONS」- 安装并使用 kubectl 管理集群
问题描述
kubectl 是 Kubernetes 集群管理命令，用于管理 Kubernetes 集群，完成集群维护任务。在使用集群时，我们有很多能用的管理工具，但是深入的集群管理与问题排查还是需要使用 kubectl 命令，而非那些高级 Web 图形化界面。
该笔记将记录：在 Linux 中，如何安装 kubectl 命令，以及常用命令、配置、使用方法，以及相关问题处理。
解决方案
Install and Set Up kubectl Overview of kubectl Kubernetes/Reference/kubectl[……]
「Doxygen」- 文档生成工具
用于 C, C++, Java, Objective-C, Python, IDL 和某些范围的 PHP, C#, D 的文档系统。可以从一组记录的源文件中，生成在线的 class 浏览（HTML 格式）和离线的参考手册（LaTeX 格式）。同时也支持生成 Man 手册、将生成的输出转化为 POstscript、超链接的 PDF、压缩的HTML。文档直接从源文件中提取，即写在代码中的注释。
用「Doxygen」可以做什么？
1）从代码的注释中，生成文档。 2）使用未注释的源码来：分析源码的结构，获取源码的调用图、继承图、关系图。 3）单纯的创建普通文档。
支持的输出格式
HTML、LaTeX、Man pages、Rich Text Format、XML
软件安装
通过包管理器安装（APT、YUM）
# Kali GNU/Linux Rolling
apt-get install doxygen doxygen-gui
# Doxygen手册
apt-get install doxygen-doc
通过源码编译安装（Linux）
参考 BLFS/Doxygen-1.8.11 站点，以获取编译安装的详细过程。
包含的可执行程序
doxygen 是一个基于命令行的程序，用于生成配置文件模板，然后用模板生成文档。 使用doxygen –help来解释命令行参数。
doxywizard 配置和运行doxygen的GUI工具。
doxyindexer 使用由doxygen生成的搜索数据文件，生成名为doxysearch.db的搜索索引文件。 http://www.stack.nl/~dimitri/doxygen/manual/extsearch.html
doxysearch.cgi 用于搜索由doxygen索引的数据的CGI程序。
参考文献
Wikipedia / Doxygen: https://en.wikipedia.org/wiki/Doxygen Homepage: http://www.stack.nl/~dimitri/doxygen/ Doxygen Manual: http://www.stack.nl/~dimitri/doxygen/manual/index.html Github Repo: https://github.com/doxygen/doxygen BLFS/Doxygen-1.8.11[……]
「COMPUTER-NETWORKING」- 计算机、网络、协议（数据通信网络）
研究对象
计算机网络。我们将开始学习网络技术，该部分内容是我们的对计算机网络技术及网络协议相关的学习笔记；
研究结果
理论：熟悉计算机网络通信过程所使用的网络协议，以及网络协议的大致交互过程； 实践：熟悉华为网络设备配置，能够通过网络设备（或开源组件）来实现企业网络；
鉴于网络工程师或计算机网络并非我们未来的发展方向，所以学习网络知识需要注意如下事项： 1）熟悉协议的交互流程，但切莫过于深入探索协议细节内容：例如，学习 IPSec VPN 内容，重点放在协议交互过程，切莫深究密码学知识； 2）减少厂商相关技术的学习，增加通用技术的学习，掌握解决问题的思想）：例如，围绕华为体系展开学习，而不再学习其他厂商相关的知识；
研究工具
培训机构：
书籍教材： 1）华为 IP 网络系列丛书：https://e.huawei.com/cn/topic/enterprise-network/ip-ebook
官方文档：RFC
文章博客：
章节列表
基础知识：基本概念术语，形成对网络的基本认识、理解网络工作原理； 通信协议：数通网络技术，涵盖诸如网络、交换、路由等等技术；应用网络协议，常见应用层服务，以及服务搭建部署； 企业数通：企业网及解决方案； 运维管理：网络维护及管理；网络自动化； 附录杂项：网络硬件及解决方案（含硬件产品，但不含硬件参数及原理）；
涵盖内容
该部分笔记内容将涵盖以下部分： 1）概念术语：形成对网络的宏观且基本的认识，了解网络的基本原理； 2）网络技术：在数据通信中用到的技术解决方案及其原理；例如对等网络、链路聚合等等； 3）网络协议：深入学习网络协议，了解协议工作原理；例如 HTTP、TCP、IP、L2TP 等等； 4）服务搭建：与具体网络协议相关的应用、服务、环境搭建及使用等等；
附加说明
该部分内容包括网络技术及网络协议，但不涉及网络硬件、操作系统网络实现等等知识； 该部分内容包括服务搭建，但不包含软件实现的过多介绍（比如客户端功能对比）； 鉴于网络协议是操作系统无关的，因此该部分并不涉及「操作系统网络配置」相关内容；[……]
「PPP」- Point-to-Point Protocol
问题描述
PPP 用于 CE 与 PE 之间发送数据。
解决方案
PPP（Point-to-Point Protocol，点到点协议）是一种常见的广域网数据链路层协议，主要用于在全双工的链路上进行点到点的数据传输封装。
原理简述
协议特性
提供链路层参数协商协议： 1） LCP（Link Control Protocol，链路控制协议），用于各种链路层参数的协商，例如最大接收单元，认证模式等。
提供安全认证协议族： 1）PAP（Password Authentication Protocol，密码验证协议）， 2）CHAP（Challenge Handshake Authentication Protocol，挑战握手认证协议）， 3）而以太网不支持直接认证，需要其他认证手段（比如 Portal 认证）
提供网络层参数协议： 1）各种 NCP（Network Control Protocol，网络控制协议），用于各网络层参数的协商，更好地支持了网络层协议。 2）如 IPCP（IP Control Protocol ，网络控制协议），
提供良好的扩展性： 1）例如，当需要在以太网链路上承载 PPP 协议时，PPP 能够扩展为 PPPoE 协议。
注意事项： 1）在 PPP 中，它是点到点协议，并非以太那种多路访问 2）是不存在 MAC Address 的，所以也没有 ARP 协议； 3）鉴于是点到点链路，链路间不需要也不能连接交换机；
应用场景
PPP 用于 CE 与 PE 之间发送数据
概念术语
配置使用[……]
「PPP」- 报文格式
PPP Packet Format
Protocol：上层承载的报文；
Code：当前协议的不同报文类型；
Data：业务数据；
建立链接
Configuration Request
Frame 44: 18 bytes on wire (144 bits), 18 bytes captured (144 bits) on interface -, id 0
Point-to-Point Protocol
Address: 0xff
Control: 0x03
Protocol: Link Control Protocol (0xc021)
PPP Link Control Protocol
Code: Configuration Request (1)
Identifier: 4 (0x04)
Length: 14
Options: (10 bytes), Maximum Receive Unit, Magic Number
Maximum Receive Unit: 1500
Magic Number: 0x3283550a
Configuration Ack
Frame 45: 18 bytes on wire (144 bits), 18 bytes captured (144 bits) on interface -, id 0
Point-to-Point Protocol
Address: 0xff
Control: 0x03
Protocol: Link Control Protocol (0xc021)
PPP Link Control Protocol
Code: Configuration Ack (2)
Identifier: 4 (0x04)
Length: 14
Options: (10 bytes), Maximum Receive Unit, Magic Number
Maximum Receive Unit: 1500
Magic Number: 0x3283550a
断开链接
Termination Request
Frame 41: 8 bytes on wire (64 bits), 8 bytes captured (64 bits) on interface -, id 0
Point-to-Point Protocol
Address: 0xff
Control: 0x03
Protocol: Link Cont[……]