Autor: JD Logística Yang Jianmin

1. Origem da arquitetura de microsserviços

Arquitetura monolítica: Pode ser entendida como uma aplicação onde o módulo principal de lógica de negócios (o módulo de código que escrevemos, excluindo o middleware independente) é executado em um processo, geralmente executado em um contêiner Tomcat e localizado em um processo. As vantagens da arquitetura monolítica são baixo limite técnico, menos carga de trabalho de programação, desenvolvimento simples e rápido, depuração conveniente, fácil construção de ambiente, fácil implantação e atualização de lançamento, baixo custo geral de desenvolvimento e manutenção e resultados rápidos. Suas desvantagens também são óbvias:

(1) O sistema de aplicação monolítico é relativamente inchado e inchado, com alto grau de acoplamento, o que dificulta o desenvolvimento sustentável, operação e manutenção.

(2) É difícil para um único aplicativo suportar as crescentes solicitações e demandas dos usuários.

Diagrama de arquitetura de aplicativo único baseado no Spring Framework

A ideia central da arquitetura distribuída é dividir um sistema de processo único em um grupo de processos que cooperam entre si em função e podem ser implantados independentemente em vários servidores. Dessa forma, o sistema pode ser implementado da seguinte forma duas maneiras de acordo com as necessidades reais do negócio A expansão de alguns componentes independentes melhora o rendimento.

Expansão horizontal: expansão aumentando o número de servidores

Expansão vertical: alocar máquinas melhores e fornecer mais recursos para determinados negócios especiais no sistema, aumentando assim a carga do sistema e o rendimento desses negócios

Arquitetura distribuída é dividir um grande aplicativo monolítico em vários processos de execução independente. Esses processos podem realizar chamadas remotas de alguma forma. Portanto, o primeiro problema técnico central a ser resolvido pela arquitetura distribuída é o processo de comunicação remota entre processos independentes. A primeira resposta a essa pergunta é a tecnologia RPC (Remote Procedure Call). O diagrama estrutural de uma plataforma típica de arquitetura de microsserviços é o seguinte:

Os frameworks de arquitetura de microsserviços mais conhecidos incluem Dubbo e Spring Cloud. Depois disso, as arquiteturas de microsserviços mais bem-sucedidas estão basicamente ligadas à tecnologia de contêineres. A mais bem-sucedida e influente é a plataforma Kubernetes, e o Docker também é semelhante. A empresa lançou o Docker Swarm (no final de 2017, o Docker Swarm também suportava o Kubernetes).

As vantagens da arquitetura de microsserviços não serão expandidas devido ao espaço limitado do artigo, mas qualquer tecnologia tem dois lados e a arquitetura de microsserviços tem certa complexidade. Por exemplo, os desenvolvedores devem dominar alguma tecnologia RPC e devem escrever código para lidar com RPC velocidade Problemas complicados como lentidão ou falha na chamada. Para resolver o problema de complexidade de programação trazido pelos microsserviços, surgiu uma nova ideia de design de arquitetura, o Service Mesh. A definição de Service Mesh é: uma infraestrutura complexa para lidar com a comunicação (chamada) entre serviços e instalações de serviços. Em essência, Service Mesh é uma rede de serviço composta por um grupo de agentes de rede. Esses agentes serão implantados junto com programas de usuário para atuar como agentes de serviço. Esse agente é posteriormente chamado de "Sidecar" na arquitetura de produto Istio do Google. Na verdade, é é usar a ideia do modo proxy para resolver o problema de intrusão de código e codificação repetida. A figura a seguir mostra o diagrama de arquitetura mais simples do Service Mesh. Servie Mesh também não é o protagonista desta vez, amigos interessados podem aprender sozinhos.

2. Conhecendo o k8s pela primeira vez

O texto oficial é: K8s é uma abreviação derivada da substituição das 8 letras “ubernete” por 8.

O nome completo do k8s é kubernetes. O nome vem do grego e significa "timoneiro" ou "navegador". É a arquitetura de microsserviços da primeira geração da tecnologia de contêineres (a segunda geração é Servie Mesh).

