Toby 1 Kenobi's questions

Instalei o kube-prometheus-stack 15.3.1 em um cluster do GKE usando o helm (no namespace "monitoramento"). Usei o values.yamlpara abrir entradas em alguns dos componentes e adicionar informações de SMTP e detalhes do receptor no gerenciador de alertas. Na maior parte, tudo parece bem, exceto que o Prometheus está disparando vários alertas e não estou recebendo nenhum e-mail de alerta.

Um alerta de disparo é:

PrometheusNotConnectedToAlertmanagers

O monitoramento do Prometheus/prometheus-kube-prometheus-stak-prometheus-0 não está conectado a nenhum Alertmanagers

Outra é:

PrometheusOperatorSyncFailed

O alertmanager do controlador no namespace de monitoramento falha ao reconciliar 1 objetos.

Eu também tentei abrir uma entrada para o alertmanager e apontei alerts.mydomiain.compara ele, mas quando tento qualquer solicitação GET (como alerts.mydomain.com/v2/status) sempre recebo um erro de servidor 502.

O que preciso fazer para que meu alertmanager funcione?

aqui está a saída de kubectl get pods,svc,daemonset,deployment,statefulset -n monitoring:

NAME                                                            READY   STATUS    RESTARTS   AGE
pod/kube-prometheus-stack-grafana-58f7fcb497-hm72h              2/2     Running   0          30h
pod/kube-prometheus-stack-kube-state-metrics-6d588499f5-d957b   1/1     Running   0          2d3h
pod/kube-prometheus-stack-operator-54f89674c9-k8ml7             1/1     Running   0          2d3h
pod/kube-prometheus-stack-prometheus-node-exporter-22vpd        1/1     Running   0          3h57m
pod/kube-prometheus-stack-prometheus-node-exporter-2qsl9        1/1     Running   0          3h57m
pod/kube-prometheus-stack-prometheus-node-exporter-4d27n        1/1     Running   0          7h36m
pod/kube-prometheus-stack-prometheus-node-exporter-7rlnk        1/1     Running   0          4h47m
pod/kube-prometheus-stack-prometheus-node-exporter-7xlf4        1/1     Running   0          4h51m
pod/kube-prometheus-stack-prometheus-node-exporter-9mfnt        1/1     Running   0          3h57m
pod/kube-prometheus-stack-prometheus-node-exporter-9zblf        1/1     Running   0          2d3h
pod/kube-prometheus-stack-prometheus-node-exporter-bdcjj        1/1     Running   0          2d3h
pod/kube-prometheus-stack-prometheus-node-exporter-bs54w        1/1     Running   0          4h47m
pod/kube-prometheus-stack-prometheus-node-exporter-fp95h        1/1     Running   0          2d3h
pod/kube-prometheus-stack-prometheus-node-exporter-h4zhw        1/1     Running   0          2d3h
pod/kube-prometheus-stack-prometheus-node-exporter-pz8js        1/1     Running   0          3h58m
pod/kube-prometheus-stack-prometheus-node-exporter-rrrhk        1/1     Running   0          27h
pod/kube-prometheus-stack-prometheus-node-exporter-rszlt        1/1     Running   0          2d3h
pod/kube-prometheus-stack-prometheus-node-exporter-s62wq        1/1     Running   0          4h47m
pod/kube-prometheus-stack-prometheus-node-exporter-w9dmb        1/1     Running   0          5h32m
pod/kube-prometheus-stack-prometheus-node-exporter-xqmxk        1/1     Running   0          4h51m
pod/prometheus-kube-prometheus-stack-prometheus-0               2/2     Running   1          30h

NAME                                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/kube-prometheus-stack-alertmanager               NodePort    10.125.4.161    <none>        9093:30903/TCP   2d3h
service/kube-prometheus-stack-grafana                    NodePort    10.125.7.177    <none>        80:32444/TCP     2d3h
service/kube-prometheus-stack-kube-state-metrics         ClusterIP   10.125.2.56     <none>        8080/TCP         2d3h
service/kube-prometheus-stack-operator                   ClusterIP   10.125.4.171    <none>        443/TCP          2d3h
service/kube-prometheus-stack-prometheus                 NodePort    10.125.13.11    <none>        9090:30090/TCP   2d3h
service/kube-prometheus-stack-prometheus-node-exporter   ClusterIP   10.125.10.231   <none>        9100/TCP         2d3h
service/prometheus-operated                              ClusterIP   None            <none>        9090/TCP         2d3h

