在配置集群时，会遇到不少既复杂又有趣的问题。比如，在制定服务策略时，需要制作相应的Istio配置，这个过程需要掌握不少技术知识，也是许多技术人员在工作中需要关注的重点。

安装KubeSphere最好的方法就是参考官方文档，而且官方文档是中文的。
官网地址：https://kubesphere.com.cn/

Kubernetes存储分配器的选择

yum install -y nfs-utils

集群存储中，我们运用StorageClass进行PV的动态生成。但要注意，使用StorageClass的前提是必须拥有一个存储分配器。Kubernetes官方的分配器不兼容NFS，这时就必须额外安装NFS存储分配器。这是Kubernetes存储体系的关键环节。在配置集群时，若不熟悉这一点，可能会导致存储分配失败。不同应用场景对存储的需求各异，若需NFS存储，这一额外步骤是必须的。

echo "/nfs/data/ *(insecure,rw,sync,no_root_squash)" > /etc/exports

NFS存储分配器在操作过程中有很多细节需要注意。它处在Kubernetes集群之中，若想管理NFS的存储空间，必须和APIServer进行沟通。这种沟通是在集群内Pod与APIServer之间进行的，因此必须设立ServiceAccount。接着，还需创建存储类、ClusterRole、ClusterRoleBinding、Role、RoleBinding等账号权限设置。这些步骤一个都不能少，缺少任何一个都可能让整个存储系统无法正常运行。

systemctl enable rpcbind
systemctl enable nfs-server
systemctl start rpcbind
systemctl start nfs-server

PersistentVolume子系统

exportfs -r ##使配置生效
exportfs ##检查配置是否已生效

PV子系统对用户和管理员来说至关重要。它提供了一套API，主要用于描述如何根据不同需求获取存储的详细信息。比如，在选择存储系统时，不论是NFS、iSCSI还是针对特定云服务提供商的存储系统，它都能捕捉到这些存储实现的详细信息。这一功能非常实用，无论是在大型数据中心还是小型企业级集群，都能借助这个子系统清楚地了解存储状况。

 showmount -e 192.168.48.10

Pod与PersistentVolume子系统关系密切。Pod利用PVC访问存储卷，并设有权限限制。早期版本中，这种限制被称为PVCProtection，而现在称作storageProtection。此机制旨在防止正在使用的PVC被误删，以此保障数据安全。在众多大规模数据存储应用中，这一机制尤为关键，有效防止因误操作导致重要数据丢失。

Metrics-Server功能

服务器在集群中扮演着至关重要的角色。它作为集群指标监控的一部分，主要与API服务器进行交互，以获取Kubernetes集群中各项指标信息。这些信息涵盖了Pod、Node等资源的使用情况，如CPU和内存。在集群管理日常工作中，通过分析这些指标，能够迅速发现并解决问题，例如某个Pod的CPU使用率异常升高，便可以快速判断是代码问题还是资源分配不当。

vim sc.yaml 

KubeSphere中，Metrics-Server扮演着关键角色。KubeSphere作为Kubernetes的仪表盘，要获取Kubernetes的数据，需依赖特定组件提供，而这功能正是Metrics-Server负责的。若缺少Metrics-Server，KubeSphere便无法准确展示集群资源使用状况，这对集群管理和监控会造成极大不便。