O Kubernetes originou-se originalmente do Borg interno do Google, que fornece um sistema de implantação e gerenciamento de cluster de contêiner orientado a aplicativos. O objetivo do Kubernetes é remover o fardo de orquestrar computação física/virtual, rede e infraestrutura de armazenamento e permitir que operadores e desenvolvedores de aplicativos se concentrem totalmente em primitivos centrados em contêineres para operações de autoatendimento. O Kubernetes também fornece uma base estável e compatível (plataforma) para criar fluxos de trabalho personalizados e tarefas de automação mais avançadas.

O Kubernetes possui recursos abrangentes de gerenciamento de cluster, incluindo proteção de segurança multinível e mecanismos de acesso, recursos de suporte a aplicativos multilocatários, registro transparente de serviços e mecanismos de descoberta de serviços, balanceadores de carga integrados, recursos de detecção e autocorreção de falhas e atualizações contínuas de serviços E expansão online, mecanismo de agendamento automático de recursos escaláveis, recursos de gerenciamento de cota de recursos multigranularidade.

O Kubernetes também fornece ferramentas de gerenciamento abrangentes, cobrindo todos os aspectos de desenvolvimento, teste de implantação, monitoramento de operação e manutenção, etc.

Arquitetura e componentes 2.1 k8s

O Kubernetes consiste principalmente nos seguintes componentes principais:

O etcd salva o estado de todo o cluster;
apiserver fornece o único acesso às operações de recursos e fornece autenticação, autorização, controle de acesso, registro de API e mecanismos de descoberta;
O gerenciador do controlador é responsável por manter o estado do cluster, como detecção de falhas, expansão automática, atualização contínua, etc.;
O escalonador é responsável pelo escalonamento dos recursos e escalonamento dos Pods para as máquinas correspondentes de acordo com a estratégia de escalonamento predeterminada;
Kubelet é responsável por manter o ciclo de vida do container, sendo responsável também pela gestão de Volume (CVI) e rede (CNI);
O tempo de execução do contêiner é responsável pelo gerenciamento de imagem e pela operação real do Pod e do contêiner (CRI);
kube-proxy é responsável por fornecer descoberta de serviço e balanceamento de carga dentro do cluster para Serviço;

conceito de design 2.2 k8s

Princípios de design da API

O objeto API é a unidade de operação de gerenciamento no cluster k8s. Sempre que o sistema de cluster k8s oferece suporte a uma nova função e introduz uma nova tecnologia, o objeto API correspondente deve ser introduzido novamente para oferecer suporte ao gerenciamento e operação da função. Por exemplo, o objeto API correspondente ao conjunto de réplicas Replica Set é RS.

k8s adota operações declarativas, yaml definido pelo usuário e a API k8s é responsável pela criação. Cada objeto tem três categorias de atributos: metadados, especificação de especificação e status de status. Os metadados são usados para identificar objetos da API, e cada objeto tem pelo menos 3 metadados: namespace, name e uid; além disso, existem vários rótulos de tags usados para identificar e combinar diferentes objetos, como usuários Você pode usar o rótulo env para identificar e distinguir diferentes ambientes de implantação de serviço e usar env=dev, env=testing e env=production para identificar diferentes serviços para desenvolvimento, teste e produção. A especificação descreve o estado ideal (estado desejado) que o usuário espera que o sistema distribuído no cluster k8s alcance. Por exemplo, o usuário pode definir o número esperado de réplicas de pod para 3 por meio do controlador de replicação; o status descreve o atual real estado do sistema (Status ), por exemplo, o número real atual de cópias do Pod no sistema é 2; então a lógica do programa atual do controlador de replicação é iniciar automaticamente um novo Pod, esforçando-se para atingir o número de cópias para 3 .

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

apiVersion - a versão da API do Kubernetes que criou o objeto

tipo - que tipo de objeto criar?

