All perguntas(server)

Para reinstalar meu cluster local usando kubeadm, executei os seguintes comandos:

sudo apt-get purge -y kubeadm kubectl kubelet kubernetes-cni  kubelet kube-apiserver kube-scheduler kube-controller-manager kube-proxy
sudo apt-get autoremove -y

e reinicie minha máquina.

O problema é que ainda encontro vários processos kube usando ps:

(base) ➜  ~ ps -ef | grep kube 
root        9198    8816  3 12:46 ?        00:01:11 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime-endpoint=unix:///run/containerd/containerd.sock --node-ip=172.23.0.2 --node-labels= --pod-infra-container-image=registry.k8s.io/pause:3.9 --provider-id=kind://docker/kind/kind-control-plane --fail-swap-on=false --cgroup-root=/kubelet
root        9480    9312  2 12:46 ?        00:00:52 kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --bind-address=127.0.0.1 --client-ca-file=/etc/kubernetes/pki/ca.crt --cluster-cidr=10.244.0.0/16 --cluster-name=kind --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --controllers=*,bootstrapsigner,tokencleaner --enable-hostpath-provisioner=true --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/16 --use-service-account-credentials=true
root        9513    9313  0 12:46 ?        00:00:11 kube-scheduler --authentication-kubeconfig=/etc/kubernetes/scheduler.conf --authorization-kubeconfig=/etc/kubernetes/scheduler.conf --bind-address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true
root        9550    9352  6 12:46 ?        00:02:13 kube-apiserver --advertise-address=172.23.0.2 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --enable-bootstrap-token-auth=true --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key --etcd-servers=https://127.0.0.1:2379 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --runtime-config= --secure-port=6443 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/etc/kubernetes/pki/sa.pub --service-account-signing-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/16 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
root        9557    9344  3 12:46 ?        00:01:06 etcd --advertise-client-urls=https://172.23.0.2:2379 --cert-file=/etc/kubernetes/pki/etcd/server.crt --client-cert-auth=true --data-dir=/var/lib/etcd --experimental-initial-corrupt-check=true --experimental-watch-progress-notify-interval=5s --initial-advertise-peer-urls=https://172.23.0.2:2380 --initial-cluster=kind-control-plane=https://172.23.0.2:2380 --key-file=/etc/kubernetes/pki/etcd/server.key --listen-client-urls=https://127.0.0.1:2379,https://172.23.0.2:2379 --listen-metrics-urls=http://127.0.0.1:2381 --listen-peer-urls=https://172.23.0.2:2380 --name=kind-control-plane --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt --peer-client-cert-auth=true --peer-key-file=/etc/kubernetes/pki/etcd/peer.key --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt --snapshot-count=10000 --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
root       10082   10017  0 12:46 ?        00:00:00 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=kind-control-plane

Mas não consegui encontrar esses arquivos (por exemplo, kube-proxy, kubelet, kube-apiserver e kube-scheduler) nos diretórios, como root:

(base) ➜  ~ ll /usr/bin/kubelet                
ls: cannot access '/usr/bin/kubelet': No such file or directory
(base) ➜  ~ kubectl 
zsh: command not found: kubectl
(base) ➜  ~ 
(base) ➜  ~ sudo kube-apiserver --help            
sudo: kube-apiserver: command not found
(base) ➜  ~ cd /usr/bin          
(base) ➜  bin ls kubelet 
ls: cannot access 'kubelet': No such file or directory
(base) ➜  bin ll kube-controller-manager                
ls: cannot access 'kube-controller-manager': No such file or directory
(base) ➜  bin ll kube-apiserver                       
ls: cannot access 'kube-apiserver': No such file or directory

Alguém poderia ajudar a explicar como esses processos são lançados? Obrigado.

Tentando estender um LVM na minha VM do Ubuntu, mas me deparei com um problema que não consegui resolver pesquisando neste site.

Quando executo df -h recebo a seguinte saída:

Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              197M   21M  176M  11% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   12G   11G  234M  98% /
tmpfs                              983M     0  983M   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/sda2                          2.0G  375M  1.5G  21% /boot
tmpfs                              197M  4.0K  197M   1% /run/user/1000

