KubeApps: Invalid GetAvailablePackageSummaries response from the plugin helm.packages: ... Unable to fetch chart categories



  • I followed the https://devops.stackexchange.com/a/16109/18965 . 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:

    • https://github.com/vmware-tanzu/kubeapps/issues/4882#issue-1265184794


  • 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 https://devops.stackexchange.com/questions/16161/newly-installed-k3s-cluster-on-fresh-os-install-can-not-resolve-external-domains


Log in to reply
 


Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2