我在笔记本电脑上的实验室设置中遇到了同样的问题。
环境:
vagrant @ master-1:〜$ kubectl获取容器-n istio-system
NAME READY STATUS RESTARTS AGE
grafana-75b5cddb4d-5t5lq 1/1 Running 1 16h
istio-egressgateway-695f5944d8-s7mbg 1/1 Running 1 16h
istio-ingressgateway-5c697d4cd7-vpd68 1/1 Running 1 16h
istiod-76fdcdd945-tscgc 1/1 Running 0 17m
kiali-6c49c7d566-8wbnw 1/1 Running 1 16h
prometheus-9d5676d95-zxbnk 2/2 Running 2 14h
集群很难部署 在运行IP 192.168.5.30和HA代理的主服务器前面有1个LB,有1个主节点192.168.5.11,在VMbox Ubuntu VM上部署了2个工作节点。我正在将weavenet用作群集的CNI。
vagrant @ loadbalancer:〜$ kubectl获取节点-o宽
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
worker-3 Ready <none> 62d v1.18.0 192.168.5.24 <none> Ubuntu 18.04.4 LTS 4.15.0-112-generic docker://19.3.12
worker-4 Ready <none> 61d v1.18.0 192.168.5.25 <none> Ubuntu 18.04.4 LTS 4.15.0-112-generic docker://19.3.12
vagrant@loadbalancer:~$
--ExecStart=/usr/local/bin/kube-apiserver \\
--advertise-address=192.168.5.11 \\
--allow-privileged=true \\
--apiserver-count=3 \\
--audit-log-maxage=30 \\
--audit-log-maxbackup=3 \\
--audit-log-maxsize=100 \\
--audit-log-path=/var/log/audit.log \\
--authorization-mode=Node,RBAC \\
--bind-address=0.0.0.0 \\
--client-ca-file=/var/lib/kubernetes/ca.crt \\
--enable-admission-plugins=NodeRestriction,ServiceAccount \\
--enable-swagger-ui=true \\
--enable-bootstrap-token-auth=true \\
--etcd-cafile=/var/lib/kubernetes/ca.crt \\
--etcd-certfile=/var/lib/kubernetes/etcd-server.crt \\
--etcd-keyfile=/var/lib/kubernetes/etcd-server.key \\
--etcd-servers=https://192.168.5.11:2379 \\
--event-ttl=1h \\
--encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \\
--kubelet-certificate-authority=/var/lib/kubernetes/ca.crt \\
--kubelet-client-certificate=/var/lib/kubernetes/kube-apiserver.crt \\
--kubelet-client-key=/var/lib/kubernetes/kube-apiserver.key \\
--kubelet-https=true \\
--service-account-key-file=/var/lib/kubernetes/service-account.crt \\
--service-cluster-ip-range=10.96.0.0/24 \\
--service-node-port-range=30000-32767 \\
--tls-cert-file=/var/lib/kubernetes/kube-apiserver.crt \\
--tls-private-key-file=/var/lib/kubernetes/kube-apiserver.key \\
--v=2
vagrant@master-1:~$ kubectl describe svc istiod -n istio-system
Name: istiod
Namespace: istio-system
Labels: app=istiod
install.operator.istio.io/owning-resource=installed-state
install.operator.istio.io/owning-resource-namespace=istio-system
istio=pilot
istio.io/rev=default
operator.istio.io/component=Pilot
operator.istio.io/managed=Reconcile
operator.istio.io/version=1.7.0
release=istio
Annotations: Selector: app=istiod,istio=pilot
Type: ClusterIP
IP: 10.96.0.197
Port: grpc-xds 15010/TCP
TargetPort: 15010/TCP
Endpoints: 10.44.0.7:15010
Port: https-dns 15012/TCP
TargetPort: 15012/TCP
Endpoints: 10.44.0.7:15012
Port: https-webhook 443/TCP
TargetPort: 15017/TCP
Endpoints: 10.44.0.7:15017
Port: http-monitoring 15014/TCP
TargetPort: 15014/TCP
Endpoints: 10.44.0.7:15014
Port: dns-tls 853/TCP
TargetPort: 15053/TCP
Endpoints: 10.44.0.7:15053
Session Affinity: None
Events: <none>
vagrant@loadbalancer:~$ kubectl -n istio-system get configmap istio-sidecar-injector -o jsonpath='{.data.config}' | grep policy:
policy: enabled
vagrant@loadbalancer:~$ kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml | grep
> istio-injection: enabled
bjectSelector: {}
reinvocationPolicy:
> Never
Aug 31 02:48:22 master-1 kube-apiserver[1750]: I0831 02:48:22.521377 1750 trace.go:116] Trace[51800791]: “Call mutating webhook” configuration:istio-sidecar-injector,webhook:sidecar-injector.istio.io,resource:/v1, Resource=pods,subresource:,operation:CREATE,UID:9b96e1b2-3bbe-41d6-a727-0e19cdd9fbd1 (started: 2020-08-31 02:47:52.521061627 +0000 UTC m=+1080.518695497) (total time:30.000277923s):
Aug 31 02:48:22 master-1 kube-apiserver[1750]: Trace[51800791]: [30.000277923s] [30.000277923s] END
Aug 31 02:48:22 master-1 kube-apiserver[1750]: W0831 02:48:22.521529 1750 dispatcher.go:181] Failed calling webhook, failing closed sidecar-injector.istio.io: failed calling webhook “sidecar-injector.istio.io”: Post https://istiod.istio-system.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Aug 31 02:48:22 master-1 kube-apiserver[1750]: I0831 02:48:22.521814 1750 trace.go:116] Trace[491776795]: “Create” url:/api/v1/namespaces/dev/pods,user-agent## ##:kubectl/v1.18.0 (linux/amd64) kubernetes/9e99141,client:192.168.5.30 (started: 2020-08-31 02:47:52.510910326 +0000 UTC m=+1080.508544152) (total time: 30.010883231s):
Aug 31 02:48:22 master-1 kube-apiserver[1750]: Trace[491776795]: [30.010883231s] [30.003030474s] END
答案 0 :(得分:0)
正如我在评论中已经提到的,如果您正在使用VM,则应遵循此guide来部署Istio并将虚拟机连接到它。
请注意,VM支持仍然是Alpha功能。
更好的虚拟机支持
扩大对不在Kubernetes中运行的工作负载的支持是我们2020年的主要投资领域之一,我们很高兴在此宣布一些重大进展。
对于将非Kubernetes工作负载添加到网格中的那些人(例如,部署在VM上的工作负载),新的WorkloadEntry资源使此操作比以往更加轻松。我们创建了此API,以在Istio中为非Kubernetes工作负载提供一流的表示。它将VM或裸机工作负载提升到与Kubernetes Pod相同的级别,而不仅仅是具有IP地址的端点。您现在甚至可以定义由Pods和VM支持的服务。为什么这样有用?好了,您现在可以将同一服务的部署(VM和Pods)混合在一起,从而提供了一种绝佳的方式,可以将VM工作负载迁移到Kubernetes集群,而不会中断往返于该集群的流量。
基于VM的工作负载仍然是我们的重中之重,您可以期望在以后的版本中看到更多的信息。
您应按照以下步骤安装Istio并将虚拟机连接到它。
YouTube上有关于此的视频。
有关istio文档的示例。