Por que o CoreOS não inicia o etcd2 automaticamente, mesmo que o meu cloud-config o diga?

Navegue suas respostas
2

Estou executando o CoreOS beta 991.1.0 em uma instância do Google Compute Engine, na qual o cloud-config é configurado por meio da variável user_data metadata. Minha configuração da nuvem é assim: 

#cloud-config
write_files:
  - path: "/etc/kubernetes/kube.conf"
    permissions: "0644"
    owner: "root"
    content: |
      apiVersion: v1
      kind: Config
      clusters:
      - name: kube
        cluster:
          server: https://127.0.0.1:443
          certificate-authority: /etc/kubernetes/ssl/ca.pem
      users:
      - name: kubelet
        user:
          client-certificate: /etc/kubernetes/ssl/master-client.pem
          client-key: /etc/kubernetes/ssl/master-client-key.pem
      contexts:
      - context:
          cluster: kube
          user: kubelet
ssh_authorized_keys:
  - "SECRET"
coreos:
  etcd2:
    discovery: https://discovery.etcd.io/106b575a45f2abefdaea40ebba4d0d84
    initial-advertise-peer-urls: https://$private_ipv4:2380
    listen-peer-urls: https://$private_ipv4:2380
    listen-client-urls: https://0.0.0.0:2379
    advertise-client-urls: https://$private_ipv4:2379
  units:
    - name: etcd2.service
      command: start
      drop-ins:
        - name: 30-certificates.conf
          content: |
            [Service]
            # Client Env Vars
            Environment=ETCD_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem
            Environment=ETCD_CERT_FILE=/etc/kubernetes/ssl/master-client.pem
            Environment=ETCD_KEY_FILE=/etc/kubernetes/ssl/master-client-key.pem
            # Peer Env Vars
            Environment=ETCD_PEER_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem
            Environment=ETCD_PEER_CERT_FILE=/etc/kubernetes/ssl/master-peer.pem
            Environment=ETCD_PEER_KEY_FILE=/etc/kubernetes/ssl/master-peer-key.pem
    - name: fleet.service
      command: start
    - name: swap.service
      command: start
      content: |
        [Unit]
        Description=Turn on swap

        [Service]
        Type=oneshot
        Environment="SWAPFILE=/swap"
        RemainAfterExit=true
        ExecStartPre=/usr/sbin/losetup -f $SWAPFILE
        ExecStart=/usr/bin/sh -c "/sbin/swapon $(/usr/sbin/losetup -j $SWAPFILE | /usr/bin/cut -d : -f 1)"
        ExecStop=/usr/bin/sh -c "/sbin/swapoff $(/usr/sbin/losetup -j $SWAPFILE | /usr/bin/cut -d : -f 1)"
        ExecStopPost=/usr/bin/sh -c "/usr/sbin/losetup -d $(/usr/sbin/losetup -j $SWAPFILE | /usr/bin/cut -d : -f 1)"

        [Install]
        WantedBy=local.target

No entanto, mesmo que eu tenha configurado o etcd2 para iniciar na inicialização, isso não acontece. Por que o etcd2 não é iniciado automaticamente?

    
por aknuds1 29.03.2016 / 16:27

1 resposta

1

O erro foi tão simples quanto nomear a variável de metadados do GCE user_data , enquanto deveria ser user-data . Eu queria que fosse mais fácil de depurar embora ...

    
por 29.03.2016 / 16:42

Tags

O Google Cloud altera as chaves ssh do servidor automaticamente? nginx faz o download do arquivo vazio quando solicitado na porta 80 (em vez de redirecionar para a porta 443)