Prefácio

Assim como tudo no Linux, tenho certeza de que existem várias maneiras de obter um resultado pretendido com iptables. Gostaria de limitar as respostas às seguintes categorias:

1. Qual a diferença entre as opções?
2. Qual opção é melhor (ou são a mesma coisa)?
3. Por que você prefere um ao outro?

E, por favor, seja claro para qual categoria você está falando. Não há problema em declarar preferências , mas não insinue que é o melhor .

por exemplo

Prefiro colocar --jumpcomo o primeiro argumento porque acho que é melhor ler a intenção primeiro e gosto de alinhar verticalmente como argumentos de vários comandos.

Pergunta

Um desses é melhor que o outro?

iptables -I INPUT --jump ACCEPT --in-interface lo
iptables -I INPUT --jump ACCEPT --source localhost

Um desses é melhor que o outro?

iptables -A INPUT --jump REJECT
iptables -P INPUT REJECT

Conforme descrito aqui https://aws.amazon.com/blogs/aws/new-amazon-ec2-feature-idempotent-instance-creation/ AWS CLI impõe a idempotência do aws ec2 run-instances --cli-input-jsoncomando. Infelizmente, não há documentação sobre como um token de cliente é gerado.

Descobri que há um ClientTokencampo nos aws ec2 describe-instancesresultados, mas é claro que você ainda receberá o seguinte erro se tentar usar um:

An error occurred (IdempotentParameterMismatch) when calling the RunInstances operation: Arguments on this idempotent request are inconsistent with arguments used in previous request(s).

Como obtenho um token para usar --client-token?

Os documentos dizem...

Um pod (como em um pod de baleias ou vagem de ervilha) é um grupo de um ou mais contêineres (como contêineres Docker), o armazenamento compartilhado para esses contêineres e opções sobre como executar os contêineres. Os pods são sempre co-localizados e co-agendados e executados em um contexto compartilhado. Um pod modela um “host lógico” específico do aplicativo - ele contém um ou mais contêineres de aplicativos que são relativamente fortemente acoplados - em um mundo pré-contêiner, eles seriam executados na mesma máquina física ou virtual.

Mas não tenho certeza se "co-location" significa no mesmo nó P̶o̶d̶. Quando os satélites são co-localizados , eles estão "próximos, de modo que, para o equipamento de recepção no solo, eles 'parecem' ocupar uma única posição orbital". Portanto, isso pode estar no mesmo Cluster, não no mesmo Node.

No momento da postagem, a única informação que encontrei sobre esse problema está em https://platform9.com/blog/compare-kubernetes-vs-ecs/ onde diz...

É garantido que os contêineres em um único pod sejam executados em um único nó do Kubernetes.

Agora isso parece bastante conclusivo, mas não consegui obter nenhuma corroboração disso em nenhum lugar. Quero ter certeza de que eles estão corretos e não apenas entenderam mal e espalharam informações erradas.

A razão pela qual estou perguntando é que parece que o Kubernetes é inerentemente um desperdício se isso for verdade. É quase certo que seus nós com pods implantados terão recursos sobrando. É provável que você tenha um pod cujas necessidades possam ser satisfeitas pela combinação desses recursos restantes. No entanto, se um pod não puder abranger vários nós, você terá que criar um novo nó e ter ainda mais recursos não utilizados.