阿里云kubernets使用记录8-后续遇到的问题

0、一些常用的命令

kubectl get hpa	//查看hpa情况

kubectl get pod -o wide //查看详细的pod情况

kubectl describe pod <pod-name>  //查看单个pod的情况,一般有问题的时候用这个

kubectl rollout restart deployment deploymeng名 //滚动更新该deploymeng下的所有的pod

kubectl scale deployment yhs-ticket-hub --replicas=3  //手动调整pod的数量,不过有hpa的时候,可能还是会变回去,用下面的命令

kubectl patch hpa dt-catering-hpa -p '{"spec":{"minReplicas":2}}'  //如果有hpa,可以通过调整最小pod数量,来增加或减少pod

1、ingress自动创建的负载均衡slb不够用

默认创建的是最低配置的负载均衡,在请求过多的时候,会不够用,出现卡顿,长时间请求的情况,需要及时的升级负载均衡

2、未开启gzip的压缩

默认的nginx没有开启gzip的压缩,需要手动开启,命令如下

#先查找下相关的configmap
kubectl get configmap -n kube-system
#找到里面nginx相关的记录,然后编辑
kubectl edit configmap -n kube-system nginx-ingress-ack-ingress-nginx-v1-controller
#在data里增加gzip的配置,一般我们配置开启和级别就行
#注意,修改这类yaml文件,需要符合yaml的格式,冒号后面要有空格
use-gzip: "true"
gzip-level: "6"
#保存后,需要重启生效
kubectl rollout restart deployment -n kube-system nginx-ingress-ack-ingress-nginx-v1-controller

3、如果前面的cdn,这里还要开启真实ip的透传

还是跟上面一样修改configmap,在data里,增加下面数据

compute-full-forwarded-for: "true"
forwarded-for-header: "X-Forwarded-For"
use-forwarded-headers: "true"
proxy-real-ip-cidr: "0.0.0.0/0,::/0"

4、如果前端请求需要options预检

一般都是后端服务处理options,使它返回204,但是其实可以在ingress层返回的,如果你的业务没有特别的要求的话,下面贴一个样例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hub-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ($request_method = OPTIONS) {
          add_header Access-Control-Allow-Origin *;
          add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
          add_header Access-Control-Allow-Headers *;
          add_header Access-Control-Max-Age 86400;
          add_header Content-Length 0;
          add_header Content-Type text/plain;
          return 204;
      }
spec:
  ingressClassName: ack-nginx
  rules:
    - host: abc.com  # 这里换成你的域名
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hub
                port:
                  number: 80

5、pod滚动更新

因为pod启动一般都需要启动项目才能接收请求,所以如果不做设置的话,很可能出现pod还没有准备好,请求就过来了,请求失败的情况,下面列一个简单的方案,主要滚动更新这里,以及10秒后探测后才ready

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 2 # 2个pod
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0   # 滚动更新时不减少可用Pod
      maxSurge: 1         # 最多额外启动1个Pod
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.cn-hangzhou.aliyuncs.com/kylin87/docker-webman:8.1-3-cli-alpine
          workingDir: /nas/web  # 设置 Webman 工作目录
          command: ["/bin/sh", "-c"]
          args: ["php start.php start"]  # 启动 Webman
          resources:
            requests:
              cpu: "1"  # 最低0.5核
              memory: "3Gi"  # 最低 2Gi 内存
            limits:
              cpu: "2"  # 限制最大1核
              memory: "3Gi"  # 最低 2Gi 内存
          ports:
            - containerPort: 8787   #接口端口
            - containerPort: 9512   #rpc端口-内部
          readinessProbe:
            tcpSocket:
              port: 8787            # 改为探测接口端口
            initialDelaySeconds: 10 # 容器启动后延迟10秒再探测
            periodSeconds: 1        # 每1秒探测一次
            failureThreshold: 1     # 探测失败一次就标记未就绪    
          volumeMounts:
            - name: yhs-nas
              mountPath: /nas  # 挂载整个 NAS
      volumes:
        - name: yhs-nas
          persistentVolumeClaim:
            claimName: my-nas-pvc  # 关联 NAS 的 PVC

文章作者: Wind
本文链接:
版权声明: 本站所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 雕刻时光
喜欢就支持一下吧