Como você pode ver, restam apenas 234 milhões no disco /dev/mapper/ubuntu--vg-ubuntu--lv.

No entanto, quando executo sudo pvresize -v /dev/mapper/ubuntu--vg-ubuntu--lv recebo o seguinte:

 Cannot use /dev/mapper/ubuntu--vg-ubuntu--lv: device is not in a usable state
 0 physical volume(s) resized or updated / 0 physical volume(s) not resized

Como eu disse, procurei por aí, mas não descobri nada que ajudasse.

Eu tenho um script invocado na sshinvocação (no Linux) para executar alguns comandos e depois fazer login como um usuário diferente su -l <anotheruser>- tudo isso funciona bem quando eu uso qualquer cliente scp/ baseado em Linux ssh. Mas quando tento com WinScp (com File Protocol SCP nas opções) não funciona! Continuando a solução de problemas, parece que o shell invocado su -l <anotheruser>está de alguma forma sendo eliminado! Então, vejo o seguinte no log do WinScp:

(EFatal) **Connection has been unexpectedly closed.** Server sent command exit status 1

Mas não consigo descobrir por que o sushell de login é eliminado apenas ao usar o WinScp! Alguma indicação para depurar ainda mais?

--EDITAR--

Últimas linhas do log do WinSCP:

! 2024-07-27 00.23.13.824 su: must be run from a terminal
. 2024-07-27 00.23.13.824 Session sent command exit status 1
. 2024-07-27 00.23.13.824 Main session channel closed
. 2024-07-27 00.23.13.824 All channels closed
. 2024-07-27 00.23.13.824 Timeout waiting for network events
. 2024-07-27 00.23.13.824 Waiting for another 1 bytes
. 2024-07-27 00.23.13.824 Looking for incoming data
. 2024-07-27 00.23.13.824 Looking for network events
. 2024-07-27 00.23.13.824 Attempt to close connection due to fatal exception:
* 2024-07-27 00.23.13.824 **Connection has been unexpectedly closed.** Server sent command exit status 1.
. 2024-07-27 00.23.13.824 Closing connection.
. 2024-07-27 00.23.13.824 Selecting events 0 for socket 1932
* 2024-07-27 00.23.13.856 (EFatal) **Connection has been unexpectedly closed.** Server sent command exit status 1.
* 2024-07-27 00.23.13.856 Error skipping startup message. Your shell is probably incompatible with the application (BASH is recommended).

A linha

! 2024-07-27 00.23.13.824 su: must be run from a terminal

Indique um problema!?

Meu script é invocado através de um plugin NSS ( libnss-ato)

--EDITAR 2--

Depois de usar uma suversão do util-linux que tem uma --ptyopção, o Winscp parece travar! registros:

< 2024-08-02 15.00.55.772 tani1@sys7-vm81B$ echo "WinSCP: this is end-of-file:0"
. 2024-08-02 15.00.55.772 Read 31 bytes (18 pending)
< 2024-08-02 15.00.55.772 WinSCP: this is end-of-file:0
. 2024-08-02 15.00.55.772 Read 18 bytes (0 pending)
. 2024-08-02 15.00.55.772 Waiting for another 1 bytes
. 2024-08-02 15.00.55.772 Looking for incoming data
. 2024-08-02 15.00.55.772 Looking for network events
. 2024-08-02 15.01.12.135 Timeout waiting for network events
. 2024-08-02 15.01.12.135 Waiting for data timed out, asking user what to do.
. 2024-08-02 15.01.12.135 Asking user:
. 2024-08-02 15.01.12.135 **Host is not communicating for 15 seconds.
. 2024-08-02 15.01.12.135 
. 2024-08-02 15.01.12.135 Wait for another 15 seconds?** ()

