Início / user-996840

best_of_man's questions

Martin Hope
best_of_man
Asked: 2023-02-07 21:41:21 +0800 CST
  • 6

Estou tentando descobrir qual tipo de dados é melhor para armazenar dados de tempo dentro do banco de dados MySQL ou Cassandra para um grande aplicativo como Facebook ou Instagram? Existem muitas perguntas e respostas semelhantes, mas não consegui finalmente perceber qual é a melhor escolha.

Então, decidi fazer essa pergunta para ver se alguém sabe que tipo de dados os aplicativos gigantes usam para armazenar seus dados de tempo?

  1. TIMESTAMP
  2. DATA HORA
  3. UNIX TIMESTAMP
mysql
Martin Hope
best_of_man
Asked: 2023-02-07 12:57:38 +0800 CST
  • 7

Estou escrevendo um aplicativo TypeScript-NodeJS e desejo manipular object ids e created_at TIMESTAMPno aplicativo NodeJS, em vez de usar MySQL ou Cassandra integrado UUIDou TIMESTAMPgerador.

1- Antes de mais nada, gostaria de saber se é uma boa ideia gerar ide created_atvalores dentro de um aplicativo de servidor da Web, em vez de permitir que os bancos de dados os gerem?

2- Em segundo lugar, quero saber se eu uso as funções internas do banco de dados como uuid()ou toTimestamp(now())no Cassandra e UUID_TO_BIN(UUID())no MySQL, isso adicionará mais sobrecarga/latência ao meu aplicativo em comparação com o uso da biblioteca NodeJS uuid () ?

mysql
Martin Hope
best_of_man
Asked: 2023-01-17 15:40:22 +0800 CST
  • 7

Eu tenho um arquivo Skaffold como este:


apiVersion: skaffold/v4beta1
kind: Config
build:
  artifacts:
  - image: app/auth
    context: auth
    sync:
      manual:
      - src: src/**/*.ts
        dest: .
    docker:
      dockerfile: Dockerfile

E deploymantarquivos como o seguinte:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auth
  template:
    metadata:
      labels:
        app: auth
    spec:
      containers:
        - name: auth
          image: app/auth
          env:
            - name: MONGO_URI
              value: 'mongodb://auth-mongo-srv:27017/auth'
            - name: JWT_KEY
              valueFrom:
                secretKeyRef:
                  name: jwt-secret
                  key: JWT_KEY

---
apiVersion: v1
kind: Service
metadata:
  name: auth-srv
spec:
  selector:
    app: auth
  ports:
    - name: auth
      protocol: TCP
      port: 3000
      targetPort: 3000

Com um Dockerfilelike abaixo:


FROM node:alpine

WORKDIR /app
COPY package.json .
RUN npm install --only=prod
COPY . .

CMD ["npm", "start"]

Mas depois de executar, skaffold devvejo uma lista de imagens docker como esta:

REPOSITORY                       TAG                                                                IMAGE ID       CREATED             SIZE
app/auth               429eadf4af2ad66af9f364eb3cfe8926e05276c4f579fe39c5112e3201b1e4ac   429eadf4af2a   15 minutes ago      345MB
app/auth               latest                                                             429eadf4af2a   15 minutes ago      345MB

É normal ter 2 imagens diferentes para cada container?

docker
Martin Hope
best_of_man
Asked: 2022-12-30 10:48:04 +0800 CST
  • 5

Estou tentando implantar Cassandrano meu Kindcluster local em execução na minha Ubuntu 22.04máquina. A única instrução que encontrei é this , que usa a StatefulSetpara isso. Estou apenas querendo saber, um Deploymentarquivo não é algo mais recente? Por que eles não usaram Deploymentarquivo em vez de StatefulSet? Se for melhor usar um Deploymentarquivo, alguém pode me ajudar a converter isso StatefulSetem um Deploymentarquivo?

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cassandra
  labels:
    app: cassandra
spec:
  serviceName: cassandra
  replicas: 3
  selector:
    matchLabels:
      app: cassandra
  template:
    metadata:
      labels:
        app: cassandra
    spec:
      terminationGracePeriodSeconds: 1800
      containers:
      - name: cassandra
        image: gcr.io/google-samples/cassandra:v13
        imagePullPolicy: Always
        ports:
        - containerPort: 7000
          name: intra-node
        - containerPort: 7001
          name: tls-intra-node
        - containerPort: 7199
          name: jmx
        - containerPort: 9042
          name: cql
        resources:
          limits:
            cpu: "500m"
            memory: 1Gi
          requests:
            cpu: "500m"
            memory: 1Gi
        securityContext:
          capabilities:
            add:
              - IPC_LOCK
        lifecycle:
          preStop:
            exec:
              command: 
              - /bin/sh
              - -c
              - nodetool drain
        env:
          - name: MAX_HEAP_SIZE
            value: 512M
          - name: HEAP_NEWSIZE
            value: 100M
          - name: CASSANDRA_SEEDS
            value: "cassandra-0.cassandra.default.svc.cluster.local"
          - name: CASSANDRA_CLUSTER_NAME
            value: "K8Demo"
          - name: CASSANDRA_DC
            value: "DC1-K8Demo"
          - name: CASSANDRA_RACK
            value: "Rack1-K8Demo"
          - name: POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
        readinessProbe:
          exec:
            command:
            - /bin/bash
            - -c
            - /ready-probe.sh
          initialDelaySeconds: 15
          timeoutSeconds: 5
        # These volume mounts are persistent. They are like inline claims,
        # but not exactly because the names need to match exactly one of
        # the stateful pod volumes.
        volumeMounts:
        - name: cassandra-data
          mountPath: /cassandra_data

  # These are converted to volume claims by the controller
  # and mounted at the paths mentioned above.
  # do not use these in production until ssd GCEPersistentDisk or other
  # ssd pd
  volumeClaimTemplates:
  - metadata:
      name: cassandra-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: fast
      resources:
        requests:
          storage: 1Gi
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: k8s.io/minikube-hostpath
parameters:
  type: pd-ssd