metadados- dados que identificam exclusivamente o objeto, incluindo nome (string), UID e Namespace (opcional)

Crie uma implantação usando o arquivo .yaml acima usando o comando kubectl create em kubectl. Passe esse arquivo .yaml como um parâmetro. Por exemplo:

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record

Objetos k8s comuns: pod, controlador de replicação (RC), conjunto de réplicas (conjunto de réplicas, RS), implantação, serviço, trabalho, volume, volume persistente e declaração de volume persistente (volume persistente, PV, declaração de volume persistente, PVC), nó ( Node), ConfigMap, Endpoint , etc.

Princípios de design do mecanismo de controle

Cada módulo pode degradar normalmente os serviços quando necessário. A lógica de controle deve depender apenas do estado atual. Isso é para garantir a estabilidade e a confiabilidade dos sistemas distribuídos. Para sistemas distribuídos que geralmente apresentam erros locais, se a lógica de controle depender apenas do estado atual, é muito fácil restaurar um sistema temporariamente defeituoso a um estado normal, porque você só Quando o sistema for redefinido para algum estado estacionário, você pode ter certeza de que toda a lógica de controle do sistema começará a funcionar normalmente.

Assuma qualquer possibilidade de erro, e faça-o com tolerância. Erros locais e temporários são um evento de alta probabilidade em um sistema distribuído. Erros podem vir de falhas físicas do sistema e falhas externas do sistema também podem vir de erros de código no próprio sistema. Na verdade, é difícil garantir a estabilidade do sistema contando com códigos auto-implementados sem erros. Portanto, é necessário projetar falhas processamento tolerante para quaisquer possíveis erros.

Tente evitar máquinas de estado complexas e a lógica de controle não deve depender de estados internos que não podem ser monitorados. Como cada subsistema de um sistema distribuído não pode ser estritamente sincronizado dentro do programa, se a lógica de controle dos dois subsistemas afetar um ao outro, os subsistemas devem poder acessar um ao outro para o estado que afeta a lógica de controle, caso contrário, apenas é equivalente à existência de lógica de controle incerta no sistema.

Assuma que qualquer operação pode ser rejeitada por qualquer objeto de operação, ou mesmo mal interpretada. Devido à complexidade do sistema distribuído e à relativa independência de cada subsistema, subsistemas diferentes muitas vezes vêm de equipes de desenvolvimento diferentes, portanto não se pode esperar que qualquer operação seja tratada por outro subsistema de maneira correta. ocorrer um erro, os erros de nível de operação não afetarão a estabilidade do sistema.

Cada módulo pode ser restaurado automaticamente após um erro. Como é impossível garantir que cada módulo do sistema esteja sempre conectado em um sistema distribuído, cada módulo deve ter a capacidade de auto-recuperação e garantir que não travará por não poder ser conectado a outros módulos.

Cada módulo pode fazer o downgrade dos serviços quando necessário. O chamado serviço de downgrade gracioso é um requisito para a robustez do sistema, ou seja, é necessário distinguir claramente entre funções básicas e funções avançadas ao projetar e implementar módulos, de modo a garantir que as funções básicas não dependam de recursos avançados funções e, ao mesmo tempo, garantir que não haverá problemas devido a funções avançadas. Uma falha causa a falha de todo o módulo. O sistema implementado de acordo com este conceito é também mais fácil de adicionar rapidamente novas funções avançadas, pensando que não há necessidade de se preocupar com a introdução de funções avançadas que afetam as funções básicas originais.

3. Gerenciamento de recursos

A maneira como a plataforma de nuvem de contêiner gerencia com precisão os recursos disponíveis para os locatários desempenha um papel vital na disponibilidade, capacidade de manutenção e facilidade de uso da plataforma e é a base para a plataforma de nuvem de contêiner fornecer aos usuários um gerenciamento avançado de microsserviços. No campo da computação em nuvem, os recursos podem ser divididos em três categorias: recursos de computação, recursos de rede e recursos de armazenamento, que também podem ser chamados de nuvens de computação, nuvens de rede e nuvens de armazenamento, respectivamente.