Tenho um problema estranho que começou a acontecer há algumas semanas e simplesmente não consigo descobrir. Quando tento usar o RDP para acessar qualquer máquina na mesma sub-rede da minha estação de trabalho, ele falha com um erro que diz que minhas credenciais não são boas. Isso só acontece se eu acessar a máquina pelo nome. Se eu acessar por endereço IP, ele se conecta bem. Posso me conectar com minha conta principal a máquinas em outras sub-redes, através da VPN, sem problemas também. O que torna tudo ainda mais estranho é que, se eu executar ping na máquina pelo nome, ela retornará o IP correto. Minha conta é uma conta de administrador de domínio e isso só acontece com meu login ou perfil principal. Se eu mudar para outra conta de administrador de domínio, ela se conectará perfeitamente pelo nome da máquina. Além disso, se eu fizer login na máquina diretamente no servidor usando minha conta principal, também não há problema. Eu me pergunto se é um problema de AD. Alguém tem alguma ideia de qual pode ser o problema?

Não tenho certeza se esta pergunta é mais adequada para ser feita aqui, no Super User ou no Unix Exchange, mas este me pareceu o melhor fórum.

Estou acostumado a virtualizar várias VMs em um único host. Tenho um pequeno cluster odroid N2+ em minha casa e estou curioso para saber se consigo de alguma forma produzir um único sistema operacional que rode em mais de um nó. Por exemplo, para executar um aplicativo que consome mais do que os 4 GB de RAM disponíveis por nó.

Encontrei o hadoop e o MPI, mas ambos parecem ser modelos de programação, não ferramentas para virtualizar sistemas operacionais. Também nunca ouvi falar de nada semelhante em KVM, VirtualBox, VMWare ou QEMU.

Há alguma maneira de fazer isso?

Talvez em outras palavras o que eu quero perguntar é: existe algo como uma implementação MPI do Linux? Ou isso é uma fantasia sonhada apenas pelos totalmente perturbados?

Tenho três servidores, totalmente conectados via wireguard. Eles executam o Ubuntu Server 22.04 e o cluster repmr postgresql com replicação de streaming.

Todos os computadores têm um endereço público, mas as instâncias do PostgreSQL e os clientes de banco de dados usam os endereços internos (na VPN wireguard).

Em um dos computadores, vejo isto nos logs:

2024-07-26 07:23:14.463 UTC [147915] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 07:25:56.242 UTC [148509] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 07:28:17.567 UTC [148818] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 07:33:13.234 UTC [149090] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 07:48:42.721 UTC [149723] FATAL:  terminating walreceiver due to timeout
2024-07-26 07:52:17.298 UTC [151521] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 08:01:25.141 UTC [151889] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 08:02:16.337 UTC [152868] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 08:06:13.169 UTC [152951] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly
2024-07-26 08:22:04.180 UTC [153377] FATAL:  could not receive data from WAL stream: server closed the connection unexpectedly

Além disso, quando tento conectar-me ao banco de dados primário a partir de um programa Go ou Python, às vezes vejo "tempo limite de conexão" ou "redefinição de conexão por peer", "a conexão foi fechada no meio da operação" e mensagens semelhantes. É importante observar que isso acontece apenas em um computador e não nos outros.

No lado do servidor (postgresql primário), vejo isso nos logs:

2024-07-26 12:31:36.667 UTC [3778655] telegraf@telegraf LOG:  could not receive data from client: Connection reset by peer
2024-07-26 12:31:36.897 UTC [3777638] telegraf@telegraf LOG:  could not receive data from client: Connection reset by peer
2024-07-26 12:31:39.462 UTC [3775606] telegraf@telegraf LOG:  could not receive data from client: Connection reset by peer
2024-07-26 12:31:39.480 UTC [3780628] telegraf@telegraf LOG:  could not receive data from client: Connection reset by peer

Esses erros acontecem apenas algumas vezes por hora. É o suficiente para tornar meus aplicativos não confiáveis, mas eles são intermitentes. Executei este teste de ping entre os endereços públicos:

ping -c 3600 primary.public.com
# waited an hour...
--- primary.public.com ping statistics ---
3600 packets transmitted, 3600 received, 0% packet loss, time 3603052ms
rtt min/avg/max/mdev = 72.849/73.214/101.325/0.881 ms

Também executei um teste de ping no endereço IP privado:

