0

I followed the setup instructions for k3s, and kubectl in this answer. I'm getting this error when I boot into KubeApps

An error occurred while fetching the catalog: Invalid GetAvailablePackageSummaries response from the plugin helm.packages: rpc error: code = Internal desc = Unable to fetch chart categories: pq: relation "charts" does not exist.

How can I resolve this error?

Picture of the Error

When I pull the logs, I see,

I0608 21:01:12.935502 1 root.go:32] asset-syncer has been configured with: server.Config{DatabaseURL:"kubeapps-postgresql:5432", DatabaseName:"assets", DatabaseUser:"postgres", DatabasePassword:"E0mn56sa5d", Debug:false, Namespace:"kubeapps", OciRepositories:[]string{}, TlsInsecureSkipVerify:false, FilterRules:"", PassCredentials:false, UserAgent:"asset-syncer/2.4.5 (kubeapps/2.4.5)", UserAgentComment:"kubeapps/2.4.5", GlobalReposNamespace:"kubeapps", KubeappsNamespace:"", AuthorizationHeader:"", DockerConfigJson:""}

Followed by,

Usage:
  asset-syncer sync [REPO NAME] [REPO URL] [REPO TYPE] [flags]

Flags:
  -h, --help                       help for sync
      --oci-repositories strings   List of OCI Repositories in case the type is OCI
      --version                    version for sync

Global Flags:
      --add_dir_header                   If true, adds the file directory to the header of the log messages
      --alsologtostderr                  log to standard error as well as files
      --database-name string             Name of the database to use (default "charts")
      --database-url string              Database URL (default "localhost:5432")
      --database-user string             Database user
      --debug                            verbose logging
      --filter-rules string              JSON blob with the rules to filter assets
      --global-repos-namespace string    Namespace for global repos (default "kubeapps")
      --log_backtrace_at traceLocation   when logging hits line file:N, emit a stack trace (default :0)
      --log_dir string                   If non-empty, write log files in this directory
      --log_file string                  If non-empty, use this log file
      --log_file_max_size uint           Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
      --logtostderr                      log to standard error instead of files (default true)
      --namespace string                 Namespace of the repository being synced
      --one_output                       If true, only write logs to their native severity level (vs also writing to each lower severity level)
      --pass-credentials                 pass credentials to all domains
      --skip_headers                     If true, avoid header prefixes in the log messages
      --skip_log_headers                 If true, avoid headers when opening log files
      --stderrthreshold severity         logs at or above this threshold go to stderr (default 2)
      --tls-insecure-skip-verify         Skip TLS verification
      --user-agent-comment string        UserAgent comment used during outbound requests
  -v, --v Level                          number for the log level verbosity (default 3)
      --vmodule moduleSpec               comma-separated list of pattern=N settings for file-filtered logging

As well as this errors,

Error: Error: Get https://charts.bitnami.com/bitnami/index.yaml: dial tcp: lookup charts.bitnami.com on 10.43.0.10:53: server misbehaving


I filed a bug upstream, but I'm not sure if this is a bug or a misconfiguration:

1 Answer 1

0

Upstream Answer -- Networking Problem.

Though I'm getting this on a fresh install I was guided to this which indicates a bigger problem,

kubectl -n kubeapps exec deployment/kubeapps -- curl -sI https://charts.bitnami.com/bitnami/index.yaml

this returns "command terminated with exit code 6".

I can further identify the problem with nslookup, without using Kube Apps by following the [k3s tutorial on troubleshooting dns]https://rancher.com/docs/rancher/v2.5/en/troubleshooting/dns/)

kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup www.google.com

Follow up

Now that I know what this problem is (with external DNS resolution), I've asked this question for more information Newly installed k3s cluster on fresh OS install can not resolve external domains, when the host can?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.