WalkingSun

K8S 整理

2020/08/27 k8s

kebectl 部署常用操作

服务管理

deployment、service、cronJob、ingress都是支持的

# 创建及更新服务（yaml文件形式）
kubectl apply -f web-click.yaml
# 删除服务（配置文件形式）
kubectl delete -f web-click.yaml
# 删除服务
kubectl delete deployment adc-web -n bigdata
kubectl delete svc adc-web -n bigdata
# 查看服务
kubectl get deployment --namespace=bigdata
kubectl get svc --namespace=bigdata
kubectl get ingress --namespace=bigdata
kubectl get cronjob smcheck-cronjob  -n bigdata
# 查看具体pod详细信息
kubectl describe pods adc-web-click-5f64b5fc-5v5n4 -n bigdata
kubectl describe ingress adc-ingress -n bigdata

pod信息

# 包含pod运行的状态
kubectl get pods --namespace=bigdata |grep adc
--
STATUS - Terminating 官方解释
Note: When a Pod is being deleted, it is shown as Terminating by some kubectl commands. This Terminating status is not one of the Pod phases. A Pod is granted a term to terminate gracefully, which defaults to 30 seconds. You can use the flag --force to terminate a Pod by force.
--

# 显示详细信息 如ip
kubectl get pods -o wide -n bigdata

查看pod日志

kubectl logs adc-web-click-5f64b5fc-6qs6w  -n bigdata

cronjob临时执行

构建job 从一个已有的cronjob载入配置执行

# cronjob 通过get cronjobs获取
kubectl create job check-test -n bigdata --from=cronjob/check-cronjob  --kubeconfig .kube/config

job执行完可以删除pods，避免占用空间

kubectl delete pod check-test-ldnfs -n bigdata

deployment

imagePullPolicy

  • Always 总是拉取 imagePullPolicy: Always
  • IfNotPresent 默认值,本地有则使用本地镜像,不拉取 imagePullPolicy: IfNotPresent
  • Never 只使用本地镜像，从不拉取 imagePullPolicy: Never

restartPolicy

  • Always pod中容器不论如何停止都将自动重启
  • OnFailure Pod中容器非正常停止会自动重启，正常停止不会重启
  • Never Pod中容器不论以任何方式停止，都不会自动重启 ```shell apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: restartPolicy: Always containers:
    • name: nginx-pod image: nginx ```

terminationGracePeriodSeconds

K8S滚动升级的步骤: 1.K8S首先启动新的POD 2.S等待新的POD进入Ready状态 3.K8S创建Endpoint，将新的POD纳入负载均衡 4.K8S移除与老POD相关的Endpoint，并且将老POD状态设置为Terminating，此时将不会有新的请求到达老POD 5.同时 K8S 会给老POD发送SIGTERM信号，并且等待 terminationGracePeriodSeconds 这么长的时间。(默认为30秒) 6.超过terminationGracePeriodSeconds等待时间后，K8S 会强制结束老POD

首先 terminationGracePeriodSeconds 要设置一个合适的值，至少保证所有现存的request能被正确处理并返回你的程序需要处理SIGTERM信号，并且保证所有事务完成后再关闭程序。

preStop

容器终止前执行，常用于资源清理。执行完成之后容器将成功终止，如果失败，容器同样也会被杀死。在其完成之前 会阻塞删除容器的操作

  lifecycle:
      preStop:
        exec:    # 在容器停止之前停止nginx服务
          command: ["/usr/sbin/nginx","-s","quit"]

postStart

容器创建后立即执行，注意由于是异步执行，它无法保证一定在 ENTRYPOINT 之前运行。如果失败，容器会被杀死，并根据 RestartPolicy 决定是 否重启

    lifecycle:
      postStart:
        exec:    # 在容器启动的时候执行一个命令，修改nginx默认首页内容
          command: ["/bin/sh","-c","echo postStart... > /usr/share/nginx/html/index.html"]

问题排查

查看容器进入容器环境

kubectl exec -it [pod name] --container [container name] -n [namespace] [执行命令]

kubectl exec -it callbackconsume-job-758874f99d-pgmtf –container adc-callback -n bigdata ls config/debug

查看日志

# -f 跟踪打印
kubectl logs -f --tail=10 callbackconsume-job-758874f99d-pgmtf -n bigdata

Ingress会有对应的ingress-controller对应pod，记录着ingress的访问日志；

 kubectl logs -f --tail=10 nginx-nginx-ingress-controller-7b85bf4f78-zsznw

将pod分配给节点

https://kubernetes.io/zh/docs/concepts/configuration/assign-pod-node/

查看节点 显示标签

kubectl get nodes --show-labels

添加标签

kubectl label nodes <node-name> <label-key>=<label-value>

添加 nodeSelector 字段到 pod 配置中

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd

kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml 命令，pod 将会调度到将标签添加到的节点上。

可以通过运行 kubectl get pods -o wide 并查看分配给 pod 的 “NODE” 来验证其是否有效

监控job

kubectl get jobs –watch -n bigdata

Replace “hello-4111706356” with the job name in your system

pods=$(kubectl get pods –selector=job-name=smcheck-cronjob-1589540820 –output=jsonpath={.items[*].metadata.name})

kubectl get pods –selector=job-name=smcheck-cronjob-1589540640

smcheck-cronjob-1589536140y

