Ir para o conteúdo
ou

Software livre Brasil

Minha rede

 Voltar a planetas
Tela cheia Sugerir um artigo
 Feed RSS

Planeta do Gnome Brasil

11 de Fevereiro de 2010, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

Jonh Wendell: Istio: O que acontece quando o painel de controle está inativo?

15 de Novembro de 2018, 10:50, por Planeta GNOME Brasil - 0sem comentários ainda

Olá, pessoal!

Eu fiz alguns experimentos no Istio derrubando alguns componentes do painel de controle e observando o que acontece com os aplicativos e a mesh de serviço. Abaixo você encontrará minhas anotações.

Pilot

O Pilot é responsável pelo recurso de gerenciamento de tráfego do Istio e também é responsável por atualizar todos os sidecars com a configuração de mesh mais recente.

Quando o Pilot inicia, ele escuta na porta 15010 (gRPC) e 8080 (HTTP legado).

Quando o sidecar do aplicativo (Envoy, Istio-Proxy) é iniciado, ele se conecta ao pilot.istio-system:15010, obtém a configuração inicial e mantém-se conectado.
Sempre que o pilot detecta uma alteração na mesh (ele monitora os recursos do kubernetes), ele envia uma nova configuração para o sidecars por meio dessa conexão gRPC.

– Se o pilot cair, essa conexão do gRPC entre o piloto e o sidecar será perdida e os sidecars tentarão se reconectar ao pilot indefinidamente.
– O tráfego não é afetado se o pilot estiver fora do ar, porque toda a configuração enviada para o sidecar reside na memória do sidecar.
– Mudanças na mesh (como novos pods, regras, serviços, etc) não chegam aos sidecars, porque o pilot não está lá para ouvir mudanças e encaminhá-las para o sidecars.
– Uma vez que o pilot está ativo novamente, os sidecars se conectam (porque estão sempre tentando se reconectar) a ele e pegam a configuração de mash mais recente.

Mixer Policy

Policy aplica a política de rede.

Mixer lê a configuração na inicialização e também monitora kubernetes para alterações. Uma vez que novas configurações são detectadas, o mixer as carrega em sua memória.

Os sidecars verificam (chamam) o pod mixer policy para cada solicitação direcionada a aplicação (serviço).

Se o pod mixer policy estiver inativo, todas as solicitações para o serviço falharão com um erro “503 UNAVAILABLE: no healthy upstream” – porque o sidecar não pôde se conectar ao pod policy.

No Istio 1.1, há uma nova configuração (policyCheckFailOpen) [global] que permite uma política “Fail Open”, isto é, se o pod mixer policy não estiver alcançável, todas as requisições terão sucesso em vez de falhar com um erro 503. Por padrão, essa configuração está definida com false, isto é, “Fail Close”.

Enquanto o mixer estiver inativo, tudo o que fazemos na mesh (como adicionar regras, alterar qualquer configuração, etc) não terá efeito nos aplicativos até que o mixer esteja ativo novamente.

Mixer Telemetry

Telemetry fornece informações de telemetria para os addons.

Os Sidecars chamam o pod Telemetry após cada solicitação ser concluída, fornecendo informações de telemetria aos adaptadores (Prometheus, etc). Ele faz isso em lotes de 100 solicitações ou 1 segundo (na configuração padrão), o que vier primeiro, para evitar chamadas excessivas ao pod Telemetry.

Se o pod Telemetry estiver desativado, os sidecars registram um erro (no stderr do pod) e descartam as informações de telemetria. As solicitações não são afetadas por isso, como acontece quando o pod Policy está inativo. Uma vez que o pod Telemetry está ativo novamente, ele começa a receber informações de telemetria dos sidecars.

Outras notas

Vale a pena observar que o Istio permite uma instalação personalizada de seus componentes de plano de controle. Por exemplo, se você não precisa de Policy, pode desabilitar totalmente o mixer policy. Essa modularidade está melhorando no Istio 1.1. Para mais informações, confira a documentação.

Além disso, o pilot, mixer policy e a mixer telemetry funcionam bem em uma configuração de alta disponibilidade (HA), com várias réplicas sendo executadas ao mesmo tempo. Na verdade, a configuração padrão vem com um HorizontalPodAutoscaler que varia de 1 a 5 para esses pods. (Curioso? Veja isso e isso).



Isaac Ferreira Filho: Um Novo Atalho no Evince. O que há por trás disso?

18 de Outubro de 2018, 13:28, por Planeta GNOME Brasil - 0sem comentários ainda

Não sei se você está sabendo, mas a versão nova do Evince (3.30) está com um atalho bastante útil.

Agora você pode destacar uma parte do texto selecionando-a com o mouse e pressionando as teclas:

CTRL + H

Este post poderia parar por aqui, mas eu gostaria de escrever mais um pouco acerca do que está por trás de um simples atalho.

O Evince e Eu

O Evince é um visualizador de documentos do GNOME. De acordo com a Wikipedia ele foi incluído no GNOME em sua versão 2.12.

No meu dia a dia, de grande consumo de informações através de arquivos PDF, um bom leitor é fundamental. O Evince sempre supriu bem este papel, porém havia um ponto que me incomodava: a falta de um atalho para destacar as partes relevantes do texto.

Para fazer isso eu tinha que utilizar o mouse, movimentando o cursor do texto até o botão de destaque, ou fazendo o contrário.

O Atalho

Em conversas informais no canal do IRC do GNOME Brasil1, comentei que sentia falta deste recurso. Na época usava o Evince 3.28.

Durante a conversa, o amigo Felipe Borges feborges pediu um tempinho e, em poucos minutos, disse que tinha implementado tal recurso e que ele viria, possivelmente, na próxima versão do Evince.