3.1. Gerenciamento de recursos de computação

Namespace

No cluster k8s, a entidade que fornece recursos de computação é chamada de Node.Node pode ser um servidor de máquina física ou um servidor de máquina virtual.Cada Node fornece recursos como CPU, memória, disco e rede. Cada Node (node) possui alguns serviços necessários para rodar o pod e é gerenciado pelo componente Master.Os serviços no node Node incluem Docker, kubelet e kube-proxy.

Ao introduzir o Namespace, o k8s divide ainda mais o cluster em vários grupos virtuais para gerenciamento. A "partição" realizada pelo Namespace é lógica e não está vinculada a recursos reais. Ele é usado em cenários multilocatários para realizar o particionamento de recursos e o uso de maximização de recursos.

A maioria dos recursos do Kubernetes (como pods, serviços, controladores de replicação ou outros) está em algum Namespace, mas os próprios recursos do Namespace não estão no Namespace. E os recursos de baixo nível (como Node e persistenteVolumes) não estão em nenhum Namespace. Os eventos são uma exceção: podem ou não ter um Namespace, dependendo do objeto Events.

Debaixo

Pod é a menor/simples unidade básica criada ou implantada pelo Kubernetes, e um Pod representa um processo em execução no cluster.

Um pod encapsula um contêiner de aplicativo (ou vários contêineres), recursos de armazenamento, um IP de rede independente e opções de política para gerenciar e controlar como o contêiner é executado. Um pod representa uma unidade de implantação: uma instância de um único aplicativo no Kubernetes, que pode consistir em um único contêiner ou recursos compartilhados por vários contêineres.

Cada Pod é uma única instância do aplicativo em execução. Se você precisar dimensionar o aplicativo horizontalmente (por exemplo, para executar várias instâncias), deverá usar vários Pods, um Pod por instância. No Kubernetes, isso geralmente é chamado de replicação. Os pods de replicação geralmente são criados e gerenciados pelo controlador. O controlador pode criar e gerenciar vários pods, fornecendo gerenciamento de réplicas, atualizações contínuas e recursos de autocorreção em nível de cluster. Por exemplo, se um nó falhar, o controlador pode agendar automaticamente os pods no nó para outros nós íntegros.

Recipiente

O Docker em si é relativamente pesado. O OCI (Open Container Initiative ) nasceu em 2015. Ele define padrões de imagem, padrões de tempo de execução e padrões de distribuição. Como o próprio k8s não tem a capacidade de criar contêineres, ele chama as interfaces e os comandos da API de tempo de execução do contêiner através do componente kubelet Para criar containers, a relação entre Kubernetes e runtimes de container é histórica e complexa. Mas como o Kubernetes abandona o Docker, os tempos de execução convencionais atuais são principalmente containerd e CRI-O

O modo "um contêiner por pod" é o uso mais comum do Kubernetes, e um pod também pode ter vários contêineres.

Três níveis de gerenciamento de recursos de computação

No k8s, a configuração e limitação de recursos podem ser gerenciadas a partir dos três níveis de Namespace, Pod e Container. Por exemplo:

O nível do contêiner pode ser configurado por meio de solicitação de recursos e limites de recursos

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
spec:
  containers:
  - name: memory-demo-3-ctr
    image: vish/stress
    resources:
      limits:
        memory: "1000Gi"
      requests:
        memory: "1000Gi"
    args:
    - -mem-total
    - 150Mi
    - -mem-alloc-size
    - 10Mi
    - -mem-alloc-sleep
    - 1s

O nível do Pod pode ser definido criando um objeto LimitRange, para que os contêineres contidos no Pod possam ser configurados uniformemente

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - max:
      cpu: "4"
      memory: 2Gi
    min:
      cpu: 200m
      memory: 6Mi
    maxLimitRequestRatio:
      cpu: 3
      memory: 2
    type: Pod
  - default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 100Mi
    max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 100m
      memory: 3Mi
    maxLimitRequestRatio:
      cpu: 5
      memory: 4
    type: Container

