月度归档:2022年06月

Kubernetes 环境下部署单节点 Redis


2022年6月03日 15:57:54   2,856 次浏览

创建namespace:  kubectl create namespace redis

创建configmap 存放redis配置文件信息

kind: ConfigMap
apiVersion: v1
metadata:
  name: redis-config
  namespace: redis
  labels:
    app: redis
data:
  redis.conf: |-
    dir /data
    port 6379
    bind 0.0.0.0
    appendonly yes
    protected-mode no
    requirepass yourpassword
    pidfile /data/redis-6379.pid

 

创建pvc存储

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: redis-pvc
  namespace: redis
  labels:
    app: redis
  annotations:
    volume.beta.kubernetes.io/storage-class: "nfs-storage"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

创建deployment

---
apiVersion: v1
kind: Service
metadata:
  name: redis-svc
  namespace: redis
  labels:
    app: redis
spec:
  type: ClusterIP
  ports:
    - name: redis
      port: 6379
  selector:
    app: redis
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-dep
  namespace: redis
  labels:
    app: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
       initContainers:
        - name: system-init
          image: busybox:1.32
          imagePullPolicy: IfNotPresent
          command:
            - "sh"
            - "-c"
            - "echo 2048 > /proc/sys/net/core/somaxconn && echo never > /sys/kernel/mm/transparent_hugepage/enabled"
          securityContext:
            privileged: true
            runAsUser: 0
          volumeMounts:
          - name: sys
            mountPath: /sys
      containers:
        - name: redis
          image: redis:5.0.8
          command:
            - "sh"
            - "-c"
            - "redis-server /usr/local/etc/redis/redis.conf"
          ports:
            - containerPort: 6379
          resources:
            limits:
              cpu: 1000m
              memory: 1024Mi
            requests:
              cpu: 1000m
              memory: 1024Mi
          livenessProbe:
            tcpSocket:
              port: 6379
            initialDelaySeconds: 300
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
          readinessProbe:
            tcpSocket:
              port: 6379
            initialDelaySeconds: 5
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
          volumeMounts:
            - name: data
              mountPath: /data
            - name: config
              mountPath: /usr/local/etc/redis/redis.conf
              subPath: redis.conf
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: redis-pvc
        - name: config
          configMap:
            name: redis-config
        - name: sys
          hostPath:
            path: /sys

执行kubectl apply -f 应用资源

查看资源

[user@vm-centos-7 ~]$ kubectl get all -n redis
NAME                             READY   STATUS    RESTARTS   AGE
pod/redis-dep-77f876647c-g42vd   1/1     Running   1          23d

NAME                TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/redis-svc   ClusterIP   10.97.105.16   <none>        6379/TCP   23d

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/redis-dep   1/1     1            1           23d

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/redis-dep-77f876647c   1         1         1       23d

测试

使用如下步骤测试 redis 是否正常运行

[user@vm-centos-7 ~]$ kubectl -it exec redis-dep-77f876647c-g42vd -n redis -- sh
# redis-cli
127.0.0.1:6379> auth yourpassword
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "yourpassword"
127.0.0.1:6379>

 

SLB实例压测请求504超时


2022年6月02日 15:06:49   3,897 次浏览

问题描述

对SLB实例进行压测,出现504状态码、请求超时的现象。压测的URL配置了HTTPS监听的URL转发策略,且该转发策略并没有启用健康检查。

问题原因

  1. 查看日志服务中的SLB实例日志,发现大部分请求都出现504状态码,但是upstream_response_time值都非常有规律,响应时间都是5秒,该情况是SLB与后端服务器TCP三次握手失败,导致连接超时抛出504状态码。

    说明:查看该日志需要您开通日志服务。

  2. 登录后端服务器,排查发现Nginx日志没有异常,但是messages日志存在“nf_conntrack: table full, dropping packet”错误。该信息是因为Linux系统为每个经过内核网络栈的数据包,都生成一个新的连接记录项,当服务器处理的连接过多时,连接跟踪表无法记录新的连接记录项,服务器会丢弃新建连接的数据包。所以导致SLB和后端服务器TCP三次握手失败,出现504状态码。

解决方案

  1. 建议调整nf_conntrack参数,调整命令如下所示,参数值请以实际情况为准。

    说明:该方法会临时修改参数,重启实例后配置会不生效。

    sysctl -w net.netfilter.nf_conntrack_max=1048576
    sysctl -w net.netfilter.nf_conntrack_buckets=262144
    sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600
  2. 确认压测正常即可。