Lembro que fiquei num misto de alegria e de espanto pela rapidez do processo e também pela consideração de feborges.

Bem, estou usando a versão 3.30 do Evince e estou usando bastante o recurso. Recomendo 😉

Queria concluir este post agradecendo ao Felipe pelo recurso, mas também deixando uma reflexão sobre como o software livre e open source é produzido e melhorado.

Acompanho, em muitos espaços, usuários reclamando da falta do recurso X ou do bug Y, porém pouca gente abre alguma issue para relatar algum bug ou propor alguma melhoria.

Diversas vezes esse modelo de desenvolvimento de software é enquadrado em uma lógica diferente e sofre análises, muito deslocadas a meu ver, como se fosse um modelo proprietário. Mas isso é um papo para um outro post.


  1. irc.gnome.org #gnome-br 


Isaac Ferreira Filho: Fedora 29 Beta

11 de Outubro de 2018, 19:07, por Planeta GNOME Brasil - 0sem comentários ainda

Estou completando duas semanas de uso do Fedora 29 Beta. Até o momento só tive um crash. Por aqui já estamos no GNOME 3.30.1.

No geral a experiência está sendo bastante agradável e estável. Abaixo eu descrevo como fiz para transformar a versão 28 em 29.

Se quiser atualizar o seu sistema, faça por sua conta e risco ok? Lembre-se: faça backup! Desative o rpm-fusion (eu não fiz, mas é aconselhado fazer).

Atualizar o Sistema Atual

sudo dnf upgrade --refresh

Instalar o Plugin para Atualização

sudo dnf install dnf-plugin-system-upgrade

Baixar os Pacotes

sudo dnf system-upgrade download --refresh --releasever=29

Finalizar

sudo dnf system-upgrade reboot

Se tudo der certo…

dnf clean packages

O que você está achando do Fedora 29 ou do GNOME 3.30. Conta aí!



Jonh Wendell: Istio, injeção de sidecar: ativando injeção automática, adicionando exceções e depuração

24 de Setembro de 2018, 21:25, por Planeta GNOME Brasil - 0sem comentários ainda

Ei pessoal. Hoje vamos falar sobre um pouco sobre injeção de sidecar do Istio em Kubernetes.

O Istio no Kubernetes funciona usando um modelo de deployment de sidecar, onde um contêiner auxiliar (sidecar) é anexado ao seu contêiner principal (serviço) em um único Pod. Ao fazer isso, seu serviço e o contêiner de sidecar compartilham a mesma rede e podem ser vistos como dois processos em um único host. Assim, o Istio pode interceptar todas as chamadas de rede de e para o seu contêiner principal e fazer sua mágica para melhorar a comunicação de serviço a serviço.

Esse contêiner de sidecar, denominado istio-proxy, pode ser injetado em seu pod de serviço de duas maneiras: manual e automaticamente. Mesmo essa técnica manual não é 100% feita à mão. Vamos ver.

Injeção manual

O Istio vem com uma ferramenta chamada istioctl. Sim, parece que é inspirado em alguma outra ferramenta amada :). Uma de suas funcionalidades é a capacidade de injetar o sidecar istio-proxy em seu pod de serviço. Vamos usá-la, usando um simples pod de busybox como exemplo:

$ cat busybox.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: busybox-test
spec:
  containers:
  - name: busybox-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep infinity']

$ istioctl kube-inject -f busybox.yaml > busybox-injected.yaml

[jwendell@jw-laptop ~]$ cat busybox-injected.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
  name: busybox-test
spec:
  containers:
  - command:
    - sh
    - -c
    - echo Hello Kubernetes! && sleep infinity
    image: busybox
    name: busybox-container

  - image: docker.io/istio/proxyv2:1.0.2
    imagePullPolicy: IfNotPresent
    name: istio-proxy
    args:
      - proxy
      - sidecar
   ...

Como você pode ver acima, esse comando gerou outro arquivo yaml, semelhante ao input (pod busybox), mas com o sidecar (istio-proxy) adicionado ao pod. Então, de alguma forma, isso não é um trabalho manual de 100%, certo? Isso nos poupa um monte de digitação. Você está pronto para aplicar este yaml modificado ao seu cluster do kubernetes:

$ kubectl apply -f busybox-injected.yaml
# ou, se você não quiser ter um arquivo intermediário, aplique diretamente usando o arquivo original:
$ kubectl apply -f <(istioctl kube-inject -f busybox.yaml)

Uma pergunta natural que pode surgir é: de onde vêm esses dados? Como ele sabe que a imagem do sidecar é docker.io/istio/proxyv2:1.0.2? A resposta é simples: Todos os dados vêm de um ConfigMap que vive no plano de controle do Istio, no namespace istio-system:

$ kubectl -n istio-system describe configmap istio-sidecar-injector
Name:         istio-sidecar-injector
Namespace:    istio-system

Data
====
config:
----
policy: enabled
template: |-
  initContainers:
  - name: istio-init
    image: "docker.io/istio/proxy_init:1.0.2"
...

Você pode editar este ConfigMap com os valores que deseja injetar nos seus pods. Como você pode ver, esse é basicamente um modelo que será adicionado à sua definição de pod. Se você quiser usar outra imagem para o contêiner istio-proxy, use outra tag ou deseje ajustar qualquer coisa que será injetada, essa é a coisa que você precisa editar. Lembre-se que este ConfigMap é usado para injeção em todos os seus pods na malha de serviço. Seja cuidadoso 🙂

Porque istioctl lê um ConfigMap para saber o que injetar, isso significa que você precisa ter acesso a um cluster do Kubernetes em funcionamento com o Istio devidamente instalado. Se por algum motivo você não tiver tal acesso, você ainda pode usar istioctl, fornecendo um arquivo de configuração local:

# execute isso antes, com acesso apropriado ao cluster k8s
$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
# sinta-se à vontade para modificar esse arquivo, e você pode executar a qualquer momento depois:
$ istioctl kube-inject --injectConfigFile inject-config.yaml ...

Injeção automática

A outra maneira de ter istio-proxy injetado em seus pods é dizendo ao Istio para fazer isso automaticamente por você. Na verdade, isso é ativado por padrão para todos os namespaces com o rótulo istio-injection=enabled. Isso significa que, se um namespace tiver esse rótulo, todos os pods dentro dele receberão o sidecar istio-proxy automaticamente. Você não precisa executar istioctl ou fazer qualquer coisa com seus arquivos yaml!

O modo como funciona é bem simples: ele faz uso de uma funcionalidade do Kubernetes chamado MutatingWebhook que consiste em Kubernetes notificando o Istio sempre que um novo pod está prestes a ser criado e dando ao Istio a chance de modificar a especificação do pod durante seu uso, pouco antes de realmente criar esse pod. Assim, o Istio injeta o sidecar istio-proxy usando o template encontrado no ConfigMap que vimos acima.

Soa bem, certo?

Você pode estar se perguntando: Ei, isso é muito intrusivo! Sim, tudo depende das suas necessidades. Esta injeção automática é muito flexível:

  • No istio-sidecar-injector ConfigMap, há um sinalizador booleano indicando se esta injeção automática está habilitada ou não.
  • Somente os namespaces rotulados adequadamente receberão a injeção automática. Você pode escolher seletivamente quais namespaces terão injeção automática.
  • Além disso, você pode ajustar esse rótulo, alterá-lo ou mesmo remover esse filtro (o que significa que a injeção ocorrerá automaticamente em todos os namespaces! Seja cuidadoso!) Editando o MutatingWebhookConfiguration: kubectl -n istio-system edit MutatingWebhookConfiguration istio-sidecar-injector. Procure o campo namespaceSelector.
  • Você pode evitar que a injeção aconteça em pods seletivos. Se um pod tiver a anotação sidecar.istio.io/inject: "false", então o Istio não irá injetar o sidecar nele.
  • Você pode inverter a lógica se você for mais conservador. Desative a injeção automática para todos e ative-a apenas para pods selecionados. Para isso, você só precisa definir a política como falsa (kubectl -n istio-system edit configmap istio-sidecar-injector) e anotar os pods que você deseja para injetar com sidecar.istio.io/inject: "true"

Eu quero mais flexibilidade!

Aqui está um caso de uso em que a flexibilidade acima não foi suficiente:

Para aqueles que não estão familiarizados com o Openshift (distribuição de Kubernetes da Red Hat), ele possui uma funcionalidade chamada source-to-image – s2i, que magicamente cria imagens de contêiner com base no código-fonte. Você fornece um repositório git (funciona com muitas linguagens de programação!) como entrada e obtém uma imagem de contêiner, sendo executada no Openshift como resultado.

É uma funcionilidade incrível! Não vou entrar em detalhes aqui, vou apenas dizer o que precisamos saber agora: para fazer isso, o Openshift cria um ou mais pods auxiliares, intermediários, para construir o código-fonte. Quando a compilação estiver concluída, os artefatos binários vão para a imagem do contêiner resultante, prontos para serem executados no Openshift, e esses conjuntos auxiliares são então descartados.

Se habilitarmos a injeção automática em um determinado namespace e usarmos a funcionalidade de s2i do Openshift, isso significa que todos os pods receberão o sidecar injetado. Mesmo aqueles pods compiladores (intermediários, auxiliares)! Pior, como eles não estão sob nosso controle (eles são criados pelo Openshift, não por nós), não podemos anotar para não obter o sidecar injetado. As compilações não se comportam bem com o sidecar injetado, então não queremos que eles sejam automaticamente injetados. O que fazer agora?

Bem, uma solução possível é seguir a abordagem conservadora explicada no último item acima: Desativar a injeção automática para todos e ativá-la apenas para os pods selecionados. Isso funciona, mas exige que você anote ativamente os pods que você deseja que a injeção automática aconteça.

Ou… Há uma nova solução para esse problema:

A nova solução

A partir da versão 1.1.0, a injeção automática do Istio tem uma maneira de adicionar exceções com base em rótulos, ou seja: não injetar o sidecar em pods que correspondam a esses rótulos, mesmo se a política for true e esse namespace for marcado para ter injeção automática. Você pode adicionar essas exceções no istio-sidecar-injector ConfigMap:

$ kubectl -n istio-system describe configmap istio-sidecar-injector
apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-sidecar-injector
data:
  config: |-
    policy: enabled
    neverInjectSelector:
      - matchExpressions:
        - {key: openshift.io/build.name, operator: Exists}
      - matchExpressions:
        - {key: openshift.io/deployer-pod-for.name, operator: Exists}
    template: |-
      initContainers:
...

Você pode ver acima um campo neverInjectSelector. É uma matriz de seletores de rótulos de Kubernetes. Eles são comparados com OR, parando no primeiro jogo. A instrução acima significa: Nunca injetar em pods que tenham o rótulo openshift.io/build.name ou openshift.io/deployer-pod-for.name – os valores dos rótulos não importam, estamos apenas verificando se as chaves existem. Com essa regra adicionada, nosso caso de uso de s2i do Openshift está coberto, o que significa que os pods auxiliares não terão sidecars injetados (porque os pods auxiliares de s2i contêm esses rótulos).

Para completar, você também pode usar um campo chamado alwaysInjectSelector, que sempre injetará o sidecar em pods que correspondam ao seletor de rótulo, apesar da política global.