O nível Namespace pode fornecer um limite geral de uso de recursos por meio da configuração do objeto de recurso ReSourceQuota. Esse limite pode ser o limite superior da quantidade total de recursos de computação usados por todos os pods ou o limite superior do número total de objetos de um determinado tipo para todos os Pods (incluindo o número de objetos como Pod, RC, Service, Secret, ConfigMap e PVC que podem ser criados)

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
  request.cpu: "4"
  request.memory: 8GB
  limit.memory:16GB
  pods: "2"

3.2 Gerenciamento de recursos de rede

O modelo ip de k8s

node Ip : o ip do node node, que é o ip físico.

pod Ip : O ip do pod, ou seja, o ip do docker container, é um ip virtual.

cluster Ip : o ip do serviço, que é um ip virtual. Forneça um IP virtual no cluster para acesso ao pod. O princípio de realização é através das regras de firewall do Linux, que pertencem à tecnologia NAT. Ao acessar o ClusterIP, a solicitação será encaminhada para a instância de back-end. Se houver várias instâncias de back-end, o balanceamento de carga será alcançado. O padrão é o método de treinamento round-robin.

Solução de rede de contêiner entre hosts

No sistema k8s, um princípio básico do design do modelo de rede k8s: cada pos tem um endereço IP independente e assume-se que todos os pods estão em um espaço de rede plano que pode ser conectado diretamente, independentemente de estarem em execução no mesmo Node (host), eles podem ser acessados diretamente pelo IP da outra parte. Mas o próprio k8s não fornece uma solução de rede de contêiner entre hosts. Ambientes de nuvem pública (como AWS, Azure e GCE) geralmente fornecem soluções de rede de contêiner, mas em ambientes de nuvem privada, as plataformas de nuvem de contêiner ainda precisam fornecer várias soluções de rede de contêiner para diferentes locatários.

Atualmente, definir uma rede Overlay para contêineres é a solução de rede de contêiner entre hosts mais comum. Uma rede de sobreposição refere-se ao encapsulamento de pacotes IP originais por meio de algum protocolo de rede adicional para formar uma rede lógica sem alterar a configuração de rede original. Na plataforma k8s, é recomendável implantar a rede de contêineres por meio do plug-in CNI.

CNI (Container Network Interface) é um projeto da Fundação CNCF. Consiste em um conjunto de especificações e bibliotecas para configuração da interface de rede do container. Define a especificação da interface entre o ambiente operacional do container e o plug-in de rede, e só se preocupa com o container.A configuração da rede no momento da criação e a destruição do container são a liberação dos recursos da rede, sendo que um container pode vincular vários plug-ins de rede CNI para ingressar na rede, conforme mostra a figura abaixo.

Atualmente, os métodos de implementação de plug-ins CNI que comparam processos incluem Flannel, Calico, macvlan, Open vSwitch e roteamento direto.

Entrada

No cluster k8s, o aplicativo fornece serviços na forma de Serviço por padrão, e o kube-proxy implementa a função de balanceador de carga do Serviço para o contêiner, conforme a figura a seguir para definir um serviço mysql:

kind: Service
apiVersion: v1
metadata:
  name: mysql-master
spec:
  selector:
    app: mysql-master
  ports:
      port: 3306
      targetPort: 3306

Neste momento, o serviço não pode ser acessado fora do cluster. Para serviços que exigem clientes fora do cluster k8s para fornecer serviços, os serviços podem ser expostos por meio do Ingress e, se o cluster (rede) tiver um nome de domínio real, o serviço também poderá ser conectado diretamente ao nome de domínio.

O k8s combina a definição de um objeto de recurso do Ingress com um Controlador do Ingress específico para implementar um balanceador de carga da Camada 7. Quando o Ingress Controller encaminha as solicitações do cliente para o serviço de back-end, ele ignora a função do balanceador de carga da camada 4 fornecida pelo kube-proxy e as encaminha diretamente para os pods de back-end (endpoints) do serviço para melhorar a eficiência do encaminhamento da rede.