NAME                                                            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/kube-prometheus-stack-prometheus-node-exporter   17        17        17      17           17          <none>          2d3h

NAME                                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/kube-prometheus-stack-grafana              1/1     1            1           2d3h
deployment.apps/kube-prometheus-stack-kube-state-metrics   1/1     1            1           2d3h
deployment.apps/kube-prometheus-stack-operator             1/1     1            1           2d3h

NAME                                                           READY   AGE
statefulset.apps/prometheus-kube-prometheus-stack-prometheus   1/1     42h

Tenho um banco de dados PostgreSQL em execução no Google Cloud SQL que preciso dimensionar horizontalmente. O Cloud SQL facilita a adição de réplicas somente leitura, mas não ajuda no balanceamento de carga do tráfego para as réplicas.

Estou procurando algo que me ajude com o balanceamento de carga entre as réplicas. Meu aplicativo está sendo executado no Kubernetes (no GKE no mesmo projeto de nuvem que o banco de dados), portanto, se a solução puder ser implantada no Kubernetes, seria ótimo.

Há muitos bons tutoriais para fazer isso usando o ProxySQL, mas todos eles assumem que você está usando o MySQL, e o arquivo de configuração do ProxySQL parece ter campos específicos do MySQL, mas não encontrei nada que diga explicitamente "você não pode usar o ProxySQL com o PostgreSQL " ou "ProxySQL funciona com PostgreSQL, e veja como fazer isso..."

Então, minha pergunta é: posso usar o ProxySQL com o PostgreSQL? Se sim, como seria o arquivo de configuração? Se não, qual equivalente posso usar?

Estou usando o Google Kubenetes Engine e coloco um certificado SSL no meu Ingress usando certificados gerenciados pelo Google. Descobri que posso visualizar o certificado usando este comando:

gcloud beta compute ssl-certificates describe certificate-name

No entanto, isso não mostra a chave privada do certificado. Existe alguma maneira de eu obter a chave privada?

Ao usar gRPC sobre TCP simples, o cliente estabelece um canal com o servidor assim (em ruby):

stub = Helloworld::Greeter::Stub.new(service_url, :this_channel_is_insecure)

mas então, quando eu implemento o TLS no servidor e coloco meu certificado LetsEncrypt no servidor, o cliente deve estabelecer uma conexão segura como esta (em ruby):

creds = GRPC::Core::Credentials.new(load_certs)  # load_certs typically loads a CA roots file
stub = Helloworld::Greeter::Stub.new(service_url, creds)

Esse código com o comentário é retirado dos documentos oficiais do gRPC.

Minha pergunta é, por que o cliente precisa de um certificado aqui? Eu pensei que era o servidor que precisava de um certificado e o cliente garante que é válido. Quando meu navegador se conecta a sites seguros, ele traz seu próprio certificado para a mesa? Se não, por que o cliente gRPC precisa de um?

Pela minha leitura, o cliente conhece algumas autoridades confiáveis, a uma das quais a cadeia de certificados do servidor está vinculada. E o comentário no código acima se refere a um "arquivo raiz CA" que pode ser o certificado da autoridade no topo da cadeia. Então, talvez o cliente gRPC compare o certificado na raiz da cadeia do servidor com o seu próprio - mas se for esse o caso, o que acontece se obtiver a CA errada?

Todos os documentos e postagens explicando como estabelecer uma conexão segura de um cliente gRPC dizem para ler o certificado de um arquivo local, mas nenhum deles diz o que é esse certificado ou de onde vem.

o que estou perdendo?

EDITAR:

Eu descobri no meu computador um diretório com um monte do que parece ser certificados raiz de CA. /etc/ssl/certs/Um deles parece ser a autoridade que verifica o LetsEncrypt, que eu uso no servidor, então tentei ler esse certificado no cliente assim:

GRPC::Core::ChannelCredentials.new(File.read('/etc/ssl/certs/ISRG_Root_X1.pem'))

mas só resultou neste erro

Falha no handshake com erro fatal SSL_ERROR_SSL: erro:1000007d:rotinas SSL:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.