1.k8s容器资源限制

Kubernetes采用request和limit两种限制类型来对资源进行分配。
request(资源需求)：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。
limit(资源限额)：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。

资源类型:
CPU 的单位是核心数，内存的单位是字节。
一个容器申请0.5个CPU，就相当于申请1个CPU的一半，你也可以加个后缀m 表示千分之一的概念。比如说100m的CPU，100豪的CPU和0.1个CPU都是一样的。
内存单位：
K、M、G、T、P、E #通常是以1000为换算标准的。
Ki、Mi、Gi、Ti、Pi、Ei #通常是以1024为换算标准的。

k8s容器资源限制
内存限制示例：

此时超过限制容器运行不成功


将内存修改至限制范围内

成功运行

如果容器超过其内存限制，则会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。
如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。

CPU限制示例：

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: stress
    resources:
      limits:
        cpu: "10"
      requests:
        cpu: "5"
    args:
    - -c
    - "2"

调度失败是因为申请的CPU资源超出集群节点所能提供的资源
但CPU 使用率过高，不会被杀死

为namespace设置资源限制：

apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-memory
spec:
  limits:
  - default:
      cpu: 0.5
      memory: 512Mi
    defaultRequest:
      cpu: 0.1
      memory: 256Mi
    max:
      cpu: 1
      memory: 1Gi
    min:
      cpu: 0.1
      memory: 100Mi
    type: Container

kubectl  create -f limit.yaml 
kubectl  describe  limitranges

LimitRange 在 namespace 中施加的最小和最大内存限制只有在创建和更新 Pod 时才会被应用。改变 LimitRange 不会对之前创建的 Pod 造成影响。
为namespace设置资源配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

创建的ResourceQuota对象将在default名字空间中添加以下限制：
每个容器必须设置内存请求（memory request），内存限额（memory limit），cpu请求（cpu request）和cpu限额（cpu limit）。
所有容器的内存请求总额不得超过1 GiB。
所有容器的内存限额总额不得超过2 GiB。
所有容器的CPU请求总额不得超过1 CPU。
所有容器的CPU限额总额不得超过2 CPU。

为 Namespace 配置Pod配额:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
    pods: "2"

设置Pod配额以限制可以在namespace中运行的Pod数量。

2.Metrics-Server部署

Metrics-Server是集群核心监控数据的聚合器，用来替换之前的heapster。

容器相关的 Metrics 主要来自于 kubelet 内置的 cAdvisor 服务，有了Metrics-Server之后，用户就可以通过标准的 Kubernetes API 来访问到这些监控数据。
Metrics API 只可以查询当前的度量数据，并不保存历史数据。
Metrics API URI 为 /apis/metrics.k8s.io/，在 k8s.io/metrics 维护。
必须部署 metrics-server 才能使用该 API，metrics-server 通过调用 Kubelet Summary API 获取数据。

Metrics-server属于Core metrics(核心指标)，提供API metrics.k8s.io，仅提供Node和Pod的CPU和内存使用情况。而其他Custom Metrics(自定义指标)由Prometheus等组件来完成。

资源下载：https://github.com/kubernetes-incubator/metrics-server

Metrics-server部署：

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml

报错2：x509: certificate signed by unknown authority

Metric Server 支持一个参数 --kubelet-insecure-tls，可以跳过这一检查，然而官方也明确说了，这种方式不推荐生产使用。

启用TLS Bootstrap 证书签发

#vim /var/lib/kubelet/config.yaml 	
...
最后添加
serverTLSBootstrap: true

systemctl  restart kubelet

kubectl get csr
NAME        AGE     REQUESTOR                     CONDITION
csr-f29hk   5s      system:node:node-standard-2   Pending
csr-n9pvr   3m31s   system:node:node-standard-3   Pending

kubectl certificate approve csr-n9pvr
certificatesigningrequest.certificates.k8s.io/csr-n9pvr approved

3. Dashboard部署

Dashboard可以给用户提供一个可视化的 Web 界面来查看当前集群的各种信息。用户可以用 Kubernetes Dashboard 部署容器化的应用、监控应用的状态、执行故障排查任务以及管理 Kubernetes 各种资源。

网址：https://github.com/kubernetes/dashboard

下载部署文件：
https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-rc5/aio/deploy/recommended.yaml
下载镜像

修改部署文件
确保拉取的版本号一致

修改为NodePort方式，以便外部访问

kubectl -n kubernetes-dashboard edit svc kubernetes-dashboard

kubectl -n kubernetes-dashboard get svc

登陆dashboard需要认证，需要获取dashboard pod的token：

HPA实例

官网：https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
运行deployment服务:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m

---

apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

上传镜像

运行

创建 Horizontal Pod Autoscaler

现在，php-apache 服务器已经运行，我们将通过 kubectl autoscale 命令创建 Horizontal Pod Autoscaler。 以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的 Deployment，使 Pod 的副本数量维持在 1 到 10 之间。 大致来说，HPA 将（通过 Deployment）增加或者减少 Pod 副本的数量以保持所有 Pod 的平均 CPU 利用率在 50% 左右（由于每个 Pod 请求 200 毫核的 CPU，这意味着平均 CPU 用量为 100 毫核）

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
kubectl get hpa

请注意当前的 CPU 利用率是 0%，这是由于我们尚未发送任何请求到服务器

增加负载

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

一分钟时间左右之后，通过以下命令，我们可以看到 CPU 负载升高了：

停止负载

我们将通过停止负载来结束我们的示例。

在我们创建 busybox 容器的终端中，输入Ctrl + C 来终止负载的产生。

然后我们可以再次检查负载状态（等待几分钟时间）：

HPA伸缩过程：
收集HPA控制下所有Pod最近的cpu使用情况（CPU utilization）
对比在扩容条件里记录的cpu限额（CPUUtilization）
调整实例数（必须要满足不超过最大/最小实例数）
每隔30s做一次自动扩容的判断
CPU utilization的计算方法是用cpu usage（最近一分钟的平均值，通过metrics可以直接获取到）除以cpu request（这里cpu request就是我们在创建容器时制定的cpu使用核心数）得到一个平均值，这个平均值可以理解为：平均每个Pod CPU核心的使用占比。

HPA进行伸缩算法：
计算公式：TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) / Target)
ceil()表示取大于或等于某数的最近一个整数
每次扩容后冷却3分钟才能再次进行扩容，而缩容则要等5分钟后。
当前Pod Cpu使用率与目标使用率接近时，不会触发扩容或缩容：
触发条件：avg(CurrentPodsConsumption) / Target >1.1 或 <0.9