kubernetes
Martin Hope
best_of_man
Asked: 2022-12-15 15:46:25 +0800 CST
  • 6

Eu instalei kubelet 1.26.0no Ubuntu 22.04 usando apt install kubeleto comando, mas quando tento journalctl -xeu kubeletobtenho o seguinte resultado:

░░ 
░░ The unit kubelet.service has entered the 'failed' state with result 'exit-code'.
Dec 14 15:41:16 a systemd[1]: kubelet.service: Scheduled restart job, restart counter is at 86.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ Automatic restarting of the unit kubelet.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Dec 14 15:41:16 a systemd[1]: Stopped kubelet: The Kubernetes Node Agent.
░░ Subject: A stop job for unit kubelet.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ A stop job for unit kubelet.service has finished.
░░ 
░░ The job identifier is 26301 and the job result is done.
Dec 14 15:41:16 a systemd[1]: Started kubelet: The Kubernetes Node Agent.
░░ Subject: A start job for unit kubelet.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ A start job for unit kubelet.service has finished successfully.
░░ 
░░ The job identifier is 26301.
Dec 14 15:41:16 a kubelet[18015]: Flag --pod-infra-container-image has been deprecated, will be removed in 1.27. Image garbage collector will get sandbox image information from CRI.
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.367525   18015 server.go:198] "--pod-infra-container-image will not be pruned by the image garbage collector in kubelet and should also be set in the rem>
Dec 14 15:41:16 a kubelet[18015]: Flag --pod-infra-container-image has been deprecated, will be removed in 1.27. Image garbage collector will get sandbox image information from CRI.
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.371255   18015 server.go:412] "Kubelet version" kubeletVersion="v1.26.0"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.371272   18015 server.go:414] "Golang settings" GOGC="" GOMAXPROCS="" GOTRACEBACK=""
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.371499   18015 server.go:836] "Client rotation is on, will bootstrap in background"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.372757   18015 certificate_store.go:130] Loading cert/key pair from "/var/lib/kubelet/pki/kubelet-client-current.pem".
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.373608   18015 dynamic_cafile_content.go:157] "Starting controller" name="client-ca-bundle::/etc/kubernetes/pki/ca.crt"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399357   18015 server.go:659] "--cgroups-per-qos enabled, but --cgroup-root was not specified.  defaulting to /"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399717   18015 container_manager_linux.go:267] "Container manager verified user specified cgroup-root exists" cgroupRoot=[]
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399832   18015 container_manager_linux.go:272] "Creating Container Manager object based on Node Config" nodeConfig={RuntimeCgroupsName: SystemCgroupsName>
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399866   18015 topology_manager.go:134] "Creating topology manager with policy per scope" topologyPolicyName="none" topologyScopeName="container"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399883   18015 container_manager_linux.go:308] "Creating device plugin manager"
Dec 14 15:41:16 a kubelet[18015]: I1214 15:41:16.399940   18015 state_mem.go:36] "Initialized new in-memory state store"
Dec 14 15:41:16 a kubelet[18015]: E1214 15:41:16.402173   18015 run.go:74] "command failed" err="failed to run Kubelet: validate service connection: CRI v1 runtime API is not implemented for endpoint \">
Dec 14 15:41:16 a systemd[1]: kubelet.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ An ExecStart= process belonging to unit kubelet.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.
Dec 14 15:41:16 a systemd[1]: kubelet.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ The unit kubelet.service has entered the 'failed' state with result 'exit-code'.
lines 2547-2600/2600 (END)

Não sei qual é o problema e como posso me livrar dele?

configuration
Martin Hope
best_of_man
Asked: 2022-12-15 14:23:35 +0800 CST
  • 7

Estou tentando fazer sudo kubeadm initisso kubeadm 1.26.0em uma máquina Ubuntu 22.04. Mas obtenho o seguinte resultado:

[init] Using Kubernetes version: v1.26.0
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [a kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.1.2]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [a localhost] and IPs [192.168.1.2 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [a localhost] and IPs [192.168.1.2 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp 127.0.0.1:10248: connect: connection refused.

Unfortunately, an error has occurred:
    timed out waiting for the condition

This error is likely caused by:
    - The kubelet is not running
    - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
    - 'systemctl status kubelet'
    - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI.
Here is one example how you may list all running Kubernetes containers by using crictl:
    - 'crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps -a | grep kube | grep -v pause'
    Once you have found the failing container, you can inspect its logs with:
    - 'crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
To see the stack trace of this error execute with --v=5 or higher
domain-name-system