云服务器内容精选

  • 操作步骤 登录 GaussDB (DWS)管理控制台。 在集群列表中单击需要访问“资源管理”页面的集群名称。 进入“基本信息”页面,左导航栏单击“资源管理”。 切换至“schema空间管理”模块,切换需要查看的数据库。 在需要修改空间限额模式的所在行操作列,单击“编辑”按钮,修改合适的空间限额。 单击“确定”提交。 空间限额仅对普通用户有效,数据库系统管理员用户不受限制(因此当显示已用空间等于空间限额时,真实使用空间可能已超出设置的值)。 单DN限额=总限额/DN节点数,所以设置值可能与最终显示值存在细微差异。
  • 空间管理简介 存储资源无节制的使用可能导致磁盘满,进而导致集群异常、业务中断。磁盘满问题具有业务恢复难度大、恢复时间长的特点,通过引入数据库只读,极大概率降低了磁盘满问题的发生,但是数据库只读同样会导致业务中断,影响业务连续性。为解决数据库只读问题,GaussDB(DWS)提供了多维度的存储资源管理能力,一方面在schema维度实现了schema空间管理,用于限制schema使用的永久空间大小;一方面在用户维度实现了永久空间、临时空间和算子空间管理,防止单用户业务异常导致数据库只读。 schema维度:schema空间管理模块可查询集群下数据库和模式空间信息,并支持修改模式空间总值。 用户维度:用户空间管理用于限定不同用户可以使用的空间限额,防止用户使用存储空间过大导致业务执行受阻。GaussDB(DWS)通过在创建用户时指定空间大小的方式实现对存储资源的管理,支持管理的存储空间类型包括: 永久表存储空间(PREM SPACE) 用于限制用户创建的永久表(非临时表)占用的空间限额。 临时表存储空间(TEMP SPACE) 用于限制用户创建的临时表占用的空间限额。 算子落盘空间(SPILL SPACE) 查询执行过程中,如果实际使用内存大于估算内存,则查询可能产生落盘,将这种查询执行过程中落盘占用的存储空间称为算子落盘空间。用户算子落盘空间管理用于限制用户查询执行过程中算子落盘占用的空间限额。 该特性仅8.1.1及以上集群版本支持。 GaussDB(DWS)管控面目前仅支持模式空间管理。
  • 使用ConfigMap配置Prometheus访问CCI 首先使用cci-iam-authenticator作为k8s client端的认证插件,通过用户名/密码的方式配置 IAM 认证信息。您可参照安装并设置kubectl进行配置。配置完成后,执行“kubectl config view”命令,获取$HOME/.kube/config路径下的kubeconfig文件。 图1 kubeconfig文件 以下示例是为Prometheus访问CCI所做的配置。使用此配置文件构造Prometheus连接API Server的信息。您只需将获取到的kubeconfig配置文件内容写入ConfigMap。 kind: ConfigMap apiVersion: v1 metadata: name: kubeconfig data: kubeconfig: |- apiVersion: v1 # cci-iam-authenticator生成的kubeconfig配置文件 ...
  • 使用ConfigMap管理Prometheus配置 为了能够方便的管理配置文件,我们这里将 prometheus.yml 文件用 ConfigMap 的形式进行管理。通过ConfigMap可以方便的做到配置解耦,使得不同环境有不同的配置。相比环境变量,Pod中引用的ConfigMap可以做到实时更新,当您更新ConfigMap的数据后,Pod中引用的ConfigMap会同步刷新。 创建prometheus-config.yml文件,并写入以下内容: kind: ConfigMap apiVersion: v1 metadata: name: prometheus-config labels: name: prometheus-config data: prometheus.yml: |- global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: kuberenete-pods # 对pod中应用的监控,自定义监控 kubernetes_sd_configs: - role: pod kubeconfig_file: /etc/kube/kubeconfig # 指定deployment挂载kubeconfig的路径 namespaces: names: - test # 要监控的命名空间列表 relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - source_labels: [__meta_kubernetes_namespace] - action: replace target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_pod_name] - action: replace target_label: kubernetes_pod_name - job_name: cci-monitor # 监控pod指标 kubernetes_sd_configs: - role: pod kubeconfig_file: /etc/kube/kubeconfig #指定deployment挂载kubeconfig的路径 namespaces: names: - test # 要监控的命名空间列表 relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_monitoring_cci_io_enable_pod_metrics] - action: drop regex: false - action: replace regex: ([^:]+)(?::\d+)? replacement: $1:19100 source_labels: [__meta_kubernetes_pod_ip] target_label: __address__ - action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 source_labels: [__meta_kubernetes_pod_ip, __meta_kubernetes_pod_annotation_monitoring_cci_io_metrics_port] target_label: __address__
  • 使用Deployment部署Prometheus 创建prometheus的工作负载,将配置项挂载到工作负载中。使用Deployment部署Prometheus所用的镜像,相比于官方镜像额外打包了cci-iam-authenticator二进制。 示例中创建一个名为prometheus-config的Volume,Volume引用名为“prometheus-config”、“kubeconfig”、“prometheus-storage”的ConfigMap,再将Volume挂载到容器的“/tmp”路径下。 kind: Deployment apiVersion: apps/v1 metadata: name: prometheus labels: app.kubernetes.io/component: prometheus app.kubernetes.io/instance: k8s app.kubernetes.io/name: prometheus app.kubernetes.io/part-of: kube-prometheus spec: replicas: 1 selector: matchLabels: app.kubernetes.io/component: prometheus # 架构中的组件 app.kubernetes.io/instance: k8s # 标识应用程序实例的唯一名称 app.kubernetes.io/name: prometheus # 应用程序的名称 app.kubernetes.io/part-of: kube-prometheus # 这是一个更高级别应用程序的名称 template: metadata: labels: app.kubernetes.io/component: prometheus app.kubernetes.io/instance: k8s app.kubernetes.io/name: prometheus app.kubernetes.io/part-of: kube-prometheus spec: volumes: # 在Volume中引用ConfigMap - name: prometheus-config configMap: name: prometheus-config defaultMode: 420 # ConfigMap卷中的所有文件默认设置为420 - name: kubeconfig configMap: name: kubeconfig defaultMode: 420 - name: prometheus-storage emptyDir: medium: LocalAuto sizeLimit: 10Gi containers: - name: prometheus image: 'swr.cn-north-7.myhuaweicloud.com/cci_k8s_gcr_io/...' args: # 传给可执行文件的参数(启动参数) - '--storage.tsdb.retention.time=12h' # 监控数据保留的时间 - '--config.file=/etc/prometheus/prometheus.yml' # 配置文件 - '--storage.tsdb.path=/prometheus/' # Prometheus写入数据库的地方 ports: - containerPort: 9090 protocol: TCP resources: limits: cpu: 500m memory: 1Gi requests: cpu: 500m memory: 1Gi volumeMounts: - name: prometheus-config mountPath: /etc/prometheus/ - name: kubeconfig mountPath: /etc/kube/ - name: prometheus-storage mountPath: /prometheus/ terminationMessagePath: /dev/termination-log # 表示容器的异常终止消息的路径 terminationMessagePolicy: File # 仅从终止消息文件中检索终止消息。 imagePullPolicy: Always restartPolicy: Always terminationGracePeriodSeconds: 30 # 优雅关闭的宽限期,即在收到停止请求后,有多少时间来进行资源释放或者做其它操作,如果到了最大时间还没有停止,会被强制结束。 dnsPolicy: ClusterFirst securityContext: {} schedulerName: default-scheduler strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25% revisionHistoryLimit: 10 progressDeadlineSeconds: 600
  • 应用场景 /dev/shm由tmpfs文件系统构成,tmpfs是Linux/Unix系统上的一种基于内存的文件系统,故读写效率非常高。 目前有用户希望通过/dev/shm实现进程间数据交互或通过/dev/shm实现临时数据存储,此时CCI场景/dev/shm默认大小64M无法满足客户诉求,故提供修改/dev/shm size大小的能力。 本操作实践展示通过“memory类型EmptyDir”和“配置securityContext与mount命令”两种方式来修改/dev/shm容量。
  • 限制与约束 /dev/shm使用基于内存的tmpfs文件系统,不具备持久性,容器重启后数据不保留。 用户可通过两种方式修改/dev/shm容量,但不建议在一个Pod中同时使用两种方式进行配置。 EmptyDir所使用的memory从Pod申请的memory中进行分配,不会额外占用资源。 在/dev/shm中写数据相当于申请内存,此种场景下需评估进程内存使用量,当容器内的进程申请内存与EmptyDir中数据量之和超过容器请求的限制内存时,会出现内存溢出异常。 当需要修改/dev/shm容量时,容量大小通常设定为Pod内存申请量的50%。
  • 内核参数配置 CCI服务底座使用安全容器构建了业内领先的Serverless容器平台,同物理机系统内核隔离且互不影响。对于资深业务部署场景,内核参数调优是比较通用的方式。在安全范围内,CCI服务允许客户根据Kubernetes社区推荐的方案,通过Pod的安全上下文(Security Context)对内核参数进行配置,极大提升用户业务部署的灵活性。如果你对securityContext概念不够熟悉,更多信息可阅读Security Context。 在 Linux 中,最通用的内核参数修改方式是通过sysctl接口进行配置。在Kubernetes中,也是通过Pod的sysctl安全上下文(Security Context)对内核参数进行配置,如果你对sysctl概念不够熟悉,可阅读在 Kubernetes 集群中使用 sysctl。安全上下文(Security Context)作用于同一个Pod内的所有容器。 CCI服务支持修改的内核参数范围如下: kernel.shm*,kernel.msg*, kernel.sem,fs.mqueue.*,net.*(net.netfilter.*和net.ipv4.vs.*除外) 以下示例中,使用Pod SecurityContext来对两个sysctl参数net.core.somaxconn和net.ipv4.tcp_tw_reuse进行设置。 apiVersion:v1kind:Podmetadata: name: xxxxx namespace: auto-test-namespacespec: securityContext: sysctls: - name: net.core.somaxconn value: "65536" - name: net.ipv4.tcp_tw_reuse value: "1" ...... 进入容器确认配置生效: 父主题: 负载管理