Istio on GKE - Admission webhook not working to inject sidecar-porxy - kubernetes

I have been trying to set up Istio on my existing GKE cluster.
I hev followed the steps mentioned on the Istio website for the installation - prerequisite.
https://istio.io/latest/docs/setup/platform-setup/gke/
I have a private cluster so I added the firewall rule mention in the prerequisite.
gke-aiq-kubernetes-0a227ee8-all default INGRESS 1000 tcp,udp,icmp,esp,ah,sctp False
gke-aiq-kubernetes-0a227ee8-master default INGRESS 1000 tcp:10250,tcp:443,tcp:15017 False
gke-aiq-kubernetes-0a227ee8-vms default INGRESS 1000 tcp:1-65535,udp:1-65535,icmp False
and then install the istio with the demo profile.
istioctl install --set profile=demo
and then verify the intallation
istioctl verify-install
Which says everything is succeeded.
I labeled by namecpace "instio-inject=enabled" so that I will automatically get the sidecar porxy injected.
But when I trying to deploy something in the namespace I am getting following error:
Error from server (InternalError): error when creating "pod-pending.yaml": Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istiod.istio-system.svc:443/inject?timeout=30s: context deadline exceeded
What I understand from this is that there is some connectivity issue, but I am not sure how to debug this.
I tried the debugging page from istio:
https://github.com/istio/istio/wiki/Troubleshooting-Istio#diagnostics
and after running the command:
kubectl get --raw /api/v1/namespaces/istio-system/services/https:istiod:https-webhook/proxy/inject -v4
I am conformend that this is connectivity issue:
t -v5
I1113 23:20:11.241079 40356 helpers.go:199] server response object: [{
"metadata": {},
"status": "Failure",
"message": "the server is currently unable to handle the request",
"reason": "ServiceUnavailable",
"details": {
"causes": [
{
"reason": "UnexpectedServerResponse",
"message": "Error trying to reach service: 'dial tcp 10.48.3.25:15017: i/o timeout'"
}
]
},
"code": 503
}]
F1113 23:20:11.241367 40356 helpers.go:114] Error from server (ServiceUnavailable): the server is currently unable to handle the request
Need help, I am new to GKE.

I figured out the issue.
I have 7 different GCP projects configured with my gcloud profile and I was in a different project while running the gcloud command. (all gke clusters have the same name)
Steps from the command line:
I logged in to the GCP UI from the browser search the firewall under VPC and opened the ports manually there and it worked.
gcloud compute firewall-rules list --filter="name~gke-<clustername>-[0-9a-z]*-master"
Then get the firewall rule name.
gcloud compute firewall-rules update <firewall rule name> --allow tcp:10250,tcp:443,tcp:15017
The idea here is to add the tcp:15017 which is required by the admission hook.

Related

Kubernetes unable to create impersonator account timeout

Hosting: Azure centos VM's running RKE1
Rancher Version: v2.6.2
Kubernetes Version: 1.18.6
Looking for help diagnosing this issue; I get two error messages
From Rancher:
Cluster health check failed: Failed to communicate with API server during namespace check: Get "https://<NODE_IP>:6443/api/v1/namespace/kube-system?timeout=45s": write tcp 172.16.0.2:443 -> <NODE_IP>:7832:i/o timeout
From Kubectl:
unable to create impersonator account: error setting up impersonation for user user-sd7q9: Put "https://<NODE_IP>:6443/apis/rbac.authorization.k8s.io/v1/clusterroles/cattle-impersonation-user-sd7q9": write tcp 172.17.0.2:443-> <NODE_IP>:7832: i/o timeout
Nothing appears to be broken and my applications are still available via ingress.
https://github.com/rancher/rancher/issues/34671

Error install istio in GKE = the server could not find the requested resource (post `gatewaies.networking.istio.io`)

