how to modify sysctl.conf which appeared as read-only in the pod

 

만약 어떤 조정을 위해서 배포될 pod 안의 /etc/sysctl.conf 값을 변경하고 싶은데 read-only filesystem 이라고 로그 확인되면서 배포 커맨드가 적용되지 않는 경우, 그러나 배포 시마다 새로운 pod에 해당 값을 고정으로 적용이 필요한 경우,

컨피그맵으로 해당 값 매칭하여 볼륨 마운트 추가 하는 방법이 가능하다.

 

컨피그맵 생성 예시 (명령어 혹은 yaml 배포 이용):

apiVersion: v1
kind: ConfigMap
metadata:
  name: sysctl-cm
data:
  sysctl.conf: |
    net.ipv6.conf.all.disable_ipv6=1

FYI it's possible that the established IPv6 connections were created before the net.ipv6.conf.all.disable_ipv6 sysctl option was set. The sysctl option disables the IPv6 protocol on the network interface, but it doesn't necessarily terminate existing connections.

Additionally, some applications may still try to establish IPv6 connections even if it's disabled on the network interface. This can be due to the application's configuration or the way it's programmed.

 

배포 yaml 파일 Deployment 항목(pod배포 항목)의 spec, 컨테이너 밑의 volumeMounts에 추가한다.

          volumeMounts:
            - name: sysctl-conf
              mountPath: "/etc/sysctl.conf"
              subPath: sysctl.conf

 

마운트할 대상 볼륨의 컨피그 맵 정의를 volumes 밑에 추가한다.

 

      volumes:
        - name: sysctl-conf
          configMap:
            name: sysctl-cm
            items:
              - key: sysctl.conf
                path: sysctl.conf

 

참고로 yaml 배포시 커맨드를 사용하여 무언가 설치하고 값을 추가하려는데 권한이 없어 안된다는 에러를 접하면,

runAsUser을 0 로 설정하여 최상위 권한으로 설정배포 가능하다.

 

예시:

스펙의 컨테이너 이미지 부분 밑에 추가하였다.

          securityContext:
            runAsUser: 0

커맨드 예시:

               command:                
               - /bin/bash
               - -c
               - apk update && apk add sudo && sysctl -w net.ipv6.conf.all.disable_ipv6=1 && sleep infinity

커맨드는 [] 묶음으로도 표현 가능하다.

command: ["/bin/bash", "-c", "echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf && sysctl -p && sleep infinity"]
    securityContext:
      privileged: true

여기서 privileged: true 는 모든 기능으로 포드를 실행하고 읽기 전용 파일 시스템을 우회하는 옵션이다.

option to run the pod with all capabilities and bypass the read-only file system.

 

위 과정을 거쳐 컨피그 맵을 생성하고 볼륨 마운트를 해서, 직접 포드 안에 들어가 해당 값이 적용된 것을 확인할 수 있다.

kubectl exec -it <your pod name> -n <your namespace> -- /bin/bash
bash-5.1# cat /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6=1

 

또한 로드밸런서(nlb)의 타겟그룹이 ipv6가 아닌 ipv4만 체크하도록 설정하려면 아래 설정을 배포 yaml 파일에 추가한다.

 

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080" # replace with the port used by your application
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 8080 # replace with the port used by your application
    targetPort: 8080 # replace with the port used by your application
  type: LoadBalancer

 

여기에 아래와 같이 추가로 원하는 설정을 입력할 수 있다.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/healthcheck"

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: ?

 

In this example, the health check protocol is set to TCP, which means that the target group will only check IPv4. You can also specify the health check path and timeout, if needed, using the service.beta.kubernetes.io/aws-load-balancer-healthcheck-path and service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout annotations.

 

why the connection status of ipv6 keeps changing from established to time_wait?

In general, when a TCP connection is closed, it enters a TIME_WAIT state to ensure that all packets have been received by the other end. During this state, the connection is closed, but the socket is still bound to the local and foreign IP addresses and ports.

In the case of IPv6, the addresses used are often based on temporary interface identifiers that are periodically regenerated by the system to protect the privacy of the user. When a new identifier is generated, existing TCP connections using the old identifier are closed, which can result in a large number of TIME_WAIT connections.

To address this issue, some operating systems provide a feature called "stable privacy addresses" that maintain a stable identifier for the network interface, even if the temporary identifier changes. This can help prevent TIME_WAIT connections from being created when the temporary identifier changes.

Additionally, you may want to check if there are any network or firewall issues that could be causing the TCP connections to be closed unexpectedly or prematurely, as this can also lead to TIME_WAIT connections.