É possível excluir um instantâneo de uma imagem QCOW2 sem desligar uma máquina virtual (QEMU+KVM)? A execução não qemu-img snapshot -d ...quebraria a consistência dos dados? Em caso afirmativo, isso quebraria a consistência se alguém fosse executado virsh pause ...antes de excluir um instantâneo e depois executado virsh resume ...? O que você acha?
Obrigado!
Preciso criar uma conexão VPN entre uma rede e um cluster Kubernetes, para que os aplicativos hospedados nessa rede possam se dirigir aos serviços K8S por meio de um túnel seguro.
Então, eu tenho um monte de nós K8S em um ambiente auto-hospedado. Eu adicionei um servidor separado a este ambiente, este servidor funciona como um gateway VPN, está conectado à mesma VLAN à qual os nós do cluster estão conectados. Os nós têm os seguintes endereços IP: 10.13.17.1/22, 10.13.17.2/22e 10.13.17.3/22assim por diante. O gateway VPN tem 10.13.16.253/22.
O CIDR de IP do cluster é 10.233.0.0/18, o CIDR de IP do pod é 10.233.64.0/18.
O servidor VPN oferece suporte a uma conexão IPSec site a site com uma rede remota, 10.103.103.0/24. Eu uso o Calico como gerenciador de rede, então configurei meu servidor VPN para manter sessões BGP com todos os nós K8S. A tabela de rotas do servidor VPN está cheia de prefixos anunciados pelos nós Calico ( 10.233.0.0/18também está presente, é claro), os nós do cluster 10.103.103.0/24e algumas outras redes em suas tabelas de rotas, então o BGP parece estar funcionando bem. Até agora tudo bem...
Quando estabeleço uma conexão com um serviço dentro do cluster do servidor VPN, tudo fica bem também. O cliente ( 10.13.16.253) envia um pacote SYN para o serviço ( 10.233.10.101:1337), o trabalhador recebe este pacote, altera seu endereço IP de destino para o endereço IP do pod ( 10.233.103.49:1337) e altera seu endereço IP de origem para algum endereço IP ( 10.233.110.0) que ajudará o trabalhador a receber a resposta e devolvê-la ao iniciador da conexão. Aqui está o que acontece no trabalhador que recebe este pacote SYN. O pacote SYN chega a um trabalhador:
22:04:25.866546 IP 10.13.16.253.56297 > 10.233.10.101.1337: Flags [S], seq 3575679444, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1385938010 ecr 0], length 0
O SYN-packed está sendo SNATed e DNATed e, em seguida, está sendo enviado para o trabalhador onde o pod está sendo executado:
22:04:25.866656 IP 10.233.110.0.54430 > 10.233.103.49.1337: Flags [S], seq 3575679444, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1385938010 ecr 0], length 0
A resposta veio:
22:04:25.867313 IP 10.233.103.49.1337 > 10.233.110.0.54430: Flags [S.], seq 2017844946, ack 3575679445, win 28960, options [mss 1460,sackOK,TS val 1201488363 ecr 1385938010,nop,wscale 7], length 0
A resposta está sendo deSNATed e deDNATed para ser enviada ao iniciador de conexão:
22:04:25.867533 IP 10.233.10.101.1337 > 10.13.16.253.56297: Flags [S.], seq 2017844946, ack 3575679445, win 28960, options [mss 1460,sackOK,TS val 1201488363 ecr 1385938010,nop,wscale 7], length 0
Assim, a conexão é estabelecida e todos ficam felizes.
Mas quando eu tento conectar ao mesmo serviço da rede externa ( 10.103.103.0/24) o trabalhador que recebe o pacote SYN NÃO altera o endereço IP de origem, ele altera apenas o endereço IP de destino, então o endereço IP de origem do pacote é inalterado. O pacote SYN chega a um trabalhador
21:56:05.794171 IP 10.103.103.1.52132 > 10.233.10.101.1337: Flags [S], seq 3759345254, win 29200, options [mss 1460,sackOK,TS val 195801472 ecr 0,nop,wscale 7], length 0
O pacote SYN está sendo DNAT e reenviado para o trabalhador onde o pod está sendo executado
21:56:05.794242 IP 10.103.103.1.52132 > 10.233.103.49.1337: Flags [S], seq 3759345254, win 29200, options [mss 1460,sackOK,TS val 195801472 ecr 0,nop,wscale 7], length 0
E nada vem em resposta. :-(
Então, vejo que o endereço IP de destino foi alterado, então posso ver esses pacotes no trabalhador em que o pod está sendo executado, mas não há respostas para eles:
21:56:05.794602 IP 10.103.103.1.52132 > 10.233.103.49.1337: Flags [S], seq 3759345254, win 29200, options [mss 1460,sackOK,TS val 195801472 ecr 0,nop,wscale 7], length 0
A rede externa ( 10.103.103.0/24) está sendo anunciada pelo servidor VPN via BGP, então todos os trabalhadores sabem que esta rede é acessível via 10.13.16.253. Quando executo o teste de ping de um host na rede externa ( 10.103.103.1) para o endereço IP do serviço ( 10.233.10.101), o teste passa, a VPN funciona bem e as tabelas de roteamento parecem estar corretas.
Então, por que a rede "confia" 10.13.16.253e não confia em 10.103.103.1? E por que o trabalhador executa SNAT e DNAT para os pacotes de 10.13.16.253e não executa SNAT para os pacotes de 10.103.103.1? Devo adicionar algumas políticas para permitir esse tráfego?
Desde já agradeço qualquer pista!
Gostaria de configurar o dimensionamento automático horizontal para uma implantação com base nas métricas do controlador de ingresso implantado em outro namespace.
Eu tenho uma implantação ( petclinic) implantada em um determinado namespace ( petclinic).
Eu tenho um controlador de ingresso ( nginx-ingress) implantado em outro namespace ( nginx-ingress).
O controlador de ingresso foi implantado com Helm e Tiller, então tenho a seguinte ServiceMonitorentidade:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"monitoring.coreos.com/v1","kind":"ServiceMonitor","metadata":{"annotations":{},"creationTimestamp":"2019-08-19T10:48:00Z","generation":5,"labels":{"app":"nginx-ingress","chart":"nginx-ingress-1.12.1","component":"controller","heritage":"Tiller","release":"nginx-ingress"},"name":"nginx-ingress-controller","namespace":"nginx-ingress","resourceVersion":"7391237","selfLink":"/apis/monitoring.coreos.com/v1/namespaces/nginx-ingress/servicemonitors/nginx-ingress-controller","uid":"0217c466-5b78-4e38-885a-9ee65deb2dcd"},"spec":{"endpoints":[{"interval":"30s","port":"metrics"}],"namespaceSelector":{"matchNames":["nginx-ingress"]},"selector":{"matchLabels":{"app":"nginx-ingress","component":"controller","release":"nginx-ingress"}}}}
creationTimestamp: "2019-08-21T13:12:00Z"
generation: 1
labels:
app: nginx-ingress
chart: nginx-ingress-1.12.1
component: controller
heritage: Tiller
release: nginx-ingress
name: nginx-ingress-controller
namespace: nginx-ingress
resourceVersion: "7663160"
selfLink: /apis/monitoring.coreos.com/v1/namespaces/nginx-ingress/servicemonitors/nginx-ingress-controller
uid: 33421be7-108b-4b81-9673-05db140364ce
spec:
endpoints:
- interval: 30s
port: metrics
namespaceSelector:
matchNames:
- nginx-ingress
selector:
matchLabels:
app: nginx-ingress
component: controller
release: nginx-ingress
Eu também tenho a instância do Prometheus Operaton, ele encontrou essa entidade e atualizou a configuração do Prometheus com esta estrofe:
- job_name: nginx-ingress/nginx-ingress-controller/0
honor_labels: false
kubernetes_sd_configs:
- role: endpoints
namespaces:
names:
- nginx-ingress
scrape_interval: 30s
relabel_configs:
- action: keep
source_labels:
- __meta_kubernetes_service_label_app
regex: nginx-ingress
- action: keep
source_labels:
- __meta_kubernetes_service_label_component
regex: controller
- action: keep
source_labels:
- __meta_kubernetes_service_label_release
regex: nginx-ingress
- action: keep
source_labels:
- __meta_kubernetes_endpoint_port_name
regex: metrics
- source_labels:
- __meta_kubernetes_endpoint_address_target_kind
- __meta_kubernetes_endpoint_address_target_name
separator: ;
regex: Node;(.*)
replacement: ${1}
target_label: node
- source_labels:
- __meta_kubernetes_endpoint_address_target_kind
- __meta_kubernetes_endpoint_address_target_name
separator: ;
regex: Pod;(.*)
replacement: ${1}
target_label: pod
- source_labels:
- __meta_kubernetes_namespace
target_label: namespace
- source_labels:
- __meta_kubernetes_service_name
target_label: service
- source_labels:
- __meta_kubernetes_pod_name
target_label: pod
- source_labels:
- __meta_kubernetes_service_name
target_label: job
replacement: ${1}
- target_label: endpoint
replacement: metrics
Também tenho uma instância do Prometheus-Adapter, então tenho a custom.metrics.k8s.ioAPI na lista de APIs disponíveis.
As métricas estão sendo coletadas e expostas, então o seguinte comando:
$ kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/nginx-ingress/ingresses/petclinic/nginx_ingress_controller_requests" | jq .
dá o seguinte resultado:
{
"kind": "MetricValueList",
"apiVersion": "custom.metrics.k8s.io/v1beta1",
"metadata": {
"selfLink": "/apis/custom.metrics.k8s.io/v1beta1/namespaces/nginx-ingress/ingresses/petclinic/nginx_ingress_controller_requests"
},
"items": [
{
"describedObject": {
"kind": "Ingress",
"namespace": "nginx-ingress",
"name": "petclinic",
"apiVersion": "extensions/v1beta1"
},
"metricName": "nginx_ingress_controller_requests",
"timestamp": "2019-08-20T12:56:50Z",
"value": "11"
}
]
}
Até aí tudo bem, certo?
E o que eu preciso é configurar a entidade HPA para minha implantação. Fazendo algo assim:
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: petclinic
namespace: petclinic
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: petclinic
minReplicas: 1
maxReplicas: 10
metrics:
- type: Object
object:
metricName: nginx_ingress_controller_requests
target:
apiVersion: extensions/v1beta1
kind: Ingress
name: petclinic
targetValue: 10k
Claro, isso está incorreto, pois nginx_ingress_controller_requestsestá relacionado ao nginx-ingressnamespace, então não funciona (bem, como era esperado):
annotations:
autoscaling.alpha.kubernetes.io/conditions: '[{"type":"AbleToScale","status":"True","lastTransitionTime":"2019-08-19T18:43:42Z","reason":"SucceededGetScale","message":"the
HPA controller was able to get the target''s current scale"},{"type":"ScalingActive","status":"False","lastTransitionTime":"2019-08-19T18:55:26Z","reason":"FailedGetObjectMetric","message":"the
HPA was unable to compute the replica count: unable to get metric nginx_ingress_controller_requests:
Ingress on petclinic petclinic/unable to fetch metrics
from custom metrics API: the server could not find the metric nginx_ingress_controller_requests
for ingresses.extensions petclinic"},{"type":"ScalingLimited","status":"False","lastTransitionTime":"2019-08-19T18:43:42Z","reason":"DesiredWithinRange","message":"the
desired count is within the acceptable range"}]'
autoscaling.alpha.kubernetes.io/current-metrics: '[{"type":""},{"type":"Resource","resource":{"name":"cpu","currentAverageUtilization":1,"currentAverageValue":"10m"}}]'
autoscaling.alpha.kubernetes.io/metrics: '[{"type":"Object","object":{"target":{"kind":"Ingress","name":"petclinic","apiVersion":"extensions/v1beta1"},"metricName":"nginx_ingress_controller_requests","targetValue":"10k"}}]'
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"autoscaling/v2beta1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"petclinic","namespace":"petclinic"},"spec":{"maxReplicas":10,"metrics":[{"object":{"metricName":"nginx_ingress_controller_requests","target":{"apiVersion":"extensions/v1beta1","kind":"Ingress","name":"petclinic"},"targetValue":"10k"},"type":"Object"}],"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"petclinic"}}}
E aqui está o que vejo no arquivo de log do Prometheus-Adapter:
I0820 15:42:13.467236 1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/petclinic/ingresses.extensions/petclinic/nginx_ingress_controller_requests: (6.124398ms) 404 [[kube-controller-manager/v1.15.1 (linux/amd64) kubernetes/4485c6f/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.103.98.0:37940]
O HPA procura essa métrica no namespace da implantação, mas preciso buscá-la no nginx-ingressnamespace, assim:
I0820 15:44:40.044797 1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/nginx-ingress/ingresses/petclinic/nginx_ingress_controller_requests: (2.210282ms) 200 [[kubectl/v1.15.2 (linux/amd64) kubernetes/f627830] 10.103.97.0:35142]
Infelizmente, a autoscaling/v2beta1API não tem a spec.metrics.object.target.namespaceentidade, então não posso "pedir" para buscar o valor de outro namespace. :-(
Alguém teria a gentileza de me ajudar a resolver esse quebra-cabeça? Existe uma maneira de configurar o dimensionamento automático com base nas métricas personalizadas que pertencem a outro namespace?
Talvez haja uma maneira de disponibilizar essa métrica no mesmo namespace ao qual essa ingress.extension pertence?
Desde já agradeço por quaisquer pistas e dicas.
É possível definir um ingresso ( ingresses.networking.k8s.io) encaminhando solicitações para um endereço IP estático concreto em uma rede privada?
Eu tenho um serviço que não está sendo executado em um cluster K8S, mas reside em uma rede privada e todos os pods K8S têm acesso a essa rede. Existem muitos serviços auxiliares nesta rede, não quero implantar esses serviços em um cluster K8S por alguns motivos. E eu gostaria de ter alguns desses serviços expostos via ingress-nginx, mas neste momento não vejo uma maneira de definir o back-end como um endereço IP estático.
Isso é possível?
Obrigado!
Eu tenho uma pergunta sobre como dividir o acesso ao mesmo gluster para diferentes namespaces K8S. Digamos que eu tenha 3 volumes diferentes ( vol-a, vol-b, vol-c) em um gluster e gostaria de permitir o acesso a cada um deles para cada um dos namespaces diferentes ( namespace-a- to vol-a, namespace-b- to vol-b, namespace-c- to vol-c).
É possível implementar tal esquema? Talvez haja uma maneira de autenticar um cliente de um Gluster com algum nome de usuário e senha? Existe uma maneira de definir essas credenciais em uma configuração de endpoint?
Desde já, obrigado!
Eu enfrentei um problema bastante estranho, que gostaria de compartilhar com você. Talvez você possa me ajudar com algumas ideias sobre o que está acontecendo.
Existem 3 máquinas virtuais em um host habilitado para KVM. Na verdade, existem cerca de 50 VMs, mas todas estão funcionando bem, embora o comportamento dessas 3 VMs seja um pouco incomum.
Aqui está um diagrama ilustrando essas 3 VMs e 2 links entre elas:
Quando tudo está OK, a sessão TCP ("GET / HTTP/1.0" - "HTTP 200 OK") entre eles fica assim:
00:58:43.885118 IP 192.168.111.2.55480 > 192.168.113.2.http: Flags [S], seq 926382744, win 14600, options [mss 1460,sackOK,TS val 277997 ecr 0,nop,wscale 7], length 0
00:58:43.885380 IP 192.168.113.2.http > 192.168.111.2.55480: Flags [S.], seq 1849545379, ack 926382745, win 14480, options [mss 1460,sackOK,TS val 3702103 ecr 277997,nop,wscale 7], length 0
00:58:43.885957 IP 192.168.111.2.55480 > 192.168.113.2.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 277998 ecr 3702103], length 0
00:58:43.886000 IP 192.168.111.2.55480 > 192.168.113.2.http: Flags [P.], seq 1:213, ack 1, win 115, options [nop,nop,TS val 277998 ecr 3702103], length 212
00:58:43.886061 IP 192.168.113.2.http > 192.168.111.2.55480: Flags [.], ack 213, win 122, options [nop,nop,TS val 3702104 ecr 277998], length 0
00:58:43.922286 IP 192.168.113.2.http > 192.168.111.2.55480: Flags [P.], seq 1:372, ack 213, win 122, options [nop,nop,TS val 3702140 ecr 277998], length 371
00:58:43.922335 IP 192.168.113.2.http > 192.168.111.2.55480: Flags [F.], seq 372, ack 213, win 122, options [nop,nop,TS val 3702140 ecr 277998], length 0
00:58:43.923150 IP 192.168.111.2.55480 > 192.168.113.2.http: Flags [.], ack 372, win 123, options [nop,nop,TS val 278035 ecr 3702140], length 0
00:58:43.923622 IP 192.168.111.2.55480 > 192.168.113.2.http: Flags [F.], seq 213, ack 373, win 123, options [nop,nop,TS val 278036 ecr 3702140], length 0
00:58:43.923671 IP 192.168.113.2.http > 192.168.111.2.55480: Flags [.], ack 214, win 122, options [nop,nop,TS val 3702142 ecr 278036], length 0
OK, está tudo bem até agora.
Em seguida, salvamos a configuração do pfSense, destruímos esta VM, criamos uma nova, instalamos o pfSense do zero e restauramos sua configuração a partir do arquivo de backup.
E aqui está o que vemos depois disso:
00:46:39.218193 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [S], seq 3622924060, win 14600, options [mss 1460,sackOK,TS val 674608862 ecr 0,nop,wscale 7], length 0
00:46:39.218316 IP 192.168.113.2.http > 192.168.111.2.51674: Flags [S.], seq 152904245, ack 3622924061, win 14480, options [mss 1460,sackOK,TS va l 2977436 ecr 674608862,nop,wscale 7], length 0
00:46:39.218570 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 674608862 ecr 2977436], length 0
00:46:40.417623 IP 192.168.113.2.http > 192.168.111.2.51674: Flags [S.], seq 152904245, ack 3622924061, win 14480, options [mss 1460,sackOK,TS val 2978636 ecr 674608862,nop,wscale 7], length 0
00:46:40.417947 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 674610062 ecr 2977436], length 0
00:46:43.158907 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674612803 ecr 2977436], length 16
00:46:43.360103 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674613004 ecr 2977436], length 16
00:46:43.761787 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674613406 ecr 2977436], length 16
00:46:44.565890 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674614210 ecr 2977436], length 16
00:46:46.174039 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674615818 ecr 2977436], length 16
00:46:49.389921 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674619034 ecr 2977436], length 16
00:46:51.753723 IP 192.168.113.2.http > 192.168.111.2.51672: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 2989972 ecr 674560137], length 0
00:46:55.821824 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674625466 ecr 2977436], length 16
00:46:57.221625 IP 192.168.113.2.http > 192.168.111.2.51672: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 2995440 ecr 674560137], length 0
00:47:08.157575 IP 192.168.113.2.http > 192.168.111.2.51672: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 3006376 ecr 674560137], length 0
00:47:08.685886 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674638330 ecr 2977436], length 16
00:47:30.029609 IP 192.168.113.2.http > 192.168.111.2.51672: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 3028248 ecr 674560137], length 0
00:47:34.413785 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674664058 ecr 2977436], length 16
00:47:40.478757 IP 192.168.113.2.http > 192.168.111.2.51674: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 3038697 ecr 674610062], length 0
00:47:34.413785 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [P.], seq 1:17, ack 1, win 115, options [nop,nop,TS val 674664058 ecr 2977436], length 16
00:47:40.478757 IP 192.168.113.2.http > 192.168.111.2.51674: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 3038697 ecr 674610062], length 0
00:47:40.479216 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [FP.], seq 17:19, ack 2, win 115, options [nop,nop,TS val 674670123 ecr 3038697], length 2
00:47:45.946604 IP 192.168.113.2.http > 192.168.111.2.51674: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 3044165 ecr 674610062], length 0
00:47:45.946979 IP 192.168.111.2.51674 > 192.168.113.2.http: Flags [.], ack 2, win 115, options [nop,nop,TS val 674675591 ecr 3044165,nop,nop,sack 1 {1:2}], length 0
Parece... sei lá, como se eles não se ouvissem. Eles podem pingar um ao outro, eles até interagem uns com os outros, mas parece que eles simplesmente ignoram alguns dos pacotes.
Ambas as VMs estão mostrando o mesmo, então o pfSense não descarta nenhum de seus pacotes. Embora pareça que algo de errado acontece com os pacotes. Como se tivessem sido mutilados por alguma coisa.
Isso é o que eu realmente não consigo entender. Se você compartilhar alguma ideia comigo, será fantástico.
Agradecemos antecipadamente a todos!