ping -c 1008 primary.private.com
# waited...
--- primary.private.com ping statistics ---
1008 packets transmitted, 783 received, 22.3214% packet loss, time 1013304ms
rtt min/avg/max/mdev = 80.742/91.383/256.720/16.133 ms

Em outras palavras, 22% dos pacotes de ping são perdidos no wireguard.

O valor MTU para todos os dispositivos wireguard é o padrão 1420.

3: dev0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.241.64.3/32 scope global dev0
       valid_lft forever preferred_lft forever

Também tentei testar o MTU usando este script:

size=1272
while ping -s $size -c1 -M do primary.internaladdress.com >&/dev/null; do 
  ((size+=4))
done
echo "Max MTU size: $((size-4+28))

E também imprimiu 1420.

E observe que o problema só existe entre dois computadores dos três. Por exemplo, é ruim entre A e B, mas é bom entre BC.

Deve-se notar que o computador problemático está longe (num continente diferente). Mas isso não deveria causar isso.

Pelo que entendi, o wireguard encapsula pacotes IP em pacotes UDP criptografados, e o protocolo TCP se encarrega de reenviar os pacotes perdidos.

É muito estranho que os pacotes IP entre endereços públicos tenham 0% de data de descarte, mas os pacotes wireguard/UDP tenham mais de 20%. É possível que pacotes UDP sejam descartados por algum roteador ou switch? Talvez QoS esteja acontecendo?

Esses servidores são alugados e ficam muito distantes um do outro. Obviamente, não posso fazer nada para eliminar a queda de pacotes. Entendo que o UDP sempre não será confiável. Mas me pergunto se posso consertar as conexões TCP de alguma forma. Mesmo que às vezes fiquem lentos (mesmo que não consigam se comunicar por um ou dois segundos), eles não devem reiniciar a conexão. Quais são minhas opções?

Estou no processo de atualização de máquinas do CentOS7 -> Rocky9. Fiz algumas dezenas com sucesso, mas tive um problema com o Dell R440 mais novo.

Quando o novo sistema operacional inicializa, recebo um erro no DRAC. Um erro fatal foi detectado em um componente no barramento 2, dispositivo 0, função 0.

Tentei substituir a placa principal, mas o problema persiste.

Isso é possível? (para um sistema operacional causar um (possível) erro de hardware)?

-- editar

Consegui reproduzir isso em vários R440s

Estou tentando instalar e configurar o servidor ISC DHCP no Debian 12 e . Mas continuo recebendo os seguintes erros no syslog.

Jul 26 13:42:38 3ecc1b69 dhcpd[774]: No subnet declaration for enp2s0 (no IPv4 addresses).
Jul 26 13:42:38 3ecc1b69 dhcpd[774]: ** Ignoring requests on enp2s0.  If this is not what
Jul 26 13:42:38 3ecc1b69 dhcpd[774]:    you want, please write a subnet declaration
Jul 26 13:42:38 3ecc1b69 dhcpd[774]:    in your dhcpd.conf file for the network segment
Jul 26 13:42:38 3ecc1b69 dhcpd[774]:    to which interface enp2s0 is attached. **
Jul 26 13:42:38 3ecc1b69 dhcpd[774]: 
Jul 26 13:42:38 3ecc1b69 dhcpd[774]: 
Jul 26 13:42:38 3ecc1b69 dhcpd[774]: Not configured to listen on any interface

Abaixo estão os arquivos de configuração

dhcpd.conf

  subnet 192.168.1.0 netmask 255.255.255.0 {
        range 192.168.1.100 192.168.1.200;
        option routers 192.168.1.1;
        option domain-name-servers 192.168.1.1;
        option subnet-mask 255.255.255.0;
    }

