K8S哲学 - 资源调度 HPA （horizontal pod autoScaler-sync-period）

kubectl exec：

kubectl exec -it pod-name -c container-name -- /bin/sh

kubectl run 

通过一个 deployment来 演示

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy
  labels: 
    app: deploy
spec: 
   replicas: 1
   selector: 
     matchLabels:
       app: deploy-pod
   template:
    metadata:
       name: deploy-pod
       labels:
         app: deploy-pod
    spec:
      containers:
        - name: deploy-con
          image: nginx
          command: ["/bin/sh"]
          args: ["-c", "while true;do wget -q -O http:127.0.0.1 > /dev/null;  done"]
          livenessProbe:
             # startupProbe:
             # readinessProbe:
            httpGet:
              path: /index.html
              port: 80
            successThreshold: 1
            failureThreshold: 3
            periodSeconds: 3
            timeoutSeconds: 5
          env: 
          -  name: ARGS
             value: hhhhh
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 128Mi
          volumeMounts:
            # - name: my-volumes
            #   mountPath: /app
            - name: my-volumes2
              mountPath: /app2
      volumes: 
      - name: my-volumes2
        hostPath:
          path: /app2
    # volumeClaimTemplates:
    # - metadata: 
    #     name: my-volumes
    #   spec: 
    #     accessModes: ['ReadWriteOnce']
    #     resources:
    #         requests: 
    #           storage: '200Mi'
          

最小2个node 最大5个

 spec.containers[0].resources 

requests: min

limits: max

执行：

为

kubectl autoscale deploy deploy --cpu-percent=20 --min=2 --max=5 

my-deploy 创建 HPA

kubectl top 查看  pod 或 node 的占用指标 （metrics） 

表示 pod一旦创建 ，就一直 死循环请求 nginx页面，造成 cpu 升高，让 hpa 自动扩展 pod

数量

超过所限制的 100m 后自动 扩展 pod1 数量

当 cpu 降低后 ，hpa 会将 pod 数量维持在最 低的数量

 kubectl exec -it pod-name  -c container-name --/bin/bash 执行这个 pod里面的容器  curl 127.0.0.1查看nginx

但是 如果对 该pod 直接 执行 curl 则无法访问

原因是：

创建一个 service.yaml

重点是kind：service里面  selector 没有 matchLabels 直接写 labels

要和上面的 pod模版里面的 labels 对应上，这样可以 通过 service 实现服务发现

直接 访问 service 的ip 就可访问 pod的 服务，而不用关心pod的ip地址，流量可能打到 任何和 service 绑定的 pod 上面。

类式docker 的 【routing mesh 】思想，

apiVersion: v1
kind: Service
metadata:
 name: deploy-service
 labels:
   app: deploy-service
spec: 
  ports: 
   - port: 80
     targetPort: 80
     name: deploy-service-pod
  selector: 
     app: deploy-pod
  type: NodePort

查看 service 与之关联的 pod

这里我用的 是minikube 可以，将 minikube内部ip 和 主机ip 打通

minikube service service-name 

现在 通过 一个死循环的方式 一直 请求这个 servive，让pod的 cpu升高 ，