A abordagem do seletor de rótulos oferece muita flexibilidade sobre como expressar essas exceções. Dê uma olhada em sua documentação para ver o que você pode fazer com eles!

Vale a pena observar que as anotações nos pods ainda têm a preferência. Se um pod é anotado com sidecar.istio.io/inject: "true/false", então ele será honrado. Então, a ordem de avaliação é:

Pod Annotations → NeverInjectSelector → AlwaysInjectSelector → Namespace Policy

Como este {Never,Always}InjectSelector é uma adição recente, eu ainda tenho que atualizar as documentações para mencioná-lo, mas para todas as outras coisas, para mais informações e exemplos confira a documentação oficial.

Por que meu pod [não] está sendo intejado?

Essa é uma pergunta muito comum. Você seguiu todas as instruções (como rotular o namespace com istio-injection=enabled) e seus pods não estão recebendo a injeção automática.

Ou bem pelo contrário, você anotou seu pod com sidecar.istio.io/inject: "false" e ele está sendo injetado. Por que?

Uma coisa que você pode fazer para descobrir o que está acontecendo é olhar nos logs do pod sidecar-injector:

$ pod=$(kubectl -n istio-system get pods -l istio=sidecar-injector -o jsonpath='{.items[0].metadata.name}')
$ kubectl -n istio-system logs -f $pod

Em seguida, você pode criar seus pods e monitorar aquele log por qualquer saída. Para uma saída de log mais detalhada – confie em mim, é realmente útil – devemos editar o deployment do sidecar-injector e anexar o argumento --log_output_level=default:debug ao executável de contêiner sidecar-injector:

$ kubectl -n istio-system edit deployment istio-sidecar-injector
...
      containers:
      - args:
        - --caCertFile=/etc/istio/certs/root-cert.pem
        - --tlsCertFile=/etc/istio/certs/cert-chain.pem
        - --tlsKeyFile=/etc/istio/certs/key.pem
        - --injectConfig=/etc/istio/inject/config
        - --meshConfig=/etc/istio/config/mesh
        - --healthCheckInterval=2s
        - --healthCheckFile=/health
        - --log_output_level=default:debug
        image: docker.io/istio/sidecar_injector:1.0.2
        imagePullPolicy: IfNotPresent
...

Salve e saia do seu editor. Agora o Kubernetes está fazendo deployment do pod sidecar-injector e o sinalizador depuração deve estar em vigor. Aguarde alguns segundos para o pod estar ativo, então você pode monitorar os logs novamente:

$ pod=$(kubectl -n istio-system get pods -l istio=sidecar-injector -o jsonpath='{.items[0].metadata.name}')
$ kubectl -n istio-system logs -f $pod
Dica

Se mesmo com a saída de depuração ativada você não viu nada relevante em seus logs, isso significa que o pod sidecar-injector não está sendo notificado sobre a criação do pod. Não está sendo invocado para fazer a injeção automática. Isso pode ser devido a uma configuração incorreta em relação ao rótulo do namespace. Verifique se o namespace está rotulado de acordo com o que está no MutatingWebhookConfiguration. Por padrão, o namespace deve ter o rótulo istio-injection=enabled. Verifique se isto foi alterado executando o kubectl -n istio-system edit MutatingWebhookConfiguration istio-sidecar-injector e verifique o campo namespaceSelector.

Quando terminar a sessão de depuração, você poderá editar o deployment novamente e remover esse argumento de depuração.

É isso. Espero que ajude. Sinta-se à vontade para perguntar ou comentar qualquer coisa, aqui ou no twitter! Nos vemos em breve!



Jonh Wendell: (English) Istio sidecar injection: enabling automatic injection, adding exceptions and debugging

24 de Setembro de 2018, 21:25, por Planeta GNOME Brasil - 0sem comentários ainda

Desculpe-nos, mas este texto esta apenas disponível em Inglês Americano.



Jonh Wendell: Istio, mTLS, depurando um erro 503

28 de Agosto de 2018, 23:33, por Planeta GNOME Brasil - 0sem comentários ainda

Olá pessoal. Neste post eu compartilharei com vocês um problema que tive enquanto testava o tutorial de Circuit Breaking na documentação do Istio. Vou seguir todos os passos que fiz durante a resolução deste problema, e espero que seja útil para alguém. Foi pelo menos para mim que aprendi um pouco mais sobre o Istio no processo.

As etapas da tarefa são bem simples:
1) Instalar um par de pods (um servindo httpbin + um com curl para se comunicar com o serviço httpbin)
2) Criar um objeto DestinationRule para que as chamadas para o serviço httpbin sejam limitadas (Circuit Breaking)
Bem simples, não? Então, vamos começar a diversão.

Vamos instalar os pods de httpbin e auxiliar:

$ kubectl create ns foo
$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo

$ kubectl -n foo get pod,svc
NAME                           READY     STATUS    RESTARTS   AGE
pod/httpbin-6bbb775889-wcp45   2/2       Running   0          35s
pod/sleep-5b597748b4-77kj5     2/2       Running   0          35s

NAME              TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/httpbin   ClusterIP   10.105.25.98           8000/TCP   36s
service/sleep     ClusterIP   10.111.0.72            80/TCP     35s

No pod auxiliar, vamos invocar o serviço httpbin, usando o curl:

$ kubectl -n foo exec -it -c sleep sleep-5b597748b4-77kj5 -- curl http://httpbin:8000/get
{
  "args": {}, 
  "headers": {
    "Accept": "*/*", 
    "Content-Length": "0", 
    "Host": "httpbin:8000", 
    "User-Agent": "curl/7.35.0", 
    "X-B3-Sampled": "1", 
    "X-B3-Spanid": "b5d006d3d9bf1f4d", 
    "X-B3-Traceid": "b5d006d3d9bf1f4d", 
    "X-Request-Id": "970b84b2-999b-990c-91b4-b6c8d2534e77"
  }, 
  "origin": "127.0.0.1", 
  "url": "http://httpbin:8000/get"
}