I have the following error when installing istio in GKE
kubernetes ver = 1.11.2-gke.18
Istio ver = 1.0.4
Kubectl = latest from repo google
Error from server (NotFound): error when creating
"`install/kubernetes/istio-demo-auth.yaml`":
the server could not find the requested resource
(post `gatewaies.networking.istio.io`)
I have tried to follow the tutorial on GCP:
https://cloud.google.com/kubernetes-engine/docs/tutorials/installing-istio
You are missing the CustomResourceDefinition required by istio and hence getting this error. You need to apply following command from istio folder:
kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml
This will create all the CRD's like virtualservice, destinationrules etc.
Try following official documentation of Istio to install it on GKE:
https://istio.io/docs/setup/kubernetes/quick-start-gke-dm/
I am also getting this issue when installing a custom Istio helm chart:
[tiller] 2019/11/15 21:50:52 failed install perform step: release test failed: the server could not find the requested resource (post gatewaies.networking.istio.io)
I've confirmed the Istio CRDs are installed properly. Note how the installed Gateway CRD explicitly notes the accepted plural name:
status:
acceptedNames:
categories:
- istio-io
- networking-istio-io
kind: Gateway
listKind: GatewayList
plural: gateways
shortNames:
- gw
singular: gateway
I created an issue on Helm to see if that is the culprit, otherwise, I can open an issue on Istio to see if that is either. I'm very confused where the source of this issue could be coming from.
**Note: ** The type of the Gateway resource is correct:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
istio works by defining a series of crds(Custom Resource Definition), for istio to work, you first need to run command like this:
kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml
for my version(istio v1.2.0), the command is
for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -f $i; done
but as I follow the instructions from the documentatino, I still get the annoying messages:
Error from server (NotFound): error when creating "samples/bookinfo/networking/bookinfo-gateway.yaml": the server could not find the requested resource (post gatewaies.networking.istio.io)
as the hint implies, the requested resource "gatewaies.networking.istio.io" cannot be found, and then I list the crds:
kubectl get crd
and I got a list like this:
enter image description here
as I see inspect this, I find something wrong.
the message issued by kubectl is (post gatewaies.networking.istio.io), but the crd enlisted is post gateways.networking.istio.io, then everything is clear, the kubectl CLI issued a wrong plural for word "gateway", the correct form is gateways, instead of gatewaies, so to satisfy the command form, the crd must change.
And I edit this file:
vim install/kubernetes/helm/istio-init/files/crd-10.yaml
by changing the name from "gateways.networking.istio.io" to "gatewaies.networking.istio.io", everything is ok now.

Not able to access app deployed on kubernetes cluster

I am getting following error while accessing the app deployed on Azure kubernetes service
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
"reason": "Forbidden",
"details": {},
"code": 403
}
I have followed all steps as given here https://learn.microsoft.com/en-us/azure/aks/tutorial-kubernetes-prepare-app
I know that this is something to do with authentication and RBAC, but i don't know what exactly is wrong and where should i make changes.
Just follow the steps in the link you posted. You will be successful in finishing that. The destination of each step below:
Create the image and make sure it can work without any error.
Create an Azure Container Registry and push the image into the registry.
Create a Service Principal for the AKS to let it just can pull the image from the registry.
Change the yaml file and make it pull the image from the Azure Registry, then crate pods in the AKS nodes.
You just need these four steps to run the application on AKS. Then get the IP address through the command kubectl get service azure-vote-front --watch like the step 4. If you can not access the application, check your steps carefully again.
Also, you can check all the pods status through the command kubectl describe pods or one pod with kubectl describe pod podName.
Update
I test with the image you provide and the result here:
And you can get the service information and know which port you should use to browse.

User "system:anonymous" cannot get path "/"