## 创建了一个存储类
apiVersion: storage.k8s.io/v1
kind: StorageClass                  #存储类的资源名称
metadata:
  name: nfs-storage                 #存储类的名称，自定义
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"          #注解，是否是默认的存储，注意：KubeSphere默认就需要个默认存储，因此这里注解要设置为“默认”的存储系统，表示为"true"，代表默认。
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner         #存储分配器的名字，自定义
parameters:
  archiveOnDelete: "true"  ## 删除pv的时候，pv的内容是否要备份
 
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
spec:
  replicas: 1                 #只运行一个副本应用
  strategy:                   #描述了如何用新的POD替换现有的POD
    type: Recreate            #Recreate表示重新创建Pod
  selector:        #选择后端Pod
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:

        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner          #创建账户
      containers:
        - name: nfs-client-provisioner         
          image: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/nfs-subdir-external-provisioner:v4.0.2      #使用NFS存储分配器的镜像
          # resources:
          #    limits:
          #      cpu: 10m
          #    requests:
          #      cpu: 10m
          volumeMounts:
            - name: nfs-client-root           #定义个存储卷，
              mountPath: /persistentvolumes   #表示挂载容器内部的路径
          env:
            - name: PROVISIONER_NAME          #定义存储分配器的名称
              value: k8s-sigs.io/nfs-subdir-external-provisioner         #需要和上面定义的保持名称一致
            - name: NFS_SERVER                                       #指定NFS服务器的地址，你需要改成你的NFS服务器的IP地址
              value: 192.168.48.10 ## 指定自己nfs服务器地址
            - name: NFS_PATH                                
              value: /nfs/data  ## nfs服务器共享的目录            #指定NFS服务器共享的目录
      volumes:
        - name: nfs-client-root           #存储卷的名称，和前面定义的保持一致
          nfs:
            server: 192.168.48.10            #NFS服务器的地址，和上面保持一致，这里需要改为你的IP地址
            path: /nfs/data               #NFS共享的存储目录，和上面保持一致
--- 
apiVersion: v1
kind: ServiceAccount                 #创建个SA账号
metadata:
  name: nfs-client-provisioner        #和上面的SA账号保持一致
  # replace with namespace where provisioner is deployed
  namespace: default
---
#以下就是ClusterRole，ClusterRoleBinding，Role，RoleBinding都是权限绑定配置，不在解释。直接复制即可。
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

修改集群配置的意义

集群配置的调整至关重要。例如，通过启用KubeSphere的一些插件，如DevOps相关的工具、激活ectd的监控以及开启告警机制等，这些操作能够增强集群的运行效能与管理效率。以告警功能为例，一旦集群中某个关键Pod出现故障，管理员便能立即获得通知，迅速采取应对措施。

kubectl apply -f sc.yaml

操作集群配置时，需认真分析各插件功能。不宜随意开启全部插件，以免资源过度消耗。应根据具体需求进行配置，比如，若项目以数据存储为主，则应优先启用和优化存储插件；若项目更偏向开发运维结合，那么DevOps相关插件的启用就尤为重要。

[root@master ~]# kubectl get sc
NAME                    PROVISIONER                                   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-storage (default)   k8s-sigs.io/nfs-subdir-external-provisioner   Delete          Immediate           false                  10h

日志相关服务

集群运维离不开日志索引、查询及数据管理等服务。安装时，若能接入现有的ES（Elasticsearch），能降低资源消耗。在企业集群中，尤其是大型环境，日志数据量极大。若每个日志功能都单独运行，将导致资源严重浪费。

[root@master ~]# kubectl get pods -A
NAMESPACE              NAME                                         READY   STATUS      RESTARTS        AGE
default                nfs-client-provisioner-65878c6456-hsxqf      1/1     Running     1 (35m ago)     10h

配置日志索引这类服务时，需全面考虑生产环境中的业务量、数据流量等关键因素。不能仅仅开启服务这么简单。例如，在业务高峰期，可能需要扩大日志索引的缓存容量，否则查询日志的速度可能会变慢，甚至出现查询失败的情况。

服务策略与Istio配置

在制定服务策略的过程中，生成相应的Istio配置同样至关重要。在复杂的网络结构中，这样的配置能协助调控服务间的数据流动，并加强安全防护。若DevOps、ServiceMesh、警告等插件均开启，便需配置得更为细致。比如，在多个服务间频繁交互且对安全要求极高的场合，若Istio配置出现失误，可能引发服务间通信的安全风险，或是流量分配出现不均等问题。

生成准确的Istio配置需对集群内各服务间的联系和具体需求有深刻理解。不同服务可能对流量和安全有不同要求，因此需对每个服务的特点进行详细分析，进而制定恰当的配置。这对众多工程师而言是一大挑战。您在工作中是否遇到过关于配置Istio的难题？阅读本文或许能帮助您更深入地了解集群配置的相关知识。同时，欢迎点赞及转发，让更多同行从中受益。

[root@master ~]# kubectl get pv
No resources found