Por enquanto, tudo bem. O próximo passo na tarefa de Circuit Breaking é adicionar uma DestinationRule:

$ cat <<EOF | kubectl -n foo apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100
EOF

Agora, vamos tentar novamente o serviço httpbin:

$ kubectl -n foo exec -it -c sleep sleep-5b597748b4-77kj5 -- curl http://httpbin:8000/get
upstream connect error or disconnect/reset before headers

Ops, alguma coisa deu errado. Vamos tornar o curl mais verboso:

$ kubectl -n foo exec -it -c sleep sleep-5b597748b4-77kj5 -- curl -v http://httpbin:8000/get
* Hostname was NOT found in DNS cache
*   Trying 10.105.235.142...
* Connected to httpbin (10.105.235.142) port 8000 (#0)
> GET /get HTTP/1.1
> User-Agent: curl/7.35.0
> Host: httpbin:8000
> Accept: */*
> 
< HTTP/1.1 503 Service Unavailable
< content-length: 57
< content-type: text/plain
< date: Tue, 28 Aug 2018 12:26:54 GMT
* Server envoy is not blacklisted
< server: envoy
< 
* Connection #0 to host httpbin left intact
upstream connect error or disconnect/reset before headers

Hmmm, erro 503… Por que? De acordo com a tarefa Circuit Breaking, deveria funcionar bem. Adicionamos apenas uma regra que define o número máximo de conexões TCP como 1 e, de fato, com o comando curl acima, geramos apenas uma conexão. Então, o que há de errado?

A primeira coisa que me veio à mente foi emitir o comando para verificar se Circuit Breaking estava em vigor:

$ kubectl -n foo exec -it -c istio-proxy sleep-5b597748b4-77kj5 -- curl localhost:15000/stats | grep httpbin | grep pending
cluster.outbound|8000||httpbin.foo.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|8000||httpbin.foo.svc.cluster.local.upstream_rq_pending_failure_eject: 0
cluster.outbound|8000||httpbin.foo.svc.cluster.local.upstream_rq_pending_overflow: 0
cluster.outbound|8000||httpbin.foo.svc.cluster.local.upstream_rq_pending_total: 5

Então, o valor 0 para a variável upstream_rq_pending_overflow confirma que nenhuma chamada foi capturada pelo Circuit Breaking.

Explicação do comando acima:
O sidecar do Istio (contêiner Envoy denominado istio-proxy) expõe (localmente) a porta 15000, que é acessível via HTTP e possui alguns utilitários, como a impressão de algumas estatísticas sobre o serviço.
Então, no comando acima nós executamos o curl (curl localhost:15000/stats) dentro do contêiner sidecar (-c istio-proxy) do pod auxiliar (sleep-5b597748b4-77kj5), filtrando a saída pelo serviço que queremos investigar (| grep httpbin) e depois filtrando para o estado pendente do circuit breaker (| grep pending).

Para confirmar que o culpado é o DestinationRule, vamos excluí-lo e tentar novamente:

$ kubectl -n foo delete DestinationRule httpbin
destinationrule.networking.istio.io "httpbin" deleted
$ kubectl -n foo exec -it -c sleep sleep-5b597748b4-77kj5 -- curl -v http://httpbin:8000/get
...
< HTTP/1.1 200 OK
...

Adicionando-o novamente:

...
< HTTP/1.1 503 Service Unavailable
...

Então, parece que o DestinationRule é o vilão aqui. Mas por quê? Precisamos investigar um pouco mais. Ei! E se verificarmos os logs do Envoy (istio-proxy sidecar)? Vamos fazer isso:

$ kubectl -n foo logs -c istio-proxy sleep-5b597748b4-77kj5 -f
# Em outro terminal, emita o comando curl (kubectl -n foo exec -it -c sleep sleep-5b597748b4-77kj5 -- curl -v http://httpbin:8000/get)
# Então, vemos no log:
[2018-08-28T13:06:56.454Z] "GET /get HTTP/1.1" 503 UC 0 57 0 - "-" "curl/7.35.0" "19095d07-320a-9be0-8ba5-e0d08cf58f52" "httpbin:8000" "172.17.0.14:8000"

Isso não ajuda. O log nos diz que o Envoy está recebendo o erro 503 do servidor. Então, vamos verificar os logs para o lado do servidor (httpbin):

$ kubectl -n foo logs -c istio-proxy httpbin-94fdb8c79-h9zrq -f
# Em outro terminal, emita o comando curl (kubectl -n foo exec -it -c sleep sleep-5b597748b4-77kj5 -- curl -v http://httpbin:8000/get)
# Log está vazio...

O que? Nós não vemos nada na saída do log. É como se a requisição não estivesse chegando ao servidor. Então, o que fazer agora?… Ei! E se pudéssemos aumentar a verbosidade do log? Talvez o pedido esteja chegando, mas não está sendo produzido? Vamos ver.

Lembre-se de que eu disse acima sobre a porta 15000 do Envoy sendo exposta localmente ao pod de serviço? Nós usamos isso para pegar estatísticas. Vamos dar uma olhada para descobrir o que mais oferece:

$ kubectl -n foo exec -it -c istio-proxy httpbin-94fdb8c79-h9zrq -- curl http://localhost:15000/help
admin commands are:
  /: Admin home page
  /certs: print certs on machine
...
  /logging: query/change logging levels
...

Ei! Parece que encontramos o que estávamos procurando: /logging. Vamos usá-lo:

$ kubectl -n foo exec -it -c istio-proxy httpbin-94fdb8c79-h9zrq -- curl http://localhost:15000/logging?level=trace
active loggers:
  admin: trace
...

O comando acima definiu todos os registradores de log de Envoy para o nível trace, o melhor. Para obter mais informações sobre essa interface administrativa, verifique os documentos do Envoy. Agora, vamos tentar recuperar o log do servidor Envoy e, esperançosamente, com o nível trace, obteremos algo (na verdade, recebemos muitos logs!):

$ kubectl -n foo logs -c istio-proxy httpbin-94fdb8c79-h9zrq -f
# Em outro terminal, emita o comando curl (kubectl -n foo exec -it -c sleep sleep-5b597748b4-77kj5 -- curl -v http://httpbin:8000/get)
# Agora, vemos nos logs (Eu filtrei parte do conteúdo não relevante):
[debug][filter] external/envoy/source/extensions/filters/listener/original_dst/original_dst.cc:18] original_dst: New connection accepted
[debug][main] external/envoy/source/server/connection_handler_impl.cc:217] [C31] new connection
[trace][connection] external/envoy/source/common/network/connection_impl.cc:389] [C31] socket event: 2
[trace][connection] external/envoy/source/common/network/connection_impl.cc:457] [C31] write ready
[debug][connection] external/envoy/source/common/ssl/ssl_socket.cc:111] [C31] handshake error: 2
[trace][connection] external/envoy/source/common/network/connection_impl.cc:389] [C31] socket event: 3
[trace][connection] external/envoy/source/common/network/connection_impl.cc:457] [C31] write ready
[debug][connection] external/envoy/source/common/ssl/ssl_socket.cc:111] [C31] handshake error: 1
[debug][connection] external/envoy/source/common/ssl/ssl_socket.cc:139] [C31] SSL error: 268435612:SSL routines:OPENSSL_internal:HTTP_REQUEST
[debug][connection] external/envoy/source/common/network/connection_impl.cc:133] [C31] closing socket: 0

Uau, isso parece interessante! Podemos ver que a requisição está realmente chegando ao servidor, mas está falhando devido a um erro de handshake e o Envoy está fechando a conexão. A questão agora é: Por que um erro de handshake? Por que o SSL está envolvido?

Quando falamos de SSL no contexto do Istio, lembramos do TLS Mútuo. Então eu fui à documentação do Istio, tentando encontrar algo relevante para o meu problema. A leitura da tarefa de tutorial de segurança abriu meus olhos!

Eu descobri que eu tinha instalado o Istio com o TLS Mútuo ativado!

Vamos fazer algumas verificações:

$ kubectl get MeshPolicy default -o yaml
apiVersion: authentication.istio.io/v1alpha1
kind: MeshPolicy
metadata: ...
spec:
  peers:
  - mtls: {}

$ kubectl -n istio-system get DestinationRule default -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata: ...
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

Essas saídas acima mostram que o mTLS está instalado no cluster. Esses objetos só existem quando o mTLS está ativado.

OK, olhando novamente os meus scripts de instalação, eu percebi que eu realmente baguncei tudo e instalei o Istio com o mTLS ativado. No entanto, a questão ainda está lá: por que o serviço httpbin está falhando? Sabendo que o mTLS está ativo na malha e lendo a documentação, não é difícil deduzir que o servidor está esperando uma conexão TLS e o cliente está emitindo um texto simples. Mudamos a pergunta novamente: Por que o cliente (sleep pod) está se conectando ao servidor (pod httpbin) usando texto simples?

Novamente, olhando para a documentação, encontramos a resposta. A maneira como o mTLS trabalha no Istio é simples: existe um objeto DestinationRule (chamado “default”, como podemos ver no comando acima) que instrui todo o tráfego na malha a passar pelo TLS. No entanto, quando criamos nossa própria DestinationRule, para o propósito da tarefa Circuit Breaking, sobrescrevemos essa configuração padrão com a nossa, que não tem nenhum TLS! Isso é indicado na documentação do TLS para o Istio (tradução livre do conteúdo):

Não se esqueça de que as regras de destino também são usadas por motivos além de autenticação, como a instalação do deployment de canary, mas a mesma ordem de precedência se aplica. Portanto, se um serviço exigir uma regra de destino específica por qualquer motivo – por exemplo, para um balanceador de carga de configuração – a regra deverá conter um bloco TLS semelhante com o modo ISTIO_MUTUAL, pois, do contrário, ele substituirá as configurações de TLS de malha ou namespace e desativará o TLS.

Então, está claro agora o que devemos fazer: Modificar a DestinationRule para a tarefa Circuit Breaking de forma a incluir o bloco TLS (linhas 20-21 abaixo):

cat <<EOF | kubectl -n foo apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100
    tls:
      mode: ISTIO_MUTUAL
EOF
destinationrule.networking.istio.io/httpbin configured

Agora, vamos tentar nosso serviço httpbin:

kubectl -n foo exec -it -c sleep sleep-5b597748b4-77kj5 -- curl -v http://httpbin:8000/get
...
< HTTP/1.1 200 OK
...

\o/

Agora, eu posso continuar com meu tutorial de Circuit Breaking!

Algumas lições aprendidas:
– Confirme se você está usando mTLS ou não; Habilitá-lo abre a porta para erros obscuros 🙂
– As DestinationRules têm ordem de precedência: as mais específicas sobrescrevem as globais
– Às vezes, podemos fazer bom uso da interface administrativa do Sidecar (porta local 15000)
– Sempre leia a documentação 🙂

Nos vemos em breve!



Jonh Wendell: (English) Istio, mTLS, debugging a 503 error

28 de Agosto de 2018, 23:33, por Planeta GNOME Brasil - 0sem comentários ainda

Desculpe-nos, mas este texto esta apenas disponível em Inglês Americano.



Felipe Borges: Summing up GUADEC 2018

19 de Julho de 2018, 8:56, por Planeta GNOME Brasil - 0sem comentários aindaThat’s my seventh edition of GUADEC (and counting) and I just can’t get enough!

This year’s edition was once again a blast. The best opportunity to put faces into the names we interact daily throughout the communication channels of our community, and to meet new folk.

Once again a volunteer, this year a chaired the sessions in the auditorium during the first day, organized one of the newcomers activities, and the football game. Don’t forget to check out the conference photos.

Lots of work got done, as you must have read from other posts in Planet GNOME. It was no different for Boxes. Our annual Birds of a Feather session was more of a whole afternoon chat under the shadow in front of the university cafeteria. We managed to count with the presence of very experienced members of our community to give us some valuable insights on how we can sanely introduce new features and optimize the existing ones.

We discussed the challenges and possibilities of the OVF support, enabling us to Import and Export virtualization appliances allowing users to easily share their VMs with each other, and perform migrations and backups. That is work that has already started and will be partially shipped in 3.30, and later complemented in the next cycle.

There we often heard of feature requests for enhancements we already landed. Therefore justifying my recent work in the new machine assistant to make the “Download an OS” page, and remote connections more discoverable. Expect more work in this area, making it easier for users to find and benefit from features we already have, such as: bridged network, file sharing, clipboard integration, notifications passthrough, multiple brokers, etc…

Another relevant topic fairly discussed during our meeting was the  integration of Boxes into the Purism mobile development workflow as a simulator in which they could easily run their Flatpak bundles built with GNOME Builder.  Alberto Fanjul participated in the discussions describing their requirements and suggesting features. Expect some interesting work in this regard for our next development cycle.

A few more specific topics were discussed related to changes under the hood related to speeding up things and making some processes more fail-proof.

Boxes among other apps got stickers!

GUADEC was also an opportunity for me to meet our Google Summer of Code mentee Adi Manglik, and chat about his challenges adding Power consumption capabilities to GNOME Usage and of being a newcomer in our community.

I would like to thank the GUADEC organizers for hosting an amazing conference. The Social Events were great, from the sangria at the beach party to the guided tour to Alcazaba ending with a delightful party at the sunset with incredible flamenco dances, it is all fantastic with friends.

Last but not least, I’d like to thank my employer Red Hat for sponsoring my trip! I hope to see you all again very soon!



Georges Stavracas: My Perspective on This Year’s GUADEC

13 de Julho de 2018, 15:24, por Planeta GNOME Brasil - 0sem comentários ainda

Greetings GNOMEies

This year, I had the pleasure to attend GUADEC at Almeria, Spain. Lots of things happened, and I believe some of them are important to be shared with the greater community.

GUADEC

This year’s GUADEC happened in Almería, Spain. It turns out Almería is a lovely city! Small and safe, locals were friendly and I managed to find pretty good vegan food with my broken Spanish.

I was particularly happy whenever locals noticed my struggle with the language, and helped and taught me some handy words. This alone was worth the entire trip!

Getting there was slightly complicated: there were no direct flights, nor single-connection routes, to there. I ended up having to get a 4 connection route to there, and it was somewhat exhausting. Apparently other people also had troublesome journeys there.

The main accommodation and the main venue could have been closer, but commuting to there was not a problem whatsoever because the GUADEC team schedule a morning bus to there. A well handled situation, I must say — turns out, commuting with other GNOME folks sparked interesting discussions and we had some interesting ideas there. The downside is that, if anyone wanted the GNOME Project to die, we were basically in a single bus 😛

Talks

There were quite a few interesting talks this year. My personal highlights:

BoFs

To me, the BoFs were the best part of this year’s GUADEC. The number of things that happened, the hard talks we’ve made, they all were extremely valuable. I think I made a good selection of BoFs to attend, because the ones I attended were interesting and valuable. Decisions were made, discussions were held, and overall it was productive.

I was particularly involved in five major areas: GNOME Shell & Mutter, GJS, GTK, GNOME Settings, and GNOME To Do.

GNOME Shell & Mutter

A big cleanup was merged during GUADEC. This probably will mean small adaptations in extensions, but I don’t particularly think it’s groundbreaking.

At the second BoF day, me and Jonas Ådahl dived into the Remote Desktop on Wayland work to figure out a few bugs we were having. Fortunately, Pipewire devs were present and we figured out some deadlocks into the code. Jonas also gave a small lecture on how the KMS-based renderer of Wayland’s code path works (thanks!), and I feel I’m more educated in that somewhat complex part of the code.

As of today, Carlos Garnacho’s paint volume rework was merged too, after extensive months of testing. It was a high-impact work, and certainly reduces Mutter’s CPU usage on certain situations.

At the very last day, we talked about various ideas for further performance improvements and cleanups on Mutter and GNOME Shell.  I myself am on the last steps of working on one of these ideas, and will write about it later.

As I sidenote, I would like to add that I can only work on that because Endless is sponsoring me to do that. Because

banner-down

Exciting times for GNOME Shell ahead!

GJS

The git master GJS received a bunch of memory optimizations. In my very informal testing, I could measure a systematic 25~33% reduce in the memory usage of every GJS-based application (Maps, Polari and GNOME Shell). However, I can’t guarantee the precisions of these results. They’re just casual observations.

Unfortunately, this rework was making GNOME Shell crash immediately on startup. Philip Chimento tricked me into fixing that issue, and so this happened! I’m very happy with the result, and looks like it’ll be an exciting release for GJS too!

Thanks Philip for helping me deep dive into the code.

GTK

Matthias already wrote an excellent write-up about the GTK BoF, and I won’t duplicate it. Check his blog post if you want to learn more about what was discussed, and what was decided.

GNOME Settings

At last, a dedicate Settings BoF happened at the last day of the conference. It had a surprisingly higher number of attendees than what I was expecting! A few points on our agenda that were addressed:

  • Maintainership: GNOME Settings has a shared maintainership model with different levels of power. We’ll add all the maintainers to the DOAP file so that anyone knows who to ping when opening a merge request against GNOME Settings.
  • GitLab: we want to finish the move to GitLab, so we’ll do like other big modules and triage Bugzilla bugs before moving them to GitLab. With that, the GitLab migration will be over.
  • Offloading Services to Systemd: Iain Lane has been working on starting sessions with systemd, and that means that we’ll be able to drop a bunch of code from GNOME Settings Daemon.
  • Future Plans: we’ve spent a good portion of this cycle cleaning up code. Before the final stable release, we’ll need to do some extensive testing on GNOME Settings. A bit of help from tech enthusiasts would be fantastic!

We should all thank Robert Ancell for proposing and organizing this BoF. It was important to get together and make some decisions for once! Also, thanks Bastien for being present and elucidating our problems with historical context – it certainly wouldn’t be the same without you!

GNOME To Do

Besides these main tracks, me and Tobias could finally sit down and review GNOME To Do’s new layout. Delegating work to who knows best is a good technique:

Tobias' GNOME To Do mockups in my engineering notebook.Tobias’ GNOME To Do mockups in my engineering notebook.

I was also excited to see GNOME To Do stickers there:

gnome-todo stickersSexy GNOME To Do stickers, a courtesy of Jakub

It’s fantastic to see how GNOME To Do is gaining momentum these days. I certainly did not expect it three years ago, when I bootstrapped it as a small app to help me deal with my Google Summer of Code project on Nautilus. It’s just getting out of control.

Epilogue

Even though I was reluctant to go, this GUADEC turned out to be an excellent and productive event. Thanks for all the organizers and volunteers that worked hard on making it happen – you all deserve a drink and a hug!

I was proudly sponsored by the GNOME Foundation.

Sponsored by the GNOME Foundation



Jonh Wendell: Istio, Service Mesh, Atualizações

7 de Julho de 2018, 17:44, por Planeta GNOME Brasil - 0sem comentários ainda

Olá, pessoal! Este blog tá meio quieto ultimamente… Só quero dar uma atualização sobre o que eu ando fazendo estes dias. Segue…

Istio Logo

Projeto Istio

Desde Dezembro de 2017/Janeiro de 2018 eu mudei de time na Red Hat, e comecei a trabalhar com o Istio. Istio é uma ferramenta/plataforma que nos ajuda na implantação de micro-serviços, em vários aspectos diferentes. Eu planejo escrever mais posts sobre isso. Enquanto isso, você pode ler mais sobre o Istio no website do projeto. Vá por mim, Istio é um projeto fantástico que merece uma olhada, se você está envolvido de alguma forma, ou se planeja entrar no mundo dos micro-serviços, seja você dev ou ops :).

Por enquanto nosso trabalho tem sido principalmente em entender os benefícios do Istio quando usado com o Kubernetes e Openshift (versão melhorada e suportada do Kubernetes pela Red Hat). Isso quer dizer que estamos mais envolvidos em tarefas downstream, tipo criar binários RPM para RHEL e CentOS e imagens para containers, embora nós já estamos contribuindo com a comunidade upstream. O plano é se envolver bem mais com a comunidade, muito, muito em breve.

Eventos

Dezembro passado estive na Kubecon US em Austin, Texas. Foi minha primeira imersão no Istio, visto que rolou uma IstioCon, um pre-evento com um tanto de palestras e workshop. Em Maio desse ano estive na Kubecon EU, que aconteceu em Copenhaguen, Dinamarca. Todas as palestras estão disponíveis gratuitamente (em inglês) no canal da CNCF no YouTube. Confiram! Definitivamente é um ótimo material para se atualizar sobre o que tá acontecendo lá fora, não somente no mundo do Istio, mas no grande ecossistema do Kubernetes.

Em abril estive no ótimo TDC (The Developers Conference) edição Florianópolis, e dei uma palestra sobre o ecossistema dos Containers – alternativas ao Docker (CRI-O, Buildah, Podman, etc).

Agora em julho estarei palestrando no TDC São Paulo. Darei duas palestras sobre Istio e uma sobre o ecossistema de containers, praticamente a mesma que dei no TDC Floripa. O evento já é um sucesso tão grande que os organizadores tiveram que duplicar algumas trilhas, de forma a poder receber todos os inscritos. Assim sendo, minhas palestras nas trilhas de microservices (Introdução a Service Mesh com Istio) e devops (Como o Istio facilita deployments entre micro-serviços) serão duplicadas, assim terão 2 de cada, somando 5 no total! Espero que os brindes que levarei dêem pra todo mundo!

Em agosto viajarei para Boston, MA para participar do primeiro Devconf dos Estados Unidos! Darei uma palestra sobre Istio lá.

Acredito que mais eventos virão, visto o tanto de hype e momentum que Istio/Service Mesh está tendo em todo o lugar.

Planos

Meu plano é escrever no blog regularmente sobre as coisas legais que estamos fazendo com o Istio, e como ele pode ser usado para melhorar a implantação de micro-serviços, tornando a vida dos desenvolvedores e administradores mais fácil!

Nos vemos em breve!



Tags deste artigo: gnome planet planeta