I just setup a kubenetes cluster base on this link https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#multi-platform
I check with kubectl get nodes, then the master node is Ready, but when I access to the link https://k8s-master-ip:6443/
it show the error: User "system:anonymous" cannot get path "/".
What is the trick I am missing ?
Hope you see something like this:
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
"reason": "Forbidden",
"details": {
},
"code": 403
}
This is good as not everyone should be able to access the cluster, if you want to see the services run "kubectl proxy", this should enable access to the services from the outside world.
C:\dev1> kubectl proxy
Starting to serve on 127.0.0.1:8001
And when you hit 127.0.0.1:8001 you should see the list of services.
The latest kubernetes deployment tools enable RBAC on the cluster. Jenkins is relegated to the catch-all user system:anonymous when it accesses https://192.168.70.94:6443/api/v1/.... This user has almost no privileges on kube-apiserver.
The bottom-line is, Jenkins needs to authenticate with kube-apiserver - either with a bearer token or a client cert that's signed by the k8s cluster's CA key.
Method 1. This is preferred if Jenkins is hosted in the k8s cluster:
Create a ServiceAccount in k8s for the plugin
Create an RBAC profile (ie. Role/RoleBinding or ClusterRole/ClusterRoleBinding) that's tied to the ServiceAccount
Config the plugin to use the ServiceAccount's token when accessing the URL https://192.168.70.94:6443/api/v1/...
Method 2. If Jenkins is hosted outside the k8s cluster, the steps above can still be used. The alternative is to:
Create a client cert that's tied to the k8s cluster's CA. You have to find where the CA key is kept and use it to generate a client cert.
Create an RBAC profile (ie. Role/RoleBinding or ClusterRole/ClusterRoleBinding) that's tied to the client cert
Config the plugin to use the client cert when accessing the URL https://192.168.70.94:6443/api/v1/...
Both methods work in any situation. I believe Method 1 will be simpler for you because you don't have to mess around with the CA key.
By default, your clusterrolebinding has system:anonymous set which blocks the cluster access.
Execute the following command, it will set a clusterrole as cluster-admin which will give you the required access.
kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous

Prometheus cannot find Apiserver of self-hosted Kubernetes cluster

I set up a Kubernetes cluster. Apiserver is started on host 192.168.0.2, and I use self-signed certificate and static token as authentication. The other 2 nodes' ip are 192.168.0.3 and 192.168.0.4
Then I created a prometheus deployment, the config is this. In prometheus dashboard, the two nodes and prometheus self are showed as "UP". However the apiserver is showed "DOWN", and the reason is "context deadline exceeded".
kubernetes-apiservers
Endpoint State Labels Last Scrape Error
https://192.168.0.2:443/metrics
DOWN instance="192.168.0.2:443" 55.979s ago context deadline exceeded
I tried to curl the address (https://192.168.0.2:443/metrics) from node server with ca certificate and token. The result is ok.
By the way, I setup the apiserver by hyperkube apiserver command line instead of kubelet. Is this the problem? And where should I look into?
In prometheus log, I only found this related one.
time="2017-01-13T10:51:28Z" level=debug msg="endpoints update" kubernetes_sd=endpoint source="endpoints.go:77" tg="&config.TargetGroup{Targets:[]model.LabelSet{model.LabelSet{\"__meta_kubernetes_endpoint_port_protocol\":\"TCP\", \"__meta_kubernetes_endpoint_ready\":\"true\", \"__address__\":\"192.168.0.2:443\", \"__meta_kubernetes_endpoint_port_name\":\"https\"}}, Labels:model.LabelSet{\"__meta_kubernetes_service_label_provider\":\"kubernetes\", \"__meta_kubernetes_namespace\":\"default\", \"__meta_kubernetes_endpoints_name\":\"kubernetes\", \"__meta_kubernetes_service_name\":\"kubernetes\", \"__meta_kubernetes_service_label_component\":\"apiserver\"}, Source:\"endpoints/default/kubernetes\"}"
Update:
The reason is that I didn't set up calico on master node. It works now.
That sounds like a network issue as the request is timing out. Can you hit that endpoint from inside the Prometheus container?