A figura acima mostra um exemplo típico do Ingress de roteamento da camada HTTP, onde:

O acesso a http://mywebsite.com/api será roteado para o Serviço denominado "api" no back-end;

O acesso a http://mywebsite.com/web será encaminhado para o Serviço com o nome de back-end "web";

O acesso a http://mywebsite.com/doc será encaminhado para o Serviço com o nome de back-end "doc".

A seguir está uma definição típica de política do Ingress. O Ingress Controller encaminha a solicitação de acesso para o endereço de destino http://mywebsite.com/demo para o webapp (webapp:8080/demo) servido no cluster

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
   name: mywebsite-ingress
spec:
   rules:
   -host：mywebsite.com
    http:
       paths:
      - path: /demo
          backend:
           serviceName: webapp
           servicePort: 8080

Os controladores Ingress comumente usados incluem: Nginx, HAProxy, Traefik, apisix, etc.

3.3 Recursos de armazenamento

Tipos de volume suportados pelo k8s

Diretório temporário (emptyDir)

Usando emptyDir, quando um Pod é alocado para um Node, um emptyDir será criado, e enquanto o Pod no Node continuar rodando, o Volume sempre existirá. Quando o Pod (por qualquer motivo) for excluído do Node, o emptyDir também será excluído ao mesmo tempo e os dados armazenados também serão excluídos permanentemente. Observação: a remoção de um contêiner não afeta o emptyDir.

classe de configuração

ConfigMap: Monte as informações do arquivo de configuração armazenadas no objeto de recurso ConfigMap em um determinado diretório do contêiner

Segredo: monte a chave de senha e outras informações armazenadas no objeto de recurso Segredo em um arquivo no contêiner

DownwardApI: injeta os dados da API descendente no contêiner na forma de variáveis de ambiente ou arquivos

gitRepo: monte uma base de código Git em um diretório no contêiner

classe de armazenamento local

hostPath: Monte o diretório ou arquivo do host no contêiner para uso

local: Introduzido a partir da versão v1.9, o armazenamento local é fornecido ao contêiner na forma de PV e pode gerenciar o espaço de armazenamento

classe de armazenamento compartilhado

PV (Persistne Volume): Defina o armazenamento compartilhado como um "volume de armazenamento persistente" que pode ser compartilhado por vários contêineres

PVC (Persistne Volume Claim): Um "aplicativo" do usuário para recursos de armazenamento. O objeto do aplicativo PVC é PV. Depois que o aplicativo for bem-sucedido, o aplicativo poderá usar o volume de armazenamento compartilhado como um diretório local. A figura a seguir é uma definição ymal do objeto PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
  annotations:
        "volume.alpha.kubernetes.io/node-affinity": '{
            "requiredDuringSchedulingIgnoredDuringExecution": {
                "nodeSelectorTerms": [
                    { "matchExpressions": [
                        { "key": "kubernetes.io/hostname",
                          "operator": "In",
                          "values": ["example-node"]
                        }
                    ]}
                 ]}
              }'
spec:
    capacity:
      storage: 100Gi
    accessModes:
    - ReadWriteOnce
    persistentVolumeReclaimPolicy: Delete
    storageClassName: local-storage
    local:
      path: /mnt/disks/ssd1

PV e PVC

O ciclo de vida da relação entre PV e PVC é mostrado na figura acima.O modo de fornecimento de armazenamento compartilhado k8s inclui modo estático (Estático) e modo dinâmico (Dinâmico).O resultado do fornecimento de recursos é a criação de um bom PV. A criação manual de PV pelo pessoal de operação e manutenção é estática e a chave para o modo dinâmico é StorageClass, que é usado para criar modelos de PV.

