I installed the traffic-manager by using the official helm chart by datawire and flux components. But when i try to list interceptable services with telepresence list i get following message:
No Workloads (Deployments, StatefulSets, or ReplicaSets)
First i used the default namespace ambassador without further configurations. Then i tried to activate the RBCA users and restricted the namespaces. In the cluster are several namespaces with different purposes like flux-system, kube-system. Services, where i want to intercept, are deployed in the same namespace. Therefore i tried to install the traffic-manager directly into this namespace, but the same message occured (i also configured my kubeconfig, so the traffic-manager can be found, as the documentation says).
In the logs of the traffic-manager i get following warning:
agent-configs : Issuing a systema request without ApiKey or InstallID may result in an error
What does that mean? Could that be part of the issue?
I am new to cluster topics in general but couldn't find anything by research, hence i decided to ask in the community.
Some hints would be very helpful, because i don't know what i could try next. In the first place it would be enough when it works trough the whole cluster without restrictions.
telepresence version:
Client: v2.6.6 (api v3)
Root Daemon: v2.6.6 (api v3)
User Daemon: v2.6.6 (api v3)
kubernetes: v1.22.6
Related
We have our k8s cluster set up with our app, including a neo4j DB deployment and other artifacts. Overnight, we've started facing an issue in our GKE cluster when trying to enter or interact somehow with any pod running in the cluster. The following screenshot shows a sample of the error we get.
issued command
error: unable to upgrade connection: Authorization error (user=kube-apiserver, verb=create, resource=nodes, subresource=proxy)
Our GKE cluster is created as standard (no autopilot) and the versions are
Node pool details
cluster basics
As said before it was working fine regardless of the warning about the versions. However, we haven't been able yet to identify what could have changed between the last time it worked, and now.
Any clue on what authorization setup might have been changed making it incompatible now is very welcomed
I've got an issue, I'm trying to install linkerd on my cluster, all is going well
I went exactly with this official README
https://linkerd.io/2.11/tasks/install-helm/
installed it via helm
MacBook-Pro-6% helm list -n default
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
linkerd2 default 1 2021-12-15 15:47:10.823551 +0100 CET deployed linkerd2-2.11.1 stable-2.11.1
linkerd itself works, and the linkerd check command as well
MacBook-Pro-6% linkerd version
Client version: stable-2.11.1
Server version: stable-2.11.1
but when I try to install viz dashboard as described in the getting-started page I run
linkerd viz install | kubectl apply -f -
and when going with
linkerd check
...
Status check results are √
Linkerd extensions checks
=========================
/ Running viz extension check
and it keeps on checking the viz extensions, and when I ran linkerd dashboard (deprecated I know) shows the same error
Waiting for linkerd-viz extension to become available
anyone got any clue what I'm doing wrong ? Been stuck at this part for 2hrs &_& and noone seem to have any answers
note, when I ran, linkerd check after instalation of viz I get
linkerd-viz
-----------
√ linkerd-viz Namespace exists
√ linkerd-viz ClusterRoles exist
√ linkerd-viz ClusterRoleBindings exist
√ tap API server has valid cert
√ tap API server cert is valid for at least 60 days
‼ tap API service is running
FailedDiscoveryCheck: failing or missing response from https://10.190.101.142:8089/apis/tap.linkerd.io/v1alpha1: Get "https://10.190.101.142:8089/apis/tap.linkerd.io/v1alpha1": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
see https://linkerd.io/2.11/checks/#l5d-tap-api for hints
‼ linkerd-viz pods are injected
could not find proxy container for grafana-8d54d5f6d-cv7q5 pod
see https://linkerd.io/2.11/checks/#l5d-viz-pods-injection for hints
√ viz extension pods are running
× viz extension proxies are healthy
No "linkerd-proxy" containers found in the "linkerd" namespace
see https://linkerd.io/2.11/checks/#l5d-viz-proxy-healthy for hints
debugging
From your problem descripiton:
‼ linkerd-viz pods are injected
could not find proxy container for grafana-8d54d5f6d-cv7q5 pod
see https://linkerd.io/2.11/checks/#l5d-viz-pods-injection for hints
and:
MacBook-Pro-6% helm list -n default
I encountered a similar problem but with flagger pod rather than grafana pod (I didn't attempt to install grafana component like you did).
A side effect of my problem is this:
$ linkerd viz dashboard
Waiting for linkerd-viz extension to become available
Waiting for linkerd-viz extension to become available
Waiting for linkerd-viz extension to become available
... ## repeating for 5 minutes or so before popping up the dashboard in browser.
The cause for my problem turned out to be that I installed the viz extension into the linkerd namespace. It should belong to the linkerd-viz namespace.
Looking at your original problem description, it seems that you installed the control plane into the default namespace (as opposed to the linkerd namespace.) While you can use any namespace you want, the control plane must be in a separate namespace from the viz extension. Details can be seen in the discussion I wrote here:
https://github.com/linkerd/website/issues/1309
The operator is https://operatorhub.io/operator/keycloak-operator version 11.0.0.
The cluster is Kubernetes version 1.18.12.
I was able to follow the steps from OperatorHub.io to install the Operator Lifecycle Manager and the Keycloak "OperatorGroup" and "Subscription".
It took much longer than I was expecting (maybe 20 minutes?), but eventually the corresponding "ClusterServiceVersion" was created.
However, now when I try to use it by creating the following resource, it doesn't seem to be doing anything at all:
apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
name: example-keycloak
namespace: keycloak
labels:
app: sso
spec:
instances: 1
externalAccess:
enabled: true
extensions:
- https://github.com/aerogear/keycloak-metrics-spi/releases/download/1.0.4/keycloak-metrics-spi-1.0.4.jar
It accepts the new resource, so I know the CRD is in place. The documentation states that it should create a stateful set, an ingress, and more, but it just doesn't seem to create anything.
I checked the cluster logs and this is the error that is jumping out to me:
olm-operator ERROR controllers.operator Could not update Operator status {"request": "/keycloak-operator.my-keycloak-operator", "error": "Operation cannot be fulfilled on operators.operators.coreos.com \"keycloak-operator.my-keycloak-operator\": the object has been modified; please apply your changes to the latest version and try again"}
I have quite a bit of experience with plain kubernetes, but I'm brand new to "operators" and so I'm really not sure where to look next wrt what might be going wrong.
Any hints/suggestions/explanations?
UPDATE: I was creating the keycloak resource in a namespace OTHER than the one I installed the operator into. Since it allowed me to create the custom resource (Kind: Keycloak) into this namespace, I thought this was supported. However, when I created the keycloak resource to the same namespace where the operator was installed (my-keycloak-operator), then it actually tried to do something. Its still failing to bring up the pod, mind you, but at least its trying to do something.
Will leave this question open for a bit to see if the "Could not update Operator status" is something I should be concerned about or not...
It looks like the operator or/and the components that it wants to bring up cannot do a write (POST/PUT) to the kube-apiserver.
From what you describe, it appears that the first time when you installed the operator on a different namespace it just didn't have permissions to bring up anything at all. The second time when you installed it on the right namespace it looks like the operator was able to talk to the kube-apiserver but the components that it's bring up (Keycloak, etc) are not able to.
I would check the logs on the kube-apiserver (control plane) to see if you have some unauthorized requests, also check the log files of the components (pods, deployments, etc) that the operator is trying to bring up.
If you have unauthorized requests you may have to manually update the RBAC rules. Finally, I would check with IBM cloud to see what specific permission its K8s control plane could have that is preventing applications to talk to it (the kube-apiserver).
✌️
I'm using Kubernetes 1.11 on Digital Ocean, when I try to use kubectl top node I get this error:
Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)
but as stated in the doc, heapster is deprecated and no longer required from kubernetes 1.10
If you are running a newer version of Kubernetes and still receiving this error, there is probably a problem with your installation.
Please note that to install metrics server on kubernetes, you should first clone it by typing:
git clone https://github.com/kodekloudhub/kubernetes-metrics-server.git
then you should install it, WITHOUT GOING INTO THE CREATED FOLDER AND WITHOUT MENTIONING AN SPECIFIC YAML FILE , only via:
kubectl create -f kubernetes-metrics-server/
In this way all services and components are installed correctly and you can run:
kubectl top nodes
or
kubectl top pods
and get the correct result.
For kubectl top node/pod to work you either need the heapster or the metrics server installed on your cluster.
Like the warning says: heapster is being deprecated so the recommended choice now is the metrics server.
So follow the directions here to install the metrics server
I am running a kubernetes cluster on google cloud(version 1.3.5) .
I found a redis.yaml
that uses petset to create a redis cluster but when i run kubectl create -f redis.yaml i get the following error :
error validating "redis.yaml": error validating data: the server could not find the requested resource (get .apps); if you choose to ignore these errors, turn validation off with --validate=false
i cant find why i get this error or how to solve this.
PetSet is currently an alpha feature (which you can tell because the apiVersion in the linked yaml file is apps/v1alpha1). It may not be obvious, but alpha features are not supported in Google Container Engine.
As described in api_changes.md, alpha level API objects are disabled by default, have no guarantees that they will exist in future versions, can break compatibility with older versions at any time, and may destabilize the cluster.
I'm using PetSet with some success, for example https://github.com/Yolean/kubernetes-mysql-cluster, in zone europe-west1-d but when I tried europe-west1-c I got the aforementioned error.
Google just enabled Alpha Clusters for GKE as announced here: https://cloud.google.com/container-engine/docs/alpha-clusters
Now you are able (but not SLA covered) to use all alpha features within an alpha cluster, what was disable previously.