interfaces

    source /etc/network/interfaces.d/*
    auto lo
    iface lo inet loopback
    
  


  allow-hotplug enp2s0
    iface enp2s0 static
        address 192.168.1.1
        netmask 255.255.255.0

servidor isc-dhcp

INTERFACESv4="enp2s0"
INTERFACESv6="enp2s0"

A tentativa de iniciar o servidor produz esta saída

    Job for isc-dhcp-server.service failed because the control process exited with error code.
    See "systemctl status isc-dhcp-server.service" and "journalctl -xeu isc-dhcp-server.service" for details.


systemctl status isc-dhcp-server.service provides this output

isc-dhcp-server.service - LSB: DHCP server
         Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)
         Active: failed (Result: exit-code) since Fri 2024-07-26 16:11:23 EEST; 57s ago
           Docs: man:systemd-sysv-generator(8)
        Process: 1290 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
            CPU: 39ms
    
    Jul 26 16:11:21 3ecc1b69 systemd[1]: Starting isc-dhcp-server.service - LSB: DHCP server...
    Jul 26 16:11:21 3ecc1b69 isc-dhcp-server[1290]: Launching IPv4 server only.
    Jul 26 16:11:23 3ecc1b69 isc-dhcp-server[1290]: Starting ISC DHCPv4 server: dhcpdcheck syslog for diagnostics. ... failed!
    Jul 26 16:11:23 3ecc1b69 isc-dhcp-server[1290]:  failed!
    Jul 26 16:11:23 3ecc1b69 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited, status=1/FAILURE
    Jul 26 16:11:23 3ecc1b69 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
    Jul 26 16:11:23 3ecc1b69 systemd[1]: Failed to start isc-dhcp-server.service - LSB: DHCP server.

Onde estão os possíveis locais para configurar o K8S usando um proxy, pois ele repete "proxyconnect tcp: dial tcp 127.0.0.1:1082: connect: connection declared" durante a configuração do Ray Cluster?

Siga as instruções do Ray CLuster quickstart :

helm repo add kuberay https://ray-project.github.io/kuberay-helm/
helm repo update

# Install both CRDs and KubeRay operator v1.1.1.
helm install kuberay-operator kuberay/kuberay-operator --version 1.1.1

# Confirm that the operator is running in the namespace `default`.
kubectl get pods
# NAME                                READY   STATUS    RESTARTS   AGE
# kuberay-operator-7fbdbf8c89-pt8bk   1/1     Running   0          27s 

no passo 2. Eu obtenho um ErrImagePullpod de status e a saída real:

(base) ➜  ~ helm install kuberay-operator kuberay/kuberay-operator --version 1.0.0                                                                                                                     [36/197]
NAME: kuberay-operator                                                                                                                                                                                         
LAST DEPLOYED: Fri Jul 26 08:56:30 2024                                                                                                                                                                        
NAMESPACE: default                                                                                                                                                                                             
STATUS: deployed                                                                                                                                                                                               
REVISION: 1
TEST SUITE: None        
(base) ➜  ~ kubectl get pods                                                                           
NAME                                READY   STATUS         RESTARTS   AGE
kuberay-operator-5d64d88fdb-shrkv   0/1     ErrImagePull   0          10s
(base) ➜  ~ kubectl describe pod kuberay-operator-5d64d88fdb-shrkv 
Name:             kuberay-operator-5d64d88fdb-shrkv 
Namespace:        default              
Priority:         0                
Service Account:  kuberay-operator                                                                     
Node:             kind-control-plane/172.23.0.2                                                        
Start Time:       Fri, 26 Jul 2024 08:56:31 +0800
Labels:           app.kubernetes.io/component=kuberay-operator    
                  app.kubernetes.io/instance=kuberay-operator     
                  app.kubernetes.io/name=kuberay-operator                                                                                                                                                      
                  pod-template-hash=5d64d88fdb         
.....
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  22s               default-scheduler  Successfully assigned default/kuberay-operator-5d64d88fdb-shrkv to kind-control-plane
  Normal   BackOff    21s               kubelet            Back-off pulling image "kuberay/operator:v1.0.0"
  Warning  Failed     21s               kubelet            Error: ImagePullBackOff
  Normal   Pulling    6s (x2 over 21s)  kubelet            Pulling image "kuberay/operator:v1.0.0"
  Warning  Failed     6s (x2 over 21s)  kubelet            Failed to pull image "kuberay/operator:v1.0.0": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/kuberay/operator:v1.0.0"
: failed to resolve reference "docker.io/kuberay/operator:v1.0.0": failed to do request: Head "https://registry-1.docker.io/v2/kuberay/operator/manifests/v1.0.0": proxyconnect tcp: dial tcp 127.0.0.1:1082: connect: connection refused
  Warning  Failed     6s (x2 over 21s)  kubelet            Error: ErrImagePull

A questão do quebra-cabeça é a mensagem: proxyconnect tcp: dial tcp 127.0.0.1:1082: connect: conexão recusada

Tentei as seguintes maneiras, mas não encontrei nenhuma configuração de proxy:

(base) ➜  ~  echo $HTTP_PROXY

(base) ➜  ~  echo $HTTPS_PROXY

(base) ➜  ~ cat /etc/environment                 
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
(base) ➜  ~ cat /etc/docker/daemon.json 
{
    "registry-mirrors": [
        "https://5wxalzzb.mirror.aliyuncs.com",    
        "https://hub-mirror.c.163.com",
        "https://mirror.iscas.ac.cn",
        "https://docker.m.daocloud.io"
    ],
    "runtimes": {
        "nvidia": {
            "args": [],
            "path": "nvidia-container-runtime"
        }
    }
}

Para atenuar o problema do pod, iniciei a porta local 1082, que é um proxy HTTP sem AuthZ e AuthN, e então reinstalei o kuberay/operator novamente, mas a mesma mensagem de erro de evento para o proxy.

Minha equipe tem tentado armazenar muitos objetos pequenos (aproximadamente 10kB) usando a classe de armazenamento AWS S3 Glacier e descobriu que isso está custando muito mais do que apenas armazenar os objetos na classe de armazenamento padrão.

Não está claro na página de preços do AWS S3 de onde vêm essas cobranças. A Calculadora de preços da AWS fornece mais informações, mas ainda carece de uma explicação para elas.

Por exemplo, para a classe de armazenamento S3 Glacier, a Calculadora de preços fornece os seguintes dados para armazenar 100 GB por mês com um tamanho médio de objeto de 10 KB:

Unit conversions
S3 Glacier Deep Archive Average Object Size: 10 KB x 9.5367432e-7 GB in a KB = 0.0000095367432 GB

Pricing calculations
100 GB per month / 0.0000095367432 GB average item size = 10,485,759.9605 unrounded number of objects
Round up by 1 (10485759.9605) = 10485760 number of objects
10,485,760 number of objects x 32 KB = 335,544,320.00 KB overhead
335,544,320.00 KB overhead / 1048576 KB in a GB = 320.00 GB overhead
320.00 GB overhead x 0.00099 USD = 0.3168 USD (Glacier Deep Archive storage overhead cost for metadata)
Glacier Deep Archive storage overhead cost: 0.3168 USD
10,485,760 number of objects x 8 KB = 83,886,080.00 KB overhead
83,886,080.00 KB overhead / 1048576 KB in a GB = 80.00 GB overhead
Tiered price for: 80.00 GB
80 GB x 0.023 USD = 1.84 USD
Total tier cost = 1.84 USD (S3 Standard storage overhead cost)
S3 Standard storage overhead cost: 1.84 USD
100 GB per month x 0.00099 USD = 0.099 USD (Glacier Deep Archive storage cost)
Glacier Deep Archive storage cost: 0.099 USD
0.3168 USD + 1.84 USD + 0.099 USD = 2.2558 USD (Total Glacier Deep Archive storage cost)
S3 Glacier Deep Archive cost (monthly): 2.26 USD

Estou lutando para entender isso.

Menciona "custos indiretos". A Internet sugere que este é o custo de armazenamento de metadados sobre os objetos armazenados. Mas por que 2 bits de metadados (um de 32 KB e outro de 8 KB)? Por que há cobrança pelo uso do Armazenamento Padrão quando estou armazenando na Classe Glacier?

Alguém poderia fornecer mais detalhes sobre esses custos adicionais? Ou indique-me a direção certa se perdi alguma coisa no AWS Docs?