Para criar um StorageClass, você precisa definir atributos de PV, como tipo de armazenamento, tamanho, etc.; além disso, você precisa usar um plug-in de armazenamento para criar tal PV. O efeito final é que o usuário envia um PVC, que especifica o tipo de armazenamento.Se corresponder ao StorageClass que definimos, um PV será criado e vinculado automaticamente.

A figura a seguir cria um objeto StorageClass por meio de ymal

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs    // 存储分配器
parameters:
  type: gp2
reclaimPolicy: Retain   // 回收策略
mountOptions:
  - debug

A relação operacional entre StorageClass e PV e PVC é mostrada na figura abaixo:

CSI

A relação entre CSI (Container Storage Interface) e k8s é um pouco semelhante à do CNI.CSI visa sugerir um conjunto de interfaces de acesso de armazenamento padrão entre contêineres e armazenamento compartilhado. Antes de seu nascimento, experimentou o método "in-tree" e o modo FlexVolume.

A especificação CSI separa completamente o código do provedor de armazenamento do código k8s, e o código do plug-in de armazenamento é mantido pelo próprio provedor de armazenamento.

Interagindo diretamente com o kube-apiserver estão alguns contêineres de sidecar fornecidos diretamente pelo oficial do K8S, e esses sidecars podem ser implantados diretamente. Esses contêineres secundários (principalmente os três componentes principais na figura acima) escutam seus CRDs correspondentes, acionam as operações correspondentes e chamam diretamente as interfaces do driver CSI (como CreateVolume(), NodePublishVolme(), etc.) por meio do UDS interface para implementar o volume.operar.

Para desenvolver Drivers CSI geralmente implementamos os seguintes serviços:

Serviço de Identidade CSI

Permite que os chamadores (componentes do Kubernetes e contêineres CSI sidecar) identifiquem o driver e os recursos opcionais compatíveis.

Serviço de nó CSI

NodePublishVolume, NodeUnpublishVolume e NodeGetCapabilities são obrigatórios.

O método necessário permite que o chamador disponibilize o volume no caminho especificado e descubra quais recursos opcionais o driver suporta.

Serviço de controlador CSI

Implemente as interfaces CreateVolume e DeleteVolume

3.4 Esquema de gerenciamento de recursos de vários clusters - federação de clusters (Federação)

Federation é um subprojeto do Kubernetes. Seu objetivo de design é gerenciar vários clusters Kubernetes de maneira unificada e implantar aplicativos de usuário em data centers em diferentes regiões. A Federação introduz um plano de controle localizado no cluster Kubernetes, protege os subclusters k8s de back-end e fornece aos clientes um portal de gerenciamento unificado, conforme mostrado na figura a seguir:

O plano de controle da Federação "encapsula" a função de Mestre de vários clusters k8s e fornece um Mestre unificado, incluindo Servidor de API de Federação e Gerenciador de Controlador de Federação. Os usuários podem operar a Federação como se estivessem operando um único cluster e unificar o DNS e o ConfigMap de todos k8s clusters. , e salve os dados em um banco de dados etcd centralizado.

escreva para os leitores

Para iniciantes do k8s, a primeira impressão do k8s deve ser que existem muitos conceitos e substantivos. O guia oficial para kubernetes: o combate à nuvem de contêineres de nível corporativo começa da perspectiva da prática corporativa, descreve a evolução da tecnologia e fornece uma comparação de diferentes implementações de tecnologia em muitos cenários. Combinado com a comunidade chinesa k8s, este livro pode ser usado como uma ferramenta de aprendizagem para livros introdutórios k8s. Este artigo é, na verdade, uma nota de leitura deste livro. O artigo se expande a partir das três direções de recursos de computação, recursos de rede e recursos de armazenamento, e apresenta alguns conceitos e objetos comuns no k8s. Devido a questões de espaço, muitos conceitos importantes não são introduzidos em detalhes no artigo, os leitores podem realizar estudos complementares de acordo com sua própria situação. Os principais componentes e princípios de funcionamento do k8s serão lançados no futuro.

Análise da tecnologia de virtualização, a segunda rodada de entendimento do Kubernetes pela primeira vez