Scenario

net.core.somaxconn indicates the maximum number of half-open connections that can be backlogged in a listening queue. The default value is 128. If the queue is overloaded, you need to increase the listening queue length.

Procedure

1. Log in to the node.
   • If the node is in a cluster of 1.15 or later:

     Log in to the CCE console, choose Resource Management > Node Pools in the navigation pane, and click Configuration in the upper right corner of the node pool card view. Then, change the values of kubelet parameters.

     

   • If the node is in a cluster of v1.13 or earlier:

     Edit the /var/paas/kubernetes/kubelet/kubelet file and enable net.core.somaxconn.

     --allowed-unsafe-sysctls=net.core.somaxconn

     

     

     After the kubelet configurations are changed for a cluster of v1.13 or earlier, the configurations will be restored if the cluster is upgraded to a later version.

2. Restart kubelet.
   • If the node is in a cluster of 1.15 or later:

     After you perform step 1, the background automatically restarts kubelet.

   • If the node is in a cluster of v1.13:

     systemctl restart kubelet

     Check the kubelet status.

     systemctl status kubelet

   • If the node is in a cluster of v1.11:

     su paas -c '/var/paas/monit/bin/monit restart kubelet'

     Check the kubelet status.

     su paas -c '/var/paas/monit/bin/monit summary'

   Example printout after kubelet of a node in a cluster of v1.13 is started:

   

3. Create a pod security policy.

   Starting from v1.17.17, CCE enables pod security policies for kube-apiserver. You need to add net.core.somaxconn to allowedUnsafeSysctls of a pod security policy to make the policy take effect. (This configuration is not required for clusters earlier than v1.17.17.)

   • For details about CCE security policies, see Pod Security Policies.
   • For details about Kubernetes security policies, see PodSecurityPolicy.
   • For clusters with net.core.somaxconn enabled, add this configuration to allowedUnsafeSysctls of the corresponding pod security policy. For example, create a pod security policy as follows:

     apiVersion: policy/v1beta1
     kind: PodSecurityPolicy
     metadata:
       annotations:
         seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
       name: sysctl-psp
     spec:
       allowedUnsafeSysctls:
       - net.core.somaxconn
       allowPrivilegeEscalation: true
       allowedCapabilities:
       - '*'
       fsGroup:
         rule: RunAsAny
       hostIPC: true
       hostNetwork: true
       hostPID: true
       hostPorts:
       - max: 65535
         min: 0
       privileged: true
       runAsGroup:
         rule: RunAsAny
       runAsUser:
         rule: RunAsAny
       seLinux:
         rule: RunAsAny
       supplementalGroups:
         rule: RunAsAny
       volumes:
       - '*'

     After creating the pod security policy sysctl-psp, you need to configure RBAC permission control for it.

     Example:

     kind: ClusterRole
     apiVersion: rbac.authorization.k8s.io/v1
     metadata:
       name: sysctl-psp
     rules:
       - apiGroups:
           - "*"
         resources:
           - podsecuritypolicies
         resourceNames:
           - sysctl-psp
         verbs:
           - use
     
     ---
     apiVersion: rbac.authorization.k8s.io/v1
     kind: ClusterRoleBinding
     metadata:
       name: sysctl-psp
     roleRef:
       kind: ClusterRole
       name: sysctl-psp
       apiGroup: rbac.authorization.k8s.io
     subjects:
     - kind: Group
       name: system:authenticated
       apiGroup: rbac.authorization.k8s.io

4. Log in to the CCE console and create a workload. For details, see Creating a Deployment.

   When creating a workload, choose Scheduling Policies > Workload-Node Affinity and Anti-affinity > Affinity with Node in Set Advanced Settings, and select the node that you have logged in to in 1.

5. Click Create YAML and set the following kernel parameters in bold:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     annotations:
       description: ''
     labels:
       appgroup: ''
     name: test1
     namespace: default
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: test1
     template:
       metadata:
         annotations:
           metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"","path":"","port":"","names":""}]'
         labels:
           app: test1
       spec:
         containers:
           - image: 'nginx:1.14-alpine-perl'
             name: container-0
             resources:
               requests:
                 cpu: 250m
                 memory: 512Mi
               limits:
                 cpu: 250m
                 memory: 512Mi
         imagePullSecrets:
           - name: default-secret
         securityContext:
           sysctls:
             - name: net.core.somaxconn
               value: '3000'
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
                 - matchExpressions:
                     - key: kubernetes.io/hostname
                       operator: In
                       values:
                         - 192.168.x.x

6. Log in to the node in 1, access the container, and check whether the parameter configuration takes effect.

   For example, run the following command to view the containerid workload whose name is test:

   docker ps –a |grep test

   Run the following command to access the container:

   docker exec -it containerid /bin/sh

   Run the following command to check whether the configuration takes effect:

   sysctl -a |grep somax

   Figure 1 Viewing the parameter configuration