ingress使用

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  namespace: bigdata
  name: adc-ingress
  annotations:
    ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"					# ingress指定nginx		
    nginx.ingress.kubernetes.io/server-snippet: |     # 设置nginx 服务脚本配置
        set $flag 0;
        if ( $uri = /click) {
          set $flag 1;
        }
        if ( $args ~ project=ios ) {
          set $flag 1$flag;
        }
        if ( $flag = 11 ) {
          rewrite ^/(.*) $uri-ios break;
        }
spec:
  rules:
    - host: walking.sun.com
      http:
        paths:															# path对应nginx path
          - path: /click/google
            backend:
              serviceName: google-srv       # 指定path 请求会转发到对应的svc
              servicePort: 8080
          - path: /click-ios
            backend:
              serviceName: web-ios-srv
              servicePort: 8080
          - path: /click
            backend:
              serviceName: web-srv
              servicePort: 8080
    - host: walking.sun123.com
      http:
        paths:
          - path: /click/google
            backend:
              serviceName: google-srv
              servicePort: 8080
  tls:																			# 开发tls
    - hosts:
        - walking.sun.com
      secretName: sun.com
    - hosts:
        - walking.sun123.com
      secretName: sun123.com

参考：http://nginx.org/en/docs/http/ngx_http_core_module.html#internal

为容器和Pods分配CPU资源

容器将会请求 1 个 CPU，而且最多限制使用 2个 CPU。

          resources:
            limits:
              cpu: '2'
              memory: 4000Mi    # 最多使用4000M字节
            requests:
              cpu: '1'
              memory: 4000Mi
          volumeMounts:
            - name: config-volume
              mountPath: /config/release

CPU 资源以 CPU 单位度量。Kubernetes 中的一个 CPU 等同于：

  • 1 个 AWS vCPU
  • 1 个 GCP核心
  • 1 个 Azure vCore
  • 裸机上具有超线程能力的英特尔处理器上的 1 个超线程

小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。 你可以使用后缀 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 精度不能超过 1m。

参考：https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-cpu-resource/

服务发现

云控制台可在服务发现创建负载均衡服务，选择负载均衡集群，提供公网/私网地址。

ingress路由，转发策略如要使用ingress https （443端口），需配置相应证书。

Horizontal Pod Autoscaler（Pod水平自动伸缩）

需要安装个HPA插件，自动弹缩

Horizontal Pod Autoscaler 根据观察到的CPU利用率（或在支持自定义指标的情况下，根据其他一些应用程序提供的指标）自动伸缩 replication controller, deployment, replica set, stateful set 中的pod数量。注意，Horizontal Pod Autoscaling不适用于无法伸缩的对象，例如DaemonSets。

  • HPA 依赖于 Metrics-Server。

hpa.yaml

apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: -hpa  
spec:  
  maxReplicas: 99  
  minReplicas: 13
  # 监控的指标数组，支持多种类型的指标共存  
  metrics:
	   # Utilization类型的目标值，Resource类型的指标只支持Utilization（CPU）和AverageValue（内存）类型的目标值  
    - type: Resource  
      resource:  
        name: cpu  
        target:  
          type: Utilization  
          averageUtilization:   # cpu平均使用率百分比
    - type: Pods
	  pods:
	    metric:
          name: packets-per-second
          # AverageValue类型的目标值，Pods指标类型下只支持AverageValue类型的目标值
          target:
            type: AverageValue
            averageValue: 1k # 在目标 Pod 内存平均值为 1000 时，进行扩缩容操作
  scaleTargetRef: # 监控目标
    apiVersion: apps/v1  
    kind: Deployment   # 监控目标类型
    name:    # 监控目标名称
  behavior:  
    scaleDown:  
      stabilizationWindowSeconds: 3600

kubectl命令 kubectl autoscale deployment gateway.com --cpu-percent=90 --min=13 --max=99

HPA算法

按照 Pod 中所有 container 的资源使用平均值来计算，期望副本数=当前副本数 *（当前指标 / 期望指标）

当前度量值为 200m，目标设定值为 100m，那么由于 200.0/100.0== 2.0，副本数量将会翻倍。 如果当前指标为 50m，副本数量将会减半，因为 50.0/100.0== 0.5。 如果计算出的扩缩比例接近1.0（根据–horizontal-pod-autoscaler-tolerance 参数全局配置的容忍值，默认为 0.1），将会放弃本次扩缩。

滚动升级时的扩缩容

当你为一个 Deployment 配置自动扩缩时，你要为每个 Deployment 绑定一个HPA。 HPA管理 Deployment 的 replicas字段。 Deployment Controller 负责设置下层 ReplicaSet 的 replicas 字段，以便确保在上线及后续过程副本个数合适。

扩缩策略

扩容时：假如一个应用平时的cpu使用率是20%，突然使用率达到了100%，根据HPA的算法会使pod数量翻5倍。对基础架构和业务都有压力。 缩容时：假如pod数量是10个，需要缩容80%，如果一次性全部缩掉，业务可能会有影响。 这种情况就可以使用HPA的高级策略。

在 spec 字段的 behavior 部分可以指定一个或多个扩缩策略。

参考：

  • https://www.cnblogs.com/cjsblog/p/12266093.html
  • https://blog.csdn.net/weixin_43616190/article/details/126433513

Search

    Table of Contents