Início / user-68794

growse's questions

Martin Hope
growse
Asked: 2021-06-02 11:51:34 +0800 CST
  • 0

Estou tendo problemas para obter um SingleStack LoadBalancerserviço IPv6 do kubernetes passando pelo endereço IP de origem correto para os pods. Funciona bem em um IPv4 irmão SingleStack LoadBalancerque passa o tráfego para os mesmos pods.

O cluster é um cluster dual-stack bare-metal v1.21.1 criado com kubeadme usa Calico v3.18 como cni e MetalLB para alocar IPs de balanceador de carga para serviços configurados com type: LoadBalancer. O Calico é então configurado para anunciar os IPs do balanceador de carga para o roteador local pelo BGP. Tomando um exemplo de brinquedo de uma única nginximplantação com dois serviços (um para IPv4, um para IPv6), se eu enrolar o IP através do endereço IPv4, o log de acesso do nginx imprime o IP do cliente correto em 192.168.2.0/24:

192.168.2.128 - - [01/Jun/2021:19:32:37 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.64.1" "-"

Mas enrolando o endereço IPv6 do mesmo cliente em 2001:8b0:c8f:e8b0::/64, o nginx mostra um endereço IP do cliente defd5a:1111:1111::f31f

fd5a:1111:1111::f31f - - [01/Jun/2021:19:34:23 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.64.1" "-"

Este endereço é do cluster serviceSubnete fd5a:1111:1111::/112passa a ser o clusterIPendereço do serviço IPv6. Parece que algo está realmente fazendo algum proxy TCP aqui (ipvs?), mas não está claro por que está se comportando dessa maneira. Eu esperaria isso se externalTrafficPolicyfosse Cluster- na verdade, se eu alterar os serviços de Localpara Cluster, recebo o endereço IP local do nó do cluster encaminhando a solicitação no IPv4 (como esperado) e o mesmo endereço do clusterIP no IPv6. externalTrafficPolicyparece não ter efeito no caso IPv6.

Estou perdendo algo óbvio ou esses serviços devem se comportar da mesma maneira que os outros?

Manifesto do teste:

---
apiVersion: v1
kind: Service
metadata:
  name: test-service-source-ip-v4
  namespace: default
  labels:
    k8s-app: test-service-source-ip
spec:
  selector:
    k8s-app: test-service-source-ip
  type: LoadBalancer
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  loadBalancerIP: 192.168.254.11
  externalTrafficPolicy: "Local"
  ports:
    - name: http-tcp
      protocol: TCP
      port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: test-service-source-ip-v6
  namespace: default
  labels:
    k8s-app: test-service-source-ip
spec:
  selector:
    k8s-app: test-service-source-ip
  type: LoadBalancer
  ipFamilies:
    - IPv6
  ipFamilyPolicy: SingleStack
  loadBalancerIP: 2001:8b0:c8f:e8b1:beef:f00d::11
  externalTrafficPolicy: "Local"
  ports:
    - name: http-tcp
      protocol: TCP
      port: 80

---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: test-service-source-ip
  labels:
    k8s-app: test-service-source-ip
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: test-service-source-ip
  template:
    metadata:
      labels:
        k8s-app: test-service-source-ip
    spec:
      containers:
        - name: test-service-source-ip
          image: nginx:1
          ports:
            - containerPort: 80
              protocol: TCP
networking ipv6 kubernetes ipvs calico
Martin Hope
growse
Asked: 2020-01-31 03:19:51 +0800 CST
  • 0

Eu tenho um sistema Debian 10 que usa chronydpara manter seu relógio sincronizado. A configuração é bem simples:

pool 2.debian.pool.ntp.org offline iburst

bindaddress ::1
bindaddress 127.0.0.1
bindcmdaddress 127.0.0.1

allow 127
deny

keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
log tracking measurements statistics

maxupdateskew 100.0

directive.
hwclockfile /etc/adjtime

rtcsync
makestep 1 3

É felizmente sincronizado:

# chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.panq.nl                  2   6     0   83h  -1247us[-1191us] +/-   26ms
^* time.cloudflare.com           3   6     0   83h  +1343ns[  +58us] +/- 2669us
^- metronoom.dmz.cs.uu.nl        2   6     0   83h    -63us[  -63us] +/-   25ms
^- .                             3   6     0   83h  +2171us[+2171us] +/-   64ms

No entanto, a "dispersão de raízes" continua aumentando de forma constante. De O que é dispersão de NTP e como posso controlá-la? parece que esta é uma medida do erro máximo no relógio do servidor upstream. Está subindo muito lentamente, o processo está em andamento há cerca de 70 horas e está em 22,5s. Eu sei por experiência que isso continuará aumentando até chronydreiniciar.

# chronyc tracking
Reference ID    : E1FE1EBE (time.cloudflare.com)
Stratum         : 4
Ref time (UTC)  : Sun Jan 26 23:19:16 2020
System time     : 0.000000005 seconds fast of NTP time
Last offset     : +0.000056495 seconds
RMS offset      : 0.000056495 seconds
Frequency       : 79.909 ppm slow
Residual freq   : +17.510 ppm
Skew            : 56.420 ppm
Root delay      : 0.004632703 seconds
Root dispersion : 22.573289871 seconds
Update interval : 1.6 seconds
Leap status     : Normal

Isso me parece incomum. Eu tenho uma carga de outros sistemas que sincronizam o tempo com um servidor Stratum 1 onde a dispersão da raiz é baixa e constante. Eu não acho que estou fazendo nada estranho na configuração, e a ideia de que o "erro máximo no relógio upstream" aumenta constantemente cheira um pouco fora.

Isso é normal?

chrony