istio pod不啟動問題解決
在kubernetes集群中安裝istio之后，在創建的depoyment中已經使用了注入注解sidecar.istio.io/inject: 'true’配置，但是istio pod不創建，代碼示例如下
kind: Deployment
apiVersion: apps/v1
metadata:name: name-anamespace: namespace-alabels:app: xxxxapp.kubernetes.io/name: xxxapp.kubernetes.io/version: v1version: v1annotations:deployment.kubernetes.io/revision: '5'servicemesh.kubesphere.io/enabled: 'true'
spec:replicas: 1selector:matchLabels:app: xxxxapp.kubernetes.io/name: xxxapp.kubernetes.io/version: v1version: v1template:metadata:creationTimestamp: nulllabels:app: xxxxapp.kubernetes.io/name: xxxapp.kubernetes.io/version: v1version: v1annotations:cni.projectcalico.org/ipv4pools: '["default-ipv4-ippool"]'kubesphere.io/restartedAt: '2024-03-01T05:44:45.617Z'sidecar.istio.io/inject: 'true'spec:containers:- name: xxx-v1image: image-a:0.0.1ports:- name: http-8080containerPort: 8080protocol: TCPresources:limits:cpu: '2'memory: 4Ginvidia.com/gpu: '0'requests:nvidia.com/gpu: '0'terminationMessagePath: /dev/termination-logterminationMessagePolicy: FileimagePullPolicy: AlwaysrestartPolicy: AlwaysterminationGracePeriodSeconds: 30dnsPolicy: ClusterFirstserviceAccountName: defaultserviceAccount: defaultsecurityContext: {}imagePullSecrets:- name: harbor-secretschedulerName: default-schedulerstrategy:type: RollingUpdaterollingUpdate:maxUnavailable: 25%maxSurge: 25%revisionHistoryLimit: 10progressDeadlineSeconds: 600
經排查對命名空間namespace-a需要設置注解屬性為enabled.
查看命令
kubectl get namespace -L istio-injection
查看各個命名空間是否鏡像istio-injection注解的設置。
使用一下命令對命名空間屬性進行配置
kubectl label namespace namespace-a istio-injection=enabled
RBAC: access denied 問題解決
部分參考 https://cloud.tencent.com/document/product/1261/62949
經過以上修改后，istio pod可以自動創建起來，但是訪問報錯 RBAC: access denied。
這里要查看授權策略，授權策略用于配置網格、namespace、服務/Workload 范圍的訪問管理規則。您可以通過 AuthorizationPolicy CRD 配置授權規則。AuthorizationPolicy 主要包含以下部分：
- selector：指定策略的生效范圍。
- action：指定該策略是 ALLOW 策略還是 DENY 策略。
- rules：授權規則主體，由from，to，where 3 部分構成。
- from：指定請求的來源特征。
- to：指定請求的操作特征。
- when：指定授權規則的生效條件。
當有 AuthorizationPolicy 的 ALLOW 和 DENY 策略應用于同一范圍時，DNEY 策略的優先級高于 ALLOW 策略，生效的規則如下：
- 如請求匹配任何一條 DENY 策略，則拒絕該請求的訪問。
- 如該范圍沒有任何 ALLOW 策略，則允許該請求的訪問。
- 如當前該范圍存在 ALLOW 策略，且請求匹配到了任何一條 ALLOW 策略，則允許該請求的訪問。
- 拒絕該請求的訪問。
執行命令
kubectl get AuthorizationPolicy -A
查看所有的授權策略，發現在istio-system空間下，有一個global-deny-all的策略。使用以下命令刪除。
kubectl delete AuthorizationPolicy -n istio-system global-deny-all
問題解決。
)
