Kubernetes

Ingress 公开了从集群内部到集群内服务的 HTTP 和 HTTPS 路由。流量路由由 Ingress 资源上定义的规定管制。 上面是一个将所有流量都发送到同一 Service 的简略 Ingress 示例： 在应用  ingress 创立后发现没有默认HTTP[root@hello ~/yaml/nginx]# kubectl describe ingressName: ingress-host-barNamespace: defaultAddress: Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)Rules: Host Path Backends ---- ---- -------- hello.chenby.cn / hello-server:8000 (172.20.1.13:9000,172.20.1.14:9000) demo.chenby.cn /nginx nginx-demo:8000 (172.20.2.14:80,172.20.2.15:80)Annotations: <none>Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 43m nginx-ingress-controller Scheduled for sync[root@hello ~/yaml/nginx]#呈现该问题后是因为没有创立默认的后端，须要卸载之前装置的，之前用什么形式装置就用对应的形式卸载 写入配置文件，并执行[root@hello ~/yaml]# vim deploy.yaml[root@hello ~/yaml]#[root@hello ~/yaml]#[root@hello ~/yaml]# cat deploy.yamlapiVersion: v1kind: Namespacemetadata: name: ingress-nginx labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx---# Source: ingress-nginx/templates/controller-serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx namespace: ingress-nginxautomountServiceAccountToken: true---# Source: ingress-nginx/templates/controller-configmap.yamlapiVersion: v1kind: ConfigMapmetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller namespace: ingress-nginxdata: allow-snippet-annotations: 'true'---# Source: ingress-nginx/templates/clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm name: ingress-nginxrules: - apiGroups: - '' resources: - configmaps - endpoints - nodes - pods - secrets - namespaces verbs: - list - watch - apiGroups: - '' resources: - nodes verbs: - get - apiGroups: - '' resources: - services verbs: - get - list - watch - apiGroups: - networking.k8s.io resources: - ingresses verbs: - get - list - watch - apiGroups: - '' resources: - events verbs: - create - patch - apiGroups: - networking.k8s.io resources: - ingresses/status verbs: - update - apiGroups: - networking.k8s.io resources: - ingressclasses verbs: - get - list - watch---# Source: ingress-nginx/templates/clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm name: ingress-nginxroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: ingress-nginxsubjects: - kind: ServiceAccount name: ingress-nginx namespace: ingress-nginx---# Source: ingress-nginx/templates/controller-role.yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx namespace: ingress-nginxrules: - apiGroups: - '' resources: - namespaces verbs: - get - apiGroups: - '' resources: - configmaps - pods - secrets - endpoints verbs: - get - list - watch - apiGroups: - '' resources: - services verbs: - get - list - watch - apiGroups: - networking.k8s.io resources: - ingresses verbs: - get - list - watch - apiGroups: - networking.k8s.io resources: - ingresses/status verbs: - update - apiGroups: - networking.k8s.io resources: - ingressclasses verbs: - get - list - watch - apiGroups: - '' resources: - configmaps resourceNames: - ingress-controller-leader verbs: - get - update - apiGroups: - '' resources: - configmaps verbs: - create - apiGroups: - '' resources: - events verbs: - create - patch---# Source: ingress-nginx/templates/controller-rolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx namespace: ingress-nginxroleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: ingress-nginxsubjects: - kind: ServiceAccount name: ingress-nginx namespace: ingress-nginx---# Source: ingress-nginx/templates/controller-service-webhook.yamlapiVersion: v1kind: Servicemetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller-admission namespace: ingress-nginxspec: type: ClusterIP ports: - name: https-webhook port: 443 targetPort: webhook appProtocol: https selector: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller---# Source: ingress-nginx/templates/controller-service.yamlapiVersion: v1kind: Servicemetadata: annotations: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller namespace: ingress-nginxspec: type: NodePort externalTrafficPolicy: Local ipFamilyPolicy: SingleStack ipFamilies: - IPv4 ports: - name: http port: 80 protocol: TCP targetPort: http appProtocol: http - name: https port: 443 protocol: TCP targetPort: https appProtocol: https selector: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller---# Source: ingress-nginx/templates/controller-deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller namespace: ingress-nginxspec: selector: matchLabels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller revisionHistoryLimit: 10 minReadySeconds: 0 template: metadata: labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller spec: dnsPolicy: ClusterFirst containers: - name: controller image: k8s.gcr.io/ingress-nginx/controller:v1.1.0@sha256:f766669fdcf3dc26347ed273a55e754b427eb4411ee075a53f30718b4499076a imagePullPolicy: IfNotPresent lifecycle: preStop: exec: command: - /wait-shutdown args: - /nginx-ingress-controller - --election-id=ingress-controller-leader - --controller-class=k8s.io/ingress-nginx - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller - --validating-webhook=:8443 - --validating-webhook-certificate=/usr/local/certificates/cert - --validating-webhook-key=/usr/local/certificates/key securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE runAsUser: 101 allowPrivilegeEscalation: true env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: LD_PRELOAD value: /usr/local/lib/libmimalloc.so livenessProbe: failureThreshold: 5 httpGet: path: /healthz port: 10254 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 readinessProbe: failureThreshold: 3 httpGet: path: /healthz port: 10254 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 ports: - name: http containerPort: 80 protocol: TCP - name: https containerPort: 443 protocol: TCP - name: webhook containerPort: 8443 protocol: TCP volumeMounts: - name: webhook-cert mountPath: /usr/local/certificates/ readOnly: true resources: requests: cpu: 100m memory: 90Mi nodeSelector: kubernetes.io/os: linux serviceAccountName: ingress-nginx terminationGracePeriodSeconds: 300 volumes: - name: webhook-cert secret: secretName: ingress-nginx-admission---# Source: ingress-nginx/templates/controller-ingressclass.yaml# We don't support namespaced ingressClass yet# So a ClusterRole and a ClusterRoleBinding is requiredapiVersion: networking.k8s.io/v1kind: IngressClassmetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: nginx namespace: ingress-nginxspec: controller: k8s.io/ingress-nginx---# Source: ingress-nginx/templates/admission-webhooks/validating-webhook.yaml# before changing this value, check the required kubernetes version# https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#prerequisitesapiVersion: admissionregistration.k8s.io/v1kind: ValidatingWebhookConfigurationmetadata: labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhook name: ingress-nginx-admissionwebhooks: - name: validate.nginx.ingress.kubernetes.io matchPolicy: Equivalent rules: - apiGroups: - networking.k8s.io apiVersions: - v1 operations: - CREATE - UPDATE resources: - ingresses failurePolicy: Fail sideEffects: None admissionReviewVersions: - v1 clientConfig: service: namespace: ingress-nginx name: ingress-nginx-controller-admission path: /networking/v1/ingresses---# Source: ingress-nginx/templates/admission-webhooks/job-patch/serviceaccount.yamlapiVersion: v1kind: ServiceAccountmetadata: name: ingress-nginx-admission namespace: ingress-nginx annotations: helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhook---# Source: ingress-nginx/templates/admission-webhooks/job-patch/clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: ingress-nginx-admission annotations: helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhookrules: - apiGroups: - admissionregistration.k8s.io resources: - validatingwebhookconfigurations verbs: - get - update---# Source: ingress-nginx/templates/admission-webhooks/job-patch/clusterrolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: ingress-nginx-admission annotations: helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhookroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: ingress-nginx-admissionsubjects: - kind: ServiceAccount name: ingress-nginx-admission namespace: ingress-nginx---# Source: ingress-nginx/templates/admission-webhooks/job-patch/role.yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: ingress-nginx-admission namespace: ingress-nginx annotations: helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhookrules: - apiGroups: - '' resources: - secrets verbs: - get - create---# Source: ingress-nginx/templates/admission-webhooks/job-patch/rolebinding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: ingress-nginx-admission namespace: ingress-nginx annotations: helm.sh/hook: pre-install,pre-upgrade,post-install,post-upgrade helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhookroleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: ingress-nginx-admissionsubjects: - kind: ServiceAccount name: ingress-nginx-admission namespace: ingress-nginx---# Source: ingress-nginx/templates/admission-webhooks/job-patch/job-createSecret.yamlapiVersion: batch/v1kind: Jobmetadata: name: ingress-nginx-admission-create namespace: ingress-nginx annotations: helm.sh/hook: pre-install,pre-upgrade helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhookspec: template: metadata: name: ingress-nginx-admission-create labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhook spec: containers: - name: create image: k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660 imagePullPolicy: IfNotPresent args: - create - --host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.$(POD_NAMESPACE).svc - --namespace=$(POD_NAMESPACE) - --secret-name=ingress-nginx-admission env: - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace securityContext: allowPrivilegeEscalation: false restartPolicy: OnFailure serviceAccountName: ingress-nginx-admission nodeSelector: kubernetes.io/os: linux securityContext: runAsNonRoot: true runAsUser: 2000---# Source: ingress-nginx/templates/admission-webhooks/job-patch/job-patchWebhook.yamlapiVersion: batch/v1kind: Jobmetadata: name: ingress-nginx-admission-patch namespace: ingress-nginx annotations: helm.sh/hook: post-install,post-upgrade helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhookspec: template: metadata: name: ingress-nginx-admission-patch labels: helm.sh/chart: ingress-nginx-4.0.10 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.1.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: admission-webhook spec: containers: - name: patch image: k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660 imagePullPolicy: IfNotPresent args: - patch - --webhook-name=ingress-nginx-admission - --namespace=$(POD_NAMESPACE) - --patch-mutating=false - --secret-name=ingress-nginx-admission - --patch-failure-policy=Fail env: - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace securityContext: allowPrivilegeEscalation: false restartPolicy: OnFailure serviceAccountName: ingress-nginx-admission nodeSelector: kubernetes.io/os: linux securityContext: runAsNonRoot: true runAsUser: 2000[root@hello ~/yaml]#启用后端，写入配置文件执行[root@hello ~/yaml]# vim backend.yaml[root@hello ~/yaml]# cat backend.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: default-http-backend labels: app.kubernetes.io/name: default-http-backend namespace: kube-systemspec: replicas: 1 selector: matchLabels: app.kubernetes.io/name: default-http-backend template: metadata: labels: app.kubernetes.io/name: default-http-backend spec: terminationGracePeriodSeconds: 60 containers: - name: default-http-backend image: k8s.gcr.io/defaultbackend-amd64:1.5 livenessProbe: httpGet: path: /healthz port: 8080 scheme: HTTP initialDelaySeconds: 30 timeoutSeconds: 5 ports: - containerPort: 8080 resources: limits: cpu: 10m memory: 20Mi requests: cpu: 10m memory: 20Mi---apiVersion: v1kind: Servicemetadata: name: default-http-backend namespace: kube-system labels: app.kubernetes.io/name: default-http-backendspec: ports: - port: 80 targetPort: 8080 selector: app.kubernetes.io/name: default-http-backend[root@hello ~/yaml]#装置测试利用[root@hello ~/yaml]# vim ingress-demo-app.yaml[root@hello ~/yaml]#[root@hello ~/yaml]# cat ingress-demo-app.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: hello-serverspec: replicas: 2 selector: matchLabels: app: hello-server template: metadata: labels: app: hello-server spec: containers: - name: hello-server image: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/hello-server ports: - containerPort: 9000---apiVersion: apps/v1kind: Deploymentmetadata: labels: app: nginx-demo name: nginx-demospec: replicas: 2 selector: matchLabels: app: nginx-demo template: metadata: labels: app: nginx-demo spec: containers: - image: nginx name: nginx---apiVersion: v1kind: Servicemetadata: labels: app: nginx-demo name: nginx-demospec: selector: app: nginx-demo ports: - port: 8000 protocol: TCP targetPort: 80---apiVersion: v1kind: Servicemetadata: labels: app: hello-server name: hello-serverspec: selector: app: hello-server ports: - port: 8000 protocol: TCP targetPort: 9000---apiVersion: networking.k8s.io/v1kind: Ingress metadata: name: ingress-host-barspec: ingressClassName: nginx rules: - host: "hello.chenby.cn" http: paths: - pathType: Prefix path: "/" backend: service: name: hello-server port: number: 8000 - host: "demo.chenby.cn" http: paths: - pathType: Prefix path: "/nginx" backend: service: name: nginx-demo port: number: 8000[root@hello ~/yaml]#[root@hello ~/yaml]# kubectl get ingressNAME CLASS HOSTS ADDRESS PORTS AGEingress-demo-app <none> app.demo.com 192.168.1.11 80 20mingress-host-bar nginx hello.chenby.cn,demo.chenby.cn 192.168.1.11 80 2m17s[root@hello ~/yaml]#过滤查看ingress端口[root@hello ~/yaml]# kubectl get svc -A | grep ingressdefault ingress-demo-app ClusterIP 10.68.231.41 <none> 80/TCP 51mingress-nginx ingress-nginx-controller NodePort 10.68.93.71 <none> 80:32746/TCP,443:30538/TCP 32mingress-nginx ingress-nginx-controller-admission ClusterIP 10.68.146.23 <none> 443/TCP 32m[root@hello ~/yaml]# ...

EMQ X 始终致力于为寰球客户提供高牢靠、高性能的实时数据挪动、解决能力。通过 EMQ X，无论是私有云还是公有云环境，用户都能够疾速构建要害 IoT 利用。 作为 EMQ X 全面拥抱云原生的一项重要停顿，EMQ X Kubernetes Operator v1.0 于近日正式公布，将帮忙宽广用户更不便、快捷、平安地基于 Kubernetes 平台对 EMQ X 集群进行生命周期治理。 我的项目地址：https://github.com/emqx/emqx-operator 什么是 EMQ X Kubernetes Operator?EMQ X Kubernetes Operator 是一种封装、部署和治理 EMQ X 的办法，也是一个特定的利用控制器，容许 DevOps 人员在 Kubernetes 上编排 EMQ X 集群，治理他们的生命周期。 为什么须要 EMQ X Kubernetes Operator？EMQ X Kubernetes Operator 能够帮忙用户在 Kubernetes 的环境上疾速创立和治理 EMQ X 集群，不仅极大简化部署和治理流程，也升高了治理和配置的专业技能要求。EMQ X Kubernetes Operator 将使部署和管理工作变成一种低成本、标准化、可重复性的能力，高效实现集群扩容、无缝降级、故障解决和对立监控。 快捷部署通过 Helm 或者 Manifest 文件，无需思考底层存储和 LB，应用默认配置就能够在 Kubernetes 上疾速部署一个 EMQ X 集群，轻松体验 MQTT 服务。 ...

装置helm环境[root@hello ~/yaml]#[root@hello ~/yaml]# curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -[root@hello ~/yaml]# sudo apt-get install apt-transport-https --yes[root@hello ~/yaml]# echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.listdeb https://baltocdn.com/helm/stable/debian/ all main[root@hello ~/yaml]# sudo apt-get update[root@hello ~/yaml]# sudo apt-get install helm[root@hello ~/yaml]#增加装置下载源[root@hello ~/yaml]# helm repo add loki https://grafana.github.io/loki/charts && helm repo updateWARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config"loki" has been added to your repositoriesWARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/configHang tight while we grab the latest from your chart repositories......Successfully got an update from the "loki" chart repositoryUpdate Complete. ⎈Happy Helming!⎈[root@hello ~/yaml]#[root@hello ~/yaml]#[root@hello ~/yaml]# helm pull loki/loki-stackWARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config[root@hello ~/yaml]# lsloki-stack-2.1.2.tgz nfs-storage.yaml nginx-ingress.yaml[root@hello ~/yaml]# tar xf loki-stack-2.1.2.tgz[root@hello ~/yaml]# lsloki-stack loki-stack-2.1.2.tgz nfs-storage.yaml nginx-ingress.yaml装置loki日志零碎[root@hello ~/yaml]# helm install loki loki-stack/WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/configWARNING: This chart is deprecatedW1203 07:31:04.751065 212245 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+W1203 07:31:04.754254 212245 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+W1203 07:31:04.833003 212245 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+W1203 07:31:04.833003 212245 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+NAME: lokiLAST DEPLOYED: Fri Dec 3 07:31:04 2021NAMESPACE: defaultSTATUS: deployedREVISION: 1NOTES:The Loki stack has been deployed to your cluster. Loki can now be added as a datasource in Grafana.See http://docs.grafana.org/features/datasources/loki/ for more detail.[root@hello ~/yaml]#查看装置后是否实现[root@hello ~/yaml]# helm list -AWARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/configNAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSIONloki default 1 2021-12-03 07:31:04.3324429 +0000 UTC deployed loki-stack-2.1.2 v2.0.0 [root@hello ~/yaml]#[root@hello ~/yaml]# kubectl get podNAME READY STATUS RESTARTS AGEloki-0 0/1 Running 0 68sloki-promtail-79tn8 1/1 Running 0 68sloki-promtail-qzjjs 1/1 Running 0 68sloki-promtail-zlt7p 1/1 Running 0 68snfs-client-provisioner-dc5789f74-jsrh7 1/1 Running 0 44m[root@hello ~/yaml]#查看svc并批改类型[root@hello ~/yaml]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.68.0.1 <none> 443/TCP 4h44mloki ClusterIP 10.68.140.107 <none> 3100/TCP 2m58sloki-headless ClusterIP None <none> 3100/TCP 2m58s[root@hello ~/yaml]#将svc设置为 type: NodePort[root@hello ~/yaml]# kubectl edit svc lokiservice/loki edited[root@hello ~/yaml]#[root@hello ~/yaml]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.68.0.1 <none> 443/TCP 4h46mloki NodePort 10.68.140.107 <none> 3100:31089/TCP 4m34sloki-headless ClusterIP None <none> 3100/TCP 4m34s[root@hello ~/yaml]#增加nginx利用[root@hello ~/yaml]# vim nginx-app.yaml[root@hello ~/yaml]# cat nginx-app.yamlapiVersion: apps/v1 kind: Deploymentmetadata: name: nginxspec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80---apiVersion: v1kind: Servicemetadata: name: nginx labels: app: nginx jobLabel: nginxspec: ports: - name: nginx port: 80 protocol: TCP selector: app: nginx type: NodePort[root@hello ~/yaml]#查看nginx的pod[root@hello ~/yaml]# kubectl apply -f nginx-app.yaml deployment.apps/nginx createdservice/nginx created[root@hello ~/yaml]# kubectl get pod | grep nginxnginx-5d59d67564-7fj4b 1/1 Running 0 29s[root@hello ~/yaml]#测试拜访[root@hello ~/yaml]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.68.0.1 <none> 443/TCP 4h57mloki NodePort 10.68.140.107 <none> 3100:31089/TCP 15mloki-headless ClusterIP None <none> 3100/TCP 15mnginx NodePort 10.68.150.95 <none> 80:31317/TCP 105s[root@hello ~/yaml]# [root@hello ~/yaml]# while true; do curl --silent --output /dev/null --write-out '%{http_code}' http://192.168.1.12:31317; sleep 1; echo; done在grafana中增加源 ...

随着云计算和容器技术的倒退，以docker为外围的容器技术迅速在开发者和科技公司中利用，Kubernetes凭借丰盛的企业级、生产级性能成为事实上的容器集群管理系统。可是k8s的通用性减弱了调度算法的定制性，本文将调研定制化调度算法的办法，并且给出一个开源实现Demo。 k8s与调度器架构下图1-1是Kubernetes的整体架构图，集群节点分为两种角色：Master节点和Node节点。Master节点是整个集群的管理中心，负责集群治理、容器调度、状态存储等组件都运行在Master节点上；Node节点是实际上的工作节点，负责运行具体的容器。 Kubernetes调度器是独立运行的过程，外部运行过程从逻辑上能够分为多个模块。图1-2展现了默认调度器外部蕴含的具体模块，配置模块负责读取调度器相干配置信息，并且依据配置内容初始化调度器。 优先队列模块是一个优先堆数据结构，负责将待调度Pod依据优先级排序，优先级高的Pod排在后面，调度器会轮询优先队列，当队列中存在待调度Pod时就会执行调度过程。调度模块由算法模块、Node缓存和调度扩大点三局部组成，算法模块提供对Node进行评分的一系列根底算法，比方平衡节点CPU和内存使用率的NodeResourcesBalancedAllocation算法，算法模块是可扩大的，用户能够批改和增加本人的调度算法；Node缓存模块负责缓存集群节点的最新状态数据，为调度算法提供数据撑持；调度扩大点由一系列扩大点形成，每个扩大点负责不同的性能，最重要的扩大点是Filter、Score和Bind这三个扩大点。最初是绑定模块，负责将调度器抉择的Node和Pod绑定在一起。 Kubernetes调度器代码采纳可插拔的插件化设计思路，包含外围局部和可插拔局部。图1-2中的配置模块、优先队列和Node缓存是外围局部，算法模块、调度扩大点属于可插拔局部。这种插件化设计容许调度器一些性能通过插件的形式实现，不便代码批改和性能扩大，同时放弃调度器外围代码简略可保护。 下图1-3列出了调度器扩大点模块中蕴含的具体扩大点。Pod的调度过程分为调度周期和绑定周期，调度和绑定周期独特形成Pod的调度上下文。调度上下文由一系列扩大点形成，每个扩大点负责一部分性能，最重要的扩大点是调度周期中的预选(Filter)和优选(Score)扩大点和绑定周期中的绑定(Bind)扩大点。预选扩大点负责判断每个节点是否可能满足Pod的资源需要，不满足就过滤掉该节点。优选扩大点局部会对每个Pod运行默认的评分算法，并且将最终评分加权汇总，失去最初所有节点的综合评分；调度器会抉择综合评分最高的节点，如果有多个节点评分雷同且最高，调度器会通过水塘采样算法在多个节点中随机抉择一个作为调度后果，而后将该节点上Pod申请的资源用量进行保留操作，避免被其它Pod应用。在绑定周期中，调度器将Pod绑定到评分最高的节点上，这一步实质是批改Pod对象中节点相干的信息，并且更新到存储组件etcd中。 定制化算法计划如果要实现自定义调度算法，次要有三种计划： 批改默认调度器的源代码，退出本人的调度算法，而后从新编译和部署调度器，论文kcss和kubecg中的调度器钻研基于此计划实现；开发本人的调度器，和默认调度器同时运行在集群中；基于Kubernetes Scheduler Extender机制，在扩大调度器中实现自定义算法，论文dynamic IO中的算法实现基于这种计划。上述三种自定义调度算法实现计划的优缺点见表2-1。综合来讲， 计划1改变最小，然而这样做会毁坏开源软件的可维护性，当Kubernetes骨干代码更新时，改变后的调度器要和上游代码保持一致，这会带来大量的保护和测试工作。计划2是实现本人的调度器，并且在集群中运行多个调度器，多个调度器之间没有集群资源数据同步，存在并发调度数据竞争和数据不统一的问题。计划3须要默认调度器通过API和Extender交互，新增的网络申请会减少整个调度过程的耗时。2-1 自研调度算法计划比照 计划长处毛病计划1：批改调度器源代码改变小毁坏源代码、不好保护计划2：运行多个调度器不改变源代码存在数据竞争、不统一计划3：开发扩大调度器不改变源代码存在网络耗时本文的调度器实现采纳计划3，设计并开发合乎Scheduler Extender机制和API标准的扩大调度器，将其命名为Liang。代码2-1是扩大调度器JOSN格局的策略配置文件，通过配置文件参数将该策略文件传递给Kubernetes默认调度器，其中urlPrefix示意扩大调度器Liang运行后监听的API地址，prioritizeVerb示意优选扩大点在扩大调度器中的路由。当默认调度器在优选扩大点运行完评分插件后会发送HTTP POST网络申请到Liang的API地址，并将Pod和候选节点信息放在HTTP Body中一起传递过来。接管到POST申请后，扩大调度器Liang会依据评分算法对节点进行评分并将后果返回给默认调度器。 { "kind": "Policy", "apiVersion": "v1", "extenders": [ { "urlPrefix": "http://localhost:8000/v1", "prioritizeVerb": "prioritizeVerb", "weight": 1, "enableHttps": false, "httpTimeout": 1000000000, "nodeCacheCapable": true, "ignorable": false } ]}图2-1是带扩大的默认调度器(kube-scheduler)启动过程，通过kube-policy.json配置文件将扩大调度器Liang的配置信息通知默认调度器。 扩大调度器Liang扩大调度器Liang独立于Kubernetes默认调度器，Liang的模块设计和组织架构如图3-1所示，包含多维资源采集存储和API服务两大部分。多维资源数据采集通过在集群中运行Prometheus和node-exporter实现，扩大调度器Liang负责从Prometheus获取多维指标而后使用调度算法，将后果返回给默认调度器。 api server模块，负责实现合乎扩大调度器数据格式和传输标准的API接口，Liang接管到Kubernetes的评分申请后，解析失去申请中的Pod和候选节点信息，作为参数传递给外部的调度算法，失去候选节点的评分后果并返回给默认调度器。调度算法模块，扩大调度器Liang的外围模块，负责实现自定义的调度算法。得益于扩大调度器机制，Liang中能够实现多个自定义调度算法。本文次要设计并实现了BNP和CMDN两个调度算法。数据缓存模块，次要性能有两个： 通过申请Prometheus的API失去整个Kubernetes集群中所有节点的状态数据。实现基于内存的指标数据缓存机制，提供指标数据的写入和读取接口，进步算法运行时获取多维指标数据的速度。Liang应用Go语言开发，代码量约3400行，开源网址为Liang开源地址。 表3-1是扩大调度器是否应用缓存机制和默认调度器做出调度决策的耗时比照，调度耗时通过在Kubernetes调度器源代码中打印工夫戳的形式获取，别离运行9次而后计算平均值。从表3-1中能够看到，默认调度器做出调度决策的耗时十分小，不到1ms。加上扩大调度器和缓存机制的状况下，均匀调度决策耗时为4.439ms，比默认调度器减少了约3ms，减少的工夫次要是默认调度器与扩大调度器Liang之间网络申请耗时以及Liang运行调度算法所需的工夫。当扩大调度器不加缓存机制时，每次做出调度决策的均匀耗时为1110.439ms，调度耗时迅速减少超过100倍，次要是每次做出调度决策都要申请Prometheus计算和获取集群中的指标数据。因而，扩大调度器加上缓存机制能够防止申请Prometheus带来的网络申请工夫，升高扩大调度器的决策工夫，晋升了扩大调度器的性能。 3-1 不同调度器架构决策耗时 调度类型均匀决策耗时默认调度器0.945ms扩大调度器-应用缓存4.439ms扩大调度器-不应用缓存1110.439msBNP算法BNP算法在Liang中实现，它将网络IO应用状况纳入k8s调度算法的考量，可能平衡集群中的网络IO用量。 图3-2是试验中默认调度算法和BNP算法中，整个集群中网络IO资源的变动状况，每部署一个Pod统计一次数据，共部署九个Pod。能够显著看到，BNP试验中网络IO资源要比默认调度算法调配更平衡。 CMDN算法CMDN算法在Liang中实现，它的指标是让集群中的多维资源分配更加平衡或者更加紧凑，外围步骤是针对CPU、内存、磁盘IO和网络IO以及网卡带宽这五个指标进行综合排序，抉择最佳Node部署Pod。图3-3是试验中CPU使用率变动比照状况，能够显著看到，CMDN平衡策略下CPU使用率平衡水平要比默认调度算法调配更平衡。 总结Kubernetes调度算法的通用性减弱了算法的定制性。本文钻研了k8s调度器架构和扩大机制，比照了三种定制化调度算法计划，抉择扩大计划实现扩大调度器Liang，并在Liang中实现了两个调度算法BNP和CMDN用于展现定制化算法能力。 扩大计划极大丰富了定制化调度算法的能力，能够满足十分多定制化场景的需要。同时也须要留神，定制调度算法往往须要更多的数据，这就须要在k8s集群中额定部署数据采集模块，减少了运维老本，升高了定制化调度算法的通用性。 原文链接，文章继续更新，能够微信搜寻「 机器学习与零碎 」浏览最新内容，回复材料、内推、考研获取相干内容。

背景 JupyterHub 为用户组带来了笔记本的弱小性能。它使用户可能拜访计算环境和资源，而不会给用户带来装置和保护工作的累赘。用户——包含学生、钻研人员和数据科学家——能够在他们本人的工作空间中实现他们的工作，共享资源能够由系统管理员无效治理。 JupyterHub 在云端或您本人的硬件上运行，能够为世界上的任何用户提供事后配置的数据迷信环境。它是可定制和可扩大的，实用于小型和大型团队、学术课程和大型基础设施。 第一步、参考：https://cloud.tencent.com/dev... 创立动静挂载存储 第二步、装置helm root@hello:~# curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -root@hello:~# sudo apt-get install apt-transport-https --yesroot@hello:~# echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.listroot@hello:~# sudo apt-get updateroot@hello:~# sudo apt-get install helm第三步、导入镜像 root@hello:~# docker load -i pause-3.5.tarroot@hello:~# docker load -i kube-scheduler.tar第四步、装置jupyterhub helm repo add jupyterhub https://jupyterhub.github.io/helm-chart/helm repo updatehelm upgrade --cleanup-on-fail \ --install ju jupyterhub/jupyterhub \ --namespace ju \ --create-namespace \ --version=1.2.0 \ --values config.yaml注：此文件能够自定义内容，具体看正文，如下开启lab性能 ...

什么是 Helm在没应用 helm 之前，向 kubernetes 部署利用，咱们要顺次部署 deployment、svc 等，步骤较繁琐。况且随着很多我的项目微服务化，简单的利用在容器中部署以及治理显得较为简单，helm 通过打包的形式，反对公布的版本治理和管制，很大水平上简化了 Kubernetes 利用的部署和治理Helm 实质就是让 K8s 的利用治理（Deployment,Service 等 ) 可配置，能动静生成。通过动静生成 K8s 资源清单文件（deployment.yaml，service.yaml）。而后调用 Kubectl 主动执行 K8s 资源部署Helm 是官网提供的相似于 YUM 的包管理器，是部署环境的流程封装。Helm 有两个重要的概念：chart 和 release Helm应用的包格局称为 chart。chart 是创立一个利用的信息汇合，包含各种 Kubernetes 对象的配置模板、参数定义、依赖关系、文档说明等。chart 是利用部署的自蕴含逻辑单元。能够将 chart 设想成 apt、yum 中的软件安装包。Chart 文件构造chart是一个组织在文件目录中的汇合。目录名称就是chart名称（没有版本信息）。因此形容WordPress的chart能够存储在wordpress/目录中。在这个目录中，Helm 冀望能够匹配以下构造： wordpress/ Chart.yaml # 蕴含了chart信息的YAML文件 LICENSE # 可选: 蕴含chart许可证的纯文本文件 README.md # 可选: 可读的README文件 values.yaml # chart 默认的配置值 values.schema.json # 可选: 一个应用JSON构造的values.yaml文件 charts/ # 蕴含chart依赖的其余chart crds/ # 自定义资源的定义 templates/ # 模板目录， 当和values 联合时，可生成无效的Kubernetes manifest文件 templates/NOTES.txt # 可选: 蕴含简要应用阐明的纯文本文件几个Helm波及的概念Repositry: 集中存储和散发Chart的仓库，相似于Perl的CPAN, 或者Python的PyPI等。Config: Chart实例化装置运行时应用的配置信息。Release: Chart实例化配置后运行于Kubernetes集群中的一个利用实例;在同一个集群上，一个Chart能够应用不同的Config反复装置屡次，每次装置都会创立一 个新的公布 (Release)Helm 蕴含两个组件：Helm 客户端和 Tiller 服务器，如下图所示Helm 客户端负责 chart 和 release 的创立和治理以及和 Tiller 的交互。Tiller 服务器运行在 Kubernetes 集群中，它会解决 Helm 客户端的申请，与 Kubernetes API Server 交互Helm 部署helm v3版本不须要部Tiller 可间接应用官网下载适宜版本: ...

介绍 Kubernetes 反对对节点上的 AMD 和 NVIDIA GPU （图形处理单元）进行治理，目前处于试验状态。 批改docker配置文件 root@hello:~# cat /etc/docker/daemon.json{ "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, "data-root": "/var/lib/docker", "exec-opts": ["native.cgroupdriver=systemd"], "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "http://hub-mirror.c.163.com" ], "insecure-registries": ["127.0.0.1/8"], "max-concurrent-downloads": 10, "live-restore": true, "log-driver": "json-file", "log-level": "warn", "log-opts": { "max-size": "50m", "max-file": "1" }, "storage-driver": "overlay2"}root@hello:~#root@hello:~# systemctl daemon-reloadroot@hello:~# systemctl start docker增加标签 root@hello:~# kubectl label nodes 192.168.1.56 nvidia.com/gpu.present=trueroot@hello:~# kubectl get nodes -L nvidia.com/gpu.presentNAME STATUS ROLES AGE VERSION GPU.PRESENT192.168.1.55 Ready,SchedulingDisabled master 128m v1.22.2 192.168.1.56 Ready node 127m v1.22.2 trueroot@hello:~#装置helm仓库 ...

CustomResourceDefinition简介：在 Kubernetes 中所有都可视为资源，Kubernetes 1.7 之后减少了对 CRD 自定义资源二次开发能力来扩大 Kubernetes API，通过 CRD 咱们能够向 Kubernetes API 中减少新资源类型，而不须要批改 Kubernetes 源码来创立自定义的 API server，该性能大大提高了 Kubernetes 的扩大能力。当你创立一个新的CustomResourceDefinition (CRD)时，Kubernetes API服务器将为你指定的每个版本创立一个新的RESTful资源门路，咱们能够依据该api门路来创立一些咱们本人定义的类型资源。CRD能够是命名空间的，也能够是集群范畴的，由CRD的作用域(scpoe)字段中所指定的，与现有的内置对象一样，删除名称空间将删除该名称空间中的所有自定义对象。customresourcedefinition自身没有名称空间，所有名称空间都能够应用。 目前扩大Kubernetes API的罕用形式有3种:应用CRD(CustomResourceDefinitions)自定义资源类型开发自定义的APIServer并聚合至主API Server及定制扩大API Server源码。这其中，CRD最为易用但限度颇多，自定义API Server更富于弹性但代码工作量偏大，而仅在必须增加新的外围类型能力确保专用的Kberneves集群性能失常，才应该定制零碎源码CRD-->CRT-->CR其中CRD与CRT个别由开发或服务供应商提供CRD只是定义一个类型Kind，但理论把kind运行起来CR须要有Controller来对资源进行管制，所有只有定义CRD定义没有并没有实际意义，当然也能够通过定义当初kind来运行，比方deployment 通过定义 RC来运行配置标准apiVersion: apiextensions.k8s.io/v1 #API群组和版本kind: CustomResourceDefinition #资源类别metadata: -name <string> #资源名称spec: conversion <object> #定义不同版本间的格局转换形式 strategy <string># 不同版本间的自定义资源转换策略，有None和webhook两种取值 webhook <0bject>#如何调用用于进行格局转换的webhook group <string>#资源所属的API群组 names <object># 自定义资源的类型，即该CRD创立资源标准时应用的kind categories <[]string>#资源所属的类别编目，例如"kubectl get all"中的all kind <string> #kind名称,必选字段 listKind <string> #资源列表名称，默认为"`kind`List" plural <string> #复数，用于API门路`/apis/<group>/<version>/. . ./<plural>' shortNames <[string>#该资源的kind的缩写格局 singular <string>#资源kind的复数模式，必须应用全小写字母，默认为小写的kind名称 preserveUnknownFields <boolean> #预留的非知名字段，kind等都是出名的预留字段 scope <string> #作用域，可用值为Cluster和Namespaced versions <[]object>#版本号定义 additionalPrinterColumns <[]0bject> #须要返回的额定信息 name <string> #形如vM[alphaN|betaN]格局的版本名称，例如v1或vlalpha2等 schema <object> #该资源的数据格式(schema)定义，必选字段 openAPIV3Schema <object> #用于校验字段的schema对象，格局请参考相干手册 served <boolean> #是否容许通过RESTful API调度该版本，必选字段 storage <boolean> #将自定义资源存储于etcd中时是不是应用该版本 subresources <0bject>#子资源定义 scale <0bject># 启用scale子资源，通过autoscaling/v1.Scale发送负荷 status <map[string]># 启用status子资源，为资源生成/status端点能够查看之前部署Calico创立的自定义CRD[root@k8s-master ~]# kubectl api-resources #查看所有资源类型NAME SHORTNAMES APIGROUP NAMESPACED KIND... bgpconfigurations crd.projectcalico.org false BGPConfigurationbgppeers crd.projectcalico.org false BGPPeerblockaffinities crd.projectcalico.org false BlockAffinityclusterinformations crd.projectcalico.org false ClusterInformationfelixconfigurations crd.projectcalico.org false FelixConfigurationglobalnetworkpolicies crd.projectcalico.org false GlobalNetworkPolicyglobalnetworksets crd.projectcalico.org false GlobalNetworkSethostendpoints crd.projectcalico.org false HostEndpointipamblocks crd.projectcalico.org false IPAMBlockipamconfigs crd.projectcalico.org false IPAMConfigipamhandles crd.projectcalico.org false IPAMHandleippools crd.projectcalico.org false IPPoolkubecontrollersconfigurations crd.projectcalico.org false KubeControllersConfigurationnetworkpolicies crd.projectcalico.org true NetworkPolicynetworksets crd.projectcalico.org true NetworkSet查看calico的yaml文件能够看到外面很多CRD的定义 ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。Kubernetes v1.23 行将公布，这是 2021 年公布的第三个版本，也是往年最初一个正式公布的版本。 此版本中次要包含 47 项加强更新，其中 11 项达到 stable, 17 项达到 beta 还有 19 项达到 alpha 。 当然，也有 1 项被标记为废除。相比于 v1.22 从数量上来说是少了一点（v1.22 有 53 项加强更新），但这并不影响这是一个很棒的版本！ 在 Kubernetes 的公布周期变更为 每4个月一个版本 后，很显著的感觉就是不必在降级下面破费太多工夫了，毕竟 Kubernetes 的降级操作是个体力活，大家感觉呢？ 咱们一起来看看这个版本中有哪些值得关注的变更吧！ 新增 kubectl alpha events 命令在之前的 《K8S 生态周报| Helm 新版本公布加强对 OCI 的反对》 文章的上游停顿中我曾为大家介绍了该性能。它是依照 KEP #1440 施行的。 减少此命令次要是因为在不批改 kubectl get 的前提下，查看 event 有一些限度，所以间接减少 kubectl events 命令能够更不便的去获取到须要的信息，尤其是 event 是在 Kubernetes 中常常须要查看的一个信息。kubectl get events 比拟典型的一些问题, 比方排序（尽管能够通过加参数解决）， watch，以及无奈依照工夫线形式去查看 events 等。咱们来看看这个命令具体如何应用。 ...

前言:流量入口代理作为互联网零碎的门户组件，具备泛滥选型：从老牌代理 HAProxy、Nginx，到微服务 API 网关 Kong、Zuul，再到容器化 Ingress 标准与实现，不同选型间性能、性能、可扩展性、实用场景参差不齐。当云原生时代大浪袭来，Envoy 这一 CNCF 毕业数据面组件为更多人所知。那么，优良“毕业生”Envoy 是否成为云原生时代下流量入口规范组件？ 背景 —— 流量入口的泛滥选型与场景 在互联网体系下，但凡须要对外裸露的零碎简直都须要网络代理：较早呈现的 HAProxy、Nginx 至今仍在风行；进入微服务时代后，性能更丰盛、管控能力更强的 API 网关又成为流量入口必备组件；在进入容器时代后，Kubernetes Ingress 作为容器集群的入口，是容器时代微服务的流量入口代理规范。对于这三类典型的七层代理，外围能力比照如下： 从上述外围能力比照来看：HAProxy&Nginx 在具备根底路由性能根底上，性能、稳定性经验多年考验。Nginx 的上游社区 OpenResty 提供了欠缺的 Lua 扩大能力，使得 Nginx 能够更宽泛的利用与扩大，如 API 网关 Kong 即是基于 Nginx+OpenResty 实现。API 网关作为微服务对外 API 流量裸露的根底组件，提供比拟丰盛的性能和动静管控能力。Ingress 作为 Kubernetes 入口流量的标准规范，具体能力视实现形式而定。如基于 Nginx 的 Ingress 实现能力更靠近于 Nginx，Istio Ingress Gateway 基于 Envoy+Istio 管制面实现，性能上更加丰盛（实质上 Istio Ingress Gateway 能力上强于通常的 Ingress 实现，但未依照 Ingress 标准实现）。那么问题来了：同样是流量入口，在云原生技术趋势下，是否找到一个能力全面的技术计划，让流量入口标准化？Envoy 外围能力介绍Envoy 是一个为云原生利用设计的开源边缘与服务代理（ENVOY IS AN OPEN SOURCE EDGE AND SERVICE PROXY, DESIGNED FOR CLOUD-NATIVE APPLICATIONS，@envoyproxy.io），是云原生计算基金会（CNCF）第三个毕业的我的项目，GitHub 目前有 13k+ Star。 ...

前言:什么是Ingress？官网的解释是:Ingress 是对集群中服务的内部拜访进行治理的 API 对象，典型的拜访形式是 HTTP。Ingress 能够提供负载平衡、SSL 终结和基于名称的虚构托管。 Ingress简介Ingress对象，其实就是对“反向代理”的一种形象，简略的说就是一个全局的负载均衡器，能够通过拜访URL定位到后端的Service有了Ingress这个形象，K8S就不须要关怀Ingress的细节了，理论应用时，只须要抉择一个具体的Ingress Controller部署就行了，业界罕用的反向代理我的项目有：Nginx、HAProxy、Envoy、Traefik 都曾经成为了K8S专门保护的Ingress Controller一个Ingress对象的次要内容，就相似Nginx的配置文件形容，对应的转发规定就是ingressRule，有了Ingress这个对象，用户就能够依据本人的需要抉择Ingress Controller，例如，如果利用对代理服务的中断十分敏感，能够应用Treafik这样的Ingress Controller Ingress工作在七层，Service工作在四层，当想要在Kubernetes里为利用进行TLS配置等HTTPS相干操作时，都必须通过Ingress来进行 ingress-nginx 简略的了解就是你原来须要改 Nginx 配置，而后配置各种域名对应哪个 Service，当初把这个动作形象进去，变成一个 Ingress 对象，你能够用 yaml 创立，每次不要去改 Nginx 了，间接改 yaml 而后创立/更新就行了；那么问题来了：”Nginx 该怎么解决？”Ingress Controller 这货色就是解决 “Nginx 的解决形式” 的；Ingress Controoler 通过与 Kubernetes API 交互，动静的去感知集群中 Ingress 规定变动，而后读取他，依照他本人模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最初 reload 一下，工作流程如下图： 实际上Ingress也是Kubernetes API的规范资源类型之一，它其实就是一组基于DNS名称（host）或URL门路把申请转发到指定的Service资源的规定。用于将集群内部的申请流量转发到集群外部实现的服务公布。咱们须要明确的是，Ingress资源本身不能进行“流量穿透”，仅仅是一组规定的汇合，这些汇合规定还须要其余性能的辅助，比方监听某套接字，而后依据这些规定的匹配进行路由转发，这些可能为Ingress资源监听套接字并将流量转发的组件就是Ingress ControllerIngress 两种路由形式1.虚拟主机2.URL 门路Ingree-nginx部署ingress-nginx 很多全局配置或批改默认配置都是通过annotations 正文来加载配置文件具体参数具体解释可参考官网文档： https://kubernetes.github.io/...抉择NodePort部署形式 https://kubernetes.github.io/...extensions/v1beta1 Ingress资源标准 1.22+版本后会被彻底弃用apiVersion: extensions/v1betal #资源所属的API群组和版本Kind: Ingress#资源类型标识符metadata: #元数据 name <string> #资源名称 annotationsl #资源注解,v1betal应用上面的注解来指定要解析该资源的控制器类型 kubernetes.io/ingress.class: <string> #适配的Ingress控制器类别 namespace <string> #名称空间spec: rules <[]Object> #Ingress规定列表; - host <string> #虚拟主机的FQDN，反对“*"前缀通配，不反对IP，不反对指定端口 http <object> paths<[]0bject>#虚拟主机PATH定义的列表，由path和backend组成 - path <string> #流量匹配的HTTP PATH，必须以/结尾 pathType <string> #匹配机制，反对Exact、_Prefix和ImplementationSpecific backend <object> #匹配到的流量转发到的指标后端 resource <Object> #援用的同一名称空间下的资源，与上面两个字段互斥 serviceName <string>#援用的Service资源的名称 servicePort <string># Service用于提供服务的端口 tls <[]object> #TLS配置，用于指定上rules中定义的哪些host须要工作HTTPS模式 - hosts <[]string> #应用同一组证书的主机名称列表 secretName <string> #保留于数字证书和私钥信息的secret资源名称 backend <object> #默认backend的定义，可嵌套字段及应用格局跟rules字段中的雷同 ingressClassName <string> #ingress类名称，用于指定适配的控制器v1 Ingress资源标准apiVersion: networking.k8s.io/v1 #资源所属的API群组和版本kind: Ingress #资源类型标识符metadata: #元数据 name <string> #资源名称 annotations: #资源注解,vlbetal应用上面的注解来指定要解析该资源的控制器类型 kubernetes.io/ingress.class:<string> #适配的Ingress控制器类别 namespace <string> #名称空间spec: rules <[]object> #Ingress规定列表 - host <string> #虚拟主机的FQDN，反对“*"前缀通配，不反对IP，不反对指定端口 http <object> paths <[]object>#虚拟主机PATH定义的列表，由path和backend组成 - path <string> #流量匹配的HTTP PATH，必须以/结尾 pathType <string> #反对Exact、Prefix和ImplementationSpecific，必选 backend <Object>#匹配到的流量转发到的指标后端 resource <object> #援用的同一名称空间下的资源，与上面两个字段互斥 service <object> #关联的后端Service对象 name <string> #后端Service的名称 port bject> #后端Service上的端口对象 name <string> #端口名称 number <integer> #端口号 tls <[]object> #TLS配置，用于指定上rules中定义的哪些host须要工作HTTPS模式 - hosts <[]string> #应用同一组证书的主机名称列表 secretName <string> #保留于数字证书和私钥信息的secret资源名称 backend <object> #默认backend的定义，可嵌套字段及应用格局跟rules字段中的雷同 ingressClassName <string> #ingress类名称，用于指定适配的控制器增加externalIPs:节点3 IP非必须步骤，不便记忆应用 而不是记忆NodePort端口 NodePort与externalIPs可同时拜访[root@k8s-master Ingress]# vim deploy.yaml...---# Source: ingress-nginx/templates/controller-service.yamlapiVersion: v1kind: Servicemetadata: annotations: labels: helm.sh/chart: ingress-nginx-4.0.1 app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/version: 1.0.0 app.kubernetes.io/managed-by: Helm app.kubernetes.io/component: controller name: ingress-nginx-controller namespace: ingress-nginxspec: type: NodePort externalIPs: [192.168.54.173] #增加externalIPs字段 固定拜访IP ports: - name: http port: 80 protocol: TCP targetPort: http appProtocol: http - name: https port: 443 protocol: TCP targetPort: https appProtocol: https selector: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/component: controller...部署Ingress-nginx[root@k8s-master Ingress]# kubectl apply -f deploy.yaml namespace/ingress-nginx unchangedserviceaccount/ingress-nginx unchangedconfigmap/ingress-nginx-controller configuredclusterrole.rbac.authorization.k8s.io/ingress-nginx unchangedclusterrolebinding.rbac.authorization.k8s.io/ingress-nginx unchangedrole.rbac.authorization.k8s.io/ingress-nginx unchangedrolebinding.rbac.authorization.k8s.io/ingress-nginx unchangedservice/ingress-nginx-controller-admission unchangedservice/ingress-nginx-controller configureddeployment.apps/ingress-nginx-controller configuredingressclass.networking.k8s.io/nginx unchangedvalidatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission configuredserviceaccount/ingress-nginx-admission unchangedclusterrole.rbac.authorization.k8s.io/ingress-nginx-admission unchangedclusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission unchangedrole.rbac.authorization.k8s.io/ingress-nginx-admission unchangedrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission unchangedjob.batch/ingress-nginx-admission-create unchangedjob.batch/ingress-nginx-admission-patch unchanged[root@k8s-master Ingress]# kubectl get podNAME READY STATUS RESTARTS AGEetcd-operator-646cbffdb6-brbn6 1/1 Running 0 19hexample-etcd-cluster-5fb5d9d6n8 1/1 Running 0 49mexample-etcd-cluster-nc8pdgjrjr 1/1 Running 0 19hexample-etcd-cluster-svgdngq28k 1/1 Running 0 48m[root@k8s-master Ingress]# kubectl get svc -n ingress-nginxNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEingress-nginx-controller NodePort 10.109.24.78 192.168.54.173 80:32493/TCP,443:30239/TCP 120mingress-nginx-controller-admission ClusterIP 10.110.72.52 <none> 443/TCP 120m示例1:创立 Ingress-nginx虚拟主机创立 Deployment 和与之对应的SVC[root@k8s-master Ingress]# cat deployment-demo.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: deployment-demo namespace: defaultspec: replicas: 4 selector: matchLabels: app: demoapp release: stable template: metadata: labels : app: demoapp release: stable spec: containers: - name: demoapp image: ikubernetes/demoapp:v1.1 ports: - containerPort: 80 name: http---apiVersion: v1kind: Servicemetadata: name: demoapp-deploy namespace: defaultspec: selector: app: demoapp release: stable ports: - name: http port: 80 targetPort: 80创立 ingress-nginx[root@k8s-master Ingress]# cat demoapp-ingress.yaml apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: ingress-demo annotations: kubernetes.io/ingress.class: "nginx" namespace: defaultspec: rules: - host: www.ik8s.io #虚拟主机 http: paths: - path: / pathType: Prefix #前缀匹配 backend: service: name: demoapp-deploy port: number: 80[root@k8s-master Ingress]# kubectl apply -f deployment-demo.yaml[root@k8s-master Ingress]# kubectl apply -f demoapp-ingress.yaml[root@k8s-master Ingress]# kubectl get svc -n ingress-nginxNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEingress-nginx-controller NodePort 10.109.24.78 192.168.54.173 80:32493/TCP,443:30239/TCP 5h50mingress-nginx-controller-admission ClusterIP 10.110.72.52 <none> 443/TCP 5h50m[root@k8s-master Ingress]# kubectl get ingressWarning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 IngressNAME CLASS HOSTS ADDRESS PORTS AGEingress-demo <none> www.ik8s.io 192.168.4.171 80 3h11m拜访测试[root@bigyong ~]# cat /etc/hosts # ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4...192.168.54.173 www.ik8s.io #写hosts[root@bigyong ~]# curl 192.168.54.173 #间接拜访只能到ingress-nginx 没到转发到后端<html><head><title>404 Not Found</title></head><body><center><h1>404 Not Found</h1></center><hr><center>nginx</center></body></html>[root@bigyong ~]# curl -H "Host:www.ik8s.io" 192.168.54.173 #拜访胜利iKubernetes demoapp v1.1 !! ClientIP: 192.168.113.37, ServerName: deployment-demo-867c7d9d55-gw6qp, ServerIP: 192.168.113.39[root@bigyong ~]# curl -H "Host:www.ik8s.io" 192.168.54.173iKubernetes demoapp v1.1 !! ClientIP: 192.168.113.37, ServerName: deployment-demo-867c7d9d55-9lnpq, ServerIP: 192.168.12.39![root@bigyong ~]# curl -H "Host:www.ik8s.io" 192.168.54.173iKubernetes demoapp v1.1 !! ClientIP: 192.168.113.37, ServerName: deployment-demo-867c7d9d55-2zcr5, ServerIP: 192.168.51.61![root@bigyong ~]# curl -H "Host:www.ik8s.io" 192.168.54.173iKubernetes demoapp v1.1 !! ClientIP: 192.168.113.37, ServerName: deployment-demo-867c7d9d55-9lnpq, ServerIP: 192.168.12.39!示例2:创立TLS Ingress HTTPS[root@k8s-master Ingress]# cat demoapp-ingress.yaml apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: ingress-demo annotations: kubernetes.io/ingress.class: "nginx" namespace: defaultspec: rules: - host: www.ik8s.io http: paths: - path: / pathType: Prefix #前缀匹配 backend: service: name: demoapp-deploy port: number: 80 tls: #增加tls - hosts: - www.ik8s.io secretName: ik8s-tls [root@k8s-master Ingress]# kubectl apply -f demoapp-ingress.yaml ingress.networking.k8s.io/ingress-demo configured[root@k8s-master Ingress]# kubectl describe ingress ingress-demoWarning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 IngressName: ingress-demoNamespace: defaultAddress: 192.168.4.171Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)TLS: ik8s-tls terminates www.ik8s.ioRules: Host Path Backends ---- ---- -------- www.ik8s.io / demoapp-deploy:80 (192.168.113.39:80,192.168.12.39:80)Annotations: kubernetes.io/ingress.class: nginxEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 113s (x3 over 6h36m) nginx-ingress-controller Scheduled for sync创立tls自签证书[root@k8s-master Ingress]# (umask 077); openssl genrsa -out tls.key 2048Generating RSA private key, 2048 bit long modulus............................+++.......................+++e is 65537 (0x10001)[root@k8s-master Ingress]# openssl req -new -x509 -key tls.key -out tls.crt -subj "/CN=www.ik8s.io" -days 365[root@k8s-master Ingress]# lsdemoapp-ingress.yaml deployment-demo.yaml tls.crtdeploy-externalIP.yaml deploy.yaml tls.key创立Secret[root@k8s-master Ingress]# kubectl create secret tls ik8s-tls --cert=./tls.crt --key=./tls.keysecret/ik8s-tls created拜访测试[root@k8s-master Ingress]# curl -H "Host:www.ik8s.io" 192.168.54.173 #308曾经被重定向<html><head><title>308 Permanent Redirect</title></head><body><center><h1>308 Permanent Redirect</h1></center><hr><center>nginx</center></body></html>#通过https拜访 提醒证书有效不被信赖[root@k8s-master Ingress]# curl -H "Host:www.ik8s.io" https://192.168.54.173 curl: (60) Issuer certificate is invalid.More details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.疏忽危险 拜访胜利[root@k8s-master Ingress]# curl -k -H "Host:www.ik8s.io" https://192.168.54.173 iKubernetes demoapp v1.1 !! ClientIP: 192.168.113.37, ServerName: deployment-demo-867c7d9d55-9lnpq, ServerIP: 192.168.12.39!示例3:为dashboard 增加ingresshttps://kubernetes.github.io/... ...

本文首发于 https://robberphex.com/error-reporting-with-kubernetes-events/ 组内有保护一个Kubernetes Webhook，能够拦挡pod的创立申请，并做一些批改（比方增加环境变量、增加init-container等）。 业务逻辑自身很简略，然而如果过程中产生谬误，就很难解决。要不间接阻止pod创立，那么就有可能导致利用无奈启动。要么疏忽业务逻辑，那么就会导致静默失败，谁也不晓得这儿呈现了一个谬误。 于是，奢侈的想法就是接入告警零碎，但这会导致以后组件和具体的告警零碎耦合起来。 在Kubernetes中，有Event机制，能够做到把一些事件，比方正告、谬误等信息记录下来，就比拟适宜这个场景。 什么是Kubernetes中的事件/Event？事件（Event）是 Kubernetes 中泛滥资源对象中的一员，通常用来记录集群内产生的状态变更，大到集群节点异样，小到 Pod 启动、调度胜利等等。 比方咱们Describe一个pod，就能看到这个pod对应的事件： kubectl describe pod sc-b-68867c5dcb-sf9hn 能够看到，从调度、到启动、再到这个pod最终拉取镜像失败，都会通过event的形式记录下来。 咱们来看下一个Event的构造： $ k get events -o json | jq .items[10] { "apiVersion": "v1", "count": 1, "eventTime": null, "firstTimestamp": "2021-12-04T17:02:14Z", "involvedObject": { "apiVersion": "v1", "fieldPath": "spec.containers{sc-b}", "kind": "Pod", "name": "sc-b-68867c5dcb-sf9hn", "namespace": "default", "resourceVersion": "322554830", "uid": "24df4a07-f41e-42c2-ba26-d90940303b00" }, "kind": "Event", "lastTimestamp": "2021-12-04T17:02:14Z", "message": "Error: ErrImagePull", "metadata": { "creationTimestamp": "2021-12-04T17:02:14Z", "name": "sc-b-68867c5dcb-sf9hn.16bd9bf933d60437", "namespace": "default", "resourceVersion": "1197082", "selfLink": "/api/v1/namespaces/default/events/sc-b-68867c5dcb-sf9hn.16bd9bf933d60437", "uid": "f928ff2d-c618-44a6-bf5a-5b0d3d20e95e" }, "reason": "Failed", "reportingComponent": "", "reportingInstance": "", "source": { "component": "kubelet", "host": "eci" }, "type": "Warning"}能够看到，一个event，比拟重要的几个字端： ...

准入管制一、什么是K8S之准入管制 就是在创立资源通过身份验证之后，kube-apiserver在数据写入etcd之前做一次拦挡，而后对资源进行更改、判断正确性等操作。 LimitRange，ResourceQuota目标：能管制特定命名空间中的资源使用量，最终实现集群的偏心应用和老本的管制 LimitRange:为Pod增加默认的计算资源需要和计算资源限度;以及存储资源需要和存储资源限度;反对别离在容器和Pod级别进行限度;比方:指定名称空间下每个Pod CPU、内存的最低最高额度ResourceQuota:限度资源数量，限度计算资源总量，存储资源总量;比方:指定名称空间下,只容许创立Pod、svc的数量, 所有Pod CPU、内存的最低最高额度须要实现的性能如下：限度运行状态的Pod的计算资源用量限度长久存储卷的数量以管制对存储的拜访限度负载均衡器的数量以管制老本避免滥用网络端口提供默认的计算资源Requests以便于零碎做出更优化的调度一个 LimitRange（限度范畴） 对象提供的限度可能做到：在一个命名空间中施行对每个 Pod 或 Container 最小和最大的资源使用量的限度。在一个命名空间中施行对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限度。在一个命名空间中施行对一种资源的申请值和限度值的比值的管制。设置一个命名空间中对计算资源的默认申请/限度值，并且主动的在运行时注入到多个 Container 中。二、启用 LimitRang对 LimitRange 的反对自 Kubernetes 1.10 版本默认启用。LimitRange 反对在很多 Kubernetes 发行版本中也是默认启用的。LimitRange 的名称必须是非法的 DNS 子域名。 三、限度范畴总览管理员在一个命名空间内创立一个 LimitRange 对象。用户在命名空间内创立 Pod ，Container 和 PersistentVolumeClaim 等资源。LimitRanger 准入控制器对所有没有设置计算资源需要的 Pod 和 Container 设置默认值与限度值， 并跟踪其使用量以保障没有超出命名空间中存在的任意 LimitRange 对象中的最小、最大资源使用量以及使用量比值。若创立或更新资源（Pod、 Container、PersistentVolumeClaim）违反了 LimitRange 的束缚， 向 API 服务器的申请会失败，并返回 HTTP 状态码 403 FORBIDDEN 与形容哪一项束缚被违反的音讯。若命名空间中的 LimitRange 启用了对 cpu 和 memory 的限度， 用户必须指定这些值的需要使用量与限度使用量。否则，零碎将会回绝创立 Pod。LimitRange 的验证仅在 Pod 准入阶段进行，不对正在运行的 Pod 进行验证 ...

RBAC 访问控制 ServiceAccount前言:在上一节曾经介绍过RBAC 通过绑定受权Users Accounts 失去不同作用域权限这节对Serviceaccount进行绑定受权 因为sa权限是针对Pod的权限 命令行无奈间接验证 所以借助dashbaortd来验证 首先在help中能够看到 有对serviceaccount的绑定[root@k8s-master authfiles]# kubectl create rolebinding --help...Usage: kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username][--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none][options]示例1:部署DashBoard验证ServiceAccount权限DashBoard官网URL https://kubernetes.io/zh/docs...kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml[root@k8s-master authfiles]# kubectl get pod -n kubernetes-dashboardNAME READY STATUS RESTARTS AGEdashboard-metrics-scraper-79c5968bdc-28h7g 1/1 Running 0 84skubernetes-dashboard-9f9799597-qj8jv 1/1 Running 0 84s[root@k8s-master authfiles]# kubectl get svc -n kubernetes-dashboardNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdashboard-metrics-scraper ClusterIP 10.98.196.130 <none> 8000/TCP 91skubernetes-dashboard ClusterIP 10.99.133.20 <none> 443/TCP 93s测试环境 这里应用比较简单的裸露形式 批改配置文件间接裸露DashBoard端口[root@k8s-master authfiles]# vim recommended.yaml kind: ServiceapiVersion: v1metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kubernetes-dashboardspec: ports: - port: 443 targetPort: 8443 externalIPs: #应用内部IP 裸露https - 192.168.54.171 selector: k8s-app: kubernetes-dashboard从新利用失效[root@k8s-master authfiles]# kubectl apply -f recommended.yaml [root@k8s-master authfiles]# kubectl get svc -n kubernetes-dashboardNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdashboard-metrics-scraper ClusterIP 10.98.196.130 <none> 8000/TCP 5m7skubernetes-dashboard ClusterIP 10.99.133.20 192.168.54.171 443/TCP 5m9s关上浏览器输出之前批改的地址 ...

RBAC 访问控制 Users Accounts前言:后面曾经对ServiceAccount、Users Account认证进行了介绍与创立,但最初的测试发现是Users Account并没有拜访权限,本节介绍RBAC受权 对ServiceAccount、Users Account认证进行受权 RBAC是什么？RBAC 是基于角色的访问控制（Role-Based Access Control ）在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而失去这些角色的权限。这就极大地简化了权限的治理。这样治理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很分明，治理起来很不便。角色　Role：角色,名称空间级别;受权特定命名空间的拜访权限　ClusterRole：集群角色,全局级别;受权所有命名空间的拜访权限角色绑定　RoleBinding：将角色绑定到主体（即subject）,意味着，用户仅失去了特定名称空间下的Role的权限，作用范畴也限于该名称空间;　ClusterRoleBinding：将集群角色绑定到主体,让用户表演指定的集群角色;意味着，用户失去了是集群级别的权限，作用范畴也是集群级别;　主体（subject）　User：用户　Group：用户组　ServiceAccount：服务账号绑定对应关系主体(Subject) --> RoleBinding --> Role #主体取得名称空间下的Role的权限主体(Subject) --> ClusterRoleBinding --> clusterRoles #主体取得集群级别clusterRoles的权限 主体(Subject) --> Rolebindig -->ClusterRole #权限降级 主体取得名称空间下的clusterRoles的权限rules中的参数阐明：1、apiGroups：反对的API组列表，例如："apiVersion: batch/v1"等2、resources：反对的资源对象列表，例如pods、deplayments、jobs等3、resourceNames: 指定resource的名称3、verbs：对资源对象的操作方法列表。 RBAC应用rbac.authorization.k8s.io API Group 来实现受权决策，容许管理员通过 Kubernetes API 动静配置策略，要启用RBAC，须要在 apiserver 中增加参数--authorization-mode=RBAC，如果应用的kubeadm装置的集群，都默认开启了RBAC，能够通过查看 Master 节点上 apiserver 的动态Pod定义文件：[root@k8s-master usercerts]# cat /etc/kubernetes/manifests/kube-apiserver.yaml apiVersion: v1kind: Podmetadata: ...spec: containers: - command: - kube-apiserver - --advertise-address=192.168.4.170 - --allow-privileged=true - --authorization-mode=Node,RBAC #默认反对BRAC 基于角色的访问控制 - --client-ca-file=/etc/kubernetes/pki/ca.crt - --enable-admission-plugins=NodeRestriction - --enable-bootstrap-token-auth=true - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt...查看 kube-system名称空间下的role角色详情[root@k8s-master ~]# kubectl get role -n kube-systemNAME CREATED ATextension-apiserver-authentication-reader 2021-06-28T17:43:31Zkube-proxy 2021-06-28T17:43:33Zkubeadm:kubelet-config-1.19 2021-06-28T17:43:31Zkubeadm:nodes-kubeadm-config 2021-06-28T17:43:31Zsystem::leader-locking-kube-controller-manager 2021-06-28T17:43:31Zsystem::leader-locking-kube-scheduler 2021-06-28T17:43:31Zsystem:controller:bootstrap-signer 2021-06-28T17:43:31Zsystem:controller:cloud-provider 2021-06-28T17:43:31Zsystem:controller:token-cleaner 2021-06-28T17:43:31Z[root@k8s-master ~]# kubectl get role kube-proxy -n kube-system -o yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: "2021-06-28T17:43:33Z" managedFields: - apiVersion: rbac.authorization.k8s.io/v1 fieldsType: FieldsV1 fieldsV1: f:rules: {} manager: kubeadm operation: Update time: "2021-06-28T17:43:33Z" name: kube-proxy namespace: kube-system resourceVersion: "195" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/kube-system/roles/kube-proxy uid: a5404b1f-90f0-447f-b104-86fcbdd388e0rules: #角色规定详细信息- apiGroups: - "" resourceNames: - kube-proxy resources: - configmaps verbs: #能执行的操作 - getrole角色绑定RoleBinding 角色绑定[root@k8s-master ~]# kubectl explain rolebindingKIND: RoleBindingVERSION: rbac.authorization.k8s.io/v1... roleRef <Object> -required- RoleRef can reference a Role in the current namespace or a ClusterRole in the global namespace. If the RoleRef cannot be resolved, the Authorizer must return an error. subjects <[]Object> Subjects holds references to the objects the role applies to.示例1: 创立role角色绑定 作用域为名称空间[root@k8s-master authfiles]# cat pods-reader-rbac.yaml kind : RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: default name: pods-readerrules:- apiGroups: [""] #空示意默认群组 resources: ["pods","services","pods/log"] #对象资源 verbs: ["get","list","watch"] #权限[root@k8s-master authfiles]# cat tom-pods-reader.yaml kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: tom-pods-reader namespace: defaultsubjects:- kind: User name: tom #绑定的用户名 apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role name: pods-reader #绑定之前的角色 apiGroup: rbac.authorization.k8s.io [root@k8s-master authfiles]# kubectl apply -f pods-reader-rbac.yaml [root@k8s-master authfiles]# kubectl apply -f tom-pods-reader.yaml [root@k8s-master authfiles]# kubectl get roleNAME CREATED ATpods-reader 2021-08-24T07:33:54Z[root@k8s-master authfiles]# kubectl get rolebindingNAME ROLE AGEtom-pods-reader Role/pods-reader 15m应用tom用户验证权限 pod、svc[root@k8s-master authfiles]# kubectl config get-contexts --kubeconfig=/tmp/mykubeconfig #查看以后用户CURRENT NAME CLUSTER AUTHINFO NAMESPACE* tom@kubernetes kubernetes tom [root@k8s-master authfiles]# kubectl get pod --kubeconfig=/tmp/mykubeconfigNAME READY STATUS RESTARTS AGEcentos-deployment-66d8cd5f8b-bnnw6 1/1 Running 0 7m8s[root@k8s-master authfiles]# kubectl get svc --kubeconfig=/tmp/mykubeconfigNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdemoapp ClusterIP 10.97.26.1 <none> 80/TCP 10ddemoapp-svc ClusterIP 10.99.170.77 <none> 80/TCP 10ddemodb ClusterIP None <none> 9907/TCP 5d22hkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 10d验证deployment、nodes权限 没有受权拜访失败[root@k8s-master authfiles]# kubectl get deployment --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): deployments.apps is forbidden: User "tom" cannot list resource "deployments" in API group "apps" in the namespace "default"[root@k8s-master authfiles]# kubectl get nodes --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): nodes is forbidden: User "tom" cannot list resource "nodes" in API group "" at the cluster scope内建管理员admin名称空间管理员adminclusterrole admin 名称空间级别资源 领有所有名称空间下的资源 所有操作权限集群管理员 cluster-adminclusterrole cluster-admin 集群级别资源 领有集群所有空的资源 所有操作权限之前绑定的rolebinding只对默认名称空间有肯定的权限[root@k8s-master authfiles]# kubectl get pod -n longhorn-system --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): pods is forbidden: User "tom" cannot list resource "pods" in API group "" in the namespace "longhorn-system"clusterrole admin 对所有名称空间下的资源权限[root@k8s-master authfiles]# kubectl get clusterrole adminNAME CREATED ATadmin 2021-06-28T17:43:30Z[root@k8s-master authfiles]# kubectl get clusterrole admin -o yaml删除绑定,从新绑定到clusterrole admin[root@k8s-master authfiles]# kubectl get rolebindingNAME ROLE AGEtom-pods-reader Role/pods-reader 35m[root@k8s-master authfiles]# kubectl delete Role/pods-readerrole.rbac.authorization.k8s.io "pods-reader" deleted[root@k8s-master authfiles]# kubectl delete rolebinding/tom-pods-readerrolebinding.rbac.authorization.k8s.io "tom-pods-reader" deleted[root@k8s-master authfiles]# kubectl get pod --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): pods is forbidden: User "tom" cannot list resource "pods" in API group "" in the namespace "default"示例2: 绑定admin 并验证权限,作用域为名称空间[root@k8s-master authfiles]# kubectl create --help ...Available Commands: clusterrole Create a ClusterRole. clusterrolebinding Create a ClusterRoleBinding for a particular ClusterRole configmap Create a configmap from a local file, directory or literal value cronjob Create a cronjob with the specified name. deployment Create a deployment with the specified name. job Create a job with the specified name. namespace Create a namespace with the specified name poddisruptionbudget Create a pod disruption budget with the specified name. priorityclass Create a priorityclass with the specified name. quota Create a quota with the specified name. role Create a role with single rule. rolebinding Create a RoleBinding for a particular Role or ClusterRole secret Create a secret using specified subcommand service Create a service using specified subcommand. serviceaccount Create a service account with the specified name能够别离对--user、--group、--serviceaccount进行受权[root@k8s-master authfiles]# kubectl create clusterrolebinding --helpCreate a ClusterRoleBinding for a particular ClusterRole.....Usage: kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname][--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none] [options]绑定并进行权限验证[root@k8s-master authfiles]# kubectl create clusterrolebinding tom-admin --user=tom --clusterrole=adminclusterrolebinding.rbac.authorization.k8s.io/tom-admin created[root@k8s-master authfiles]# kubectl get pod -n longhorn-system --kubeconfig=/tmp/mykubeconfigNAME READY STATUS RESTARTS AGEcsi-attacher-54c7586574-bh88g 1/1 Running 5 7dcsi-attacher-54c7586574-fvv4p 1/1 Running 7 19dcsi-attacher-54c7586574-zkzrg 1/1 Running 10 19dcsi-provisioner-5ff5bd6b88-9tqnh 1/1 Running 5 7dcsi-provisioner-5ff5bd6b88-bs687 1/1 Running 8 19dcsi-provisioner-5ff5bd6b88-qkzt4 1/1 Running 12 19dcsi-resizer-7699cdfc4-4w49w 1/1 Running 8 19d......[root@k8s-master authfiles]# kubectl get pod -n kube-system --kubeconfig=/tmp/mykubeconfigNAME READY STATUS RESTARTS AGEcoredns-f9fd979d6-l9zck 1/1 Running 16 56dcoredns-f9fd979d6-s8fp5 1/1 Running 15 56detcd-k8s-master 1/1 Running 12 56dkube-apiserver-k8s-master 1/1 Running 16 56dkube-controller-manager-k8s-master 1/1 Running 39 56dkube-flannel-ds-6sppx 1/1 Running 1 6d22hkube-flannel-ds-j5g9s 1/1 Running 3 6d22hkube-flannel-ds-nfz77 1/1 Running 1 6d22hkube-flannel-ds-sqhq2 1/1 Running 1 6d22h[root@k8s-master authfiles]# kubectl get deployment --kubeconfig=/tmp/mykubeconfigNAME READY UP-TO-DATE AVAILABLE AGEcentos-deployment 1/1 1 1 6d22hnode是集群级别资源 无权限[root@k8s-master authfiles]# kubectl get node --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): nodes is forbidden: User "tom" cannot list resource "nodes" in API group "" at the cluster scope[root@k8s-master authfiles]# kubectl get pv --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): persistentvolumes is forbidden: User "tom" cannot list resource "persistentvolumes" in API group "" at the cluster scope示例3: 绑定cluster-admin 并验证权限 作用域为集群级别资源[root@k8s-master authfiles]# kubectl delete clusterrolebinding tom-adminclusterrolebinding.rbac.authorization.k8s.io "tom-admin" deleted[root@k8s-master authfiles]# kubectl create clusterrolebinding tom-cluste-admin --user=tom --clusterrole=cluster-adminclusterrolebinding.rbac.authorization.k8s.io/tom-cluste-admin created[root@k8s-master authfiles]# kubectl get pv --kubeconfig=/tmp/mykubeconfigNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpv-nfs-demo002 10Gi RWX Retain Available 21dpv-nfs-demo003 1Gi RWO Retain Available 21dpvc-33e9acff-afd9-417e-bbfb-293cb6305fb1 1Gi RWX Retain Bound default/data-demodb-1 longhorn 5d23hpvc-c5a0bfaa-6948-4814-886f-8bf079b00dd1 1Gi RWX Retain Bound default/data-demodb-0 longhorn 5d23h[root@k8s-master authfiles]# kubectl get node --kubeconfig=/tmp/mykubeconfigNAME STATUS ROLES AGE VERSIONk8s-master Ready master 56d v1.19.9k8s-node1 Ready <none> 56d v1.19.9k8s-node2 Ready <none> 56d v1.19.9k8s-node3 Ready <none> 20d v1.19.9须要留神的是 cluster-admin 是通过system:masters组形式进行受权,如果咱们在创立用户证书时,/CN=XX/O=system:masters;那么这个用户就领有超级管理员的权限[root@k8s-master authfiles]# kubectl describe clusterrolebinding cluster-adminName: cluster-adminLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate: trueRole: Kind: ClusterRole Name: cluster-adminSubjects: Kind Name Namespace ---- ---- --------- Group system:masters #通过组受权所有system:masters都领有超级管理员权限示例4: rolebinding 绑定admin权限降级后面有提到User --> Rolebindig -->ClusterRole:权限降级，ClusterRole，用户失去的权限仅是ClusterRole的权限在Rolebinding所属的名称空间上的一个子集;删除之前绑定[root@k8s-master authfiles]# kubectl delete clusterrolebinding tom-cluste-adminclusterrolebinding.rbac.authorization.k8s.io "tom-cluste-admin" deleted创立角色绑定集群角色 权限降级 只对指定名称空间有权限[root@k8s-master authfiles]# kubectl create rolebinding tom-admin --user=tom -n longhorn-system --clusterrole=adminrolebinding.rbac.authorization.k8s.io/tom-admin created测试权限 作用域尽为longhorn-system名称空间[root@k8s-master authfiles]# kubectl get pod -n kube-system --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): pods is forbidden: User "tom" cannot list resource "pods" in API group "" in the namespace "kube-system"[root@k8s-master authfiles]# kubectl get pod --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): pods is forbidden: User "tom" cannot list resource "pods" in API group "" in the namespace "default"[root@k8s-master authfiles]# kubectl get deployment --kubeconfig=/tmp/mykubeconfigError from server (Forbidden): deployments.apps is forbidden: User "tom" cannot list resource "deployments" in API group "apps" in the namespace "default"[root@k8s-master authfiles]# kubectl get pod -n longhorn-system --kubeconfig=/tmp/mykubeconfigNAME READY STATUS RESTARTS AGEcsi-attacher-54c7586574-bh88g 1/1 Running 5 7dcsi-attacher-54c7586574-fvv4p 1/1 Running 7 19dcsi-attacher-54c7586574-zkzrg 1/1 Running 10 19dcsi-provisioner-5ff5bd6b88-9tqnh 1/1 Running 5 7dcsi-provisioner-5ff5bd6b88-bs687 1/1 Running 8 19dcsi-provisioner-5ff5bd6b88-qkzt4 1/1 Running 12 19dcsi-resizer-7699cdfc4-4w49w 1/1 Running 8 19dcsi-resizer-7699cdfc4-f5jph 1/1 Running 6 7dcsi-resizer-7699cdfc4-l2j49 1/1 Running 9 19d...

简介：2021年双十一是阿里巴巴团体的外围利用全面云化的第二年。往年在保障稳定性的前提下，次要摸索如何利用云原生的技术劣势，降低成本，晋升资源利用率。在往年大促中，针对外围集群采纳独享共享实例混部，对立了底层资源，联合交易业务云盘化使得混部单元大促成本降落30%+。引言2021年双十一是阿里巴巴团体的外围利用全面云化的第二年。往年在保障稳定性的前提下，次要摸索如何利用云原生的技术劣势，降低成本，晋升资源利用率。在往年大促中，针对外围集群采纳独享共享实例混部，对立了底层资源，联合交易业务云盘化使得混部单元大促成本降落30%+。 云原生数据库管控随着云原生技术的遍及，越来越多的利用开始运行在Kubernetes上，Kubernetes有一统利用交付界面的趋势。数据库产品外部也在全面推动云原生，冀望通过资源池化及与云基础设施深度集成开释数据库产品能力，数据库管控本全面基于Kubernetes来编排DB实例。因为繁多的Kubernetes集群规模限度无奈满足DB实例的部署规模，所以咱们设计了一套多集群的调度编排零碎，可能反对多个Kubernetes集群的资源调度。 接入Kubernetes集群的Node，数据库不同的产品会在以下2种模式下依据业务特定自行抉择： 单实例独占ECS Node：节点实例独占，资源调度工作有ECS实现，特点是节点间隔离性较好，然而因为ECS的资源严格限度，也导致了一些在稳定性和性能的问题ECS资源池模式：数据库团队保护一个由较大规格的ECS组成的资源池，由数据库的二次调度在资源池内进行调度。特点是能够在多Pod间协调资源，晋升产品的稳定性和性能。对于第二种，构建ECSPool由数据库团队进行二次调度的场景下，要求采纳cgroup隔离组的模式进行实例Pod的资源限度，对于云上的客户而言，存在两种实例状态： 独享：采纳cgroup外面cpu-set的模式来进行cpu资源的绑定共享：采纳cgroup隔离组的外面的cpu-share来进行资源隔离，并肯定水平上镜像cpu资源的超卖。底层的ECS资源池会依据两种不同隔离模式严格划分，分为独占资源池和共享资源池。某一个Node，一旦调配了独享实例就不再容许调配共享实例，严格划分了两个独立的资源池。 个别状况下，资源池由阿里云数据库团队来进行对立调度。因为节点池足够大，辨别不同的资源池并不会产生资源利用不佳的状况。但对于服务于企业级的客户而言，因为不与其余客户进行混合部署，这种严格辨别的模式资源利用率就不是最佳。举个例子：客户由4个实例，2个采纳共享模式，2个须要采纳独占模式；依照之前的调度逻辑，客户则必须洽购4台机器能力实现实例的部署。因而，为了解决下面的问题，咱们心愿可能将外围实例和非核心实例混部部署在同一台机器上。同时外围实例采纳CPUSet的形式保障独享局部CPU外围，非核心实例采纳CPUShare的形式共享残余的CPU外围，实现资源的充分利用。 CPUSet和CPUShare模式混部计划独享共享混部的前提是独享实例的性能不受影响，因为必须对共享实例应用的资源进行限度。在Kubernetes中，通过cgroup能够限度pod能够应用的cpu和memory的上上限。其中，对于内存的限度比较简单，给pod设置一个内存最大可用内存，一旦超过内存下限就会触发OOM。对于cpu的限度，Kubernetes采纳cfs quota来限度过程在单位工夫内可用的工夫片。当独享和共享实例在同一台node节点上的时候，一旦实例的工作负载减少，可能会导致独享实例工作负载在不同的cpu外围上来回切换，影响独享实例的性能。所以，为了不影响独享实例的性能，咱们心愿在同一个node上，独享实例和共享实例的cpu可能离开绑定，互不影响。 Kubernetes原生混部实现在linux中，通过cgroup的cpuset子系统能够实现绑定过程到指定的CPU下面，docker也有相干的启动参数来反对绑定容器到指定的CPU上。 --cpuset-cpus="" CPUs in which to allow execution (0-3, 0,1)--cpuset-mems="" Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.Kubernetes 从1.8版本当前，提供了CPU Manager个性来反对cpuset的能力。从Kubernetes 1.12版本开始到目前的1.22版本，该个性还是Beta版。CPU Manager是kubelet中的一个模块，次要工作就是给某些合乎绑核策略的containers绑定到指定的cpu上，从而晋升这些CPU敏感型工作的性能。 目前CPU Manager反对两种Policy，别离为none和static，通过kubelet --cpu-manager-policy设置，将来会减少dynamic policy做Container生命周期内的cpuset动静调整。 none: 为cpu manager的默认值，相当于没有启用cpuset的能力。cpu request对应到cpu share，cpu limit对应到cpu quota。static: 容许为节点上具备某些资源特色的 pod 赋予加强的 CPU 亲和性和独占性。kubelet将在Container启动前调配绑定的cpu set，调配时还会思考cpu topology来晋升cpu affinitystatic策略管理一个共享CPU资源池，最后该资源池蕴含节点上所有的CPU资源。可用的独占性CPU资源数量等于节点的CPU总量减去通过 --kube-reserved 或 --system-reserved 参数保留的CPU 。从1.17版本开始，CPU保留列表能够通过 kublet 的 '--reserved-cpus' 参数显式地设置。 通过 '--reserved-cpus' 指定的显式CPU列表优先于应用 '--kube-reserved' 和 '--system-reserved' 参数指定的保留CPU。 通过这些参数预留的 CPU是以整数形式，按物理内 核 ID 升序从初始共享池获取的。 共享池是 BestEffort 和 Burstable pod 运行 的 CPU汇合。Guaranteed pod中的容器，如果申明了非整数值的CPU requests，也将运行在共享池的CPU上。只有Guaranteed pod中指定了整数型CPUrequests 的容器，才会被调配独占CPU资源。 ...

镜像下载、域名解析、工夫同步请点击 阿里巴巴开源镜像站 实际环境CentOS-7-x86_64-DVD-1810 Docker 19.03.9 Kubernetes version: v1.20.5 开始之前1台Linux操作或更多，兼容运行deb,rpm 确保每台机器2G内存或以上 确保当控制面板的结点机，其CPU核数为双核或以上 确保集群中的所有机器网络互连 指标装置一个Kubernetes集群控制面板基于集群装置一个Pod networ以便集群之间能够互相通信 装置领导装置Docker装置过程略 留神，装置docker时，须要指Kubenetes反对的版本（参见如下），如果装置的docker版本过高导致，会提醒以下问题 WARNING SystemVerification]: this Docker version is not on the list of validated versions: 20.10.5. Latest validated version: 19.03装置docker时指定版本 sudo yum install docker-ce-19.03.9 docker-ce-cli-19.03.9 containerd.io如果没有装置docker，运行kubeadm init时会提醒以下问题 cannot automatically set CgroupDriver when starting the Kubelet: cannot execute 'docker info -f {{.CgroupDriver}}': executable file not found in $PATH[preflight] WARNING: Couldn't create the interface used for talking to the container runtime: docker is required for container runtime: exec: "docker": executable file not found in $PATH装置kubeadm如果没有装置的话，先装置kubeadm，如果已装置，可通过apt-get update && apt-get upgrade或yum update命令更新kubeadm最新版 ...

简介：本次课程次要分为三大部分，首先将介绍慢调用的危害以及常见的起因；其次介绍慢调用的分析方法以及最佳实际；最初将通过几个案例来去演示一下慢调用的剖析过程。 作者：李煌东 大家好，我是阿里云的李煌东。明天我为大家分享 Kubernetes 监测公开课第四节，如何应用 Kubernetes 监测定位慢调用。明天的课程次要分为三大部分，首先我会介绍一下慢调用的危害以及常见的起因；其次我会介绍慢调用的分析方法以及最佳实际；最初通过几个案例来去演示一下慢调用的剖析过程。 慢调用危害及常见起因 在开发软件过程中，慢调用是十分常见的异样。慢调用可能带来的危害包含： 前端业务维度：首先慢调用可能会引起前端加载慢的问题，前端加载慢可能会进一步导致利用卸载率高，进而影响品牌的口碑。 我的项目交付的维度：因为接口慢导致达不到 SLO，进而导致我的项目延期。 业务架构稳定性：当接口调用慢时，非常容易引起超时，当其余业务服务都依赖这个接口，那么就会引发大量重试，进而导致资源耗尽，最终导致局部服务或者整个服务不可用的雪崩的景象。 所以，看似一个无关痛痒的慢调用可能暗藏着微小危险，咱们应该引起警觉。对慢调用最好都不要去漠视它，应该尽可能去剖析其背地的起因，从而进行危险管制。 产生慢调用的起因有哪些？产生慢调用的起因是千千万万的，归纳起来有五个常见起因。 第一个是资源使用率过高问题，比如说 CPU 内存、磁盘、网卡等等。当这些使用率过高的时候，非常容易引起服务慢。 第二个是代码设计的问题，通常来说如果 SQL 它关联了很多表，做了很多表，那么会十分影响 SQL 执行的性能。 第三个是依赖问题，服务本身没有问题，但调用上游服务时上游返回慢，本身服务处于期待状态，也会导致服务慢调用的状况。 第四个是设计问题，比如说海量数据的表十分大，亿级别数据查问没有分库分表，那么就会非常容易引起慢查问。相似的状况还有耗时的操作没有做缓存。 第五个是网络方面问题，比如说跨洲调用，跨洲调用是物理间隔太大了，导致往返工夫比拟长，进而导致慢调用。或者两点之间的网络性能可能比拟差。比如说有丢包重传率，重传率高的问题。 明天咱们的例子围绕这五个方面，咱们一起来看一下。 定位慢调用一般来说有什么样的步骤，或者说有什么样的最佳实际呢？我这里总结的为三个方面：黄金信号 + 资源指标 + 全局架构。 咱们先来看一下黄金信号。首先，黄金信号是出自谷歌 SRE 圣经外面的 Site Reliability Engineering 一书。用来表征零碎是否衰弱的最小指标的汇合，这其中包含： 延时--用来形容零碎执行申请破费的工夫。常见指标包含均匀响应工夫，P90/P95/P99 这些分位数，这些指标可能很好的表征这个零碎对外响应的快还是慢，是比拟直观的。 流量--用来表征服务忙碌水平，典型的指标有 QPS、TPS。 谬误--也就是咱们常见的相似于协定里 HTTP 协定外面的 500、400 这些，通常如果谬误很多的话，阐明可能曾经呈现问题了。 饱和度--就是资源水位，通常来说靠近饱和的服务比拟容易呈现问题，比如说磁盘满了，导致日志没方法写入，进而导致服务响应。典型的那些资源有 CPU、 内存、磁盘、队列长度、连接数等等。 除了黄金信号，咱们还须要关注一个资源指标。驰名的性能剖析大神 Brandan Gregg ，在他的性能剖析方法论文章中提到一个 USE 办法。USE 办法是从资源角度进行剖析，它是对于每一个资源去查看 utilization（使用率），saturation （饱和度），error（谬误） ，合起来就是 USE 了，查看这三项基本上可能解决 80% 的服务问题，而你只须要破费 5% 的工夫。 image.gif ...

13、service四层网络负载 创立[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# vim my-app.yaml[root@k8s-master-node1 ~/yaml/test]# cat my-app.yamlapiVersion: apps/v1kind: Deploymentmetadata: labels: app: my-dep name: my-depspec: replicas: 3 selector: matchLabels: app: my-dep template: metadata: labels: app: my-dep spec: containers: - image: nginx name: nginx[root@k8s-master-node1 ~/yaml/test]# kubectl apply -f my-app.yaml deployment.apps/my-dep created[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# kubectl get deployments.apps NAME READY UP-TO-DATE AVAILABLE AGEingress-demo-app 2/2 2 2 155mmy-dep 3/3 3 3 71snfs-client-provisioner 1/1 1 1 140m[root@k8s-master-node1 ~/yaml/test]#应用标签查找[root@k8s-master-node1 ~/yaml/test]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELShello-27285682--1-q2p6x 0/1 Completed 0 3m15s controller-uid=5e700c2e-29b3-4099-be17-b005d8077284,job-name=hello-27285682hello-27285683--1-b2qgn 0/1 Completed 0 2m15s controller-uid=d7455e28-bd37-4fdf-bf47-de7ae6b4b7bb,job-name=hello-27285683hello-27285684--1-glsmp 0/1 Completed 0 75s controller-uid=9cc7f28d-e780-49fb-a23a-ab725413ea8a,job-name=hello-27285684hello-27285685--1-s7ws5 0/1 ContainerCreating 0 15s controller-uid=169e3631-6981-4df8-bfee-6a4f4632b713,job-name=hello-27285685ingress-demo-app-694bf5d965-8rh7f 1/1 Running 0 157m app=ingress-demo-app,pod-template-hash=694bf5d965ingress-demo-app-694bf5d965-swkpb 1/1 Running 0 157m app=ingress-demo-app,pod-template-hash=694bf5d965my-dep-5b7868d854-kzflw 1/1 Running 0 2m34s app=my-dep,pod-template-hash=5b7868d854my-dep-5b7868d854-pfhps 1/1 Running 0 2m34s app=my-dep,pod-template-hash=5b7868d854my-dep-5b7868d854-v67ll 1/1 Running 0 2m34s app=my-dep,pod-template-hash=5b7868d854nfs-client-provisioner-dc5789f74-5bznq 1/1 Running 0 141m app=nfs-client-provisioner,pod-template-hash=dc5789f74pi--1-k5cbq 0/1 Completed 0 25m controller-uid=2ecfcafd-f848-403b-b37f-9c145a0dc8cc,job-name=piredis-app-86g4q 1/1 Running 0 27m controller-revision-hash=77c8899f5d,name=fluentd-redis,pod-template-generation=1redis-app-rt92n 1/1 Running 0 27m controller-revision-hash=77c8899f5d,name=fluentd-redis,pod-template-generation=1redis-app-vkzft 1/1 Running 0 27m controller-revision-hash=77c8899f5d,name=fluentd-redis,pod-template-generation=1web-0 1/1 Running 0 91m app=nginx,controller-revision-hash=web-57c5cc66df,statefulset.kubernetes.io/pod-name=web-0web-1 1/1 Running 0 91m app=nginx,controller-revision-hash=web-57c5cc66df,statefulset.kubernetes.io/pod-name=web-1web-2 1/1 Running 0 90m app=nginx,controller-revision-hash=web-57c5cc66df,statefulset.kubernetes.io/pod-name=web-2[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# kubectl get pod -l app=my-depNAME READY STATUS RESTARTS AGEmy-dep-5b7868d854-kzflw 1/1 Running 0 2m42smy-dep-5b7868d854-pfhps 1/1 Running 0 2m42smy-dep-5b7868d854-v67ll 1/1 Running 0 2m42s[root@k8s-master-node1 ~/yaml/test]#命令行裸露端口[root@k8s-master-node1 ~/yaml/test]# kubectl expose deployment my-dep --port=8000 --target-port=80service/my-dep exposed[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# kubectl get serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEingress-demo-app ClusterIP 10.96.145.40 <none> 80/TCP 158mkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 160mmy-dep ClusterIP 10.96.241.162 <none> 8000/TCP 11snginx ClusterIP None <none> 80/TCP 92m[root@k8s-master-node1 ~/yaml/test]#yaml文件裸露端口apiVersion: v1kind: Servicemetadata: labels: app: my-dep name: my-depspec: selector: app: my-dep ports: - port: 8000 protocol: TCP targetPort: 80ClusterIP形式裸露命令行kubectl expose deployment my-dep --port=8000 --target-port=80 --type=ClusterIPyaml形式apiVersion: v1kind: Servicemetadata: labels: app: my-dep name: my-depspec: ports: - port: 8000 protocol: TCP targetPort: 80 selector: app: my-dep type: ClusterIP拜访测试[root@k8s-master-node1 ~/yaml/test]# curl -I 10.96.241.162:8000HTTP/1.1 200 OKServer: nginx/1.21.4Date: Wed, 17 Nov 2021 09:30:27 GMTContent-Type: text/htmlContent-Length: 615Last-Modified: Tue, 02 Nov 2021 14:49:22 GMTConnection: keep-aliveETag: "61814ff2-267"Accept-Ranges: bytes[root@k8s-master-node1 ~/yaml/test]#NodePort形式裸露命令行kubectl expose deployment my-dep --port=8000 --target-port=80 --type=NodePortyaml形式apiVersion: v1kind: Servicemetadata: labels: app: my-dep name: my-depspec: ports: - port: 8000 protocol: TCP targetPort: 80 selector: app: my-dep type: NodePort查看service[root@k8s-master-node1 ~/yaml/test]# kubectl get serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEingress-demo-app ClusterIP 10.96.145.40 <none> 80/TCP 165mkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 167mmy-dep NodePort 10.96.241.162 <none> 8000:32306/TCP 7m13snginx ClusterIP None <none> 80/TCP 99m[root@k8s-master-node1 ~/yaml/test]#拜访测试应用kubernetes任何node的ip都能够拜访 ...

简介：本文分享了阿里巴巴服务网格技术三位一体策略背地的思考和实际，对于阿里云服务网格 ASM 的一些产品性能，包含最近公布的一些性能，欢送大家点击下文查看详情～作者：宗泉、宇曾 阿里巴巴三位一体策略阿里云外部很早就提出了开源、自研、商业化三位一体策略，先谈谈我对它的了解。 多年的软件开发教训通知咱们，开发出一款杰出的软件有一些要害因素： 沟通反馈实际在软件开发过程中咱们不能闭门造车，不能随便“发明”业务场景需要。业务场景和产品性能须要提炼，开源给咱们提供了一个独特翻新的平台，基于这个平台，大家能够独特定义一些标准和规范。不同的厂商遵循相应的规范，客户就没有被锁定的危险，能够不停地迁徙，总是能找到最好的厂商，将本人的业务放上去，用最简略、最便捷、最经济的形式来经营本人的业务。 很多客户在抉择阿里云服务网格的时候，有一条比拟重要的评判指标：是否和社区 Istio 兼容。因为客户放心被锁定，强依赖于阿里云； 而后说到自研，兴许有同学会问到，开源与自研是否互相矛盾，答案是否定的。 因为，咱们这里提到的自研，其实是基于开源的自研，并非摒弃开源的版本，从新造个新的轮子。自研是指咱们要对开源产品有足够深度的了解： 要把握所有源代码；领有批改每一行代码的能力当然，自研还有意味着可能有本身业务特定独有的需要场景，一些没方法标准化的场景。基于自研，对开源产品的深度把控和了解，咱们将有通用客户场景需要的性能搬到云上，封装成云产品，让云上客户能够开箱即用去应用，这是商业化的初心。 回到阿里团体外部，开源、自研、商业其实是一个技术飞轮。 对于阿里的技术同学来说，每年的 双11 都是一场“盛宴”。为了让顾客有顺滑的购物体验，给商户提供更多样化的让利流动，阿里电商平台对于效率、可靠性、规模性的要求在 双11 的驱动下成倍进步，激发着技术人的后劲。作为根底技术外围之一，阿里巴巴中间件也会在每年 双11 迎来一次技术的全面演进和降级。 阿里在开源社区中推出了 Dubbo、RocketMQ、Nacos、Seata 等多个为人熟知的开源我的项目，激励宽广开发者共建中间件生态体系，也包含了 ServiceMesh 相干技术。 拥抱服务网格开源技术 阿里云外部很早就开始调研并实际 ServiceMesh 技术 。2018 年，Istio 正式公布 1.0 版本，进入公众视线。在这更早期间，阿里巴巴外部曾经开始参加相干生态开源产品的奉献。 阿里云在微服务生态畛域，也有一些开源的服务化框架，比方 Dubbo 、Spring Cloud Alibaba，能够说微服务畛域，因为电商这层试验大平台，阿里云在这方面是妥妥滴“技术专家”，咱们会进行横向性能比照，比照 Sidecar 模式和原有模式的优缺点；在这过程中，咱们也积极参与 Istio 微服务相干生态我的项目的开源奉献；例如 Envoy、 Dubbo Filter 、RocketMQ Filter 、Nacos Mcp 性能、Spring Cloud Alibaba、Sentinel 等。 目前风行着各种各样的服务框架，如何基于不同的框架开发的可互通的业务？服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。 Dubbo 和 HSF 都是阿里巴巴外部在应用的微服务 RPC 框架。这些框架在阿里业务一直迭代开发的过程提供了松软的底层微服务能力反对，保障了一个又一个 双11 大促。 随同着云原生的浪潮，以及整体资源老本优化、DevOps 等大背景下，原有微服务框架 Dubbo 、HSF 的一些毛病也在缓缓裸露进去，比方多语言的反对，配置和代码逻辑拆散等，SDK 版本升级须要推动业务方，收买的业务采纳不同框架互通的问题等。 ...

10、job工作 应用perl，做pi的圆周率计算[root@k8s-master-node1 ~/yaml/test]# vim job.yaml [root@k8s-master-node1 ~/yaml/test]# cat job.yaml apiVersion: batch/v1kind: Jobmetadata: name: pispec: template: spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never backoffLimit: 4[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# kubectl apply -f job.yaml job.batch/pi created[root@k8s-master-node1 ~/yaml/test]#查看工作[root@k8s-master-node1 ~/yaml/test]# kubectl get podNAME READY STATUS RESTARTS AGEingress-demo-app-694bf5d965-8rh7f 1/1 Running 0 134mingress-demo-app-694bf5d965-swkpb 1/1 Running 0 134mnfs-client-provisioner-dc5789f74-5bznq 1/1 Running 0 118mpi--1-k5cbq 0/1 Completed 0 115sredis-app-86g4q 1/1 Running 0 4m14sredis-app-rt92n 1/1 Running 0 4m14sredis-app-vkzft 1/1 Running 0 4m14sweb-0 1/1 Running 0 67mweb-1 1/1 Running 0 67mweb-2 1/1 Running 0 67m[root@k8s-master-node1 ~/yaml/test]# kubectl get jobNAME COMPLETIONS DURATION AGEpi 1/1 84s 2m[root@k8s-master-node1 ~/yaml/test]#查看计算结果[root@k8s-master-node1 ~/yaml/test]# kubectl logs pi--1-k5cbq 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901[root@k8s-master-node1 ~/yaml/test]#11、CronJobCronJobs 对于创立周期性的、重复反复的工作很有用，例如执行数据备份或者发送邮件。CronJobs 也能够用来打算在指定工夫来执行的独立工作，例如打算当集群看起来很闲暇时 执行某个 Job。 ...

Users Accounts认证kubeconfig配置文件之前有提到过,K8S间的通信是通过https实现,https通信每次都须要认证,比方咱们在命令行输出命令 [root@k8s-master ~]# kubectl get pod都须要https认证,而且https是无状态链接 意味着每次拜访 都须要附带证书,如果这所有都手动指定实现,实际操作必定十分不不便,为了简化连贯和方便使用,K8s应用kubeconfig配置文件来简化应用时文件附带认证信息 kubeconfig配置文件:3种搜寻门路1.指定证书地位 优先级最高2.通过环境变量 &dollar;KUBECONFIG加载config文件3.读取用户家目录 &dollar;HOME/.kube/config kubeconfig配置文件:将用户名、认证信息等组织一起，便于认证到API Server上的认证信息文件;反对一个文件中保留m个集群的n个认证信息; kubectl选项中能够看到能够指定证书与秘钥[root@k8s-master kubernetes]# kubectl options The following options can be passed to any command: --add-dir-header=false: If true, adds the file directory to the header of the log messages --alsologtostderr=false: log to standard error as well as files --as='': Username to impersonate for the operation --as-group=[]: Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --cache-dir='/root/.kube/cache': Default cache directory --certificate-authority='': Path to a cert file for the certificate authority --client-certificate='': Path to a client certificate file for TLS #客户端证书 --client-key='': Path to a client key file for TLS #指客户端秘钥 --cluster='': The name of the kubeconfig cluster to use --context='': The name of the kubeconfig context to use --insecure-skip-tls-verify=false: If true, the server's certificate will not be checked for validity. This willmake your HTTPS connections insecure...kubeconfig配置文件 ...

概述:1. kubernetes API 访问控制官网文档：https://kubernetes.io/zh/docs...kubernetes api分为：认证、受权、准入管制 用户通过 kubectl、客户端库或者通过发送 REST 申请拜访 API。 用户（自然人）和 Kubernetes 服务账户 都能够被受权进行 API 拜访。 申请达到 API 服务器后会通过几个阶段，具体阐明如图：首先看一下 Kubernetes API 申请的发动，申请的发动分为两个局部：第一个局部是人机交互的过程。 是大家十分相熟的用 kubectl 对 apiserver 的一个申请过程 应用的是 Users Accounts一般账户；第二个局部是 Pod 中的业务逻辑与 apiserver 之间的交互 应用的是Service Accounts 服务帐号。当咱们的 apiserver 收到申请后，就会开启访问控制流程。这外面分为三个步骤：Authentication 认证阶段：判断申请用户是否为可能拜访集群的非法用户。如果用户是个非法用户，那 apiserver会返回一个 401 的状态码，并终止该申请；如果用户非法的话，咱们的 apiserver 会进入到访问控制的第二阶段 Authorization：受权阶段。在该阶段中apiserver 会判断用户是否有权限进行申请中的操作。如果无权进行操作，apiserver 会返回 403的状态码，并同样终止该申请；如果用户有权进行该操作的话，访问控制会进入到第三个阶段：AdmissionControl。在该阶段中 apiserver 的admission controller 会判断申请是否是一个平安合规的申请。如果最终验证通过的话，访问控制流程才会完结。此时咱们的申请将会转换为一个 Kubernetes objects 相应的变更申请，最终长久化到 ETCD 中。 认证（任意一种） -->受权（个别是rbac 和 node）–> 准入管制（本人抉择） 2. 认证 Authentication认证有多种，能够启动一种或多种认证形式，只有有一种认证形式通过，就不再对其它形式认证，通常启动X 509 Client Certs和Service Accout Tokens两种认证形式 ...

8、ConfigMap抽取利用配置，并且能够自动更新 创立配置文件[root@k8s-master-node1 ~/yaml/test]# vim configmap.yaml[root@k8s-master-node1 ~/yaml/test]# cat configmap.yaml apiVersion: v1data: redis.conf: | appendonly yeskind: ConfigMapmetadata: name: redis-conf namespace: default[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# kubectl apply -f configmap.yaml configmap/redis-conf created[root@k8s-master-node1 ~/yaml/test]#查看配置[root@k8s-master-node1 ~/yaml/test]# kubectl get configmaps NAME DATA AGEkube-root-ca.crt 1 110mredis-conf 1 18s[root@k8s-master-node1 ~/yaml/test]#9、DaemonSetDaemonSet 确保全副（或者某些）节点上运行一个 Pod 的正本。当有节点退出集群时， 也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创立的所有 Pod。 DaemonSet 的一些典型用法： 在每个节点上运行集群存守护过程在每个节点上运行日志收集守护过程在每个节点上运行监控守护过程一种简略的用法是为每种类型的守护过程在所有的节点上都启动一个 DaemonSet。一个略微简单的用法是为同一种守护过程部署多个 DaemonSet；每个具备不同的标记， 并且对不同硬件类型具备不同的内存、CPU 要求。 创立[root@k8s-master-node1 ~/yaml/test]# vim daemonset.yaml[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# cat daemonset.yaml apiVersion: apps/v1kind: DaemonSetmetadata: name: redis-app labels: k8s-app: redis-appspec: selector: matchLabels: name: fluentd-redis template: metadata: labels: name: fluentd-redis spec: tolerations: # this toleration is to have the daemonset runnable on master nodes # remove it if your masters can't run pods - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd-redis image: redis command: - redis-server - "/redis-master/redis.conf" #指的是redis容器外部的地位 ports: - containerPort: 6379 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: data mountPath: /data - name: config mountPath: /redis-master readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: data emptyDir: {} - name: config configMap: name: redis-conf items: - key: redis.conf path: redis.conf[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# kubectl apply -f daemonset.yaml daemonset.apps/redis-app created[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]#查看[root@k8s-master-node1 ~/yaml/test]# [root@k8s-master-node1 ~/yaml/test]# kubectl get podNAME READY STATUS RESTARTS AGEingress-demo-app-694bf5d965-8rh7f 1/1 Running 0 130mingress-demo-app-694bf5d965-swkpb 1/1 Running 0 130mnfs-client-provisioner-dc5789f74-5bznq 1/1 Running 0 114mredis-app-86g4q 1/1 Running 0 28sredis-app-rt92n 1/1 Running 0 28sredis-app-vkzft 1/1 Running 0 28sweb-0 1/1 Running 0 64mweb-1 1/1 Running 0 63mweb-2 1/1 Running 0 63m[root@k8s-master-node1 ~/yaml/test]# kubectl get daemonsets.apps NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGEredis-app 3 3 3 3 3 <none> 38s[root@k8s-master-node1 ~/yaml/test]# ...

作者简介：吕冬冬，云知声超算平台架构师， 负责大规模分布式机器学习平台架构设计与性能研发，负责深度学习算法利用的优化与 AI 模型减速。钻研畛域包含高性能计算、分布式文件存储、分布式缓存等。朱唯唯，Juicedata 全栈工程师，负责 JuiceFS CSI Driver 的开发和保护，负责 JuiceFS 在云原生畛域的倒退。云知声 Atlas 团队在 2021 年初开始接触并跟进 JuiceFS 存储，并且在晚期曾经积攒了丰盛的 Fluid 应用教训。近期，云知声团队与 Juicedata 团队合作开发了 Fluid JuiceFS 减速引擎，使用户可能更好地在 Kubernetes 环境中应用 JuiceFS 缓存治理能力。本篇文章解说如何在 Kubernetes 集群中玩转 Fluid + JuiceFS。 背景介绍Fluid 简介CNCF Fluid 是一个开源的 Kubernetes 原生的分布式数据集编排和减速引擎，次要服务于云原生场景下的数据密集型利用，例如大数据利用、AI 利用等，对于 Fluid 更多信息能够参考地址。 Fluid 不是全存储减速和治理，而是利用应用的数据集减速和治理。Fluid 提供了一种更加云原生的形式对数据集进行治理，通过缓存减速引擎实现将底层存储系统的数据 cache 在计算节点的内存或者硬盘上，解决了计算与存储拆散架构中因为数据传输带宽限度以及底层存储带宽与 IOPS 能力限度等问题，导致的 IO 效率不低等问题。Fluid 提供缓存数据调度能力，缓存被纳入 kubernetes 扩大资源，kubernetes 在进行工作的调度的时候，可能参考缓存进行调度策略的调配。 Fluid 有 2个重要的概念：Dataset 与 Runtime Dataset: 数据集是逻辑上相干的一组数据的汇合，统一的文件个性，会被同一运算引擎应用。Runtime: 实现数据集安全性，版本治理和数据减速等能力的执行引擎的接口，定义了一系列生命周期的办法。Fluid 的 Runtime 定义了标准化的接口，Cache Runtime Engine 能够对接多种缓存引擎，提供了用户更灵便的抉择，用户可能针对不同的场景与需要，充分利用缓存引擎减速相应的场景利用。 ...

7、StatefulSetsStatefulSet 是用来治理有状态利用的工作负载 API 对象。 StatefulSet 用来治理 Deployment 和扩大一组 Pod，并且能为这些 Pod 提供序号和唯一性保障。 和 Deployment 雷同的是，StatefulSet 治理了基于雷同容器定义的一组 Pod。但和 Deployment 不同的是，StatefulSet 为它们的每个 Pod 保护了一个固定的 ID。这些 Pod 是基于雷同的申明来创立的，然而不能互相替换：无论怎么调度，每个 Pod 都有一个永恒不变的 ID。 StatefulSet 和其余控制器应用雷同的工作模式。你在 StatefulSet 对象 中定义你冀望的状态，而后 StatefulSet 的 控制器 就会通过各种更新来达到那种你想要的状态。 应用 StatefulSetsStatefulSets 对于须要满足以下一个或多个需要的应用程序很有价值： 稳固的、惟一的网络标识符。稳固的、长久的存储。有序的、优雅的部署和缩放。有序的、主动的滚动更新。在下面，稳固意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不须要任何稳固的标识符或有序的部署、删除或伸缩，则应该应用由一组无状态的正本控制器提供的工作负载来部署应用程序，比方 Deployment 或者 ReplicaSet 可能更实用于您的无状态利用部署须要。 限度给定 Pod 的存储必须由 PersistentVolume 驱动 基于所申请的 storage class 来提供，或者由管理员事后提供。删除或者膨胀 StatefulSet 并不会删除它关联的存储卷。这样做是为了保障数据安全，它通常比主动革除 StatefulSet 所有相干的资源更有价值。StatefulSet 以后须要无头服务 来负责 Pod 的网络标识。您须要负责创立此服务。当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保障。为了实现 StatefulSet 中的 Pod 能够有序和优雅的终止，能够在删除之前将 StatefulSet 缩放为 0。在默认 Pod 管理策略(OrderedReady) 时应用 滚动更新，可能进入须要 人工干预 能力修复的损坏状态。 ...

大家好，我是张晋涛。 在我之前公布的文章 《云原生时代下的容器镜像平安》（系列）中，我提到过 Kubernetes 集群的外围组件 -- kube-apiserver，它容许来自终端用户或集群的各组件与之进行通信（例如，查问、创立、批改或删除 Kubernetes 资源）。 本篇咱们将聚焦于 kube-apiserver 申请处理过程中一个很重要的局部 -- 准入控制器（Admission Controller） K8s 的准入控制器是什么K8s 中的申请解决流程在聊 K8s 准入控制器是什么之前，让咱们先来回顾一下 Kubernetes API 的解决具体申请的过程。 图 1 ，Kubernetes API 解决申请的过程 （从 API Handler 到 etcd 长久化的过程） 如上图所示，每个 API 的申请从开始被 kube-apiserver 接管到最终长久化到 ETCD 的过程，即为 Kubernetes API 的申请解决流程。 它次要蕴含了以下几个局部： API Handler -- 次要负责提供服务，接管申请。对于其外部实现而言，申请会先到 FullHandlerChain （它是由 DefaultBuildHandlerChain 构建进去的）是一个 director 对象 type director struct { name string goRestfulContainer *restful.Container nonGoRestfulMux *mux.PathRecorderMux}director依据配置进行初始化，如果 goRestfulContainer的 WebServices 的 RootPath 是 /apis，或者申请前缀与 RootPath 匹配，则进入 Restful 解决链路。 ...

- 作者：SRE运维博客 博客地址： https://www.cnsre.cn/ 文章地址：https://www.cnsre.cn/posts/211129946481/ 相干话题：https://www.cnsre.cn/kubernetes/ - Taint 和 Toleration（污点和容忍）在 k8s 集群中，节点亲和性 NodeAffinity 是一种 Pod 上定义的属性，可能让 Pod 能够按找咱们的需要调度到指定节点上，而 Taints (污点) 则于NodeAffinity (节点亲和性)是相同的，它是一种 Node 上定义的属性，能够让 Pod 不被调度到带污点的节点上，甚至会对带污点节点上已有的 Pod 进行驱赶。对应的 k8s 能够给 Pod 设置 Tolerations(容忍) 让 Pod 可能对有污点的节点设置容忍，将 Pod 调度到该节点。 Taints 个别是配合 Tolerations 应用的。 为 node 设置污点和容忍NoSchedule: 肯定不能被调度PreferNoSchedule: 尽量不要调度NoExecute: 不仅不会调度, 还会驱赶Node上已有的Pod为 node1 设置 taint： kubectl taint nodes k8s-node1 key1=value1:NoSchedulekubectl taint nodes k8s-node1 key1=value1:NoExecutekubectl taint nodes k8s-node1 key2=value2:NoSchedule查看 node1 上的 taint： kubectl describe nodes k8s-node1 |grep Taint删除下面的 taint： ...

6、Deployments（重点）一个 Deployment 控制器为 Pods和 ReplicaSets提供描述性的更新形式。 形容 Deployment 中的 desired state，并且 Deployment 控制器以受控速率更改理论状态，以达到冀望状态。能够定义 Deployments 以创立新的 ReplicaSets ，或删除现有 Deployments ，并通过新的 Deployments 应用其所有资源。 用例 以下是典型的 Deployments 用例： 创立 Deployment 以开展 ReplicaSet 。ReplicaSet 在后盾创立 Pods。查看 ReplicaSet 开展的状态，查看其是否胜利。 申明 Pod 的新状态 通过更新 Deployment 的 PodTemplateSpec。将创立新的 ReplicaSet ，并且 Deployment 管理器以受控速率将 Pod 从旧 ReplicaSet 挪动到新 ReplicaSet 。每个新的 ReplicaSet 都会更新 Deployment 的批改历史。 回滚到较早的 Deployment 版本，如果 Deployment 的以后状态不稳固。每次回滚都会更新 Deployment 的批改。 扩大 Deployment 以承当更多负载. 暂停 Deployment 对其 PodTemplateSpec 进行批改，而后复原它以启动新的开展。 ...

11月27日，由云原生基金会 CNCF 与阿里云开发者 ACE 联结主办的「KubeMeet ·云原生边缘计算专场」在深圳举办，本次流动围绕云原生边缘容器团队开源我的项目 OpenYurt 的技术架构、企业实际开展， 来自智能制作、互联网金融、电信、交通出行、互联网等行业 80+ 位酷爱开源技术、关注云原生边缘计算方向的开发者来到现场，与 OpenYurt 社区的核心成员、企业级用户进行了深度交换。 流动现场，OpenYurt 我的项目发起人、凋谢原子基金会 TOC Member、阿里云高级技术专家黄玉奇（徙远）介绍了社区背景和近期动静，并发表来自 VMware、Intel、中国电信、浙江大学、阿里巴巴的五位社区成员晋升为 OpenYurt Maintainer。 上面就让咱们一起回顾本次流动上都有哪些精彩霎时。扫描下方金句海报二维码即可回看本次流动现场直播。 精彩回顾关注【阿里巴巴云原生】公众号，后盾回复 1127，即可取得本次流动讲师PPT 分享主题：OpenYurt 简介及近期社区倒退与布局本次演讲围绕 OpenYurt 开源我的项目开展，从 OpenYurt 的诞生背景、近期社区动静、落地行业案例到社区倒退布局。让大家理解到 OpenYurt 是如何保持对规范云原生体系非侵入实现的准则，主打标准化和开放性，以及如何优雅对接上下游边缘计算生态的。 分享主题：OpenYurt v0.5：开启边缘设施的云原生治理能力VMware 主任工程师，刘武明分享了在 OpenYurt v0.5 中引入的新个性，开发者能够通过 Kubernetes-native 操作 CR（客户资源）一样的形式去管制边缘设施，让云原生治理边缘设施成为事实。 分享主题：深刻了解 OpenYurt电信天翼云研发工程师，张力方讲述了边缘计算场景下，原生 Kubernetes 面临的诸多挑战，通过 OpenYurt 来治理边缘应用程序，用户能够取得与核心式云计算利用治理统一的用户体验。深入分析了 OpenYurt 的原理以及架构，揭发了 OpenYurt 是如何在放弃一致性体验的同时，来应答这些挑战的。 分享主题：深服气智能边缘计算平台与 OpenYurt 落地计划摸索与实际深服气云计算研发工程师，赵震通过案例展现为咱们分享了深服气智能边缘计算平台的贵重教训，他们是如何来解决用户业务上云过程中遇到的高时延、大带宽、数据安全危险加剧、生产业务与云端对接老本高、智能化革新难落地等一系列问题，帮忙用户实现生产业务的智能化革新的，同时介绍了如何利用 OpenYurt 的一些性能个性，确保在弱网环境下的服务失常运行。 分享主题：边缘云原生平台建设之路招商云 PaaS 平台负责人，段嘉在现场为咱们分享了针对边缘计算的一些集体了解，包含边缘计算以后的现状，困局以及将来的倒退方向，云原生为传统核心云计算带来了颠覆式的改革，同时也为边缘计算带来微小的改革。 精彩霎时 ...

概述:污点taints是定义在节点之上的键值型属性数据，用于让节点回绝将Pod调度运行于其上， 除非该Pod对象具备接收节点污点的容忍度。而容忍度tolerations是定义在 Pod对象上的键值型属性数据，用于配置其可容忍的节点污点，而且调度器仅能将Pod对象调度至其可能容忍该节点污点的节点之上，如图所示 一个Pod是否被调度到节点上因素有是否节点有污点节点上有污点.Pod是否能容忍这个污点污点和容忍度污点定义在节点的node Spec中，而容忍度则定义在Pod的podSpec中，它们都是键值型数据，但又都额定反对一个成果effect标记，语法格局为key=value:effect，其中key和value的用法及格局与资源注俯－信息类似， 而effect则用于定义对Pod对象的排挤等级，它次要蕴含以下三种类型效用标识 NoSchedule不能容忍此污点的新Pod对象不可调度至以后节点，属于强制型束缚关系，节点上现存的Pod对象不受影响。PreferNoSchedule的柔性束缚版本，即不能容忍此污点的新Pod对象尽量不要调度至以后节点，不过无其余节点可供调度时也容许承受相应的Pod对象。节点上现存的Pod对象不受影响。NoExecute不能容忍此污点的新Pod对象不可调度至以后节点，属于强制型束缚关系，而且节点上现存的Pod对象因节点污点变动或Pod容忍度变动而不再满足匹配规定时，Pod对象将被驱赶。在Pod对象上定义容忍度时，它反对两种操作符：一种是等值比拟Equal,示意容忍度与污点必须在key、value和effect三者之上齐全匹配；另一种是存在性判断Exists，示意二者的key和effect必须齐全匹配，而容忍度中的value字段要应用空值。 Pod调度程序一个节点能够配置应用多个污点，一个Pod对象也能够有多个容忍度，不过二者在进行匹配查看时应遵循如下逻辑。 首先解决每个有着与之匹配的容忍度的污点不能匹配到的污点上，如果存在一个污点应用了NoSchedule效用标识，则回绝调度Pod对象至此节点不能匹配到的污点上，若没有任何一个应用了NoSchedule效用标识，但至多有一个应用了PreferNoScheduler，则应尽量避免将Pod对象调度至此节点如果至多有一个不匹配的污点应用了NoExecute效用标识，则节点将立刻驱赶Pod对象，或者不予调度至给定节点；另外，即使容忍度能够匹配到应用了 NoExecute效用标识的污点，若在定义容忍度时还同时应用tolerationSeconds属性定义了容忍时限，则超出时限后其也将被节点驱赶。应用kubeadm部署的Kubernetes集群，其Master节点将主动增加污点信息以阻止不能容忍此污点的Pod对象调度至此节点，因而，用户手动创立的未特意增加容忍此污点容忍度的Pod对象将不会被调度至此节点 示例1: Pod调度到master 对master:NoSchedule标识容忍[root@k8s-master Scheduler]# kubectl describe node k8s-master.org #查看master污点 效用标识...Taints: node-role.kubernetes.io/master:NoScheduleUnschedulable: false[root@k8s-master Scheduler]# cat tolerations-daemonset-demo.yaml apiVersion: apps/v1kind: DaemonSetmetadata: name: daemonset-demo namespace: default labels: app: prometheus component: node-exporterspec: selector: matchLabels: app: prometheus component: node-exporter template: metadata: name: prometheus-node-exporter labels: app: prometheus component: node-exporter spec: tolerations: #容忍度 容忍master NoSchedule标识 - key: node-role.kubernetes.io/master #是key值 effect: NoSchedule #效用标识 operator: Exists #存在即可 containers: - image: prom/node-exporter:latest name: prometheus-node-exporter ports: - name: prom-node-exp containerPort: 9100 hostPort: 9100[root@k8s-master Scheduler]# kubectl apply -f tolerations-daemonset-demo.yaml [root@k8s-master Scheduler]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdaemonset-demo-7fgnd 2/2 Running 0 5m15s 10.244.91.106 k8s-node2.org <none> <none>daemonset-demo-dmd47 2/2 Running 0 5m15s 10.244.70.105 k8s-node1.org <none> <none>daemonset-demo-jhzwf 2/2 Running 0 5m15s 10.244.42.29 k8s-node3.org <none> <none>daemonset-demo-rcjmv 2/2 Running 0 5m15s 10.244.59.16 k8s-master.org <none> <none>示例2: 为节点增加effect效用标识NoExecute 驱赶所有Pod[root@k8s-master Scheduler]# kubectl taint --helpUpdate the taints on one or more nodes. * A taint consists of a key, value, and effect. As an argument here, it is expressed as key=value:effect. * The key must begin with a letter or number, and may contain letters, numbers, hyphens, dots, and underscores, up to253 characters. * Optionally, the key can begin with a DNS subdomain prefix and a single '/', like example.com/my-app * The value is optional. If given, it must begin with a letter or number, and may contain letters, numbers, hyphens,dots, and underscores, up to 63 characters. * The effect must be NoSchedule, PreferNoSchedule or NoExecute. * Currently taint can only apply to node.Examples: #示例 # Update node 'foo' with a taint with key 'dedicated' and value 'special-user' and effect 'NoSchedule'. # If a taint with that key and effect already exists, its value is replaced as specified. kubectl taint nodes foo dedicated=special-user:NoSchedule # Remove from node 'foo' the taint with key 'dedicated' and effect 'NoSchedule' if one exists. kubectl taint nodes foo dedicated:NoSchedule- # Remove from node 'foo' all the taints with key 'dedicated' kubectl taint nodes foo dedicated- # Add a taint with key 'dedicated' on nodes having label mylabel=X kubectl taint node -l myLabel=X dedicated=foo:PreferNoSchedule # Add to node 'foo' a taint with key 'bar' and no value kubectl taint nodes foo bar:NoSchedule[root@k8s-master Scheduler]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdaemonset-demo-7ghhd 1/1 Running 0 23m 192.168.113.35 k8s-node1 <none> <none>daemonset-demo-cjxd5 1/1 Running 0 23m 192.168.12.35 k8s-node2 <none> <none>daemonset-demo-lhng4 1/1 Running 0 23m 192.168.237.4 k8s-master <none> <none>daemonset-demo-x5nhg 1/1 Running 0 23m 192.168.51.54 k8s-node3 <none> <none>pod-antiaffinity-required-697f7d764d-69vx4 0/1 Pending 0 8s <none> <none> <none> <none>pod-antiaffinity-required-697f7d764d-7cxp2 1/1 Running 0 8s 192.168.51.55 k8s-node3 <none> <none>pod-antiaffinity-required-697f7d764d-rpb5r 1/1 Running 0 8s 192.168.12.36 k8s-node2 <none> <none>pod-antiaffinity-required-697f7d764d-vf2x8 1/1 Running 0 8s 192.168.113.36 k8s-node1 <none> <none>为Node 3打上NoExecute效用标签,驱赶Node所有Pod[root@k8s-master Scheduler]# kubectl taint node k8s-node3 diskfull=true:NoExecute node/k8s-node3 tainted[root@k8s-master Scheduler]# kubectl describe node k8s-node3...CreationTimestamp: Sun, 29 Aug 2021 22:45:43 +0800Taints: diskfull=true:NoExecutenode节点所有Pod曾经被驱赶 但因为Pod 定义为每个节点只能存在一个同类型Pod 所以会被挂起,不会被在其它节点创立[root@k8s-master Scheduler]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdaemonset-demo-7ghhd 1/1 Running 0 31m 192.168.113.35 k8s-node1 <none> <none>daemonset-demo-cjxd5 1/1 Running 0 31m 192.168.12.35 k8s-node2 <none> <none>daemonset-demo-lhng4 1/1 Running 0 31m 192.168.237.4 k8s-master <none> <none>pod-antiaffinity-required-697f7d764d-69vx4 0/1 Pending 0 7m45s <none> <none> <none> <none>pod-antiaffinity-required-697f7d764d-l86td 0/1 Pending 0 6m5s <none> <none> <none> <none>pod-antiaffinity-required-697f7d764d-rpb5r 1/1 Running 0 7m45s 192.168.12.36 k8s-node2 <none> <none>pod-antiaffinity-required-697f7d764d-vf2x8 1/1 Running 0 7m45s 192.168.113.36 k8s-node1 <none> <none>删除污点 Pod从新被创立[root@k8s-master Scheduler]# kubectl taint node k8s-node3 diskfull- node/k8s-node3 untainted[root@k8s-master Scheduler]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdaemonset-demo-7ghhd 1/1 Running 0 34m 192.168.113.35 k8s-node1 <none> <none>daemonset-demo-cjxd5 1/1 Running 0 34m 192.168.12.35 k8s-node2 <none> <none>daemonset-demo-lhng4 1/1 Running 0 34m 192.168.237.4 k8s-master <none> <none>daemonset-demo-m6g26 0/1 ContainerCreating 0 4s <none> k8s-node3 <none> <none>pod-antiaffinity-required-697f7d764d-69vx4 0/1 ContainerCreating 0 10m <none> k8s-node3 <none> <none>pod-antiaffinity-required-697f7d764d-l86td 0/1 Pending 0 9m1s <none> <none> <none> <none>pod-antiaffinity-required-697f7d764d-rpb5r 1/1 Running 0 10m 192.168.12.36 k8s-node2 <none> <none>pod-antiaffinity-required-697f7d764d-vf2x8 1/1 Running 0 10m 192.168.113.36 k8s-node1 <none> <none>参考文档: ...

5、ReplicationControllerReplicationController 确保在任何时候都有特定数量的 Pod 正本处于运行状态。换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。 ReplicationController 如何工作当 Pod 数量过多时，ReplicationController 会终止多余的 Pod。当 Pod 数量太少时，ReplicationController 将会启动新的 Pod。与手动创立的 Pod 不同，由 ReplicationController 创立的 Pod 在失败、被删除或被终止时会被主动替换。例如，在中断性保护（如内核降级）之后，你的 Pod 会在节点上从新创立。因而，即便你的应用程序只须要一个 Pod，你也应该应用 ReplicationController 创立 Pod。ReplicationController 相似于过程管理器，然而 ReplicationController 不是监控单个节点上的单个过程，而是监控跨多个节点的多个 Pod。 在探讨中，ReplicationController 通常缩写为 "rc"，并作为 kubectl 命令的快捷方式。 一个简略的示例是创立一个 ReplicationController 对象来牢靠地无限期地运行 Pod 的一个实例。更简单的用例是运行一个多正本服务（如 web 服务器）的若干雷同正本。 示例： [root@k8s-master-node1 ~/yaml/test]# vim rc.yaml[root@k8s-master-node1 ~/yaml/test]# cat rc.yamlapiVersion: v1kind: ReplicationControllermetadata: name: nginxspec: replicas: 3 selector: app: nginx template: metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80[root@k8s-master-node1 ~/yaml/test]#创立[root@k8s-master-node1 ~/yaml/test]# kubectl apply -f rc.yaml replicationcontroller/nginx created[root@k8s-master-node1 ~/yaml/test]#查看pod[root@k8s-master-node1 ~/yaml/test]# kubectl get podNAME READY STATUS RESTARTS AGEingress-demo-app-694bf5d965-q4l7m 1/1 Running 0 23hingress-demo-app-694bf5d965-v652j 1/1 Running 0 23hnfs-client-provisioner-dc5789f74-nnk77 1/1 Running 1 (8h ago) 22hnginx-87sxg 1/1 Running 0 34snginx-kwrqn 1/1 Running 0 34snginx-xk2t6 1/1 Running 0 34s[root@k8s-master-node1 ~/yaml/test]#查看rc[root@k8s-master-node1 ~/yaml/test]# kubectl describe replicationcontrollers nginxName: nginxNamespace: defaultSelector: app=nginxLabels: app=nginxAnnotations: <none>Replicas: 3 current / 3 desiredPods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 FailedPod Template: Labels: app=nginx Containers: nginx: Image: nginx Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none>Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 102s replication-controller Created pod: nginx-xk2t6 Normal SuccessfulCreate 102s replication-controller Created pod: nginx-kwrqn Normal SuccessfulCreate 102s replication-controller Created pod: nginx-87sxg[root@k8s-master-node1 ~/yaml/test]# ...

概述:先来理解 topology key 字段pod亲和性调度须要各个相干的pod对象运行于"同一地位"， 而反亲和性调度则要求他们不能运行于"同一地位"，这里指定“同一地位” 是通过 topologyKey 来定义的，topologyKey 对应的值是 node 上的一个标签名称，比方各别节点zone=A标签，各别节点有zone=B标签，pod affinity topologyKey定义为zone，那么调度pod的时候就会围绕着A拓扑，B拓扑来调度，而雷同拓扑下的node就为“同一地位”。顾名思义，topology 就是 拓扑的意思这里指的是一个 拓扑域，是指一个范畴的概念，比方一个 Node、一个机柜、一个机房或者是一个地区（如杭州、上海）等，实际上对应的还是 Node 上的标签。这里的 topologyKey 对应的是 Node 上的标签的 Key（没有Value），能够看出，其实 topologyKey 就是用于筛选 Node 的。通过这种形式，咱们就能够将各个 Pod 进行跨集群、跨机房、跨地区的调度了。 查看 podAffinity的具体阐明[root@k8s-master Scheduler]# kubectl explain pods.spec.affinityKIND: PodVERSION: v1RESOURCE: affinity <Object>DESCRIPTION: If specified, the pod's scheduling constraints Affinity is a group of affinity scheduling rules.FIELDS: nodeAffinity <Object> #节点亲和 Describes node affinity scheduling rules for the pod. podAffinity <Object> #Pod亲和 Describes pod affinity scheduling rules (e.g. co-locate this pod in the same node, zone, etc. as some other pod(s)). podAntiAffinity <Object> #Pod反亲和 Describes pod anti-affinity scheduling rules (e.g. avoid putting this pod in the same node, zone, etc. as some other pod(s)). #亲和与反亲和中又分硬亲和 软亲和前一节提到的Node亲和一样不在累述[root@k8s-master Scheduler]# kubectl explain pods.spec.affinity.podAffinity FIELDS: preferredDuringSchedulingIgnoredDuringExecution <[]Object>... requiredDuringSchedulingIgnoredDuringExecution <[]Object>...#Pod反亲和[root@k8s-master Scheduler]# kubectl explain pods.spec.affinity.podAntiAffinityFIELDS: preferredDuringSchedulingIgnoredDuringExecution <[]Object>...ffinityTerm; the node(s) with the highest sum are the most preferred. requiredDuringSchedulingIgnoredDuringExecution <[]Object>...[root@k8s-master Scheduler]# kubectl explain pods.spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution labelSelector <Object> A label query over a set of resources, in this case pods. namespaces <[]string> namespaces specifies which namespaces the labelSelector applies to (matches against); null or empty list means "this pod's namespace" topologyKey <string> -required- #拓扑标签 应用哪一个标签为地位标签(必选字段) This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.示例1: podAffinity Pod硬亲和requiredDuringSchedulingIgnoredDuringExecution ...

前言在k8s集群建设过程中，个别状况下咱们部署的 Pod 是通过集群的主动调度策略来抉择节点的，默认状况下调度器思考的是资源足够，并且负载尽量均匀。然而有的时候咱们须要可能更加细粒度的去管制 Pod 的调度；有时咱们心愿对内和对外的两类业务别离跑在不同的节点上，互相有依赖的两个pod跑在同一节点上，等状况；这就须要咱们更好的管制pod的部署；k8s给咱们提供了亲和性和反亲和性，污点(taint)和Toleration（容忍）等概念。 节点node亲和性其中又分为硬亲和与软亲和硬亲和示意条件必须满足软亲和示意尽量满足节点亲和 Node affinity:硬亲和示意条件必须满足条件requiredDuringSchedulingIgnoredDuringExecution示意pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution示意pod部署之后运行的时候，如果节点标签产生了变动，不再满足pod指定的条件，pod也会持续运行。软亲和示意尽量满足条件preferredDuringSchedulingIgnoredDuringExecution示意优先部署到满足条件的节点上，如果没有满足条件的节点，就疏忽这些条件，依照失常逻辑部署。查看nodeAffinity的具体阐明[root@k8s-master scheduler]# kubectl explain pods.spec.affinity.nodeAffinity KIND: Pod...FIELDS: preferredDuringSchedulingIgnoredDuringExecution <[]Object> #软亲和 The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding matchExpressions; the node(s) with the highest sum are the most preferred. requiredDuringSchedulingIgnoredDuringExecution <Object> #硬亲和 If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node. [root@k8s-master ~]# kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution #硬亲和详情阐明...FIELDS: nodeSelectorTerms <[]Object> -required- #节点抉择条件 Required. A list of node selector terms. The terms are ORed.[root@k8s-master scheduler]# kubectl explain pods.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution #软亲和详情阐明...FIELDS: preference <Object> -required- #亲和偏差与权重一起应用 A node selector term, associated with the corresponding weight. weight <integer> -required- #权重 Weight associated with matching the corresponding nodeSelectorTerm, in the range 1-100.[root@k8s-master scheduler]# kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecutionKIND: PodVERSION: v1RESOURCE: requiredDuringSchedulingIgnoredDuringExecution <Object>DESCRIPTION: If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node. A node selector represents the union of the results of one or more label queries over a set of nodes; that is, it represents the OR of the selectors represented by the node selector terms.FIELDS: nodeSelectorTerms <[]Object> -required- Required. A list of node selector terms. The terms are ORed.示例1: 节点硬亲和[root@k8s-master Scheduler]# cat pod-with-nodeselector.yaml apiVersion: v1kind: Podmetadata: name: pod-with-nodeselectorspec: containers: - name: demoapp image: ikubernetes/demoapp:v1.0 nodeSelector: #硬亲和选项 gpu: '' #为空[root@k8s-master Scheduler]# kubectl get podNAME READY STATUS RESTARTS AGEdeployment-demo-5fddfb8ffc-lssq8 1/1 Running 0 23mdeployment-demo-5fddfb8ffc-r277n 1/1 Running 0 23mdeployment-demo-5fddfb8ffc-wrpjx 1/1 Running 0 23mdeployment-demo-5fddfb8ffc-zzwck 1/1 Running 0 23mpod-with-nodeselector 0/1 Pending 0 3m8s #挂起状态[root@k8s-master Scheduler]# kubectl describe pod pod-with-nodeselector......Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 15s default-scheduler 0/4 nodes are available: 4 node(s) didn't match node selector. #提醒所有节点没有匹配的标签 Warning FailedScheduling 15s default-scheduler 0/4 nodes are available: 4 node(s) didn't match node selector.[root@k8s-master Scheduler]# kubectl label node k8s-node3 gpu='' #给node3 打标签gpu为空node/k8s-node3 labeled[root@k8s-master Scheduler]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdeployment-demo-5fddfb8ffc-lssq8 1/1 Running 0 24m 192.168.113.14 k8s-node1 <none> <none>deployment-demo-5fddfb8ffc-r277n 1/1 Running 0 24m 192.168.12.12 k8s-node2 <none> <none>deployment-demo-5fddfb8ffc-wrpjx 1/1 Running 0 24m 192.168.12.11 k8s-node2 <none> <none>deployment-demo-5fddfb8ffc-zzwck 1/1 Running 0 24m 192.168.51.19 k8s-node3 <none> <none>pod-with-nodeselector 1/1 Running 0 3m59s 192.168.51.20 k8s-node3 <none> <none> #运行在node3[root@k8s-master Scheduler]# kubectl label node k8s-node3 gpu- #删除标签不会对已创立的Pod产生影响，因为调度只产生在创立之前node/k8s-node3 labeled[root@k8s-master Scheduler]# kubectl get podNAME READY STATUS RESTARTS AGEdeployment-demo-5fddfb8ffc-lssq8 1/1 Running 0 28mdeployment-demo-5fddfb8ffc-r277n 1/1 Running 0 28mdeployment-demo-5fddfb8ffc-wrpjx 1/1 Running 0 28mdeployment-demo-5fddfb8ffc-zzwck 1/1 Running 0 28mpod-with-nodeselector 1/1 Running 0 8m9s[root@k8s-master Scheduler]# cat node-affinity-required-demo.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: node-affinity-required namespace: defaultspec: replicas: 5 selector: matchLabels : app: demoapp ctlr: node-affinity-required template: metadata: labels : app: demoapp ctlr: node-affinity-required spec: containers : - name: demoapp image: ikubernetes/demoapp:v1.0 livenessProbe : httpGet: path: '/livez' port: 80 initialDelaySeconds: 5 readinessProbe: httpGet : path: '/readyz' port: 80 initialDelaySeconds: 15 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: #匹配条件 - key: gpu #领有这个标签 operator: Exists - key: node-role.kubernetes.io/master #不能为主节点 两个条件同时满足 operator: DoesNotExist[root@k8s-master Scheduler]# kubectl apply -f node-affinity-required-demo.yaml[root@k8s-master Scheduler]# kubectl get podNAME READY STATUS RESTARTS AGEnode-affinity-required-5cb67df4b-d5nk6 0/1 Pending 0 3m51snode-affinity-required-5cb67df4b-m6zxf 0/1 Pending 0 3m52snode-affinity-required-5cb67df4b-sq5k9 0/1 Pending 0 3m51snode-affinity-required-5cb67df4b-tvpwf 0/1 Pending 0 3m51snode-affinity-required-5cb67df4b-vkx7j 0/1 Pending 0 3m52spod-with-nodeselector 0/1 Pending 0 31m #Pod挂起[root@k8s-master Scheduler]# kubectl label node k8s-node2 gpu='true'node/k8s-node2 labeled #为节点增加标签以符合条件[root@k8s-master Scheduler]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnode-affinity-required-5cb67df4b-d5nk6 0/1 ContainerCreating 0 5m14s <none> k8s-node2 <none> <none>node-affinity-required-5cb67df4b-m6zxf 0/1 ContainerCreating 0 5m15s <none> k8s-node2 <none> <none>node-affinity-required-5cb67df4b-sq5k9 0/1 ContainerCreating 0 5m14s <none> k8s-node2 <none> <none>node-affinity-required-5cb67df4b-tvpwf 0/1 ContainerCreating 0 5m14s <none> k8s-node2 <none> <none>node-affinity-required-5cb67df4b-vkx7j 0/1 ContainerCreating 0 5m15s <none> k8s-node2 <none> <none>示例2: nodeAffinity 硬亲和requiredDuringSchedulingIgnoredDuringExecution[root@k8s-master Scheduler]# cat node-affinity-and-resourcefits.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: node-affinity-and-resourcefits namespace: defaultspec: replicas: 5 selector: matchLabels: app: demoapp ctlr: node-affinity-and-resourcefits template: metadata: labels: app: demoapp ctlr: node-affinity-and-resourcefits spec: containers: - name: demoapp image: ikubernetes/demoapp:v1.0 resources: #预选函数 只有满足资源需要的node 才会进行上面的权重打分 进行优选 requests: cpu: 1000m memory: 200Mi livenessProbe: httpGet: path: '/livez' port: 80 initialDelaySeconds: 5 readinessProbe: httpGet: path: '/readyz' port: 80 initialDelaySeconds: 15 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: #硬亲和 nodeSelectorTerms: - matchExpressions: - key: gpu operator: Exists示例3: nodeAffinity 软亲和preferredDuringSchedulingIgnoredDuringExecution[root@k8s-master Scheduler]# cat node-affinity-preferred-demo.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: node-affinity-preferredspec: replicas: 5 selector: matchLabels: app: demoapp ctir: node-affinity-preferred template: metadata: name: demoapp labels: app: demoapp ctir: node-affinity-preferred spec: containers : - name: demoapp image: ikubernetes/demoapp:v1.0 resources: #预选函数 只有满足资源需要的node 才会进行上面的权重打分 进行优选 requests: cpu: 100m memory: 100Mi affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: #软亲和 - weight: 60 preference: matchExpressions: #带gpu标签的加60权重 - key: gpu operator: Exists - weight: 30 preference: matchExpressions: #蕴含foo、bar标签的加30权重 - key: region operator: In values: ["foo","bar"] [root@k8s-master Scheduler]# kubectl apply -f node-affinity-preferred-demo.yaml deployment.apps/node-affinity-preferred created#为节点增加标签[root@k8s-master ~]# kubectl label node k8s-node1.org gpu=2node/k8s-node1.org labeled[root@k8s-master ~]# kubectl label node k8s-node3.org region=foonode/k8s-node3.org labeled[root@k8s-master ~]# kubectl label node k8s-node2.org region=barnode/k8s-node2.org labeled[root@k8s-master ~]# kubectl get node -l gpu # node1为gpuNAME STATUS ROLES AGE VERSIONk8s-node1.org Ready <none> 47d v1.22.2[root@k8s-master ~]# kubectl get node -l region #node2、node3为NAME STATUS ROLES AGE VERSIONk8s-node2.org Ready <none> 47d v1.22.2k8s-node3.org Ready <none> 47d v1.22.2[root@k8s-master Scheduler]# kubectl apply -f node-affinity-preferred-demo.yaml deployment.apps/node-affinity-preferred created实践上 node1权重更高 pod会都运行在node1上[root@k8s-master ~]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdetails-v1-79f774bdb9-vjmll 2/2 Running 0 27d 10.244.42.13 k8s-node3.org <none> <none>node-affinity-preferred-5579fd76bc-5hfd2 0/2 Init:0/1 0 15s <none> k8s-node1.org <none> <none> node-affinity-preferred-5579fd76bc-gzhd6 0/2 Init:0/1 0 15s <none> k8s-node1.org <none> <none>node-affinity-preferred-5579fd76bc-q8wrc 0/2 Init:0/1 0 15s <none> k8s-node1.org <none> <none>node-affinity-preferred-5579fd76bc-v42sn 0/2 Init:0/1 0 15s <none> k8s-node1.org <none> <none>node-affinity-preferred-5579fd76bc-vvc42 0/2 Init:0/1 0 15s <none> k8s-node1.org <none> <none>productpage-v1-6b746f74dc-q564k 2/2 Running 0 27d 10.244.42.21 k8s-node3.org <none> <none>ratings-v1-b6994bb9-vh57t 2/2 Running 0 27d 10.244.42.19 k8s-node3.org <none> <none>reviews-v1-545db77b95-clh87 2/2 Running 0 27d 10.244.42.12 k8s-node3.org <none> <none>reviews-v2-7bf8c9648f-hdbdl 2/2 Running 0 27d 10.244.42.9 k8s-node3.org <none> <none>reviews-v3-84779c7bbc-4vzcz 2/2 Running 0 27d 10.244.42.17 k8s-node3.org <none> <none>

kubernetes外围实战 1、资源创立形式命令行创立 yaml文件创建 2、namespace命名空间（namespace）是Kubernetes提供的组织机制，用于给集群中的任何对象组进行分类、筛选和治理。每一个增加到Kubernetes集群的工作负载必须放在一个命名空间中。 命名空间为集群中的对象名称赋予作用域。尽管在命名空间中名称必须是惟一的，然而雷同的名称能够在不同的命名空间中应用。这对于某些场景来说可能帮忙很大。例如，如果应用命名空间来划分应用程序生命周期环境（如开发、staging、生产），则能够在每个环境中保护利用同样的名称保护雷同对象的正本。 命名空间还能够让用户轻松地将策略利用到集群的具体局部。你能够通过定义ResourceQuota对象来管制资源的应用，该对象在每个命名空间的根底上设置了应用资源的限度。相似地，当在集群上应用反对网络策略的CNI（容器网络接口）时，比方Calico或Canal（calico用于策略，flannel用于网络）。你能够将NetworkPolicy利用到命名空间，其中的规定定义了pod之间如何彼此通信。不同的命名空间能够有不同的策略。 应用命名空间最大的益处之一是可能利用Kubernetes RBAC（基于角色的访问控制）。RBAC容许您在单个名称下开发角色，这样将权限或性能列表分组。ClusterRole对象用于定义集群规模的应用模式，而角色对象类型（Role object type）利用于具体的命名空间，从而提供更好的管制和粒度。在角色创立后，RoleBinding能够将定义的性能授予单个命名空间上下文中的具体具体用户或用户组。通过这种形式，命名空间能够使得集群操作者可能将雷同的策略映射到组织好的资源汇合。 将命名空间映射到团队或我的项目上 应用命名空间对生命周期环境进行分区 应用命名空间隔离不同的使用者 [root@k8s-master-node1 ~]# kubectl create namespace cbynamespace/cby created[root@k8s-master-node1 ~]# [root@k8s-master-node1 ~]# kubectl get namespaces NAME STATUS AGEcby Active 2sdefault Active 21hingress-nginx Active 21hkube-node-lease Active 21hkube-public Active 21hkube-system Active 21hkubernetes-dashboard Active 21h[root@k8s-master-node1 ~]# [root@k8s-master-node1 ~]# kubectl delete namespace cbynamespace "cby" deleted[root@k8s-master-node1 ~]# [root@k8s-master-node1 ~]# [root@k8s-master-node1 ~]# kubectl get namespaces NAME STATUS AGEdefault Active 21hingress-nginx Active 21hkube-node-lease Active 21hkube-public Active 21hkube-system Active 21hkubernetes-dashboard Active 21h[root@k8s-master-node1 ~]#查看yaml格局[root@k8s-master-node1 ~]# kubectl create namespace cbynamespace/cby created[root@k8s-master-node1 ~]# [root@k8s-master-node1 ~]# kubectl get namespaces cby -o yamlapiVersion: v1kind: Namespacemetadata:creationTimestamp: "2021-11-17T03:08:10Z"labels: kubernetes.io/metadata.name: cbyname: cbyresourceVersion: "311903"uid: 63f2e47d-a2a5-4a67-8fd2-7ca29bfb02bespec:finalizers:- kubernetes status: phase: Active **Linux运维交换社区**Linux运维交换社区，互联网新闻以及技术交换。57篇原创内容公众号 https://blog.csdn.net/qq_33921750https://my.oschina.net/u/3981543https://www.zhihu.com/people/chen-bu-yun-2https://segmentfault.com/u/hppyvyv6/articleshttps://juejin.cn/user/3315782802482007https://space.bilibili.com/352476552/articlehttps://cloud.tencent.com/developer/column/93230知乎、CSDN、开源中国、思否、掘金、哔哩哔哩、腾讯云

Kubernetes根底概念 kubernetes个性：- 服务发现和负载平衡 Kubernetes 能够应用 DNS 名称或本人的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 能够负载平衡并调配网络流量，从而使部署稳固。 - 存储编排 Kubernetes 容许你主动挂载你抉择的存储系统，例如本地存储、公共云提供商等。 - 主动部署和回滚 你能够应用 Kubernetes 形容已部署容器的所需状态，它能够以受控的速率将理论状态 更改为冀望状态。例如，你能够自动化 Kubernetes 来为你的部署创立新容器， 删除现有容器并将它们的所有资源用于新容器。 - 主动实现装箱计算 Kubernetes 容许你指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源申请时，Kubernetes 能够做出更好的决策来治理容器的资源。 - 自我修复 Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况查看的容器，并且在筹备好服务之前不将其通告给客户端。 - 密钥与配置管理 Kubernetes 容许你存储和治理敏感信息，例如明码、OAuth 令牌和 ssh 密钥。你能够在不重建容器镜像的状况下部署和更新密钥和应用程序配置，也无需在堆栈配置中裸露密钥。 Kubernetes 为你提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足你的扩大要求、故障转移、部署模式等。例如，Kubernetes 能够轻松管理系统的 Canary 部署。 kubernetes组件构造与介绍 1、管制立体组件（Control Plane Components）管制立体的组件对集群做出全局决策(比方调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）。 管制立体组件能够在集群中的任何节点上运行。然而，为了简略起见，设置脚本通常会在同一个计算机上启动所有管制立体组件， 并且不会在此计算机上运行用户容器。请参阅应用 kubeadm 构建高可用性集群 中对于多 VM 管制立体设置的示例。 kube-apiserverAPI 服务器是 Kubernetes 管制面的组件， 该组件公开了 Kubernetes API。API 服务器是 Kubernetes 管制面的前端。 ...

作者：司徒放 审核&校对：田玮靖、溪洋 编辑&排版：雯燕 导语： 云原生时代，间接应用 Kubernetes 和云基础设施过于简单，如用户须要学习很多底层细节、利用治理的上手老本高、容易出错、故障频频。随着云计算的遍及，不同云又有不同的细节，进一步加剧了上述问题。 本文将介绍如何在 Kubernetes 上构建新的利用治理平台，提供一层形象以封装底层逻辑，只出现用户关怀的接口，使用户能够只关注本人的业务逻辑，治理利用更快更平安。 云原生时代是一个十分好的时代，咱们所面临的是整体技术的颠覆性变革，全面地对利用做端到端重构。目前，云原生在演进过程中产生了三个关键技术： 一是容器化，容器作为标准化交互的介质，在运维效率、部署密度和资源隔离性方面相比传统形式有很大改良，据 CNCF 最新调研报告显示，目前已有 92% 的企业生产零碎在应用容器；二是 Kubernetes，它对基础设施进行了形象和治理，现已成为云原生的标配；三是 Operator 自动化运维，通过控制器和定制资源的机制，使 Kubernetes 不仅能够运维无状态利用，还能够执行由用户定义的运维能力，实现更简单的自动化运维利用进行自动化部署和交互。这三项关键技术其实是逐步演进的关系，另外，在利用交付畛域，也有与之对应的实践在追随上述技术一直地演进。云原生的崛起，带来了交付介质、基础设施治理、运维模型和继续交付实践的全面降级和冲破，减速了云计算时代的到来。 图 1 云原生技术全景图（详情可点击此处查看） 从 CNCF 公布的云原生技术全景图（见图 1）中，能够看到云原生的蓬勃生态，细数图中这 900 + Logo，其中不乏开源我的项目、守业公司，将来云原生的技术都会在这些中央诞生。 云原生 “操作系统” Kubernetes 带来的利用交付挑战上文提到，Kubernetes 已成为云原生的标配，其对下封装基础设施的差别，对上反对各种利用的运维部署，如无状态利用、微服务，再如有状态、批处理、大数据、AI、区块链等新技术的利用，在 Kubernetes 下面都有方法部署。Kubernetes 曾经成为了现实意义的 “操作系统” 。它在云原生的位置正如挪动设施中的 Android。为什么这样讲？Android 不仅仅装在咱们的手机上，它还进一步渗透到汽车、电视、天猫精灵等智能终端里，挪动利用能够通过 Android 运行在这些设施上。而 Kubernetes 也有这样的后劲或发展趋势，当然它不是呈现在智能家电中，而是呈现在各家私有云、自建机房，以及边缘集群。能够料想，Kubernetes 将来会像 Android 一样无处不在。 那么，有了 Kubernetes 这层交付当前，容器 + Kubernetes 这层界面是不是就能够解决掉所有的交付问题了？答案必定不是。试想，如果咱们的手机中只有 Android 零碎，它可能满足咱们工作和生存需要吗？不能，必须有各种各样的软件应用才行。对应到云原生，它除了 Kubernetes 这个 “操作系统” 外，也须要一套利用的交付能力。在手机中，软件应用能够通过相似“豌豆荚”这样的利用以便用户装置，同样在云原生时代，咱们也须要将利用部署到不同的 Kubernetes 集群上。但因为 Kubernetes 海量琐碎的设施细节与简单各异的操作语言，导致部署过程中会遇到各种各样的问题，这时就须要云原生的“豌豆荚”来解决这个问题，也就是利用治理平台，去屏蔽交付的复杂性。 利用治理平台在业界有两种支流模式，第一种是传统平台模式，在 Kubernetes 上 “盖一个大帽子” ，将所有复杂度屏蔽，在此之上，再依据需要本人提供一层简化的利用形象。通过这种形式，尽管利用平台变得易用了，但新的能力须要由平台开发实现，也就带来了扩大难、迭代迟缓的问题，无奈满足日益增长的利用治理诉求。 ...

简介： 本文是一篇 kubernetes（下文用 k8s 代替）的入门文章，将会波及 k8s 的架构、集群搭建、一个 Redis 的例子，以及如何应用 operator-sdk 开发 operator 的教程。在文章过程中，会交叉引出 Pod、Deployment、StatefulSet 等 k8s 的概念，这些概念通过例子引出来，更容易了解和实际。 作者 | 凡澈起源 | 阿里技术公众号 前言本文是一篇 kubernetes（下文用 k8s 代替）的入门文章，将会波及 k8s 的架构、集群搭建、一个 Redis 的例子，以及如何应用 operator-sdk 开发 operator 的教程。在文章过程中，会交叉引出 Pod、Deployment、StatefulSet 等 k8s 的概念，这些概念通过例子引出来，更容易了解和实际。文章参考了很多博客以及材料，放在最初参考资料局部。 一 k8s架构 咱们看下 k8s 集群的架构，从左到右，分为两局部，第一局部是 Master 节点（也就是图中的 Control Plane），第二局部是 Node 节点。 Master 节点个别包含四个组件，apiserver、scheduler、controller-manager、etcd，他们别离的作用是什么： Apiserver：上知地理下知天文，上连其余组件，下接ETCD，提供各类 api 解决、鉴权，和 Node 上的 kubelet 通信等，只有 apiserver 会连贯 ETCD。Controller-manager：管制各类 controller，通过控制器模式，致力于将以后状态转变为冀望的状态。Scheduler：调度，打分，分配资源。Etcd：整个集群的数据库，也能够不部署在 Master 节点，独自搭建。Node 节点个别也包含三个组件，docker，kube-proxy，kubelet Docker：具体跑利用的载体。Kube-proxy：次要负责网络的买通，晚期利用 iptables，当初应用 ipvs技术。Kubelet：agent，负责管理容器的生命周期。总结一下就是 k8s 集群是一个由两局部组件 Master 和 Node 节点组成的架构，其中 Master 节点是整个集群的大脑，Node 节点来运行 Master 节点调度的利用，咱们后续会以一个具体的调度例子来解释这些组件的交互过程。 ...

大家好，我是张晋涛。 目前曾经确定， dockershim 的代码将在 Kubernetes v1.24 版本中被正式从 Kubernetes 的代码仓库移除，预计新版本明年 4 月左右公布。对于喜爱尝献的小伙伴，dockershim 的代码下个月就将从 Kubernetes 的源代码仓库中正式移除了，届时能够尝试应用 alpha 版本进行测试应用，或者自性编译。 老粉们可能在去年看过我公布的 《K8S 弃用 Docker 了？Docker 不能用了？别逗了！》，在其中我具体的阐明了所谓的 “Kubernetes 在弃 Docker 一事上的起源，后果” 等。 当初这个事件从正式发表到当初曾经倒退了快一年了，咱们来看看它有哪些变动和更新吧。 为了关照新的小伙伴，咱们再明确下，本次 Kubernetes 移除 dockershim 的树内代码，对于不同角色（架构、开发、集群管理员等等）的小伙伴都有哪些影响以及须要做些什么。 首先，还是须要给大家一剂强心针，本次 Kubernetes 移除树内 dockershim 代码 并不阐明 Docker 不可用！而 dockershim 自身作用就是通过 CRI 的形式连贯 Kubelet 和 Docker 的。Kubernetes 推出了 CRI，以满足对不同容器运行时的反对！咱们须要从根本上，理解 Docker 的定位以及 dockershim 对 Kubernetes 来讲意味着什么。 追根溯源 - Docker 的定位以及 Kubernetes CRI晓得的越多，恐怖的越少。 DockerDocker 的定位是 Development Platform ，即，作为一个开发者工具，而非底层的容器运行时。 所以，咱们能够看到，Docker 于 2017年 给 CNCF 奉献了 containerd ，同年的 11月 ，Kubernetes 也减少了对 containerd 的反对（2018 年， Kubernetes 的 containerd 集成，正式 GA）。 ...

问题背景并不是所有的Kubernetes集群都有很大数量的机器，一个Pod也有可能占用几十G内存，心愿读者能在浏览前就理解这样的事实。 在我管控的集群中，有个集群机器数量比拟少（大略7~8个计算节点），配置也个别（本文依照64核，128G这样的配置来阐明，将来有可能有更好或者更差的机器），集群的拥有者会心愿他的机器资源可能被无效的利用，最好在80%左右，作为管理员的我就须要思考下这个问题。 默认部署策略的应用该集群中有几个利用的内存使用率很高，每个Pod启动后内存会逐步回升，咱们能承受的范畴大略在20G左右。对于这种大利用，资源申请不能过高或者过低，因而程序中的资源配置如下，requests与limits雷同。 requests: cpu: "10000m" memory: "21474836480" limits: cpu: "10000m" memory: "21474836480"以128G的节点为例，每个节点咱们冀望部署4/5个Pod，有以下起因： 如果部署6个，内存超过90%的使用率，监控会报警；如果所有节点都部署5个，那么每次滚动更新时就会有可能报警。比拟现实的计划是某些节点4个Pod，某些节点5个Pod，滚动更新时，从4个Pod的节点开始，逐渐替换Pod。 然而这就带来了一个问题，Kuberntes的默认节点抉择策略是比拟自在的，如果一台机器有资源，那么它有肯定可能被抉择部署。 5个Pod总共100G mem的申请资源，就存在这么一种可能性，某个节点的Pod有6个，某个节点的Pod有3个，默认的调配策略是有这种可能性的。 咱们在应用默认策略时遇到了好屡次这样的部署后果，只能用kubectl delete pod手动来进行修整，用共事的话来讲就是蛋碎了。 一个比较简单的控制策略Kubernetes中针对节点的可分配资源是能够定义的，咱们限度节点保留10%的资源，用Ansible生成的kubelet参数能够这么加：--system-reserved=memory={(ansible_memtotal_mb * 0.1)int}Mi 那么，会保障不产生报警，然而各个机器之间的负载还是有可能不平衡，只能局部解决问题。 精密管制Pod散布因为咱们不止部署了一个利用，而且有些利用须要非凡的看待，必定不能齐全寄希望于主动的调配策略。机器自身较少，而且想要实现较高的利用率时，反对用户手工调整Pod数量是有必要的。 无关精密管制节点中的Pod数量，咱们调研了几种计划： Pod 拓扑散布束缚（https://kubernetes.io/docs/co...） 该计划实现较为简单，它引入了域的概念，将节点分组，每个组为一个域，针对各个域中部署的Pod数量进行限度，比方两个域之间的Pod数量不能相差1，如果用这个计划解决负载不平衡的问题，那么会引入新的问题：如果咱们减少了新的机器，而新机器的性能配置都较好，那么Pod数量不能相差1，那么新机器的性能不能被充分利用。 说真的，我想不到这个计划利用的场景，如果大家有适合的使用场景及思路能够在评论外面通知我，我也学习下。 节点减少拓展资源（https://kubernetes.io/docs/ta...） 我集体认为这个计划是一种折衷方案，配置不太简单也能达到想要的成果，具体的实现是减少新的资源限度。 书写控制策略时配合CPU以及mem来应用： 用户能够手动批改节点的资源限度，也能够针对某几个利用来设置。 当咱们有了不同配置的新机器后，能够针对新机器批改该选项到适合的值。 我认为这个计划（主动抉择+手工配置）曾经根本解决了咱们的问题，不过有个小毛病就是：每次增加新的机器都须要设置资源，否则设置会导致Pod无奈调配到新节点中。 总结咱们在解决手动部署问题时也探讨了一下Kubernetes更加适宜的场景：领有大量的服务器；服务器中运行渺小服务的状况；并且该集群最好能管制资源利用率在80%以下，这样遇到了突发的流量能够做到有空余工夫去扩容。 这篇文章中，我提到了三个解决计划，大家能够针对本人的状况本人去抉择： 在建设集群时就思考下，给每个节点预留资源 Pod的拓扑散布束缚我临时没想到适合的场景 对于某些机器较少的集群，用户想要实现细力度的管制，我还是举荐应用扩大资源来限度。原文链接：https://corvo.myseu.cn/2021/0...中一种细力度控制程序部署的计划 起源：云原生技术爱好者社区作者：冯裕浩 【IDCF共创读书会】第2期汇报在【冬哥有话说】收费直播，关注公众号回复“共创”获取地址 11月18日（周四）晚8点，共读《第五项修炼》11月25日（周四）晚8点，共读《继续交付2.0》

KubeSphere 降级 root@master1:~# export KKZONE=cnroot@master1:~# kk upgrade --with-kubernetes v1.22.1 --with-kubesphere v3.2.0 -f sample.yaml 启用插件 用户能够应用 KubeSphere Web 控制台查看和操作不同的资源。要在装置后启用可插拔组件，只须要在控制台中进行稍微调整。对于那些习惯应用 Kubernetes 命令行工具 kubectl 的人来说，因为该工具已集成到控制台中，因而应用 KubeSphere 将毫无艰难。 以 admin 身份登录控制台。点击左上角的平台治理 ，而后抉择集群治理。 集群治理 点击 CRD，而后在搜寻栏中输出 clusterconfiguration，点击搜寻后果进入其详情页面。 CRD 编辑配置文件 在该配置文件中，将对应组件 enabled 的 false 更改为 true，以启用要装置的组件。实现后，点击更新以保留配置。 我的内容： apiVersion: installer.kubesphere.io/v1alpha1kind: ClusterConfigurationmetadata: labels: version: v3.2.0 name: ks-installer namespace: kubesphere-systemspec: alerting: enabled: true auditing: enabled: true authentication: jwtSecret: '' common: core: console: enableMultiLogin: true port: 30880 type: NodePort es: basicAuth: enabled: true password: '' username: '' data: volumeSize: 20Gi elkPrefix: logstash externalElasticsearchPort: '' externalElasticsearchUrl: '' logMaxAge: 7 master: volumeSize: 4Gi gpu: kinds: - default: true resourceName: nvidia.com/gpu resourceType: GPU minio: volumeSize: 20Gi monitoring: GPUMonitoring: enabled: true endpoint: 'http://prometheus-operated.kubesphere-monitoring-system.svc:9090' openldap: enabled: true redis: enabled: true devops: enabled: true jenkinsJavaOpts_MaxRAM: 2g jenkinsJavaOpts_Xms: 512m jenkinsJavaOpts_Xmx: 512m jenkinsMemoryLim: 2Gi jenkinsMemoryReq: 1500Mi jenkinsVolumeSize: 8Gi etcd: endpointIps: 192.168.1.10 monitoring: false port: 2379 tlsEnable: true events: enabled: true kubeedge: cloudCore: cloudHub: advertiseAddress: - '' nodeLimit: '100' cloudhubHttpsPort: '10002' cloudhubPort: '10000' cloudhubQuicPort: '10001' cloudstreamPort: '10003' nodeSelector: node-role.kubernetes.io/worker: '' service: cloudhubHttpsNodePort: '30002' cloudhubNodePort: '30000' cloudhubQuicNodePort: '30001' cloudstreamNodePort: '30003' tunnelNodePort: '30004' tolerations: [] tunnelPort: '10004' edgeWatcher: edgeWatcherAgent: nodeSelector: node-role.kubernetes.io/worker: '' tolerations: [] nodeSelector: node-role.kubernetes.io/worker: '' tolerations: [] enabled: true logging: containerruntime: docker enabled: true logsidecar: enabled: true replicas: 2 metrics_server: enabled: true monitoring: gpu: nvidia_dcgm_exporter: enabled: true storageClass: '' multicluster: clusterRole: none network: ippool: type: none networkpolicy: enabled: true topology: type: none openpitrix: store: enabled: true persistence: storageClass: '' servicemesh: enabled: true启用组件 ...

简介： 随着 Kubernetes 的一直实际落地，咱们常常会遇到负载平衡、集群调度、程度扩大等问题。归根到底，这些问题背地都暴露出流量散布不均的问题。那么，咱们该如何发现资源应用，解决流量散布不均问题呢？明天，咱们就借助三个具体场景聊聊这一问题以及相应的解决方案。 作者｜炎寻 大家好，我是阿里云云原生利用平台的炎寻，很快乐能与大家持续分享 Kubernetes 监控系列公开课。前两期公开课咱们讲到了 Vol.1《通过 Kubernetes 监控摸索利用架构，发现预期外的流量》、Vol.2《如何发现 Kubernetes 中服务和工作负载的异样》。 如何应用 Kubernetes 监控的拓扑来摸索利用架构，应用产品采集的监控数据配置告警来发现服务性能问题。明天咱们将进行第三讲《应用 Kubernetes 监控发现资源应用，流量散布不平均的问题》，大家能够钉钉搜寻钉群 31588365，退出 Kubernetes 监控答疑群进行交换。 随着 Kubernetes 的一直实际落地，咱们常常会遇到越来越多问题，诸如负载平衡、集群调度、程度扩大等问题。归根到底，这些问题背地都暴露出流量散布不均的问题。那么，咱们该如何发现资源应用，解决流量散布不均问题呢？明天，咱们就借助三个具体场景聊聊这一问题以及相应的解决方案。 零碎架构面临的挑战一：负载平衡 通常来说，对于一个业务零碎，架构会有很多层，每层蕴含很多组件，比方服务接入、中间件、存储，咱们心愿每个组件的负载都是平衡的，这样性能和稳定性都是最高的，但在多语言多通信协议场景下，疾速发现以下问题具备肯定难度，比方： 应用服务器解决的申请是否平均？应用服务器对中间件服务实例的拜访流量是否平均？数据库各个分库分表实例读写流量是否平均？…咱们在理论工作实际中会遇到的典型场景就是负载不平衡，线上的流量转发策略或者流量转发组件本身有问题，导致应用服务各个实例接管到的申请量不平衡，局部实例解决的流量显著高于其余节点，导致这部分实例的性能绝对于其余实例来说显著好转，那么路由到这部分实例上的申请无奈失去及时的响应，造成零碎整体的性能和稳定性升高。 除了服务端不平均场景之外，云上用户大多应用云服务实例，在实践中会呈现应用服务各个实例解决的流量平均，但拜访云服务实例的节点呈现流量不平均，导致云服务实例整体性能和稳定性降落。通常在利用运行时整体链路梳理和特定问题节点上下游剖析时，会进入该场景。 那么，咱们如何疾速发现问题、解决问题呢？ 针对这一问题，咱们能够从服务负载、申请负载这两个方面对客户端、服务端进行问题发现，判断各个组件实例服务负载和对外申请负载是否平衡。 （1）服务端负载 对于服务端负载平衡问题排查，咱们须要理解服务详情，对任意特定的 Service，Deployment，DaemonSet，StatefulSet 进行更具针对性的排查。通过 Kubernetes 监控服务详情性能，咱们能够看到 Pod 列表局部会列出后端的所有 Pod，在表格中咱们列出了每个 Pod 在抉择时间段内的申请数聚合值和申请数时序，通过对申请数一列进行排序，咱们能够分明地看到后端的流量是否平均。 （2）客户端负载 对于客户端负载平衡问题排查，Kubernetes 监控提供集群拓扑性能，对于任意特定的 Service，Deployment，DaemonSet，StatefulSet，咱们都能够查看其关联的拓扑，入选定关联关系之后，点击表格化会列出所有与问题实体关联的网络拓扑，表格每一项都是应用服务节点对外申请的拓扑关系，在表格中咱们会展现每一对拓扑关系在抉择时间段内的申请数聚合值和申请数时序，通过对申请数一列进行排序，能够分明地看到特定节点作为客户端对特定的服务端拜访是否流量平均。 零碎架构面临的挑战二：集群调度在 Kubernetes 集群部署场景下，将 Pod 散发到某个节点的过程称之为调度，对于每个 Pod 来说，其调度过程蕴含了“依据过滤条件找候选节点”以及“找最好的节点”两个步骤，“依据过滤条件找候选节点”除了依据 Pod 和 node 的污点，忍耐关系来过滤节点，还有一点十分重要的就是依据资源预留的量来过滤，比方节点的 CPU 只有 1 核的预留，那么对于一个申请 2 核的 Pod 来说该节点将被过滤。“找最好的节点”除了依据 Pod 和 node 的亲和性来抉择，个别是在过滤出来的节点外面抉择最闲暇的。 ...

作者｜董天欣（雾雾）审核&校对：溪洋、海珠编辑&排版：雯燕 KubeVela 是一个简略、易用、且高可扩大的云原生利用治理和交付平台，能让开发人员方便快捷地在 Kubernetes 上定义与交付古代微服务利用，无需理解任何 Kubernetes 基础设施相干的细节。 KubeVela 背地的 OAM 模型人造解决了利用构建过程中对简单资源的组合、编排等治理问题，同时也将前期的运维策略模型化，这意味着 KubeVela 能够联合 GitOps 治理简单大规模利用，收敛因为团队与零碎规模增长导致的零碎复杂度问题。 什么是 GitOps它的核心思想是将利用零碎所需的基础架构和利用配置申明性形容寄存在Git仓库中，并配合一个自动化流程，使每次仓库被更新后，自动化过程都能逐步将环境更新到最新配置。 这样的形式容许开发人员通过间接更改 Git 仓库中的代码和配置来主动部署利用，应用 GitOps 的形式能够为利用研发带来诸多价值，例如： • 进步生产效率。通过主动的继续部署可能放慢均匀部署工夫，减少开发效率。• 升高开发人员部署的门槛。通过推送代码而非容器配置，开发人员能够不须要理解 Kubernetes 的外部实现，便能够轻易部署。• 使变更记录可追踪。通过 Git 来治理集群，能够使每一次更改都可追踪，增强了审计跟踪。• 可通过 Git 的回滚/分支性能来复原集群。 KubeVela 与 GitOpsKubeVela 作为一个申明式的利用交付管制立体，人造反对以 GitOps 的形式来应用，并使用户更显著地感触到由 GitOps 带来的好处，和端到端的利用交付与治理体验，包含： • 利用交付工作流（CD 流水线）：即：KubeVela 反对在 GitOps 模式中形容过程式的利用交付，而不只是简略的申明终态；• 解决部署过程中的各种依赖关系和拓扑构造；• 在现有各种 GitOps 工具的语义之上提供对立的下层形象，简化利用交付与治理过程；• 对立进行云服务的申明、部署和服务绑定；• 提供开箱即用的交付策略（金丝雀、蓝绿公布等）；• 提供开箱即用的混合云/多云部署策略（搁置规定、集群过滤规定等）；• 在多环境交付中提供 Kustomize 格调的 Patch 来形容部署差别，而无需学习任何 Kustomize 自身的细节；• …… 在本文中，咱们次要解说间接应用 KubeVela 在 GitOps 模式下进行交付的步骤。 GitOps 工作流GitOps 工作流分为 CI 和 CD 两个局部： ...

背景：2017-2018年左右的吧，不记得看什么了看到了spinnaker，然而过后真的装置不起来。各种被墙裂。2020年底学习了泽阳大佬的spinnaker实际课程。通过Halyard形式搭建了spinnaker的集群，并与jenkins gitlab harbor k8s实现了集成。2021年初略微玩了一下，就去整别的事件去了，没有能利用于线上环境。下半年了，jenkins k8s这些的流程当初根本都是清晰了。想把cd从jenkins中剥离进去教给spinnaker了，就从新复习一下spinnaker吧！ 对于spinnakerspinnaker是Netfix公司开源的一款继续部署工具，采纳java语言编写，遵循微服务的设计思维，指标是为团队提供灵便的继续部署流水线并提供软件的部署效率 spinnaker的劣势反对多云部署主动公布内置部署最佳实际 spinnaker架构对于spinnaker的架构阐明 deck-基于浏览器的 UIgate 微服务api网关，Spinnaker UI 和所有 api 调用者通过 Gate 与 Spinnaker 通信orca 流水线阶段编排引擎。它解决所有长期操作和管道。浏览无关 Orca 服务概述的更多信息clouddriver 负责对云提供商的所有变异调用以及索引/缓存所有部署的资源。front50 用于长久化应用程序、管道、我的项目和告诉的元数据rosco 为各种云提供商生成不可变的 VM 映像（或映像模板） 它用于生成机器映像（例如 GCE 映像 、 AWS AMI 、 Azure VM 映像 ）。它目前包装了 packer ，但将 被扩大以反对用于生成图像的其余机制。 igor 用于通过 Jenkins 和 Travis CI 等零碎中的继续集成作业触发管道，它容许在管道中应用 Jenkins/Travis 阶段echo 事件总线 它反对发送告诉（例如 Slack、电子邮件、SMS），并对来自 Github 等服务的传入 webhook 采取行动。fiat 认证受权核心 它用于查问用户对帐户、应用程序和服务帐户的拜访权限kayenta 主动金丝雀剖析Keel 为治理交付提供能源 注：这个还没有用过 halyard 配置服务 治理上述每项服务的生命周期。它仅在 Spinnaker 启动、更新和回滚期间与这些服务交互。 服务依赖调用关系：重要的事件： 这些货色去看官网文档很是具体，比其余的比拟具体多了：https://spinnaker.io/docs/reference/architecture/microservices-overview/ ...

大家好，我是张晋涛。 这篇文章中我将介绍 OCI 及 Docker 镜像相干的内容，欢送留言探讨。 OCI 的前世今生2013 年 3 月 dotCloud 公司在 PyCon 上进行了 Docker 的首次展现，随后发表开源。自此 Docker 开始被众人通晓，随后掀起了一股容器化的热潮。 在 2014 年 6 月 Docker 1.0 正式公布，有近 460 位贡献者和超过 8700 次提交，这也标记着 Docker 达到了生产可用的状态。 在过后，提到容器化第一想法就是用 Docker 。而过后 Docker 的实现或者说倒退方向次要是由 Docker Inc. 公司管制的，并没有一个对立的工业规范。这对于一些头部公司而言，显然是不能承受的，没有对立的工业规范意味着如果抉择了应用 Docker 的容器化技术，便会被 Docker Inc. 公司所绑定；加上随着 Docker 软件的降级，某些性能或者个性必然会进行变动，没人能保障不产生破坏性变更。 所以，为了推动容器化技术的工业标准化，2015 年 6 月在 DockerCon 上 Linux 基金会与 Google，华为，惠普，IBM，Docker，Red Hat，VMware 等公司独特发表成立凋谢容器我的项目(OCP)，后更名为 OCI。它的次要指标便是 建设容器格局和运行时的工业凋谢通用规范。 倒退至今， OCI 制订的次要规范有三个别离是 runtime-spec 、image-spec 和 distribution-spec 这三个规范别离定义了容器运行时，容器镜像还有散发的标准，前面会开展介绍。 ...

作者｜炎寻 审核&校对：白玙 编辑&排版：雯燕 大家好，我是阿里云云原生利用平台的炎寻，很快乐能与大家持续分享 Kubernetes 监控系列公开课。前两期公开课咱们讲到了 Vol.1《通过 Kubernetes 监控摸索利用架构，发现预期外的流量》、Vol.2《如何发现 Kubernetes 中服务和工作负载的异样》。 如何应用 Kubernetes 监控的拓扑来摸索利用架构，应用产品采集的监控数据配置告警来发现服务性能问题。明天咱们将进行第三讲《应用 Kubernetes 监控发现资源应用，流量散布不平均的问题》，大家能够钉钉搜寻钉群 31588365，退出 Kubernetes 监控答疑群进行交换。 随着 Kubernetes 的一直实际落地，咱们常常会遇到越来越多问题，诸如负载平衡、集群调度、程度扩大等问题。归根到底，这些问题背地都暴露出流量散布不均的问题。那么，咱们该如何发现资源应用，解决流量散布不均问题呢？明天，咱们就借助三个具体场景聊聊这一问题以及相应的解决方案。 零碎架构面临的挑战一：负载平衡 通常来说，对于一个业务零碎，架构会有很多层，每层蕴含很多组件，比方服务接入、中间件、存储，咱们心愿每个组件的负载都是平衡的，这样性能和稳定性都是最高的，但在多语言多通信协议场景下，疾速发现以下问题具备肯定难度，比方： 应用服务器解决的申请是否平均？应用服务器对中间件服务实例的拜访流量是否平均？数据库各个分库分表实例读写流量是否平均？…咱们在理论工作实际中会遇到的典型场景就是负载不平衡，线上的流量转发策略或者流量转发组件本身有问题，导致应用服务各个实例接管到的申请量不平衡，局部实例解决的流量显著高于其余节点，导致这部分实例的性能绝对于其余实例来说显著好转，那么路由到这部分实例上的申请无奈失去及时的响应，造成零碎整体的性能和稳定性升高。 除了服务端不平均场景之外，云上用户大多应用云服务实例，在实践中会呈现应用服务各个实例解决的流量平均，但拜访云服务实例的节点呈现流量不平均，导致云服务实例整体性能和稳定性降落。通常在利用运行时整体链路梳理和特定问题节点上下游剖析时，会进入该场景。 那么，咱们如何疾速发现问题、解决问题呢？ 针对这一问题，咱们能够从服务负载、申请负载这两个方面对客户端、服务端进行问题发现，判断各个组件实例服务负载和对外申请负载是否平衡。 （1）服务端负载 对于服务端负载平衡问题排查，咱们须要理解服务详情，对任意特定的 Service，Deployment，DaemonSet，StatefulSet 进行更具针对性的排查。通过 Kubernetes 监控服务详情性能，咱们能够看到 Pod 列表局部会列出后端的所有 Pod，在表格中咱们列出了每个 Pod 在抉择时间段内的申请数聚合值和申请数时序，通过对申请数一列进行排序，咱们能够分明地看到后端的流量是否平均。 （2）客户端负载对于客户端负载平衡问题排查，Kubernetes 监控提供集群拓扑性能，对于任意特定的 Service，Deployment，DaemonSet，StatefulSet，咱们都能够查看其关联的拓扑，入选定关联关系之后，点击表格化会列出所有与问题实体关联的网络拓扑，表格每一项都是应用服务节点对外申请的拓扑关系，在表格中咱们会展现每一对拓扑关系在抉择时间段内的申请数聚合值和申请数时序，通过对申请数一列进行排序，能够分明地看到特定节点作为客户端对特定的服务端拜访是否流量平均。 零碎架构面临的挑战二：集群调度在 Kubernetes 集群部署场景下，将 Pod 散发到某个节点的过程称之为调度，对于每个 Pod 来说，其调度过程蕴含了“依据过滤条件找候选节点”以及“找最好的节点”两个步骤，“依据过滤条件找候选节点”除了依据 Pod 和 node 的污点，忍耐关系来过滤节点，还有一点十分重要的就是依据资源预留的量来过滤，比方节点的 CPU 只有 1 核的预留，那么对于一个申请 2 核的 Pod 来说该节点将被过滤。“找最好的节点”除了依据 Pod 和 node 的亲和性来抉择，个别是在过滤出来的节点外面抉择最闲暇的。 基于下面的实践，咱们在实际过程中常常会遇到一些问题： ...

现如今最热门的服务器端技术是什么？答案大略就是云原生！KubeSphere 作为一个以 Kubernetes 为内核的云原生分布式操作系统，也是这热火朝天的云原生热潮中的一份子。KubeSphere 继续秉承 100% 开源的承诺，借助于开源社区的力量，迅速走向寰球。 2021 年 11 月 2 日，KubeSphere 开源社区冲动地向大家发表，KubeSphere 3.2.0 正式公布！ 6 个月前，KubeSphere 3.1.0 带着 “边缘计算”、“计量计费” 等性能来炸场，将 Kubernetes 从云端扩大至边缘，更进一步欠缺交互设计晋升了用户体验。3 个月前，KubeSphere 又公布了 v3.1.1，在部署 KubeSphere 时能够指定 Kubernetes 集群中已有的 Prometheus。 明天，KubeSphere 3.2.0 带来了更多令人期待的性能，新增了对 “GPU 资源调度治理” 与 GPU 应用监控的反对，进一步加强了在云原生 AI 场景的应用体验。同时还加强了 “多集群治理、多租户治理、可观测性、DevOps、利用商店、微服务治理” 等个性，更进一步欠缺交互设计，并全面晋升了用户体验。 并且，v3.2.0 失去了来自青云科技之外的更多企业与用户的奉献和参加，无论是性能开发、功能测试、缺点报告、需要倡议、企业最佳实际，还是提供 Bug 修复、国际化翻译、文档奉献，这些来自开源社区的奉献都为 v3.2.0 的公布和推广提供了极大的帮忙，咱们将在文末予以特地致谢！ 解读 KubeSphere 3.2.0 重大更新GPU 调度与配额治理以后随着人工智能机器学习等畛域技术的疾速倒退，市场上涌现了越来越多 AI 公司对服务器集群中 GPU 资源调度治理的需要，其中监控 GPU 应用状况以及 GPU 资源配额治理等需要在社区的呼声很高，在 KubeSphere 中文论坛收到了很多 GPU 相干的需要，KubeSphere 自身是始终反对 GPU 的，当初在 v3.2.0 中会将 GPU 的治理变得更易用。 ...

云效通知你如何抉择适宜你的Kubernetes利用公布模式，Kubernetes面向通用场景提供了非常灵活的利用治理和运维形式，而作为云效CI/CD平台的开发同学，在日常和用户交换过程中，咱们常常会被用户问到对于公布的问题，比方不同职能团队之间应该如何配合、公布的最佳实际应该是什么样子的等等。明天咱们就来聊聊Kubernetes下利用公布形式的抉择，每种公布模式适宜什么样的场景。 作者：砧木，阿里云云效技术专家 Kubernetes利用首先咱们来看看个别状况下Kubernetes是如何治理利用的。 Kubernetes通过申明式的API，并提供了一系列的资源来满足各种各样的利用运维场景：• 从利用的角度咱们会关注利用容器（Pod），利用配置（ConfigMap/Secret），利用须要长久化的信息（Volume），利用与利用之间的服务发现（Service），以及如何将应用服务裸露给集群外的用户（Ingress）等。• 从集群运维的角度看，因为利用运行在集群中咱们须要管制利用在集群中的权限（ServiceAccount/ClusterRole/Role）使得利用可能以最小所需权限准则在集群中运行，同时运维要治理和配置集群的存储资源(PV/PVC)，同时对于资源无限的状况咱们还须要治理和管制利用自身的资源暂用以及配额（quata）等等等。 而在理论场景中因为利用应用的框架（Doubbo/Spring Cloud）的不同，利用对外提供的服务场景不同（后端或者前端），不同的利用可能只须要关注其中的一小部分资源； 比方当你采纳了像Spring Cloud或者Doubbo这类自带了服务发现的利用开发框架，你可能并不关怀Kubernetes所提供的服务发现能力(Service)，只须要通过Deployment来部署和治理这些利用实例。又比如说如果你采纳了独自的配置管理核心，那ConfigMap/Secret这些可能也不会呈现在你的Kubernetes资源清单中。 又比如说，如果是一个面向用户前端利用，在利用部署是除了Deployment实例以外，你还要关系如何将这个服务裸露给内部用户，这是就须要相应的Ingress以及Service的资源来形容。同时在单个利用在整个零碎中所处的地位不同又会导致咱们对于公布的验证形式也会产生差别，比方一个后端微服务的公布，咱们可能只须要确保公布过程零碎不中断即可，而对于前端利用咱们可能心愿公布可能当初一小部分用户上进行验证，在线上流量充沛测试后，再实现整个版本升级。 如上所示，对于利用而言采纳的技术架构不同，提供的服务的形式不同，对公布验证形式要求的不同都会导致Kubernetes的应用上产生各种各样的差别，而云效为了可能反对这些不同的差别提供了多种多样的公布模式，接下来咱们就来看看云效下罕用的这些公布模式，以及他们所实用的场景。 最原生：YAML公布模式顾名思义，这是咱们在应用Kubernetes时最间接的利用部署形式，而在继续交付流水线中咱们个别将这些用于形容Kubernetes资源的YAML文件通过Git进行对立版本治理，通过云效CI/CD平台监听代码库的变更事件，并通过流水线将这些YAML变更同步到集群当中。这种形式也被称为GitOps模式。 在云效当中，咱们除了反对间接同步YAML到Kubernetes集群以外，还扩大了根本的模板能力，你能够通过在YAML文件中定义变量占位符如${IMAGE}，通过流水线运行是通过Docker镜像构建或者阿里云镜像仓库触发器（帮忙文档：阿里云镜像仓库触发器触发流水线），动静产生要公布的镜像版本 阐明 立刻体验：云效流水线Flow如下所示： YAML公布反对任意资源类型，因而实用于如下场景： 1.开发自运维，团队并充沛了解和把握Kubernetes原生的公布策略，心愿通过YAML实现利用的降级与公布以及回滚，一般来说利用Git库会蕴含利用源码，Dockerfile以及部署利用所需的所有YAML文件（在某些状况下，YAML可能是由独自的Git仓库进行治理，以进行细粒度的权限管制）。 2.基础设施运维：运维团队通过Git治理集群的所有基础设施配置，并通过流水线实现集群的对立治理以及配置的同步 更多具体应用介绍请参考：云效Kubernetes YAML公布 最简略：镜像降级在和一些用户的交换场景中，在也会有用户心愿开发团队可能尽可能少的了解Kubernetes相干概念，在这种状况下由专职的运维团队负责实现应用环境的部署和初始化。而开发团队只负责实现代码开发，并通过流水线自动化实现利用镜像构建，并应用该镜像对集群中已有的利用进行降级。开发团队只关怀利用的工作负载实例资源。 如下图所示，在云效流水线中咱们监听利用代码库的变动，并构建出相应的Docker镜像，而公布阶段只须要指定对集群中实例并关联前序工作产生的镜像即可实现利用的降级公布： 如上所述，该场景实用于： • 开发和运维拆散：运维团队充沛了解Kubernetes的原生公布策略，开发团队只负责产出代码以及利用镜像，由运维团队负责集群中利用的理论运维治理 对于如何在云效中应用镜像降级能力，请参考：云效Kubernetes镜像降级 过程可控：分批公布在后面两个小结中，咱们都强调用户须要充沛了解Kubernetes的原生公布策略，Kubernetes原生的公布策略次要是指RollingUpdate模式，用户通过申明降级策略，如maxSurge和maxUnavailable管制Pod的启动策略以及最大不可用Pod数，来确保即便利用公布出现异常的状况，也能保障服务的根本可用。 除此，因为利用启动往往有肯定的耗时，如果应用了Kubernetes的服务发现机制，咱们还须要配置如liveness以及readiness探针，来防止利用还在启动过程中就有不在打算内的流量进入到正在启动的实例当中。同时整个公布过程是不可逆的，如果认定以后公布呈现了异样咱们只能通过从新公布的形式来使利用回到可用状态。 而在云效的分批公布中，咱们以Service为最小公布单元，在公布开始阶段咱们将基于新版镜像创立出利用的版本V2，并依据以后利用的正本总数以及分批数量，对新旧两个版本的利用实例别离进行缩容和扩容，来管制理论进入到新版利用的流量比例，从而能够实现小规模的公布验证，在对公布进行充沛验证后再逐渐齐全下线老版利用。 同时批次之间反对暂停和手动复原让用户能够充沛对针对公布过程进行管制。 该模式实用于：采纳Kubernetes原生的服务发现机制，并心愿取得相比于原生Kubernetes公布更好过程控制性以及安全性的用户。 内部流量可控：Ingress灰度公布相比于分批公布灰度公布更强调更加可控和平安的线上验证。而灰度公布在Kubernetes中因为利用的部署模式的不同大抵分为两种，咱们首先来说第一种，基于Ingress的灰度公布，如下所示，咱们通过Ingress将集群内的服务裸露给内部用户： 在公布过程中咱们心愿可能通过cookie或者header的形式使得特定的用户或者开发人员，可能在线上对新版本援用进行验证，通过小局部可控的线上流量验证后，咱们的公布可靠性更好，如果呈现预期外的问题，也能够疾速回滚，并且整个灰度验证过程对非灰度用户齐全不可感知。 在云效流水线的Ingress灰度公布中，咱们以Ingress作为公布单元，当触发部署后，将会依据以后Ingress以及其关联的Service/Deployment资源，基于新版镜像创立出V2版本的Service/Deployment。并通过Nginx Ingress的Annoation实现对流量规定申明，从而确保只有满足特定特色的流量能力进入到V2版本中，当处于灰度状态时，流水线将会期待人工验证，以触发公布或者回滚操作。 对于如何在云效流水线中应用灰度公布请参考帮忙文档：云效Nginx Ingress灰度公布 该模式实用于：采纳Ingress对外裸露应用服务，并且心愿可能通过灰度的形式对公布进行验证； 外部流量可控：Istio/ASM灰度公布而在微服务的场景中，并不是所有的服务都须要间接裸露给内部用户，如下所示： 当采纳微服务架构，咱们大部分的后端服务是只裸露与集群内，微服务之间通过Kubernetes Service进行互相拜访，在这种状况下，当采纳灰度公布模式时，咱们须要在Service级别进行流量管制，已确保指定的流量才进入到灰度的链路而不对失常用户产生影响。 不过因为Kubernetes原生在Service级别并不反对任何的流量管制规定，因而咱们须要在集群中部署Istio或者采纳阿里云ServiceMesh来对服务之间的流量进行细粒度的管制。 如下图所示，当应用Kubernetes蓝绿公布模式时，能够设置灰度流量规定，从而只有当申请中蕴含指定的Cookie配置的申请转发到灰度版本当中： 该模式实用于：采纳Istio或者阿里云ServiceMesh的Kubernetes用户，并且心愿可能通过灰度的形式对公布进行验证。 更多应用介绍请参考：云效Kubernetes灰度公布 小结云效通知你如何抉择适宜你的Kubernetes利用公布模式，在本文中，咱们次要介绍了云效Kubernetes理论中的各种公布模式以及相干的实用场景，心愿可能帮忙云效用户疾速找到适宜本人的公布模式，当然如果你还有更多更好的交付实际，也能够在留言中进行分享。

作者：郑增权 爱可生南区数据库工程师，爱可生 DBA 团队成员，负责数据库相干技术支持。喜好：桌球、羽毛球、咖啡、电影 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、本文概述及次要术语1.1概述本文基于 Pod 、Service 和 Ingress 三大模块进行划分，对于 Kubernetes 日常可能呈现的故障问题，提供了较为具体的排查步骤，并附上相干解决办法或参考文献。 1.2 次要术语Pod: Kubernetes 中创立和治理的、最小的可部署的计算单元。是一组（一个或多个） 容器； 这些容器共享存储、网络、以及怎么运行这些容器的申明。Port-forward: 通过端口转发映射本地端口到指定的利用端口。Service: 一个 Kubernetes 的 Service 是一种形象，它定义了一组 Pods 的逻辑汇合和一个用于拜访它们的策略 - 有时被称为微服务。Ingress: 提供了集群内部到外部 HTTP 和 HTTPS 服务的路由通信，流量路由通过 Ingress 资源上定义的规定管制。二、故障诊断流程2.1 Pods 模块查看以下流程若胜利则持续往下进行，若失败则依据提醒进行跳转。2.1.1 查看是否有pod处于PENDING状态kubectl get pods： 如果有 pod 处于 PENDING 状态则往下看，否则返回2.1.5 。[root@10-186-65-37 ~]# kubectl get podsNAME READY STATUS RESTARTS AGEmyapp-deploy-55b54d55b8-5msx8 0/1 Pending 0 5mkubectl describe pod <pod-name>: 若正确输入指定的一个或多个资源的详细信息,则判断是否集群资源有余，若有余则进行拓展，否则返回 2.1.2 。2.1.2 查看是否触发 ResourceQuota limitkubectl describe resourcequota -n <namespace>:[root@10-186-65-37 ~]# kubectl describe quota compute-resources --namespace=myspaceName: compute-resourcesNamespace: myspaceResource Used Hard-------- ---- ----limits.cpu 0 2limits.memory 0 2Gipods 0 4requests.cpu 0 1requests.memory 0 1Gi如有限度则进行相应资源开释或拓展，参考：https://kubernetes.io/zh/docs...否则返回 2.1.32.1.3查看是否有 PVC 处于 PENDING 状态长久卷（PersistentVolume，PV）是集群中的一块存储，能够由管理员当时供给，或者应用存储类（Storage Class）来动静供给;长久卷申领（PersistentVolumeClaim, PVC）表白的是用户对存储的申请。kubectl describe pvc <pvc-name>: 若 STATUS 为 Pending ...

作者｜郝树伟（流生） 以 Kubernetes 为代表的云原生技术不仅屏蔽了各个云厂商和数据中心在基础设施上的差异性，还使得利用能够在不同的云上应用标准化的形式形容和部署运行。在此基础之上，咱们才能够低成本治理处于任何地理位置的 Kubernetes 集群。本文将次要为您介绍如何实现对公共云 ACK 集群和数据中心自建 Kubernetes 集群统一体验的集群治理和平安治理。 ACK 注册集群平安架构要实现对公共云 ACK 集群和数据中心自建 Kubernetes 集群统一体验的集群治理和平安治理，就必须先将其对立到同一管制立体，ACK 注册集群容许处于任何地理位置的自建 Kubernetes 集群通过公网或私网（云上云下网络买通）连贯端点接入阿里云容器服务管理系统。上面是 ACK 注册集群的架构示意图： 在 ACK 注册集群架构示意图中，次要包含以下几个组成部分： ACK 容器服务控制台。ACK 注册集群 Agent 组件：Agent 组件以 Deployment 的模式部署在自建 Kubernetes 集群中（或者其余云厂商的容器集群中），用于接管 ACK 注册集群 Stub 组件（应用 ACK 容器服务控制台或 ACK 注册集群 kubeconfig）下发的申请，并将其转发给指标集群的 Kubernetes API Server，同时接管 Kubernetes API Server的响应并将其发送回 Stub 组件。ACK 注册集群 Stub 组件：Stub组件部署的容器服务管控侧，每一个注册集群都对应一个 Stub 组件，用于代理转发 ACK 容器服务控制台或 ACK 注册集群 kubeconfig 拜访集群产生的申请，转发到 Agent 组件并接管来自 Agent 组件的响应，最终返回响应到用户端。Kubernetes API Server：指标自建 Kubernetes 集群或其余云厂商容器集群的 Kubernetes API Server。单向注册双向通信后面咱们提到，ACK 注册集群能够接入处于任何地理位置的自建 Kubernetes 集群，数据中心内自建的 Kubernetes 集群有一个特点就是通常状况下，这些自建集群处于一个受限的公有网络环境下，只能集群出公网拜访外部环境。ACK 注册集群为了解决这个问题，将 Stub/Agent 组件设计为 Agent 被动单向注册到 Stub 组件，Agent 连贯 Stub 时，会带上事后生成的 token 和证书等信息进行验证，整个通信链路采纳 TLS 协定确保数据加密。 ...

Local PV呈现起因1．如果应用hostPath Volume这种办法 , 还得抉择节点来调度2．须要当时创立好目录 , 而且还得留神权限的配置, 比方root用户创立的目录 , 普通用户就用不了了3．不能指定大小 , 可能 会面临磁盘随时被写满的危险 , 而且没有I/O隔离机制4．statefulset不能应用hostPath Volume , 写好的Helm不能兼容hostPath Volume Local PV应用场景实用于高优先级零碎，须要在多个不同节点上存储数据，而且I/O要求较高。 Local PV和惯例PV的区别对于惯例的PV，Kubernetes都是先调度Pod到某个节点上，而后再长久化这台机器上的Volume目录。而Local PV，则须要运维人员提前准备好节点的磁盘，当Pod调度的时候要思考这些LocalPV的散布。 创立Local PV下面定义的local字段，指定了它是一个Local Persistent Volume；而path字段，指定的是这个PV对应的磁盘的门路。而这个磁盘存在于k8s-node01节点上，也就意味着pod应用这个pv就必须运行在这个节点上。 创立PVC 创立pod当pod创立之后，能够看到pod会调度到k8s-node01上，这时pvc和pv的状态曾经绑定。 删除Local PV删除Local PV时因为咱们是手动创立PV，在删除时须要依照如下流程操作：1.删除应用这个PV的Pod2.删除PVC3.删除PV hostPath与Local PV比照 StorageClass提早绑定机制 provisioner 字段定义为no-provisioner，这是因为 Local Persistent Volume 目前尚不反对 Dynamic Provisioning动静生成PV，所以咱们须要提前手动创立PV。 volumeBindingMode字段定义为WaitForFirstConsumer，它是 Local Persistent Volume 里一个十分重要的个性，即：提早绑定。提早绑定就是在咱们提交PVC文件时，StorageClass为咱们提早绑定PV与PVC的对应关系。 这样做的起因是：比方咱们在以后集群上有两个雷同属性的PV，它们散布在不同的节点Node1和Node2上，而咱们定义的Pod须要运行在Node1节点上 ，然而StorageClass曾经为Pod申明的PVC绑定了在Node2上的PV，这样的话，Pod调度就会失败，所以咱们要提早StorageClass的绑定操作。 也就是提早到到第一个申明应用该 PVC 的 Pod 呈现在调度器之后，调度器再综合思考所有的调度规定，当然也包含每个 PV 所在的节点地位，来对立决定，这个 Pod 申明的 PVC，到底应该跟哪个 PV 进行绑定。 数据安全危险local volume仍受node节点可用性方面的限度，因而并不适用于所有应用程序。 如果node节点变得不衰弱，则local volume也将变得不可拜访，应用这个local volume的Pod也将无奈运行。 应用local voluems的应用程序必须可能容忍这种升高的可用性以及潜在的数据失落，是否会真得导致这个结果将取决于node节点底层磁盘存储与数据保护的具体实现了。 ...

一、介绍Kubernetes operator是一种封装、部署、治理kubernetes利用的办法。它是Kubernetes的扩大软件，利用自定义资源治理利用及组件。operator所有的操作都是调用Kubernetes Apiserver的接口，所以实质上它也是Apiserver的客户端软件。 本文是对于Kubernetes operator开发入门的教程，旨在率领有趣味理解Operator开发的老手一窥Operator开发的根本流程。 二、 筹备工作首先你须要有一个可用的kubernetes测试集群，如果你对kubernetes相干概念，集群建设还没有充沛的理解，我倡议你先理解这方面的常识本教程应用Go语言，须要你对Go语言的语法有简略的理解，Go语言也是kubernetes的开发语言。如果你应用其余语言也是没有问题的，进入到底层都是HTTP申请。官网的或社区的SDK也提供了多种语言可供选择，当你理解了其中原理，再应用其余语言进行开发该当是能得心应手咱们将应用官网提供的k8s.io/client-go库来做测试, 它根本封装了对Kurbernetes的大部分操作。示例代码目录如下： ├── Dockerfile├── go.mod├── go.sum├── k8s //客户端封装│ └── client.go├── LICENSE├── main.go├── Makefile├── utils //助手组件│ ├── errs│ │ └── errs.go│ └── logs│ └── slog.go└── yaml ├── Deployment.yaml //operator 部署文件 └── ServiceAccount.yaml //权限绑定文件， 下文把权限配置，绑定定义离开了，这里放在一起也是能够的作为演示，本教程咱们次要关注以下几个方面的操作： 列出所有Node/namespace列出指定命名空间的Deployment/Services创立一个Deployment/Service删除Deployment/ServiceOperator的开发跟你平时开发的程序并无二致，它最重要的关注点是权限问题。Kubernetes有十分严格粗疏的权限设计，具体到每个资源每个操作。所以咱们的Operator软件并无严格要求必须运行在Kubernetes集群的容器里，只有权限配置切当，你能够间接运行go build进去的二进制包，甚至你能够间接在你的开发环境里go run都是能够的。通常咱们为了开发调试不便，都会间接采纳这种形式运行。 如果你对Kubernetes的权限治理并不相熟，我倡议你把你的代码放在你的测试集群的Master节点里运行，Master节点领有集群的最高权限，省去了你配置权限的麻烦，把次要精力集中在业务逻辑下面。 三、开始0x01、初始化客户端对象首先咱们须要在代码中实例化一个k8s.io/client-go/kubernetes.Clientset类型的对象变量，它就是咱们整个Operator利用操作的客户端对象。 它能够由 func NewForConfig(c *rest.Config) (*Clientset, error)func NewForConfigOrDie(c *rest.Config) *Clientset两个函数实例化。两个函数的区别：一个是实例化失败返回谬误，另一个间接抛出异样。通常倡议应用前者，由程序处理谬误，而不是间接抛出异样。 两个办法都须要一个rest.Config对象作为参数， rest.Config最重要的配置我的项目就是权限配置。 SDK给咱们提供了func BuildConfigFromFlags(masterUrl, kubeconfigPath string) (*restclient.Config, error) 办法来实例化rest.Config对象。 masterUrl参数就是主节点的Server URLkubeconfigPath参数就是权限配置文件门路。Master节点的权限配置文件通常是文件：/etc/kubernetes/admin.conf。 kubernetes在部署master节点后通过会倡议你把/etc/kubernetes/admin.conf文件拷贝到$HOME/.kube/config，所以你看到这两个中央的文件内容是一样的。 咱们在传参的时候通常倡议应用$HOME/.kube/config文件，免得因为文件权限问题出现异常，减少问题的复杂性。 BuildConfigFromFlags办法两个参数其实都是能够传空值的，如果咱们的Operator程序在Kubernetes集群容器里运行，传空值（通过也是这么干的）进来它会应用容器里的默认权限配置。然而在非kubernetes集群容器里，它没有这个默认配置的，所以在非kubernetes集群容器咱们须要显式把权限配置文件的门路传入。 说了一堆，咱们间接上代码吧： import "k8s.io/client-go/kubernetes"//调用之前请确认文件存在，如果不存在应用/etc/kubernetes/admin.confcfg, err := clientcmd.BuildConfigFromFlags("", "/root/.kube/config") if err != nil { log.Fatalln(err)}k8sClient, err := kubernetes.NewForConfig(cfg)if err != nil { log.Fatalln(err)}k8sClient就是咱们频繁应用的客户端对象。 ...

NetworkPolicy简介咱们常常须要按租户进行网络隔离，k8s 提供了 networkpolicy 来定义网络策略，从而实现网络隔离以满足租户隔离及局部租户下业务隔离等。Network Policy 提供了基于策略的网络管制，用于隔离利用并缩小攻击面。它应用标签选择器模仿传统的分段网络，并通过策略管制它们之间的流量以及来自内部的流量。但这个 networkpolicy 须要有第三方外接网络插件的反对，如Calico、Romana、Weave Net和trireme等资源标准apiVersion: networking.k8s.io/v1 #资源附属的API群组及版本号kind: NetworkPolicy #资源类型的名称,名称空间级别资源metadata: #资源元数据 name <string> #资源名称标识 namespace <string> #NetworkPolicy是名称空间级别的资源spec:#冀望的状态 podSelector <Object> #以后规定失效的同一名称空间中的一组指标Pod对象，必选字段; #空值示意以后名称空间中的所有Pod资源 policyTypes<[]string> #Ingress示意失效ingress字段;Egress示意失效 # egress字段,同时提供示意二者均无效 ingress <[]0bject>#入站流量源端点对象列表，白名单，空值示意“所有” - from <[jobject> #具体的端点对象列表，空值示意所有非法端点 - ipBlock <0bject> # IP地址块范畴内的端点，不能与另外两个字段同时应用 - namespaceSelector <0bject>#匹配的名称空间内的端点 podSelector <Object># 由Pod标签选择器匹配到的端点，空值示意<none> ports <[ ]0bject>#具体的端口对象列表,空值示意所有非法端口 engress,<[jobject> #出站流量指标端点对象列表，白名单,空值示意“所有” - to <[]0bject> #具体的端点对象列表，空值示意所有非法端点，格局同ingres.from; ports <[j0bject> #具体的端口对象列表，空值示意所有非法端口策略匹配规定为1.不辨别规定前后秩序与权重2.以最大容许权限为最优匹配 #测试在default名称空间下拜访dev名称空间[root@k8s-master Network]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdeployment-demo-fb544c5d8-r7pc8 1/1 Running 0 28h 192.168.51.1 k8s-node3 <none> <none>deployment-demo-fb544c5d8-splfr 1/1 Running 0 28h 192.168.12.1 k8s-node2 <none> <none>[root@k8s-master ~]# kubectl get pod -o wide -n devNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdeployment-demo-867c7d9d55-kzctj 1/1 Running 0 134m 192.168.51.4 k8s-node3 <none> <none>deployment-demo-867c7d9d55-l88qg 1/1 Running 0 134m 192.168.12.2 k8s-node2 <none> <none>#default名称空间拜访 dev名称空间pod 默认是能够互相通信的[root@k8s-master Network]# kubectl exec deployment-demo-fb544c5d8-r7pc8 -it -- /bin/sh[root@deployment-demo-fb544c5d8-r7pc8 /]# curl 192.168.12.2iKubernetes demoapp v1.1 !! ClientIP: 192.168.51.1, ServerName: deployment-demo-867c7d9d55-l88qg, ServerIP: 192.168.12.2![root@deployment-demo-fb544c5d8-r7pc8 /]# curl 192.168.12.2iKubernetes demoapp v1.1 !! ClientIP: 192.168.51.1, ServerName: deployment-demo-867c7d9d55-l88qg, ServerIP: 192.168.12.2!为所有名称空间打上标签[root@k8s-master Network]# kubectl label ns default name=defaultnamespace/default labeled[root@k8s-master Network]# kubectl label ns kube-system name=kube-systemnamespace/default kube-system[root@k8s-master Network]# kubectl get ns --show-labelsNAME STATUS AGE LABELSdefault Active 3d9h name=defaultdev Active 45h name=devkube-node-lease Active 3d9h name=kube-node-leasekube-public Active 3d9h name=kube-publickube-system Active 3d9h name=kube-systemtest Active 38h name=test......示例1：禁止所有入站流量规定创立NetworkPolicy 为K8S规范资源 为了阐明 策略会以最大容许权限为最优匹配，增加一条默认回绝所有流量的策略[root@k8s-master Network]# cat netpol-dev-denyall.yaml apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-all-ingress namespace: devspec: podSelector: {} #空值匹配所有 policyTypes: ["Ingress", "Egress"] #回绝所有出站入站流量 egress: - to: - podSelector: {} #空值为none ingress: - from: - podSelector: {} #空值为none [root@k8s-master Network]# kubectl apply -f netpol-dev-denyall.yaml #测试在default、dev名称空间下互相联通性[root@deployment-demo-fb544c5d8-r7pc8 /]# curl 192.168.12.2^C[root@deployment-demo-fb544c5d8-r7pc8 /]# curl 192.168.12.2^C[root@deployment-demo-fb544c5d8-r7pc8 /]# ping 192.168.12.2PING 192.168.12.2 (192.168.12.2): 56 data bytes^C--- 192.168.12.2 ping statistics ---3 packets transmitted, 0 packets received, 100% packet loss#所有流量拜访失败示例2: 创立NetworkPolicy2 放行dev名称空间规定1:标签匹配的名称空间所有流量都能拜访dev下所有Pod;规定2:除了default名额空间,其它所有名称空间都能够拜访dev下的 80端口组合应用，会以最大容许权限为最优匹配权限[root@k8s-master Network]# cat netpol-dev-demoapp-ingress.yaml apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: demoapp-ingress namespace: devspec: podSelector: matchLabels : app: demoapp #dev名称空间下 领有这个标签的Pod失效 policyTypes: ["Ingress"] #入站流量 ingress: - from: #规定1 - namespaceSelector: #名称空间标签匹配 matchExpressions: - key: name operator: In values: [dev,kube-system,logs,monitoring,kubernetes-dashboard] # 匹配名称空间蕴含这些标签 如:name=dev、name=kube-system 这里不蕴含default# - ipBlock: #网段匹配 以下网段的pod也被容许拜访# cidr: 192.168.0.0/16 - from: #规定2 只是非default名称空间流量拜访80端口都容许 - namespaceSelector: matchExpressions: - {key: name,operator: NotIn, values: ["default"]} #回绝defaultq名称空间流量拜访80端口都容许 ports: - protocol: TCP port: 80[root@k8s-master Network]# kubectl apply -f netpol-dev-demoapp-ingress.yaml networkpolicy.networking.k8s.io/demoapp-ingress configured[root@k8s-master Network]# kubectl get netpol -n devNAME POD-SELECTOR AGEdemoapp-ingress app=demoapp 38hdeny-all-ingress <none> 8h[root@k8s-master Network]# kubectl describe netpol demoapp-ingress -n devName: demoapp-ingressNamespace: devCreated on: 2021-08-31 17:31:59 +0800 CSTLabels: <none>Annotations: <none>Spec: PodSelector: app=demoapp Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: name in (dev,kube-system,kubernetes-dashboard,logs,monitoring) ---------- To Port: 80/TCP From: NamespaceSelector: name notin (default) Not affecting egress traffic Policy Types: Ingress在default名称空间下拜访dev名称空间80端口测试 仍然无法访问 没有匹配到合乎规定的条目 ...

Calico简介Calico 是一种容器之间互通的网络计划。在虚拟化平台中，比方 OpenStack、Docker 等都须要实现 workloads 之间互连，但同时也须要对容器做隔离管制，就像在 Internet 中的服务仅凋谢80端口、私有云的多租户一样，提供隔离和管控机制。而在少数的虚拟化平台实现中，通常都应用二层隔离技术来实现容器的网络，这些二层的技术有一些弊病，比方须要依赖 VLAN、bridge 和隧道等技术，其中 bridge 带来了复杂性，vlan 隔离和 tunnel 隧道则耗费更多的资源并对物理环境有要求，随着网络规模的增大，整体会变得越加简单。咱们尝试把 Host 当作 Internet 中的路由器，同样应用 BGP 同步路由，并应用 iptables 来做平安拜访策略，最终设计出了 Calico 计划。 设计思维：Calico 不应用隧道或 NAT 来实现转发，而是奇妙的把所有二三层流量转换成三层流量，并通过 host 上路由配置实现跨 Host 转发 设计劣势：1.更优的资源利用二层网络通讯须要依赖播送音讯机制，播送音讯的开销与 host 的数量呈指数级增长，Calico 应用的三层路由办法，则齐全克制了二层播送，缩小了资源开销。 2.可扩展性Calico 应用与 Internet 相似的计划，Internet 的网络比任何数据中心都大，Calico 同样人造具备可扩展性。 3.简略而更容易 debug因为没有隧道，意味着 workloads 之间门路更短更简略，配置更少，在 host 上更容易进行 debug 调试。 4.更少的依赖Calico 仅依赖三层路由可达。 5.可适配性Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。 Calico 网络Node之间通信网络IPIP(可跨网段通信)从字面来了解，就是把一个IP数据包又套在一个IP包里，即把 IP 层封装到 IP 层的一个 tunnel。它的作用其实基本上就相当于一个基于IP层的网桥！一般来说，一般的网桥是基于mac层的，基本不需 IP，而这个 ipip 则是通过两端的路由做一个 tunnel，把两个原本不通的网络通过点对点连接起来。 相似vxlan 但封装开销比vxlan小 效率绝对更高一些，但安全性也更差 ...

前言CNI是Container Network Interface的是一个规范的，通用的接口。当初容器平台：docker，kubernetes，mesos，容器网络解决方案：flannel，calico，weave。只有提供一个规范的接口，就能为同样满足该协定的所有容器平台提供网络性能，而CNI正是这样的一个规范接口协议。CNI用于连贯容器管理系统和网络插件。提供一个容器所在的network namespace，将network interface插入该network namespace中（比方veth的一端），并且在宿主机做一些必要的配置（例如将veth的另一端退出bridge中），最初对namespace中的interface进行IP和路由的配置Kubernetes次要存在4种类型的通信: container-to-container:产生在Pod外部,借助于lo实现;Pod-to-Pod: Pod间的通信，k8s本身并未解决该类通信，而是借助于CNI接口，交给第三方解决方案;CNI之前的接口叫kubenet;Service-to-Pod:借助于kube-proxy生成的iptables或ipvs规定实现;ExternalClients-to-Service:引入集群内部流量 hostPort、hostNletwork、nodeport/service,、loadbalancer/service、 exteralP/service、 Ingres;Flannel简介Flannel是CoreOS团队针对Kubernetes设计的一个网络布局服务，简略来说，它的性能是让集群中的不同节点主机创立的Docker容器都具备全集群惟一的虚构IP地址。在默认的Docker配置中，每个节点上的Docker服务会别离负责所在节点容器的IP调配。这样导致的一个问题是，不同节点上容器可能取得雷同的内外IP地址。并使这些容器之间可能之间通过IP地址互相找到，也就是互相ping通。Flannel的设计目标就是为集群中的所有节点从新布局IP地址的应用规定，从而使得不同节点上的容器可能取得“同属一个内网”且”不反复的”IP地址，并让属于不同节点上的容器可能间接通过内网IP通信。Flannel本质上是一种“笼罩网络(overlaynetwork)”，也就是将TCP数据包装在另一种网络包外面进行路由转发和通信，目前曾经反对udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发形式，默认的节点间数据通信形式是UDP转发。简略总结Flannel特点使集群中的不同Node主机创立的Docker容器都具备全集群惟一的虚构IP地址。建设一个笼罩网络（overlay network），通过这个笼罩网络，将数据包一成不变的传递到指标容器。笼罩网络是建设在另一个网络之上并由其基础设施反对的虚构网络。笼罩网络通过将一个分组封装在另一个分组内来将网络服务与底层基础设施拆散。在将封装的数据包转发到端点后，将其解封装。创立一个新的虚构网卡flannel0接管docker网桥的数据，通过保护路由表，对接管到的数据进行封包和转发（vxlan）。etcd保障了所有node上flanned所看到的配置是统一的。同时每个node上的flanned监听etcd上的数据变动，实时感知集群中node的变动。Flannel反对三种Pod网络模型，每个模型在flannel中称为一种"backend": vxlan: Pod与Pod经由隧道封装后通信，各节点彼此间能通信就行，不要求在同一个二层网络; 毛病:因为通过2次封装,吞吐量绝对变低,长处:不要求节点处于同一个2层网络vwlan directrouting:位于同一个二层网络上的、但不同节点上的Pod间通信，毋庸隧道封装;但非同一个二层网络上的节点上的Pod间通信，仍须隧道封装; 最优的计划host-gw: Pod与Pod不经隧道封装而间接通信，要求各节点位于同一个二层网络; #吞吐量最大 但须要在同个2层网络中Flannel 下载安装地址 https://github.com/flannel-io...示例1: 部署flannel 以Vxlan类型运行#查看flannel部署清单yaml文件中有对于网络类型的形容[root@k8s-master plugin]# cat kube-flannel.ymlkind: ConfigMapapiVersion: v1metadata: name: kube-flannel-cfg namespace: kube-system labels: tier: node app: flanneldata: cni-conf.json: | { "name": "cbr0", "cniVersion": "0.3.1", "plugins": [ { "type": "flannel", #实现虚构网络 "delegate": { "hairpinMode": true, "isDefaultGateway": true } }, { "type": "portmap", #端口映射 如:NodePort "capabilities": { "portMappings": true } } ] } net-conf.json: | { "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan" #默认为vxlan模式 } }[root@k8s-master plugin]# kubectl apply -f kube-flannel.ymlvxlan模式下 路由表Pod地址指向flannel.1[root@k8s-master plugin]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.54.2 0.0.0.0 UG 101 0 0 eth410.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0 #本机虚构网络接口10.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 flannel.110.244.2.0 10.244.2.0 255.255.255.0 UG 0 0 0 flannel.110.244.3.0 10.244.3.0 255.255.255.0 UG 0 0 0 flannel.1172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0192.168.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0192.168.54.0 0.0.0.0 255.255.255.0 U 101 0 0 eth4[root@k8s-node1 ~]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.54.2 0.0.0.0 UG 101 0 0 eth410.244.0.0 10.244.0.0 255.255.255.0 UG 0 0 0 flannel.110.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0 #本机虚构网络接口10.244.2.0 10.244.2.0 255.255.255.0 UG 0 0 0 flannel.110.244.3.0 10.244.3.0 255.255.255.0 UG 0 0 0 flannel.1172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0192.168.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0192.168.54.0 0.0.0.0 255.255.255.0 U 101 0 0 eth4[root@k8s-master plugin]# ip neighbour|grep flannel.1 #生成的永恒neighbour信息 进步路由效率10.244.1.0 dev flannel.1 lladdr ba:98:1c:fa:3a:51 PERMANENT10.244.3.0 dev flannel.1 lladdr da:29:42:38:29:55 PERMANENT10.244.2.0 dev flannel.1 lladdr fa:48:c1:29:0b:dd PERMANENT[root@k8s-master plugin]# bridge fdb show flannel.1|grep flannel.1ba:98:1c:fa:3a:51 dev flannel.1 dst 192.168.54.171 self permanent22:85:29:77:e1:00 dev flannel.1 dst 192.168.54.173 self permanentfa:48:c1:29:0b:dd dev flannel.1 dst 192.168.54.172 self permanentda:29:42:38:29:55 dev flannel.1 dst 192.168.54.173 self permanent#抓包flannel网络 其中 udp 8472为flannel网络默认端口[root@k8s-node3 ~]# tcpdump -i eth4 -nn udp port 8472tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes17:08:15.113389 IP 192.168.54.172.46879 > 192.168.54.173.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.2.9 > 10.244.3.92: ICMP echo request, id 2816, seq 61, length 6417:08:15.113498 IP 192.168.54.173.55553 > 192.168.54.172.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.3.92 > 10.244.2.9: ICMP echo reply, id 2816, seq 61, length 6417:08:16.114359 IP 192.168.54.172.46879 > 192.168.54.173.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.2.9 > 10.244.3.92: ICMP echo request, id 2816, seq 62, length 6417:08:16.114447 IP 192.168.54.173.55553 > 192.168.54.172.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.3.92 > 10.244.2.9: ICMP echo reply, id 2816, seq 62, length 6417:08:17.115558 IP 192.168.54.172.46879 > 192.168.54.173.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.2.9 > 10.244.3.92: ICMP echo request, id 2816, seq 63, length 6417:08:17.115717 IP 192.168.54.173.55553 > 192.168.54.172.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.3.92 > 10.244.2.9: ICMP echo reply, id 2816, seq 63, length 6417:08:18.117498 IP 192.168.54.172.46879 > 192.168.54.173.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.2.9 > 10.244.3.92: ICMP echo request, id 2816, seq 64, length 64能够看到10.244.2.9 > 10.244.3.92 Pod间的传输 通过封装从节点192.168.54.172.46879 传输到节点 192.168.54.173.8472 通过一层数据封装示例2: 增加flannel网络类型DirectRouting增加DirectRouting后,2层网络节点会应用宿主机网络接口间接通信,3层网络的节点会应用Vxlan 隧道封装后通信,组合应用是flannel最现实的网络类型因为测试环境所有节点都处于同一2层网络,所以从路由表无奈看到和flannel.1接口同时存在[root@k8s-master ~]# kubectl get cm -n kube-systemNAME DATA AGEcoredns 1 57dextension-apiserver-authentication 6 57dkube-flannel-cfg 2 57dkube-proxy 2 57dkubeadm-config 2 57dkubelet-config-1.19 1 57d[root@k8s-master ~]# kubectl edit cm kube-flannel-cfg -n kube-system net-conf.json: | { "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan", "DirectRouting": true #增加 } }重启Pod 正式环境用蓝绿更新[root@k8s-master ~]# kubectl get pod -n kube-system --show-labelsNAME READY STATUS RESTARTS AGE LABELScoredns-f9fd979d6-l9zck 1/1 Running 16 57d k8s-app=kube-dns,pod-template-hash=f9fd979d6coredns-f9fd979d6-s8fp5 1/1 Running 15 57d k8s-app=kube-dns,pod-template-hash=f9fd979d6etcd-k8s-master 1/1 Running 12 57d component=etcd,tier=control-planekube-apiserver-k8s-master 1/1 Running 16 57d component=kube-apiserver,tier=control-planekube-controller-manager-k8s-master 1/1 Running 40 57d component=kube-controller-manager,tier=control-planekube-flannel-ds-6sppx 1/1 Running 1 7d23h app=flannel,controller-revision-hash=585c88d56b,pod-template-generation=2,tier=nodekube-flannel-ds-j5g9s 1/1 Running 3 7d23h app=flannel,controller-revision-hash=585c88d56b,pod-template-generation=2,tier=nodekube-flannel-ds-nfz77 1/1 Running 1 7d23h app=flannel,controller-revision-hash=585c88d56b,pod-template-generation=2,tier=nodekube-flannel-ds-sqhq2 1/1 Running 1 7d23h app=flannel,controller-revision-hash=585c88d56b,pod-template-generation=2,tier=nodekube-proxy-42vln 1/1 Running 4 25d controller-revision-hash=565786c69c,k8s-app=kube-proxy,pod-template-generation=1kube-proxy-98gfb 1/1 Running 3 21d controller-revision-hash=565786c69c,k8s-app=kube-proxy,pod-template-generation=1kube-proxy-nlnnw 1/1 Running 4 17d controller-revision-hash=565786c69c,k8s-app=kube-proxy,pod-template-generation=1kube-proxy-qbsw2 1/1 Running 4 25d controller-revision-hash=565786c69c,k8s-app=kube-proxy,pod-template-generation=1kube-scheduler-k8s-master 1/1 Running 38 57d component=kube-scheduler,tier=control-planemetrics-server-6849f98b-fsvf8 1/1 Running 15 8d k8s-app=metrics-server,pod-template-hash=6849f98b[root@k8s-master ~]# kubectl delete pod -n kube-system -l app=flannelpod "kube-flannel-ds-6sppx" deletedpod "kube-flannel-ds-j5g9s" deletedpod "kube-flannel-ds-nfz77" deletedpod "kube-flannel-ds-sqhq2" deleted[root@k8s-master ~]# 再次查看master、node路由表[root@k8s-master ~]# route -n Kernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.54.2 0.0.0.0 UG 101 0 0 eth410.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni010.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 eth410.244.2.0 192.168.54.172 255.255.255.0 UG 0 0 0 eth410.244.3.0 192.168.54.173 255.255.255.0 UG 0 0 0 eth4172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0192.168.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0192.168.54.0 0.0.0.0 255.255.255.0 U 101 0 0 eth4[root@k8s-node1 ~]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.54.2 0.0.0.0 UG 101 0 0 eth410.244.0.0 192.168.54.170 255.255.255.0 UG 0 0 0 eth410.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni010.244.2.0 192.168.54.172 255.255.255.0 UG 0 0 0 eth410.244.3.0 192.168.54.173 255.255.255.0 UG 0 0 0 eth4172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0192.168.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0192.168.54.0 0.0.0.0 255.255.255.0 U 101 0 0 eth4#网络相干的Pod的IP会间接通过宿主机网络接口地址[root@k8s-master ~]# kubectl get pod -n kube-system -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEScoredns-f9fd979d6-l9zck 1/1 Running 16 57d 10.244.0.42 k8s-master <none> <none>coredns-f9fd979d6-s8fp5 1/1 Running 15 57d 10.244.0.41 k8s-master <none> <none>etcd-k8s-master 1/1 Running 12 57d 192.168.4.170 k8s-master <none> <none>kube-apiserver-k8s-master 1/1 Running 16 57d 192.168.4.170 k8s-master <none> <none>kube-controller-manager-k8s-master 1/1 Running 40 57d 192.168.4.170 k8s-master <none> <none>kube-flannel-ds-d79nx 1/1 Running 0 2m12s 192.168.4.170 k8s-master <none> <none>kube-flannel-ds-m48m7 1/1 Running 0 2m14s 192.168.4.172 k8s-node2 <none> <none>kube-flannel-ds-pxmnf 1/1 Running 0 2m14s 192.168.4.171 k8s-node1 <none> <none>kube-flannel-ds-vm9kt 1/1 Running 0 2m19s 192.168.4.173 k8s-node3 <none> <none>kube-proxy-42vln 1/1 Running 4 25d 192.168.4.172 k8s-node2 <none> <none> #应用宿主机网络接口kube-proxy-98gfb 1/1 Running 3 21d 192.168.4.173 k8s-node3 <none> <none>kube-proxy-nlnnw 1/1 Running 4 17d 192.168.4.171 k8s-node1 <none> <none>kube-proxy-qbsw2 1/1 Running 4 25d 192.168.4.170 k8s-master <none> <none>kube-scheduler-k8s-master 1/1 Running 38 57d 192.168.4.170 k8s-master <none> <none>metrics-server-6849f98b-fsvf8 1/1 Running 15 8d 10.244.2.250 k8s-node2 <none> <none>抓包查看数据封装[root@k8s-master plugin]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESclient-1639 1/1 Running 0 52s 10.244.1.222 k8s-node1 <none> <none>replicaset-demo-v1.1-lgf6b 1/1 Running 0 59m 10.244.1.221 k8s-node1 <none> <none>replicaset-demo-v1.1-mvvfq 1/1 Running 0 59m 10.244.3.169 k8s-node3 <none> <none>replicaset-demo-v1.1-tn49t 1/1 Running 0 59m 10.244.2.136 k8s-node2 <none> <none>root@k8s-master plugin]# kubectl exec replicaset-demo-v1.1-tn49t -it -- /bin/sh #拜访node3[root@replicaset-demo-v1 /]# curl 10.244.3.169iKubernetes demoapp v1.1 !! ClientIP: 10.244.2.136, ServerName: replicaset-demo-v1.1-mvvfq, ServerIP: 10.244.3.169![root@replicaset-demo-v1 /]# curl 10.244.3.169#node3上抓包[root@k8s-node3 ~]# tcpdump -i eth4 -nn tcp port 80tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes11:03:57.508877 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [S], seq 1760692242, win 64860, options [mss 1410,sackOK,TS val 4266124446 ecr 0,nop,wscale 7], length 011:03:57.509245 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [S.], seq 3150629627, ack 1760692243, win 64308, options [mss 1410,sackOK,TS val 1453973317 ecr 4266124446,nop,wscale 7], length 011:03:57.510198 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [.], ack 1, win 507, options [nop,nop,TS val 4266124447 ecr 1453973317], length 011:03:57.510373 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [P.], seq 1:77, ack 1, win 507, options [nop,nop,TS val 4266124447 ecr 1453973317], length 76: HTTP: GET / HTTP/1.111:03:57.510427 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [.], ack 77, win 502, options [nop,nop,TS val 1453973318 ecr 4266124447], length 011:03:57.713241 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [P.], seq 1:18, ack 77, win 502, options [nop,nop,TS val 1453973521 ecr 4266124447], length 17: HTTP: HTTP/1.0 200 OK11:03:57.713821 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [.], ack 18, win 507, options [nop,nop,TS val 4266124651 ecr 1453973521], length 011:03:57.733459 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [P.], seq 18:155, ack 77, win 502, options [nop,nop,TS val 1453973541 ecr 4266124651], length 137: HTTP11:03:57.733720 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [FP.], seq 155:271, ack 77, win 502, options [nop,nop,TS val 1453973541 ecr 4266124651], length 116: HTTP11:03:57.735862 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [.], ack 155, win 506, options [nop,nop,TS val 4266124671 ecr 1453973541], length 011:03:57.735883 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [F.], seq 77, ack 272, win 506, options [nop,nop,TS val 4266124672 ecr 1453973541], length 011:03:57.736063 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [.], ack 78, win 502, options [nop,nop,TS val 1453973543 ecr 4266124672], length 011:03:58.650891 IP 10.244.2.136.49662 > 10.244.3.169.80: Flags [S], seq 3494935965, win 64860, options [mss 1410,sackOK,TS val 4266125588 ecr 0,nop,wscale 7], length 0能够看到数据的传输没有再通过封装 间接通过Pod IP flannel网络传输示例3: 批改flannel网络类型host-gw 须要留神host-gw只反对2层网络因为所有节点都处在2层网络中,实践上和后面增加DirectRouting 成果是一样的 就不累述 ...

前言外围资源类型存储卷，PV、PVC、SC、CSI(Longhorn)非凡类型的插件:ConfigMap、Secret、downwardAPI 如何为容器化利用提供配置信息: 启动容器时,间接向应用程序传递参数,args: []将定义好的配置文件焙进镜像之中;通过环境变量向容器传递配置数据:有个前提要求，利用得反对从环境变量加载配置信息;制作镜像时，应用entrypoint脚本来预处理变量，常见的做法就是应用非交互式编辑工具，将环境变量的值替换到利用的配置文件中;基于存储卷向容器传递配置文件; 运行中的扭转,须要由应用程序重载;ConfigMap简介ConfigMap API资源用来保留key-value pair配置数据，这个数据能够在pods里应用，或者被用来为像controller一样的零碎组件存储配置数据。尽管ConfigMap跟Secrets相似，然而ConfigMap更不便的解决不含敏感信息的字符串。 留神：ConfigMaps不是属性配置文件的替代品。ConfigMaps只是作为多个properties文件的援用。你能够把它了解为Linux零碎中的/etc目录，专门用来存储配置文件的目录。 ConfigMap 通过env环境变量援用通过环境变量的配置容器化利用时，须要在容器配置段中嵌套应用env字段，它的值是一个由环境变量构建的列表。每个环项变量通常由name和value(或valueFron)字段形成 name <string>:环境变量的名称,必选字段;value <string>:环境变量的值，通过 $(VAR_NAME)援用，逃逸格局为“$$(VAR_NAME)" 默认值为空;valueFrom <object> ∶环境变量值的援用源，例如以后Pod资源的名称、名称空间、标签等，不能与非空值的value字段同时应用，即环境变量的值要么源于value字段，要么源于valuFron字段，二者不可同时提供数据。valueFron: 字段可援用的值有多种起源，包含以后Pod资源的属性值，容器相干的零碎资源配置、ConfigMap对象中的key以及Secret对象中的Key，它们别离要应用不同的嵌套字段进行定义。fieldRef <bject>:以后Pod资源的指定字段，目前反对应用的字段包含metadata.mime、metadata.namespce、 metadata.labels、metadeta.annotations、spesc.nodeName、spec.serviceAccountName、status.hostIP和status.podIP等;configMapKeyRef <Object>: ConfigMap对象中的特定Key;secretKeyRef<object>: Secret对象中的特定Key;resourceFieldRef <object>: 以后容器的特定系统资源的最小值(配额）或最大值《限额)，目前反对的援用包含 limits.cpu. limits.memory、limits.ephemeral-storage. requests.cpu、reuests.memory和requests.ephemeral-storage[root@k8s-master ~]# kubectl create configmap --help #查看示例...Examples: # Create a new configmap named my-config based on folder bar kubectl create configmap my-config --from-file=path/to/bar # Create a new configmap named my-config with specified keys instead of file basenames on disk kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt # Create a new configmap named my-config with key1=config1 and key2=config2 kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2 # Create a new configmap named my-config from the key=value pairs in the file kubectl create configmap my-config --from-file=path/to/bar # Create a new configmap named my-config from an env file kubectl create configmap my-config --from-env-file=path/to/bar.envOptions: --allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in...示例1:comfigMap创立[root@k8s-master nginx-conf.d]# cat myserver.conf server { listen 8080; server_name www.ik8s.io; include /etc/nginx/conf.d/myserver-*.cfg; location / { root /usr/share/nginx/html; }}[root@k8s-master nginx-conf.d]# cat myserver-gzip.cfg gzip on;gzip_comp_level 5;gzip_proxied expired no-cache no-store private auth;gzip_types text/plain text/css application/xml text/javascript;[root@k8s-master nginx-conf.d]# cat myserver-status.cfg location /nginx-status {stub_status on;access_log off;}[root@k8s-master nginx-conf.d]# ls #一共3个配置文件 myserver.conf myserver-gzip.cfg myserver-status.cfg[root@k8s-master ~]# kubectl create configmap demoapp-config --from-literal=host=0.0.0.0 --from-literal=port=8080 #创立host=0.0.0.0、literal=port=8080为两个valconfigmap/demoapp-config created[root@k8s-master ~]# kubectl get cmNAME DATA AGEdemoapp-config 2 5s #能够看到DATA为2 2个数据项my-grafana 1 34dmy-grafana-test 1 34d[root@k8s-master ~]# kubectl describe cm demoapp-configName: demoapp-configNamespace: defaultLabels: <none>Annotations: <none>Data====port: #数据项1 Port:8080----8080host: #数据项2 host: 0.0.0.----0.0.0.0Events: <none>[root@k8s-master ~]# kubectl get cm demoapp-config -o yamlapiVersion: v1data: host: 0.0.0.0 port: "8080"kind: ConfigMapmetadata: creationTimestamp: "2021-08-05T09:16:15Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:data: .: {} f:host: {} f:port: {} manager: kubectl-create operation: Update time: "2021-08-05T09:16:15Z" name: demoapp-config namespace: default resourceVersion: "6906130" selfLink: /api/v1/namespaces/default/configmaps/demoapp-config uid: 625c38a9-02bc-43c7-b351-b2ce7387cab7 [root@k8s-master nginx-conf.d]# kubectl create configmap nginx-config --from-file=./myserver.conf --from-file=status.cfg=./myserver-status.cfg #创立2个数据项指定文件,默认以文件名为键名 第2个文件指定status.cfg为键名configmap/nginx-config created[root@k8s-master nginx-conf.d]# kubectl get cm NAME DATA AGEdemoapp-config 2 18mmy-grafana 1 34dmy-grafana-test 1 34dnginx-config 2 17s[root@k8s-master nginx-conf.d]# kubectl get cm nginx-config -o yamlapiVersion: v1data: myserver.conf: | # |为多行键值分隔符 为了保留多行数据应用了|和缩进 server { listen 8080; server_name www.ik8s.io; include /etc/nginx/conf.d/myserver-*.cfg; location / { root /usr/share/nginx/html; } } status.cfg: | location /nginx-status { stub_status on; access_log off; }kind: ConfigMapmetadata: creationTimestamp: "2021-08-06T06:35:41Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:data: .: {} f:myserver.conf: {} f:status.cfg: {} manager: kubectl-create operation: Update time: "2021-08-06T06:35:41Z" name: nginx-config namespace: default resourceVersion: "7159858" selfLink: /api/v1/namespaces/default/configmaps/nginx-config uid: 8dbd637a-fb23-447a-8bb5-9e722d7e871d[root@k8s-master nginx-conf.d]# lsmyserver.conf myserver-gzip.cfg myserver-status.cfg[root@k8s-master configmap]# kubectl create configmap nginx-config-files --from-file=./nginx-conf.d/configmap/nginx-config-file created[root@k8s-master configmap]# kubectl get cmNAME DATA AGEdemoapp-config 2 21hmy-grafana 1 35dmy-grafana-test 1 35dnginx-config 2 18mnginx-config-files 3 3s #3个数据项[root@k8s-master nginx-conf.d]# kubectl get cm nginx-config-files -o yamlapiVersion: v1data: myserver-gzip.cfg: | gzip on; gzip_comp_level 5; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css application/xml text/javascript; myserver-status.cfg: | location /nginx-status { stub_status on; access_log off; } myserver.conf: | server { listen 8080; server_name www.ik8s.io; include /etc/nginx/conf.d/myserver-*.cfg; location / { root /usr/share/nginx/html; } }kind: ConfigMapmetadata: creationTimestamp: "2021-08-06T08:02:34Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:data: .: {} f:myserver-gzip.cfg: {} f:myserver-status.cfg: {} f:myserver.conf: {} manager: kubectl-create operation: Update time: "2021-08-06T08:02:34Z" name: nginx-config-files namespace: default resourceVersion: "7177123" selfLink: /api/v1/namespaces/default/configmaps/nginx-config-files uid: 2fd21dc3-5e61-4413-bcd5-35337b1ce286示例2: configMap援用[root@k8s-master configmap]# cat configmaps-env-demo.yaml apiVersion: v1kind: ConfigMapmetadata: name: demoapp-config namespace: defaultdata: demoapp.port: "8080" demoapp.host: 0.0.0.0---apiVersion: v1kind: Podmetadata: name: configmaps-env-demo namespace: defaultspec: containers: - image: ikubernetes/demoapp:v1.0 name: demoapp env: - name: PORT valueFrom: configMapKeyRef: #援用configMap 键值 name: demoapp-config key: demoapp.port optional: false #是否为可有可无项 false 为必选项 - name: HOST valueFrom: configMapKeyRef: name: demoapp-config key: demoapp.host optional: true #是否可有可无 ture 非必选项[root@k8s-master configmap]# kubectl apply -f configmaps-env-demo.yaml[root@k8s-master configmap]# kubectl get podNAME READY STATUS RESTARTS AGEcentos-deployment-66d8cd5f8b-95brg 1/1 Running 0 46hconfigmaps-env-demo 1/1 Running 0 118smy-grafana-7d788c5479-bpztz 1/1 Running 1 46hvolumes-pvc-longhorn-demo 1/1 Running 0 27h[root@k8s-master comfigmap]# kubectl exec configmaps-env-demo -- netstat -tnl #查看配置是否失效Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN [root@k8s-master configmap]# cat configmaps-volume-demo.yaml apiVersion: v1kind: Podmetadata: name: configmaps-volume-demo namespace: defaultspec: containers: - image: nginx:alpine name: nginx-server volumeMounts: - name: ngxconfs mountPath: /etc/nginx/conf.d/ readOnly: true volumes : - name: ngxconfs configMap: name: nginx-config-files #援用后面定义的configmap optional: false[root@k8s-master configmap]# kubectl get podNAME READY STATUS RESTARTS AGEcentos-deployment-66d8cd5f8b-95brg 1/1 Running 0 46hconfigmaps-env-demo 1/1 Running 0 35mconfigmaps-volume-demo 1/1 Running 0 6m8smy-grafana-7d788c5479-bpztz 1/1 Running 1 46hvolumes-pvc-longhorn-demo 1/1 Running 0 28h[root@k8s-master configmap]# kubectl exec configmaps-volume-demo -it -- /bin/sh/ # nginx -T......# configuration file /etc/nginx/conf.d/myserver.conf: #看容器配置文件是否加载configmap配置server { listen 8080; server_name www.ik8s.io; include /etc/nginx/conf.d/myserver-*.cfg; location / { root /usr/share/nginx/html; }}# configuration file /etc/nginx/conf.d/myserver-gzip.cfg:gzip on;gzip_comp_level 5;gzip_proxied expired no-cache no-store private auth;gzip_types text/plain text/css application/xml text/javascript;# configuration file /etc/nginx/conf.d/myserver-status.cfg:location /nginx-status {stub_status on;access_log off;}[root@k8s-master configmap]# kubectl get pods configmaps-volume-demo -o go-template={{.status.podIP}}10.244.1.177[root@k8s-master configmap]# curl 10.244.1.177:8080 #默认页面...<h1>Welcome to nginx!</h1>[root@k8s-master configmap]# curl -H "Host:www.ik8s.io" 10.244.1.177:8080/nginx-status #自定义页面Active connections: 1 server accepts handled requests 2 2 2 Reading: 0 Writing: 1 Waiting: 0挂载configMap一部分资源时有两种办法1.挂载卷时通过items:参数 指定容许输入到卷的键2.在容器挂载卷时，指定挂载哪些卷 ...

前言：后面介绍的PV、PVC实现了存储类型和Pod挂载的解耦，开发人员间接应用PVC，而Volume存储系统的PV由管理员保护，但随之带来的问题，开发人员应用PVC之前，须要系统管理员提前手动创立PV，而随着pod的一直增多，系统管理员的工作会变得反复和繁琐，动态供应形式这并不合乎自动化运维的趋势，随之应运而生的Storageclass 动静预配存储空间，它的作用就是创立PV的模板,解决了PV的主动创立，备份等扩大性能. Storageclass简介简称SC;PV和PVC都可属于某个特定的SC;创立PV的模板:能够将某个存储服务与SC关联起来，并且将该存储服务的治理接口提供给SC，从而让SC可能在存储服务上CRUD(create、Read.Update和Delete)存储单元;因此，在同一个SC上申明PVC时，若无现存可匹配的PV，则SC可能调用治理接口间接创立出一个合乎PVC申明的需要的PV来。这种PV的提供机制，就称为Dynamic Provision. 具体来说，StorageClass会定义一下两局部： PV的属性 ，比方存储的大小、类型等；创立这种PV须要应用到的存储插件，比方Ceph等；有了这两局部信息，Kubernetes就可能依据用户提交的PVC，找到对应的StorageClass，而后Kubernetes就会调用 StorageClass申明的存储插件，创立出须要的PV。 这里须要留神的是这么多种存储系统并不是所有的存储系统都反对StorageClass,它须要你的存储系统提供某种接口来让controller能够调用并传递进去PVC的参数去创立PV 常用字段:StorageClass资源的冀望状态间接与apiversion、kind和metadata定义于同一级别而无须嵌套于spec字段中，它反对应用的字段包含如下几个 allowVolumeExpansion <boolean>:是否反对存储卷空间扩大性能;allowedTopologies <[]0bject>:定义能够动静配置存储卷的节点拓扑，仅启用了卷调度性能的服务器才会用到该字段;每个卷插件都有本人反对的拓扑标准，空的拓扑选择器示意无拓扑限度;provisioner <strinp>:必选字段，用于指定存储服务方(provisioner，或称为准备器)，存储类要依赖该字段值来断定要应用的存储插件以便适配到指标存储系统;kubernetes内建反对许多的Provisioner，它们的名字都以kubernetes.io/为前缀，例如kubernetes.io/glusterfs等;parameters <map[string]stringp: 定义连贯至指定的Provisioner类别下的某特定存储时须要应用的各相干参数;不同Provisioner的可用的参数各不相同;reclaimPolicy <strinp:由以后存储类动态创建约PV资源的默认回收策路，可用值为Delete(默认)和Retain两个;但那些动态FV的回收策略则取决于它们本身的定义;volumeBindingMlode <string>:定义如何为PVC实现预配和绑定，默认值为VolumeBindingImmediate;该字段仅在启用了存储卷调度性能时能力失效;mountoptions<[]string>:由以后类动态创建的PV资源的默认挂载选项列表。模板示例:[root@k8s-master storage]# cat Storageclass-rdb-demo.yaml apiversion: storage.k8s.io/v1 kind: Storageclassmetadata: name: fast-rbdprovisioner: kubernetes.io/rbd #不同的存储后端 parameters模板各不一样 须要查阅官网文档 这里是ceph的 也不是所有的存储类型都是反对Storageclassparameters: monitors: ceph01.ilinux.io:6789,ceph02.ilinux.io:6789,ceph03.ilinux.io:6789 adminId: admin adminSecretName: ceph-admin-secret adminSecretNamespace: kube-system pool: kube userId: kube userSecretName: ceph-kube-secret userSecretNamespace: kube-system fsType: ext4 imageFormat: "2" imageFeatures: "layering"reclaimPolicy: Retain #回收策略因为测试环境没有ceph集群这里不作演示Longhorn Storageclass插件官网文档: https://longhorn.io Longhorn极大地晋升了开发人员和ITOps的效率，仅需点击一下鼠标，即可轻松实现长久化存储，并且无需为专有解决方案领取低廉的费用。除此之外，Longhorn缩小了治理数据及操作环境所需的资源，从而帮忙企业更加专一且疾速地交付代码及应用程序。 Longhorn仍旧秉承Rancher 100%开源的产品理念，它是一个应用微服务构建的分布式块存储我的项目。2019年，Longhorn公布Beta版本，并于同年10月作为沙箱（Sandbox）我的项目募捐给CNCF。Longhorn受到了开发者们的宽泛关注，成千上万名用户对其进行了压力测试，并提供了极为贵重的反馈意见。 Longhorn的GA版本提供了一系列功能丰富的企业级存储性能，包含： 主动配置，快照，备份和复原零中断卷扩容具备定义的RTO和RPO的跨集群劫难复原卷在不影响卷的状况下实时降级全功能的Kubernetes CLI集成和独立的用户界面 装置Longhorn装置筹备:节点数至多为3台 要抉择leader [root@k8s-master storage]# yum -y install iscsi-initiator-utils #装置前须要装置ISCSI[root@k8s-master storage]# kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/deploy/longhorn.yaml #装置 因为要下载镜像 须要期待一些工夫[root@k8s-master storage]# kubectl get pods -n longhorn-system --watch #期待所有pod就绪[root@k8s-master storage]# kubectl get pods --namespace longhorn-system -o wide #所有pod就绪NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEScsi-attacher-54c7586574-fvv4p 1/1 Running 0 37m 10.244.3.16 k8s-node3 <none> <none>csi-attacher-54c7586574-swdsr 1/1 Running 0 43m 10.244.2.111 k8s-node2 <none> <none>csi-attacher-54c7586574-zkzrg 1/1 Running 0 43m 10.244.3.10 k8s-node3 <none> <none>csi-provisioner-5ff5bd6b88-bs687 1/1 Running 0 37m 10.244.3.17 k8s-node3 <none> <none>csi-provisioner-5ff5bd6b88-gl4xn 1/1 Running 0 43m 10.244.2.112 k8s-node2 <none> <none>csi-provisioner-5ff5bd6b88-qkzt4 1/1 Running 0 43m 10.244.3.11 k8s-node3 <none> <none>csi-resizer-7699cdfc4-4w49w 1/1 Running 0 37m 10.244.3.15 k8s-node3 <none> <none>csi-resizer-7699cdfc4-l2j49 1/1 Running 0 43m 10.244.3.12 k8s-node3 <none> <none>csi-resizer-7699cdfc4-sndlm 1/1 Running 0 43m 10.244.2.113 k8s-node2 <none> <none>csi-snapshotter-8f58f46b4-6s89m 1/1 Running 0 37m 10.244.2.119 k8s-node2 <none> <none>csi-snapshotter-8f58f46b4-qgv5r 1/1 Running 0 43m 10.244.3.13 k8s-node3 <none> <none>csi-snapshotter-8f58f46b4-tf5ls 1/1 Running 0 43m 10.244.2.115 k8s-node2 <none> <none>engine-image-ei-a5a44787-5ntlm 1/1 Running 0 44m 10.244.1.146 k8s-node1 <none> <none>engine-image-ei-a5a44787-h45hr 1/1 Running 0 44m 10.244.3.6 k8s-node3 <none> <none>engine-image-ei-a5a44787-phnjf 1/1 Running 0 44m 10.244.2.108 k8s-node2 <none> <none>instance-manager-e-4384d6f1 1/1 Running 0 44m 10.244.2.110 k8s-node2 <none> <none>instance-manager-e-54f46256 1/1 Running 0 34m 10.244.1.148 k8s-node1 <none> <none>instance-manager-e-e008dd8a 1/1 Running 0 44m 10.244.3.7 k8s-node3 <none> <none>instance-manager-r-0ad3175d 1/1 Running 0 44m 10.244.3.8 k8s-node3 <none> <none>instance-manager-r-61277092 1/1 Running 0 44m 10.244.2.109 k8s-node2 <none> <none>instance-manager-r-d8a9eb0e 1/1 Running 0 34m 10.244.1.149 k8s-node1 <none> <none>longhorn-csi-plugin-5htsd 2/2 Running 0 7m41s 10.244.2.123 k8s-node2 <none> <none>longhorn-csi-plugin-hpjgl 2/2 Running 0 16s 10.244.1.151 k8s-node1 <none> <none>longhorn-csi-plugin-wtkcj 2/2 Running 0 43m 10.244.3.14 k8s-node3 <none> <none>longhorn-driver-deployer-5479f45d86-l4fpq 1/1 Running 0 57m 10.244.3.4 k8s-node3 <none> <none>longhorn-manager-dgk4d 1/1 Running 1 57m 10.244.1.145 k8s-node1 <none> <none>longhorn-manager-hb7cl 1/1 Running 0 57m 10.244.2.107 k8s-node2 <none> <none>longhorn-manager-xrxll 1/1 Running 0 57m 10.244.3.3 k8s-node3 <none> <none>longhorn-ui-79f8976fbf-sb79r 1/1 Running 0 57m 10.244.3.5 k8s-node3 <none> <none>示例1:测试创立PVC 主动创立PV[root@k8s-master storage]# cat pvc-dyn-longhorn-demo.yaml apiVersion: v1kind: PersistentVolumeClaim #资源类型metadata: name: pvc-dyn-longhorn-demo namespace: defaultspec: accessModes: ["ReadWriteOnce"] volumeMode: Filesystem resources: requests: storage: 2Gi #新的PV会以最低容量创立PV limits: storage: 10Gi storageClassName: longhorn #抉择longhorn发明[root@k8s-master storage]# kubectl apply -f longhorn.yaml 批改回收策略及正本数 非必要操作 依据理论须要批改 ...

kubernetes高可用集群的典型架构 管制面组件： etcd：多实例并行运行，通过Raft保障统一；apiserver：多实例并行运行；controller-manager：多实例仅有1个节点active；scheduler：多实例仅有1个节点active；工作节点组件： kubeletkube-proxyapiserver多实例运行apiserver是无状态的，所有数据保留在etcd中，apiserver不做缓存。 apiserver多个实例并行运行，通过Loadbalancer负载平衡用户的申请。 scheuler和controller-manager单实例运行scheduler和controller-manager会批改集群状态，多实例运行会产生竞争状态。 通过--leader-elect机制，只有领导者实例能力运行，其它实例处于standby状态；当领导者实例宕机时，残余的实例选举产生新的领导者。 领导者选举的办法：多个实例抢占创立endpoints资源，创立成功者为领导者。比方多个scheduler实例，抢占创立子endpoints资源：kube-scheduler # kubectl get endpoints kube-scheduler -n kube-system -oyamlapiVersion: v1kind: Endpointsmetadata: annotations: control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"master1_293eaef2-fd7e-4ae9-aae7-e78615454881","leaseDurationSeconds":15,"acquireTime":"2021-10-06T20:46:43Z","renewTime":"2021-10-19T02:49:21Z","leaderTransitions":165}' creationTimestamp: "2021-02-01T03:10:48Z"......查问kube-scheduler资源，能够看到此时master1上的scheduler是active状态，其它实例则为standby。 kubelet和kube-proxy在工作节点上运行kubelet和kube-proxy运行在工作节点上。 kubelet负责： 向apiserver创立一个node资源，以注册该节点；继续监控apiserver，若有pod部署到该节点上，创立并启动pod；继续监控运行的pod，向apiserver报告pod的状态、事件和资源耗费；周期性的运行容器的livenessProbe，当探针失败时，则重启容器；继续监控apiserver，若有pod删除，则终止该容器；kube-proxy负责： 负责确保对服务ip和port的拜访最终能达到pod中，通过节点上的iptables/ipvs来实现；参考：kubernetes in action

前言CNI是Container Network Interface的是一个规范的，通用的接口。当初容器平台：docker，kubernetes，mesos，容器网络解决方案：flannel，calico，weave。只有提供一个规范的接口，就能为同样满足该协定的所有容器平台提供网络性能，而CNI正是这样的一个规范接口协议。CNI用于连贯容器管理系统和网络插件。提供一个容器所在的network namespace，将network interface插入该network namespace中（比方veth的一端），并且在宿主机做一些必要的配置（例如将veth的另一端退出bridge中），最初对namespace中的interface进行IP和路由的配置Kubernetes次要存在4种类型的通信: container-to-container:产生在Pod外部,借助于lo实现;Pod-to-Pod: Pod间的通信，k8s本身并未解决该类通信，而是借助于CNI接口，交给第三方解决方案;CNI之前的接口叫kubenet;Service-to-Pod:借助于kube-proxy生成的iptables或ipvs规定实现;ExternalClients-to-Service:引入集群内部流量 hostPort、hostNletwork、nodeport/service,、loadbalancer/service、 exteralP/service、 Ingres;Flannel简介Flannel是CoreOS团队针对Kubernetes设计的一个网络布局服务，简略来说，它的性能是让集群中的不同节点主机创立的Docker容器都具备全集群惟一的虚构IP地址。在默认的Docker配置中，每个节点上的Docker服务会别离负责所在节点容器的IP调配。这样导致的一个问题是，不同节点上容器可能取得雷同的内外IP地址。并使这些容器之间可能之间通过IP地址互相找到，也就是互相ping通。Flannel的设计目标就是为集群中的所有节点从新布局IP地址的应用规定，从而使得不同节点上的容器可能取得“同属一个内网”且”不反复的”IP地址，并让属于不同节点上的容器可能间接通过内网IP通信。Flannel本质上是一种“笼罩网络(overlaynetwork)”，也就是将TCP数据包装在另一种网络包外面进行路由转发和通信，目前曾经反对udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发形式，默认的节点间数据通信形式是UDP转发。简略总结Flannel特点使集群中的不同Node主机创立的Docker容器都具备全集群惟一的虚构IP地址。建设一个笼罩网络（overlay network），通过这个笼罩网络，将数据包一成不变的传递到指标容器。笼罩网络是建设在另一个网络之上并由其基础设施反对的虚构网络。笼罩网络通过将一个分组封装在另一个分组内来将网络服务与底层基础设施拆散。在将封装的数据包转发到端点后，将其解封装。创立一个新的虚构网卡flannel0接管docker网桥的数据，通过保护路由表，对接管到的数据进行封包和转发（vxlan）。etcd保障了所有node上flanned所看到的配置是统一的。同时每个node上的flanned监听etcd上的数据变动，实时感知集群中node的变动。Flannel反对三种Pod网络模型，每个模型在flannel中称为一种"backend": vxlan: Pod与Pod经由隧道封装后通信，各节点彼此间能通信就行，不要求在同一个二层网络; 毛病:因为通过2次封装,吞吐量绝对变低,长处:不要求节点处于同一个2层网络vwlan directrouting:位于同一个二层网络上的、但不同节点上的Pod间通信，毋庸隧道封装;但非同一个二层网络上的节点上的Pod间通信，仍须隧道封装; 最优的计划host-gw: Pod与Pod不经隧道封装而间接通信，要求各节点位于同一个二层网络; #吞吐量最大 但须要在同个2层网络中Flannel 下载安装地址 https://github.com/flannel-io...示例1: 部署flannel 以Vxlan类型运行#查看flannel部署清单yaml文件中有对于网络类型的形容[root@k8s-master plugin]# cat kube-flannel.ymlkind: ConfigMapapiVersion: v1metadata: name: kube-flannel-cfg namespace: kube-system labels: tier: node app: flanneldata: cni-conf.json: | { "name": "cbr0", "cniVersion": "0.3.1", "plugins": [ { "type": "flannel", #实现虚构网络 "delegate": { "hairpinMode": true, "isDefaultGateway": true } }, { "type": "portmap", #端口映射 如:NodePort "capabilities": { "portMappings": true } } ] } net-conf.json: | { "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan" #默认为vxlan模式 } }[root@k8s-master plugin]# kubectl apply -f kube-flannel.ymlvxlan模式下 路由表Pod地址指向flannel.1[root@k8s-master plugin]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.54.2 0.0.0.0 UG 101 0 0 eth410.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0 #本机虚构网络接口10.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 flannel.110.244.2.0 10.244.2.0 255.255.255.0 UG 0 0 0 flannel.110.244.3.0 10.244.3.0 255.255.255.0 UG 0 0 0 flannel.1172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0192.168.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0192.168.54.0 0.0.0.0 255.255.255.0 U 101 0 0 eth4[root@k8s-node1 ~]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.54.2 0.0.0.0 UG 101 0 0 eth410.244.0.0 10.244.0.0 255.255.255.0 UG 0 0 0 flannel.110.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0 #本机虚构网络接口10.244.2.0 10.244.2.0 255.255.255.0 UG 0 0 0 flannel.110.244.3.0 10.244.3.0 255.255.255.0 UG 0 0 0 flannel.1172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0192.168.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0192.168.54.0 0.0.0.0 255.255.255.0 U 101 0 0 eth4[root@k8s-master plugin]# ip neighbour|grep flannel.1 #生成的永恒neighbour信息 进步路由效率10.244.1.0 dev flannel.1 lladdr ba:98:1c:fa:3a:51 PERMANENT10.244.3.0 dev flannel.1 lladdr da:29:42:38:29:55 PERMANENT10.244.2.0 dev flannel.1 lladdr fa:48:c1:29:0b:dd PERMANENT[root@k8s-master plugin]# bridge fdb show flannel.1|grep flannel.1ba:98:1c:fa:3a:51 dev flannel.1 dst 192.168.54.171 self permanent22:85:29:77:e1:00 dev flannel.1 dst 192.168.54.173 self permanentfa:48:c1:29:0b:dd dev flannel.1 dst 192.168.54.172 self permanentda:29:42:38:29:55 dev flannel.1 dst 192.168.54.173 self permanent#抓包flannel网络 其中 udp 8472为flannel网络默认端口[root@k8s-node3 ~]# tcpdump -i eth4 -nn udp port 8472tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes17:08:15.113389 IP 192.168.54.172.46879 > 192.168.54.173.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.2.9 > 10.244.3.92: ICMP echo request, id 2816, seq 61, length 6417:08:15.113498 IP 192.168.54.173.55553 > 192.168.54.172.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.3.92 > 10.244.2.9: ICMP echo reply, id 2816, seq 61, length 6417:08:16.114359 IP 192.168.54.172.46879 > 192.168.54.173.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.2.9 > 10.244.3.92: ICMP echo request, id 2816, seq 62, length 6417:08:16.114447 IP 192.168.54.173.55553 > 192.168.54.172.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.3.92 > 10.244.2.9: ICMP echo reply, id 2816, seq 62, length 6417:08:17.115558 IP 192.168.54.172.46879 > 192.168.54.173.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.2.9 > 10.244.3.92: ICMP echo request, id 2816, seq 63, length 6417:08:17.115717 IP 192.168.54.173.55553 > 192.168.54.172.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.3.92 > 10.244.2.9: ICMP echo reply, id 2816, seq 63, length 6417:08:18.117498 IP 192.168.54.172.46879 > 192.168.54.173.8472: OTV, flags [I] (0x08), overlay 0, instance 1IP 10.244.2.9 > 10.244.3.92: ICMP echo request, id 2816, seq 64, length 64能够看到10.244.2.9 > 10.244.3.92 Pod间的传输 通过封装从节点192.168.54.172.46879 传输到节点 192.168.54.173.8472 通过一层数据封装示例2: 增加flannel网络类型DirectRouting增加DirectRouting后,2层网络节点会应用宿主机网络接口间接通信,3层网络的节点会应用Vxlan 隧道封装后通信,组合应用是flannel最现实的网络类型因为测试环境所有节点都处于同一2层网络,所以从路由表无奈看到和flannel.1接口同时存在[root@k8s-master ~]# kubectl get cm -n kube-systemNAME DATA AGEcoredns 1 57dextension-apiserver-authentication 6 57dkube-flannel-cfg 2 57dkube-proxy 2 57dkubeadm-config 2 57dkubelet-config-1.19 1 57d[root@k8s-master ~]# kubectl edit cm kube-flannel-cfg -n kube-system net-conf.json: | { "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan", "DirectRouting": true #增加 } }重启Pod 正式环境用蓝绿更新[root@k8s-master ~]# kubectl get pod -n kube-system --show-labelsNAME READY STATUS RESTARTS AGE LABELScoredns-f9fd979d6-l9zck 1/1 Running 16 57d k8s-app=kube-dns,pod-template-hash=f9fd979d6coredns-f9fd979d6-s8fp5 1/1 Running 15 57d k8s-app=kube-dns,pod-template-hash=f9fd979d6etcd-k8s-master 1/1 Running 12 57d component=etcd,tier=control-planekube-apiserver-k8s-master 1/1 Running 16 57d component=kube-apiserver,tier=control-planekube-controller-manager-k8s-master 1/1 Running 40 57d component=kube-controller-manager,tier=control-planekube-flannel-ds-6sppx 1/1 Running 1 7d23h app=flannel,controller-revision-hash=585c88d56b,pod-template-generation=2,tier=nodekube-flannel-ds-j5g9s 1/1 Running 3 7d23h app=flannel,controller-revision-hash=585c88d56b,pod-template-generation=2,tier=nodekube-flannel-ds-nfz77 1/1 Running 1 7d23h app=flannel,controller-revision-hash=585c88d56b,pod-template-generation=2,tier=nodekube-flannel-ds-sqhq2 1/1 Running 1 7d23h app=flannel,controller-revision-hash=585c88d56b,pod-template-generation=2,tier=nodekube-proxy-42vln 1/1 Running 4 25d controller-revision-hash=565786c69c,k8s-app=kube-proxy,pod-template-generation=1kube-proxy-98gfb 1/1 Running 3 21d controller-revision-hash=565786c69c,k8s-app=kube-proxy,pod-template-generation=1kube-proxy-nlnnw 1/1 Running 4 17d controller-revision-hash=565786c69c,k8s-app=kube-proxy,pod-template-generation=1kube-proxy-qbsw2 1/1 Running 4 25d controller-revision-hash=565786c69c,k8s-app=kube-proxy,pod-template-generation=1kube-scheduler-k8s-master 1/1 Running 38 57d component=kube-scheduler,tier=control-planemetrics-server-6849f98b-fsvf8 1/1 Running 15 8d k8s-app=metrics-server,pod-template-hash=6849f98b[root@k8s-master ~]# kubectl delete pod -n kube-system -l app=flannelpod "kube-flannel-ds-6sppx" deletedpod "kube-flannel-ds-j5g9s" deletedpod "kube-flannel-ds-nfz77" deletedpod "kube-flannel-ds-sqhq2" deleted[root@k8s-master ~]# 再次查看master、node路由表[root@k8s-master ~]# route -n Kernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.54.2 0.0.0.0 UG 101 0 0 eth410.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni010.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 eth410.244.2.0 192.168.54.172 255.255.255.0 UG 0 0 0 eth410.244.3.0 192.168.54.173 255.255.255.0 UG 0 0 0 eth4172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0192.168.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0192.168.54.0 0.0.0.0 255.255.255.0 U 101 0 0 eth4[root@k8s-node1 ~]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.54.2 0.0.0.0 UG 101 0 0 eth410.244.0.0 192.168.54.170 255.255.255.0 UG 0 0 0 eth410.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni010.244.2.0 192.168.54.172 255.255.255.0 UG 0 0 0 eth410.244.3.0 192.168.54.173 255.255.255.0 UG 0 0 0 eth4172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0192.168.4.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0192.168.54.0 0.0.0.0 255.255.255.0 U 101 0 0 eth4#网络相干的Pod的IP会间接通过宿主机网络接口地址[root@k8s-master ~]# kubectl get pod -n kube-system -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEScoredns-f9fd979d6-l9zck 1/1 Running 16 57d 10.244.0.42 k8s-master <none> <none>coredns-f9fd979d6-s8fp5 1/1 Running 15 57d 10.244.0.41 k8s-master <none> <none>etcd-k8s-master 1/1 Running 12 57d 192.168.4.170 k8s-master <none> <none>kube-apiserver-k8s-master 1/1 Running 16 57d 192.168.4.170 k8s-master <none> <none>kube-controller-manager-k8s-master 1/1 Running 40 57d 192.168.4.170 k8s-master <none> <none>kube-flannel-ds-d79nx 1/1 Running 0 2m12s 192.168.4.170 k8s-master <none> <none>kube-flannel-ds-m48m7 1/1 Running 0 2m14s 192.168.4.172 k8s-node2 <none> <none>kube-flannel-ds-pxmnf 1/1 Running 0 2m14s 192.168.4.171 k8s-node1 <none> <none>kube-flannel-ds-vm9kt 1/1 Running 0 2m19s 192.168.4.173 k8s-node3 <none> <none>kube-proxy-42vln 1/1 Running 4 25d 192.168.4.172 k8s-node2 <none> <none> #应用宿主机网络接口kube-proxy-98gfb 1/1 Running 3 21d 192.168.4.173 k8s-node3 <none> <none>kube-proxy-nlnnw 1/1 Running 4 17d 192.168.4.171 k8s-node1 <none> <none>kube-proxy-qbsw2 1/1 Running 4 25d 192.168.4.170 k8s-master <none> <none>kube-scheduler-k8s-master 1/1 Running 38 57d 192.168.4.170 k8s-master <none> <none>metrics-server-6849f98b-fsvf8 1/1 Running 15 8d 10.244.2.250 k8s-node2 <none> <none>抓包查看数据封装[root@k8s-master plugin]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESclient-1639 1/1 Running 0 52s 10.244.1.222 k8s-node1 <none> <none>replicaset-demo-v1.1-lgf6b 1/1 Running 0 59m 10.244.1.221 k8s-node1 <none> <none>replicaset-demo-v1.1-mvvfq 1/1 Running 0 59m 10.244.3.169 k8s-node3 <none> <none>replicaset-demo-v1.1-tn49t 1/1 Running 0 59m 10.244.2.136 k8s-node2 <none> <none>root@k8s-master plugin]# kubectl exec replicaset-demo-v1.1-tn49t -it -- /bin/sh #拜访node3[root@replicaset-demo-v1 /]# curl 10.244.3.169iKubernetes demoapp v1.1 !! ClientIP: 10.244.2.136, ServerName: replicaset-demo-v1.1-mvvfq, ServerIP: 10.244.3.169![root@replicaset-demo-v1 /]# curl 10.244.3.169#node3上抓包[root@k8s-node3 ~]# tcpdump -i eth4 -nn tcp port 80tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes11:03:57.508877 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [S], seq 1760692242, win 64860, options [mss 1410,sackOK,TS val 4266124446 ecr 0,nop,wscale 7], length 011:03:57.509245 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [S.], seq 3150629627, ack 1760692243, win 64308, options [mss 1410,sackOK,TS val 1453973317 ecr 4266124446,nop,wscale 7], length 011:03:57.510198 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [.], ack 1, win 507, options [nop,nop,TS val 4266124447 ecr 1453973317], length 011:03:57.510373 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [P.], seq 1:77, ack 1, win 507, options [nop,nop,TS val 4266124447 ecr 1453973317], length 76: HTTP: GET / HTTP/1.111:03:57.510427 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [.], ack 77, win 502, options [nop,nop,TS val 1453973318 ecr 4266124447], length 011:03:57.713241 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [P.], seq 1:18, ack 77, win 502, options [nop,nop,TS val 1453973521 ecr 4266124447], length 17: HTTP: HTTP/1.0 200 OK11:03:57.713821 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [.], ack 18, win 507, options [nop,nop,TS val 4266124651 ecr 1453973521], length 011:03:57.733459 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [P.], seq 18:155, ack 77, win 502, options [nop,nop,TS val 1453973541 ecr 4266124651], length 137: HTTP11:03:57.733720 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [FP.], seq 155:271, ack 77, win 502, options [nop,nop,TS val 1453973541 ecr 4266124651], length 116: HTTP11:03:57.735862 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [.], ack 155, win 506, options [nop,nop,TS val 4266124671 ecr 1453973541], length 011:03:57.735883 IP 10.244.2.136.49656 > 10.244.3.169.80: Flags [F.], seq 77, ack 272, win 506, options [nop,nop,TS val 4266124672 ecr 1453973541], length 011:03:57.736063 IP 10.244.3.169.80 > 10.244.2.136.49656: Flags [.], ack 78, win 502, options [nop,nop,TS val 1453973543 ecr 4266124672], length 011:03:58.650891 IP 10.244.2.136.49662 > 10.244.3.169.80: Flags [S], seq 3494935965, win 64860, options [mss 1410,sackOK,TS val 4266125588 ecr 0,nop,wscale 7], length 0能够看到数据的传输没有再通过封装 间接通过Pod IP flannel网络传输示例3: 批改flannel网络类型host-gw 须要留神host-gw只反对2层网络因为所有节点都处在2层网络中,实践上和后面增加DirectRouting 成果是一样的 就不累述 ...

上云的企业越来越多，与之绝对的，「云原生」这个词也一直呈现在大家眼帘中，成为几年来 IT 行业最热门的概念之一。 依据云原生计算基金会（CNCF）对云原生给出的定义： “云原生技术有利于各组织在私有云、公有云和混合云等新型动静换环境中，构建和运行可扩大的利用。云原生的代表技术包含容器、服务网络，微服务，不可变的基础设施和申明式 API 。” 云计算带来了业务模式与基础设施之间的关系改革，而云原生也正扭转着应用程序和基础设施之间的关系。云原生的呈现，能够帮忙企业解决传统利用降级迟缓、架构臃肿、无奈疾速迭代、无奈疾速定位故障等问题。 随着业务复杂度减少，应用程序变得越来越简单，不再具备敏捷性，开发人员也很难开发和保护代码。解决这个问题的最好方法之一是将整个利用的性能从新定义宰割为更小的微服务，并对每个微服务独立开发保护。与微服务相干的一个重要概念是容器，借此可将应用程序中的各个组件拆分并打包成独立服务，让每个组件都能够容易地替换、降级和调试。 由此可见：微服务和容器化是相辅相成的。然而单机运行容器无奈将容器的最大性能施展进去，只有造成集群，能力最大水平施展容器劣势。但如何编排治理这些容器则成了新的，迫切需要解决的问题。 Kubernetes 的呈现很好地解决这个辣手问题，为企业应用上云铺平了路线。Kubernetes 是一个开源容器治理平台，具备灵便的架构能力，让企业不仅能轻松对基础设施资源进行对立治理，还能不便地对立治理下层业务，实现业务架构的对立。 现在， Kubernetes 已成云原生中流砥柱。将来，企业内现存的各类根底软件平台都将对立到基于 Kubernetes 的云原生平台上。由此可见，熟练掌握 Kubernetes 对企业标准化 IT 对立治理平台具备不可或缺的意义。 在这一系列《云原生利用之旅—— Kubernetes 成长记》文章中，咱们将通过 10 期内容，帮忙大家在 2 个月左右的工夫里实现 Kubernetes 的从入门到精通。你将理解到 Kubernetes 基础知识，并有机会实际不同组件和解决方案，进而积攒贵重教训。 铺垫实现，咱们的成长之旅就此开始！ Day 1：初识Kubernetes基本概念与任何一项新技术相似，刚开始接触 Kubernetes 时，免不了会遇到很多新的专有词汇。所谓万丈高楼平地起，任何简单的零碎都起始于最根本的实践， Kubernetes 也是如此。只有能先把握这些基本概念，打好根底，无疑就能沿着正确方向疾速入门。 那么对于Kubernetes老手来说， 容器组（Pods）正本集（ReplicaSet）秘密（Secrets）部署（Deployments）……这些概念别离都是什么意思？对云原生程序的开发、部署和运行都起到了什么作用？ 让咱们用「二次元」的模式来了解吧。追随长颈鹿菲比阿姨（Phippy）和她的斑马侄子小季（Zee）一起，逛逛 Kubernetes 动物园，探寻各个组件的机密。 点击这里，开启旅程 在把握了基本概念后，咱们将通过后续文章别离向大家介绍 Kubernetes 技术细节、Azure Kubernetes 服务、微服务架构、分布式系统等重要概念、办法和实际，欢送继续关注，独特学习并驾驭 Kubernetes 技术，在云时代玩转云原生利用。 此外，对于本文介绍的 Kubernetes 重要概念和组件，以及后续的内容安顿，大家是否有什么想法或倡议？也欢送通过评论留言发表你的想法，咱们会筛选精彩留言并送上精美小礼品一份。欢送大家踊跃参加，也欢送将本文分享给更多有志于 Kubernetes 开发的小伙伴，大家独特学习，共同进步！

endpoints是一种kubernetes资源类型，它是namespace scoped，简写为ep: kubectl api-resources|grep endpointsendpoints ep true Endpointsendpoints有两种应用办法： 随service被创立： 创立service对象的同时，kubernetes会创立同名的endpoints的对象；service的podSelector会将指标pod的endpoint信息(ip/port)，增加到endpoints对象中；独立创立endpoints： enpdoints作为一种资源类型，反对用户创立；将内部服务的endpoint增加到endpoints对象，能够应用kubernetes service拜访内部服务；service与endpoints以一个简略的例子，来演示endpoints随service被主动创立进去。创立nginx deploy，含2个pod: apiVersion: apps/v1kind: Deploymentmetadata: labels: app: nginx name: nginxspec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest imagePullPolicy: IfNotPresent command: - nginx - -g - "daemon off;" workingDir: /usr/share/nginx/html ports: - name: http containerPort: 80 protocol: TCP创立nginx service: apiVersion: v1kind: Servicemetadata: name: nginx-svcspec: ports: - port: 80 targetPort: 80 selector: app: nginx查看其service和endpoints资源：有一个同名的endpoints被创立进去 ...

【本文内容基于9月份Cloud Ace CTO 江文远分享的线上研讨会内容总结而成。】 摘要Kubernetes，简称K8s，是Google开发的，目前最为风行的容器编排和治理引擎，它反对自动化部署、大规模可伸缩、利用容器化治理。K8s的个性使得它实用于架构简单且要求高的服务，也就是游戏架构的搭建。 因为Cloud Ace为谷歌云代理公司，所以咱们本次分享的实操是在谷歌开发的Google Kubernetes Engines上运行的，GKE是谷歌基于K8s所开发的Kubernetes治理平台，次要在谷歌云平台上运行。 Kubernetes与微服务架构随着利用的倒退，程序变得越来越简单，传统一体化架构的服务会造成微小的不便，比如说：新增性能与测试放在一起，使得程序十分复杂；开发和利用新语言和新框架的效率低；安全性低，所有的模块构建在一个process里，一旦呈现bug可能牵一发而动全身。 而微服务 (microservices) 架构正好解决了这样的问题，将每一个具备商业逻辑的服务独立进去，例如不再将所有材料都写入同一个资料库，而是每个独自的服务都有一个最适宜本人自身构造的资料库。益处是让每个服务都能够用最适宜本人的语言、资料库来开发。在实操时，每一个商业性能/服务都可能是一台 VM 或者一个容器。 微服务架构的呈现给了游戏一个新的抉择，下图的两个架构就是游戏应用的架构，都是通过不同的功能模块来划分的，按功能模块划分不同的服务，前端通过HAProxy来代理用户申请，后端服务能够依据负载来实现扩缩容。在服务发现模块中，通过registrator来监督容器的启动和进行，依据容器裸露的端口和环境变量主动注册服务，后端存储应用了consul，联合consul-template来发现服务的变动时，能够更新业务配置，并重载。 K8s就是微服务架构 后面提到K8s适宜微服务架构，为什么呢？ 因为k8s的架构与微服务十分相似，在某些性能上是统一的，第一就是k8s的master和node，能够实现不同性能不同服务器之间的隔离；第二是k8s下面提供了API server，基本上能够等同于网关；第三是k8s的服务编排性能好，能够实现弹性伸缩；第四点是k8s的configmap基本上能够作为配置核心；第五是k8s能够通过在node上部署agent来实现日志的收集和监控。 Kubernetes 将数个容器组合起来成一个服务(Service，注：Service 是 K8S 的专有名词，上面会介绍)，Kubernetes 也提供了良好的服务发现(Service discovery)机制，让每个服务彼此能够通信。最重要的是 K8S 弱小的编程能够主动扩大服务，甚至还能够对大规模的容器作滚动更新 (Rolling update) 以及回滚机制 (Rolling back/Undo)，更能够整合 CI/CD 等 DevOps 的工具。 K8s在游戏架构搭建上的劣势基于前两者，咱们总结进去K8s在游戏架构搭建上的劣势为： 定制的网络与调度计划，为游戏容器的运行提供根底环境；域名服务与负载平衡，解决游戏高可用、弹性伸缩问题；通过性能数据、日志的收集、统计分析，及时发现程序问题与性能瓶颈，保障游戏容器稳固、可持续性运行；基于image的公布扩容，使得游戏部署流程更加标准化以及高效。Google Kubernetes Engine(GKE）游戏架构搭建实操咱们的实操参考的是谷歌的技术文档来搭建的。 游戏：Open Arena（雷神之锤）---开源游戏 游戏架构如下图，明天咱们只讲对于dedicated game server这一部分。 游戏环境设定如下： 为什么这么设置呢？ 第一是处于占用资源上思考，如果是地图比拟大的游戏，关上地图就会须要比拟长的工夫去载入，同样的，你工夫越长须要载入的材料越多，占用越多的资源，因而大部分游戏都会定义工夫限度，因为一旦有玩家在玩，主机就无奈敞开，造成大量的资源节约。 第二点是出于老本管制上设置的，因为线上游戏须要弹性，高峰期和非高峰期的人数差别较大，因而须要尽可能的match更多的玩家进来，把玩家集中在一个服务器上玩，这样对vm的需要会比拟少，有利于老本管制。 第三点是思考到游戏技术上的难度，如果说玩家呈现问题掉线了，那么就间接重开游戏，不要复原它的状态，因为复原状态对技术要求十分高。 GKE搭建后盾示例如下： 首先咱们先从右上角开始，右上角就是一个根本的游戏的组成，DGS也就是delicate game server ，它是一个open source的套件，能够在GKE上运行。 这里波及到两个VM，第一个VM用来搭建image，第二个VM用于加载数据/资料片，也就是Asset Disk，咱们把Asset Disk挂起来后，VM2咱们就间接删掉，VM2是不会留下来的，咱们只有留下Disk就能够，之后一旦GKE的class开起来，也就是把gke-dgs image部署进去，部署进去之后，这边就他会去把资料片挂起来。 在K8s上的话，有个点须要留神，如果pod想用到disk外面的材料，那么disk须要做成PV，也就是群集中的资源。PVC是对这些资源的申请，只有用户申请后发送了PVC能力拜访存储的资料片。 一轮游戏一个回合，可能容许的玩家是有肯定限度的，如果说node上有两个pod，两个pod可能容许20集体玩，那么当玩家数量超过了20集体的时候，就须要零碎及时监控到这个状况，开新的pod，这里就波及到了scaling manager。 ...

整体流程APIServer接管到删除Pod的申请后： 首先，批改etcd中的状态；而后，把删除pod的事件，告诉给kubelet和endpoint-controller； kubelet: 负责pod资源的删除；endpoint-controller: 负责endpoint资源的删除；两个组件并行执行； Kubelet解决pod敞开kubelet敞开pod的时候，会敞开pod中的每一个容器；kubelet给容器肯定的工夫(TerminationGracePeriod)优雅的进行。 kubelet终止容器的过程： 执行preStop，期待它执行结束；向容器的过程发送SIGTERM；期待容器优雅的敞开或超时(terminationGracePeriod)；若敞开超时，则发送SIGKILL强制敞开； endpoint-controller解决pod敞开endpoint-controller接管到pod删除的告诉时，向APIServer发送申请，批改svc的endpoints对象，从pod所在svc中删除该pod的endpoint。 而后，APIServer告诉节点上的kube-proxy组件，kube-proxy会批改本机的iptables/ipvs规定，将该endpoint移除。 Kubelet和endpoint-controller并行执行的问题kube-proxy可能因为过载解决申请变慢，会呈现： kubelet曾经把容器删除，但kube-proxy还未更新iptables。这种状况下，流量还会被散发到对应的endpoint，然而pod已删除，客户端返回"连贯回绝"之类的谬误。 目前的解决办法，在pod的preStop中sleep一段时间，期待kube-proxy更新iptables结束： lifecycle: preStop: exec: command: [ "sh", "-c", "sleep 10" ]参考kubernetes in action

微软对于Kubernetes服务有哪些最新进展？咱们直入主题！ Azure Kubernetes Service (AKS) 自定义策略反对 - 现已公开预览通过全新性能，您能够创立自定义策略定义和束缚模板，并将其调配给启用了以下新性能的 AKS 集群： 嵌入式反对和新的模板信息属性谬误状态报告和合规性起因代码Azure policy VS code扩大加强对公有AKS集群的公共 DNS 反对 – 现已根本可用AKS公有集群当初反对公共 DNS 作为名称解析选项。 这个性能通过创立一个与Kubernetes API服务器的公有IP相关联的公共 DNS 记录简化了AKS集群的名称解析，该公有IP放弃非公共路由。当初，您能够应用公有DNS区域、自定义公有DNS区域，或公共FQDN创立公有AKS集群。 Azure Red Hat OpenShift 反对OpenShift 4.8 – 现已根本可用OpenShift Container Platform 基于 Red HatEnterprise Linux (RHEL) 和 Kubernetes，为企业级应用程序提供了一个更平安和可扩大的多租户操作系统。此版本应用 Kubernetes 1.21 和 CRI-O 运行时。 具体更新信息，请点击下方链接或浏览原文 https://techcommunity.microso...这里有更多微软官网学习材料和技术文档，扫码获取免费版！内容将会不定期更新哦！

整体流程client向APIServer发送创立pod的申请： APIServer将pod信息存入etcd，告诉Scheduler；Scheduler依据调度算法，为pod抉择一个节点，而后向APIServer发送更新spec.nodeName；APIServer更新结束，告诉对应节点的kubelet；kubelet发现pod调度到本节点，创立并运行pod的容器； APIServer解决pod启动APIServer收到创立pod的申请后： 首先，对client起源进行认证，实现形式是证书(cert)或token(sa)；而后，对client进行鉴权，确认其是否有创立pod的权限，实现办法是rbac；而后，通过准入管制插件验证或批改资源申请，罕用的准入管制插件有：LimitRanger/ResourceQuota/NamespaceLifecycle；最初，将pod资源存储到etcd； Scheduler解决pod启动Scheduler监听到APIServer创立pod的事件后： 依照默认的调度算法(预选算法+优选算法)，为pod抉择一个可运行的节点nodeName；向APIServer发送更新pod的音讯：pod.spec.nodeName；APIServer更新pod，告诉nodeName上的kubelet，pod被调度到了nodeName；Kubelet解决pod启动kubelet监听到APIServer创立pod的事件后，告诉容器运行时dockerd拉取镜像，创立容器，启动容器。 pod中容器的启动过程： InitC容器： 多个initC程序启动，前一个启动胜利后才启动下一个；仅当最初一个initC执行结束后，才会启动主容器；罕用于进行初始化操作或期待依赖的服务已ok；postStart钩子： postStart与container的主过程并行执行；在postStart执行结束前，容器始终是waiting状态，pod始终是pending状态；若postStart运行失败，容器会被杀死；startupProbe钩子： v1.16版本后新增的探测形式；若配置了startupProbe，就会先禁止其余探测，直到胜利为止；readinessProbe探针： 探测容器状态是否ready，筹备好接管用户流量；探测胜利后，将pod的endpoint增加到service；livenessProbe探针： 探测容器的衰弱状态，若探测失败，则依照重启策略进行重启；containers: 多个container之间是程序启动的，参考源码；参考kubernetes in actioncontainer启动源码：https://github.com/kubernetes...

作者：张强 爱可生研发核心成员，后端研发工程师，目前负责DMP产品 Redis 相干业务开发。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一. 什么是 Kubernetes ?Kubernetes，又称为 k8s（首字母为 k、首字母与尾字母之间有 8 个字符、尾字母为 s，所以简称 k8s ）或者简称为「kube」，是一个可移植的、可扩大的开源平台，用于治理容器化的工作负载和服务。相比与传统部署以及虚拟化部署形式而言，具备如下特点： 麻利应用程序的创立和部署：与应用 VM 镜像相比，进步了容器镜像创立的简便性和效率。继续开发、集成和部署：通过疾速简略的回滚（因为镜像不可变性），反对牢靠且频繁的 容器镜像构建和部署。关注开发与运维的拆散：在构建/公布时而不是在部署时创立应用程序容器镜像， 从而将应用程序与基础架构拆散。可察看性：不仅能够显示操作系统级别的信息和指标，还能够显示应用程序的运行状况和其余指标信号。跨开发、测试和生产的环境一致性：在便携式计算机上与在云中雷同地运行。跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其余任何中央运行。以应用程序为核心的治理：进步形象级别，从在虚构硬件上运行 OS 到应用逻辑资源在 OS 上运行应用程序。涣散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立局部， 并且能够动静部署和治理 - 而不是在一台大型单机上整体运行。资源隔离：可预测的应用程序性能。资源利用：高效率和高密度。1. Docker 的衰亡要说 Kubernetes，还要从 docker 容器化技术谈起。 2013年，Docker 公司（彼时还称之为 dotCloud Inc.）在 PyCon 大会上首次公开介绍了 Docker 这一产品。过后最热门的 PaaS 我的项目是 Cloud Foundary，然而 Docker 我的项目在 docker 镜像上的优良设计，解决了过后其余 PaaS 技术未能解决的利用打包和利用公布的繁琐步骤问题。大多数 docker 镜像是间接由一个残缺操作系统的所有文件和目录形成的，所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是齐全一样的 —— 正是这一优良的个性使得 docker 我的项目在泛滥 Pass 技术迅速崛起。 2. Docker 编排的进化Swarm 的最大特点，是齐全应用 Docker 我的项目本来的容器治理 API 来实现集群治理。在部署了 Swarm 的多机环境下，用户只须要应用原先的 Docker 指令创立一个容器，这个申请就会被 Swarm 拦挡下来解决，而后通过具体的调度算法找到一个适合的 Docker Daemon 运行起来。 ...

NFS因为本身的问题，不罕用于生产环境，这里仅作为demo展现动静存储的应用。生产环境能够应用ceph，rook-ceph来治理ceph存储。 假如已部署好NFS Server，这里演示如何在集群中部署动静存储与创立storageclass/pvc/pv。 1.创立独立的namespace# kubectl create ns storage2.创立rbac给serviceAccount赋权创立一个serviceAccount: apiVersion: v1kind: ServiceAccountmetadata: name: nfs-client-provisioner namespace: storage为serviceAccount赋权： kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: name: nfs-client-provisioner-runnerrules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] - apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["events"] verbs: ["list", "watch", "create", "update", "patch"] - apiGroups: [""] resources: ["endpoints"] verbs: ["get", "list", "watch", "create", "update", "patch"]kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: run-nfs-client-provisionersubjects: - kind: ServiceAccount name: nfs-client-provisioner namespace: storageroleRef: kind: ClusterRole name: nfs-client-provisioner-runner apiGroup: rbac.authorization.k8s.io3.部署Provisionerprivisioner能够了解为底层存储的驱动，由privisioner治理底层存储。privisioner以deploy形式部署了1个pod，pod内container指定了nfs的环境信息(包含name/ip/path等)，serviceAccountName=上一步创立的serviceAccount名称； ...

requests和limitspod能够配置每个container的requests以标识资源申请额，配置limits以限度资源应用下限。 kubernetes依据requests，调度pod运行在哪个节点上。 kubernetes依据limits，限度pod能够应用cpu/memory资源: 当容器应用的cpu达到limits时，过程不会调配到更多的cpu；当容器应用的memory达到limits时，容器会被OOMKilled，尝试重启；apiVersion: v1Kind: Podmetadata: name: pod1spec: containers: - image: nginx name: main resources: requests: cpu: 200m memory: 10Mi limits: cpu: 500m memory: 100Mi为什么须要pod Qos?requests与limits不同，单个节点上，所有limits的总和运行超过节点资源总量的100%，也就是说，limits能够超卖： 如果节点资源使用量超过100%，一些容器会被杀掉，比方podA应用了节点内存的90%，podB忽然须要节点20%的内存，导致节点无奈提供更多的内存，此时该杀掉哪个pod以满足podB的内存申请？ kubernetes通过pod的Qos级别，决定当资源有余时，优先杀掉哪些容器： BestEffort: 优先级最低(最先被Kill)Burstable:Guaranteed: 优先级最高(最初被Kill)当遇到内存不足，BestEffort的Pod有多个，如何确定该kill哪个： 依据过程的OOM分数来抉择，分数越高，优先被杀掉；OOM分数：(理论内存使用量 / request.memory )的值越大，OOM分数越高；如何确定pod Qos？办法一：kubectl describe pod查问# kubectl describe pod -n monitoring prometheus-k8s-0Name: prometheus-k8s-0Namespace: monitoring......QoS Class: Burstable......办法二：按上面的规定(举荐)BestEffort: 所有的容器都没有调配requests和limits；Guaranteed: 所有的容器都调配了requests和limits;Burstable: 其它不属于BestEffort和Guaranteed的pod;办法三：先判断container的Qos，再判断pod的qoscontainer的Qos判断办法： pod的Qos判断办法： 参考：kubernetes in action

大家好，我是来自阿里云的李煌东，明天由我为大家分享 Kubernetes 监控公开课的第二节内容：如何发现 Kubernetes 中服务和工作负载的异样。 本次分享由三个局部组成： 一、Kubernetes 异样定位存在痛点； 二、针对这些痛点，Kubernetes 监控如何更快、更准、更全的发现异常； 三、网络性能监控、中间件监控等典型案例解析。 Kubernetes 异样定位存在痛点当下的互联网架构中，越来越多的公司采纳微服务 + Kubernetes 这样的架构，这样的架构有如下特点： 首先应用层基于微服务，微服务由解耦开的几个服务互相调用形成，服务个别职责明显、边界明确，造成的后果是一个简略的产品也有几十、甚至上百个微服务，相互之间的依赖、调用是非常复杂的，这给定位问题带来比拟大的老本。同时，每个服务的 owner 可能来自不同团队，不同的开发，可能应用不同的语言，对咱们监控的影响是对每一种语言都须要进行监控工具的接入，投资回报率低。还有一个特点是多协定，简直每种中间件（Redis、MySQL、Kafka）都有他们独特的协定，怎么要做到疾速对这些协定进行观测，是不小的挑战。尽管 Kubernetes 和容器对下层利用屏蔽了底层的复杂度，然而带来的两个后果是：基础设施层越来越高；另一个是下层利用和基础设施之间信息变得越来越简单了。举个例子，用户反馈网站拜访很慢，管理员查看拜访日志、服务状态、资源水位发现都没问题，这时候不晓得问题呈现在哪里，尽管狐疑基础设施有问题，但无奈定界的状况下只能一个一个排查效率低，问题的本源就是下层利用和基础设施之间短少高低问题关联，无奈做到端到端串联。最初一个痛点是数据散、工具多、信息没买通。举个例子，假如咱们收到一个告警，用 grafana 去查看指标，指标只能形容的比拟粗略，咱们得去看下日志，这时候咱们要去 SLS 日志服务看下有没有对应的日志，日志也没问题，这时候咱们须要登录到机器下来看，然而登录到容器外面可能又因为重启导致日志没有了。查了一波之后，可能咱们会感觉可能问题不是呈现在这个利用，于是咱们又去看链路追踪是不是上游有问题。总而言之，工具用了一大堆，浏览器开了十几个窗口，效率低、体验差。这三个痛点别离演绎为老本、效率、体验三个方面。针对这些痛点，接下来咱们一起看下 Kubernetes 监控的数据体系，看下怎么来更好的解决老本、效率、体验三大问题。 Kubernetes 监控如何发现异常下图金子塔自顶向下示意信息的密度或者具体水平，越往下面信息越具体。咱们从底部开始讲，Trace 是咱们通过eBPF技术以无入侵、多协定、多语言的形式采集应用层协定数据，如 HTTP、MySQL、Redis，协定数据会进一步解析成容易了解的申请详情、响应详情、各个阶段的耗时信息。 再上一层是指标，指标次要由黄金指标、网络、Kubernetes 体系中的指标。其中黄金指标和网络指标是基于 eBPF 采集的，所以同样他们是没有入侵的，反对各种协定的，有了黄金指标，咱们就能晓得服务整体上是否有异样、是否有慢、是否影响用户；网络指标次要是对socket的反对，如丢包率、重传率、RTT 等，次要用来监控网络是否失常的指标。Kubernetes 体系中的指标是指原来 Kubernetes 监控体系中的 cAdvisor/MetricServer/Node Exporter/NPD 这些指标。 再上一层是事件，事件间接明确地通知咱们产生了什么，可能咱们遇到最多的是 Pod 重启、拉镜像失败等。咱们对 Kubernetes 事件进行了长久化存储，并保留一段时间，这样不便定位问题。而后，咱们的巡检和健康检查也是反对以事件的模式报进去。 最顶层是告警，告警是监控零碎的最初一环，当咱们发现某些特定异样可能对业务有损后，咱们就须要对指标、事件进行告警配置。告警目前反对 PromQL，智能告警反对对历史数据进行智能算法检测，从而发现潜在的异样事件。告警的配置反对动静阈值，通过调节灵敏度的形式来配置告警，从而防止写死阈值。 有了 Trace、指标、事件、告警之后，咱们用拓扑图将这些数据和 Kubernetes 实体都关联起来，每个节点对应 Kubernetes 实体中的服务和工作负载，服务之间调用用线示意。有了拓扑图，咱们就像拿到一张地图，能疾速辨认拓扑图中的异样，并对异样进行进一步的剖析，对上下游、依赖、影响面进行剖析，从而对系统有了更全面的掌控。 最佳实际&场景剖析接下来咱们讲下发现 Kubernetes 中服务和工作负载的异样的最佳实际。 首先还是先有指标，指标能反馈服务的监控状态，咱们应尽可能地收集各种指标，并且越全越好，不限于黄金指标、USE 指标、Kubernetes 原生指标等；而后，指标是宏观数据，须要做根因剖析咱们得有 Trace 数据，多语言、多协定的状况下要思考采集这些 Trace 的老本，同样尽可能地反对多一点协定、多一点语言；最初，用一张拓扑将指标、Trace、事件汇总起来、串联起来，造成一张拓扑图，用来做架构感知剖析、上下游剖析。 通过这三种办法的剖析，服务和工作负载的异样通常暴露无遗了，但咱们不应该就此进行后退的脚步，退出这个异样下次再来，那么咱们这些工作得重来一遍，最好的方法是针对这类异样配置对应的告警，自动化地治理起来。 咱们用几个具体的场景来具体介绍： ...

kubectlkubectl [command] [TYPE] [NAME] [flags]command creategetdeletedescribeTYPE (to specify resource types） kubectl get pod pod1kubectl get pods pod1kubectl get po pod1NAME (to specify resource name, if not specified, list all the resources)Generate a yamlkubectl create # Generate a yaml but not actually create the deploymentkubectl create deployment DeployTest --image=nginx -o yaml --dry-runkubectl create deployment DeployTest --image=nginx -o yaml --dry-run > m1.yamlkubectl getExport a yaml from a deployed application

K8s pod 节点调配：亲和性与反亲和性https://kubernetes.io/zh/docs... k8s StatefulSet稳固的长久化存储，即Pod从新调度后还是能拜访到雷同的长久化数据，基于PVC来实现。稳固的网络标识符，即Pod从新调度后其PodName和HostName不变。有序部署，有序扩大，基于init containers来实现。有序膨胀。

遇到的坑1. Timeout: Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0shttps://stackoverflow.com/que... 2. The connection to the server localhost:8080 was refused - did you specify the right host or port? mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config3. 单节点k8s创立利用pendingkubectl get events # 查看k8s事件日志解决：0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate. ...

argo装置kubectl create ns argokubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo-workflows/stable/manifests/quick-start-postgres.yamlkubectl create clusterrolebinding test-cluster-admin-binding --clusterrole=cluster-admin --user=test@test.comkubectl -n argo port-forward deployment/argo-server 2746:2746mkdir argo;cd argocurl -svLO https://github.com/argoproj/argo-workflows/releases/download/v3.1.1/argo-linux-amd64.gzgunzip argo-linux-amd64.gzchmod +x argo-linux-amd64mv ./argo-linux-amd64 /usr/local/bin/argoargo admin配置kubectl create role argo-admin --verb=list,update --resource=workflows.argoproj.io kubectl create sa argo-adminkubectl create rolebinding argo-admin --role=argo-admin --serviceaccount=argo:argo-admin## 获取secretSECRET=$(kubectl get sa argo-admin -o=jsonpath='{.secrets[0].name}')

1. Single-Container Management Patterns2. Single-Node, Multi-Container Application Patterns跨容器设计模式https://kubernetes.io/blog/20...* Pod: k8s中创立和治理的、最小可部署计算单元。共享网络、存储 * Container: 容器，资源核算和调配的单元 1) Sidecar PatternAn extra container in your pod to enhance or extend the functionality of the main container. 应用独立容器，不将性能构建在主容器中的劣势 辅助容器在主容器服务不忙碌时应用闲置资源独自开发测试辅助容器可作为组件反复利用容错边界，辅助容器出错不影响主容器服务失常运行独自公布回滚2）Ambassador PatternA container that proxy the network connection to the main container. 大使模式：通过大使容器帮忙利用容器拜访内部服务 3）Adapter PatternA container that transform output of the main container. 适配器模式：格式化解决主容器的输入 3. Multi-Node Application Patterns1) Leader Election Pattern2) Work Queue Pattern3) Scatter/Gatter PatternReferencehttps://kubernetes.io/zh/docs... https://segmentfault.com/a/11... ...

OSSOSS数据卷是应用OSSFS文件进行挂载的FUSE文件系统，适宜于读文件场景。例如：读配置文件、视频、图片文件等场景。OSSFS不擅长于写文件的利用场景。如果您的业务是将文件写入存储的场景，举荐应用NAS存储卷服务。NASNAS 存储卷：为多个pod同时提供服务，多个ecs实例可共享数据本地存储本地存储卷：主机节点文件系统，须要做 业务和指定node的匹配。同一个我的项目的不同调度工作须要在同一个node上执行。

在 Linux 上以 All-in-One 模式装置 KubeSphere Install KubeSphere in All-in-One mode on Linux 背景 KubeSphere 是在Kubernetes 之上构建的面向云原生利用的分布式操作系统，齐全开源，反对多云与多集群治理，提供全栈的IT 自动化运维能力，简化公司的DevOps 工作流。... 作为全栈的多租户容器平台，KubeSphere 提供了运维敌对的向导式操作界面，帮忙公司疾速构建一个弱小和功能丰富的容器云平台。 KubeSphere is a distributed operating system for cloud-native applications built on Kubernetes. It is fully open source, supports multi-cloud and multi-cluster management, provides full-stack IT automated operation and maintenance capabilities, and simplifies the company's DevOps workflow. ... As a full-stack multi-tenant container platform, KubeSphere provides an operation and maintenance-friendly guided operation interface to help the company quickly build a powerful and feature-rich container cloud platform. ...

Turn off firewall# temporarilysystemctl stop firewalld# permanentlysystemctl disable firewalldTurn off selinux# temporarilysed -i 's/enforcing/disabled/' /etc/selinux/config# permanentlysetenforce 0Turn off swap# temporarilyswapoff -a# permanentlyvim /etc/fstabConfigure hostnamesystemctl set-hostname [hostname]Synchronize time across cluster nodessystemctl start chronydsystemctl enable chronydoryum install ntpdate -yntpdate time.windows.comConfigure static IPvi /etc/sysconfig/network-scripts/ifcfg-ens32 BOOTPROTO="static"IPADDR=192.168.8.20PREFIX0=24GATEWAY=192.168.8.2DNS1=114.114.114.114DNS2=8.8.8.8Add information of hosts on the master node cat >> /etc/hosts << EOF192.168.8.20 master01192.168.8.21 worker01192.168.8.22 worker02

背景：是这样的一个事件：服务运行于kubernetes集群（腾讯云tke1.20.6）。日志采集到了elasticsearch集群and腾讯的cls日志服务中。小伙伴看日志感觉还是不太不便，还是想看控制台输入的。给他们调配过一台服务器（退出到集群中，然而有污点标签的节点）。为了不便他们测试一下货色。当初想让他们通过此work节点能够在控制台查看日志。失常的就是把master节点的/root/.kube/目录下的config配置文件copy过去就能够了。然而这权限也太大了！从新温习一遍kubeconfig配置文件以及 role rolebinding的常识！注： namespace为official。想调配的权限是list and log，嗯查看pod列表和查看日志 不能删除批改namespace下pod。并且不能查看其余namespace。 Kubernetes之kuberconfig1. 创立用户凭证前提： openssl的装置就疏忽了...... 1. 创立用户证书私钥用户就用我本人名字了，私钥命名为zhangpeng.key openssl genrsa -out zhangpeng.key 20482. 创立证书签名申请文件应用咱们刚刚创立的私钥创立一个证书签名申请文件：zhangpeng.csr，要留神须要确保在-subj参数中指定用户名和组(CN示意用户名，O示意组) openssl req -new -key zhangpeng.key -out zhangpeng.csr -subj "/CN=zhangpeng/O=layabox"可能你会呈现上面的报错：注：图非下面执行命令的截图，其余环境下操作呈现的解决形式如下： cd /rootopenssl rand -writerand .rnd而后从新执行命名 openssl req -new -key zhangpeng.key -out zhangpeng.csr -subj "/CN=zhangpeng/O=layabox"3. 生成最终证书文件找到Kubernetes集群的CA，如果你是应用的是kubeadm装置的集群，CA相干证书位于/etc/kubernetes/pki/目录上面，如果你是二进制形式搭建的，你应该在最开始搭建集群的时候就曾经指定好了CA的目录，咱们会利用该目录上面的ca.crt和ca.key两个文件来批准下面的证书申请。当然了我应用的是腾讯云的tke集群。证书是位于/etc/kubernetes目录下的 server.crt和server.key。这里就用这两个文件生成证书文件，命令如下： root@ap-shanghai-k8s-master-1:~/ap-shanghai# openssl x509 -req -in zhangpeng.csr -CA /etc/kubernetes/ca.crt -CAkey /etc/kubernetes/ca.key -CAcreateserial -out zhangpeng.crt -days 3650Signature oksubject=CN = zhangpeng, O = layaboxGetting CA Private Key查看咱们以后文件夹上面是否生成了一个证书文件 4. 在kubernetes集群中创立凭证和上下文（context）创立新的用户凭证 ...

文章链接 下载deployment我这里保留成kube-event.yaml # cat kube-event.yaml---apiVersion: apps/v1kind: Deploymentmetadata: labels: name: kube-eventer name: kube-eventer namespace: kube-systemspec: replicas: 1 selector: matchLabels: app: kube-eventer template: metadata: labels: app: kube-eventer annotations: scheduler.alpha.kubernetes.io/critical-pod: '' spec: dnsPolicy: ClusterFirstWithHostNet serviceAccount: kube-eventer containers: - image: registry.aliyuncs.com/acs/kube-eventer-amd64:v1.2.0-484d9cd-aliyun name: kube-eventer command: - "/kube-eventer" - "--source=kubernetes:https://kubernetes.default" ## .e.g,dingtalk sink demo #- --sink=dingtalk:[your_webhook_url]&label=[your_cluster_id]&level=[Normal or Warning(default)] - --sink=dingtalk:https://oapi.dingtalk.com/robot/send?access_token=355cf0156xxxxxxxxxxxxxxxxxx&level=Warning env: # If TZ is assigned, set the TZ value as the time zone - name: TZ value: "Asia/Shanghai" volumeMounts: - name: localtime mountPath: /etc/localtime readOnly: true - name: zoneinfo mountPath: /usr/share/zoneinfo readOnly: true resources: requests: cpu: 100m memory: 100Mi limits: cpu: 500m memory: 250Mi volumes: - name: localtime hostPath: path: /etc/localtime - name: zoneinfo hostPath: path: /usr/share/zoneinfo---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: kube-eventerrules: - apiGroups: - "" resources: - configmaps - events verbs: - get - list - watch---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kube-eventerroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: kube-eventersubjects: - kind: ServiceAccount name: kube-eventer namespace: kube-system---apiVersion: v1kind: ServiceAccountmetadata: name: kube-eventer namespace: kube-system钉钉群里创立自定义webhook设置--智能群助手--增加机器人--抉择WeebHook。定义机器人名称和平安设置 ...

简介： OpenKruise 在 2021.9.6 公布了最新的 v0.10.0 版本新增了弹性拓扑治理和利用平安防护等能力，本文将为大家揭晓 OpenKruise 是如何实现利用的可用性防护能力。 前言OpenKruise 是阿里云开源的云原生利用自动化治理套件，也是以后托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 我的项目。它来自阿里巴巴多年来容器化、云原生的技术积淀，是阿里外部生产环境大规模利用的基于 Kubernetes 之上的规范扩大组件，也是紧贴上游社区规范、适应互联网规模化场景的技术理念与最佳实际。 OpenKruise 在 2021.9.6 公布了最新的 v0.10.0 版本新增了弹性拓扑治理和利用平安防护等能力，本文将为大家揭晓 OpenKruise 是如何实现利用的可用性防护能力。 背景在文章开始局部，我想先聊聊到底什么是“利用的可用性防护”。例如，在 Kubernetes 下面部署的 ETCD 服务，时刻要保障可用的实例数不小于 N（受限于 raft 协定的选举机制）。很多同学都会想到 Deployment 中能够设置 maxUnavailable，那不就行了吗？再说了，还会有 RS Controller 在做正本管制呢？认真想想，Deployment 的 MaxUnavailable 是在利用滚动公布的过程中保障最小的 Pod 数量，而 RS Controller 控制器则是尽快让利用理论的福本数等于预期的正本数，并不能保障利用每时每刻的最小可用正本数。 针对上述场景，Kubernetes 原生提供的 PodDisruptionBudget（PDB）通过限度同时中断 Pod 的数量，来保障利用的高可用性。然而，以后 PDB 的能力并不全面，它只能防护 Pod Eviction 场景（例如：kubectl drain node 驱赶 node 下面的 Pod）。在如下“并发 Pod 更新/驱赶/删除”场景中，即使有 PDB 防护仍然将会导致业务中断、服务降级： ...

文｜金敏（蚂蚁团体技术专家)\邱见（Red Hat) 校对｜ 冯泳（蚂蚁团体资深技术专家) 本文 3311 字 浏览 6 分钟 从最后 Kubernetes 技术问世，业界一遍一遍的质疑它是否能经得住生产级的考验，到明天许多大型企业曾经采纳 Kubernetes 技术“云化”之前大规模的基础设施，在企业外部创立了数十个甚至数百个集群。 Kubernetes 原生的治理能力目前依然停留在单集群级别。每一个集群能够稳固地自治运行，然而却不足横贯多个集群的兼顾治理能力。基础设施的建设者须要协调扩散在各处的治理组件，造成一个对立的治理平台。 通过它，运维管理人员可能获知多集群水位的变动，节点衰弱状态的震荡等信息；业务利用负责人可能决策如何调配应用服务在各个集群中的部署散布；利用的运维人员可能获知服务状态，下发腾挪的策略。 与多集群相干的翻新正在不断涌现。例如 ClusterAPI 和 Submariner 就是解决特定多集群治理问题比拟胜利的我的项目。 而本文要探讨的是那些试图解决企业在面对多集群治理时遇到的所有问题的技术摸索。 在过来五年中，中国的技术公司蚂蚁团体在多集群治理的思考、应用和施行等方面学习到了很多贵重的教训。 蚂蚁团体治理着遍布寰球的数十个 Kubernetes 集群，每个集群均匀领有数千个节点（服务器）。他们将应用程序及其所需组件（包含中间件，数据库，负载平衡等等）在架构层面组织成逻辑数据中心（LDC）的弹性逻辑单元中，并将它们布局部署到物理基础设施上。这种架构设计帮忙他们实现基础设施运维的两个要害指标：高可用性和事务性。 首先，部署在某个 LDC 上的业务利用的可用性在所属 LDC 内可能失去保障。其次，部署在 LDC 内的利用组件能够被验证，并在故障产生时，能够被回滚。蚂蚁团体 PaaS 团队的资深技术专家冯泳示意： “蚂蚁团体领有数十个 Kubernetes 集群、数十万个节点和数千个要害利用的基础设施。在这样的云原生基础设施中，每天都会有数以万计的 Pod 被创立和删除。构建一个高度可用、可扩大且平安的平台来治理这些集群和应用程序是一项挑战。”PART. 1 始于 KubeFed在 Kubernetes 我的项目生态中，多集群性能次要由与之同名的 SIG-Multicluster 团队解决。这个团队在 2017 年开发了一个集群联邦技术叫做 KubeFed。 联邦最后被认为是 Kubernetes 的一个内置个性，但很快就遇到了实现以及用户诉求决裂的问题，Federation v1 能够将服务散发到多个 Kubernetes 集群，但不能解决其余类型的对象，也不能真正的以任何形式“治理”集群。一些有相当业余需要的用户——尤其是几个学术实验室——仍在应用它，但该我的项目已被 Kubernetes 归档，从未成为外围性能。 而后，Federation v1 很快被一种名为“ KubeFed v2 ”的重构设计所取代，世界各地的经营人员都在应用该设计。它容许单个 Kubernetes 集群将多种对象部署到多个其余 Kubernetes 集群。KubeFed v2 还容许“管制立体”主集群治理其余集群，包含它们的大量资源和策略。这是蚂蚁团体多集群治理平台的第一代计划。 ...

办法1：kube-proxy1.集群内：启动proxy端口9999，拜访该端口将proxy到api-server # kubectl proxy --address='178.104.163.243' --accept-hosts='^*$' --port=99992.集群外： # curl http://178.104.163.243:9999/api/v1/nodes办法2: Token1.集群内：创立sa kubectl create serviceaccount sa-test2.集群内：rbac给sa赋权 将clusterrole：cluster-admin绑定给sa，该sa领有了管理员的权限： kubectl create clusterrolebinding sa-wanglipeng-cluster-admin --clusterrole='cluster-admin' --serviceaccount=default:sa-test3.集群内：取得token刚创立的sa带一个secret，secret中寄存了token： TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='sa-test')].data.token}"|base64 -d)4.集群外：应用token拜访API curl --header "Authorization: Bearer $TOKEN" --insecure -X GET https://178.104.163.38:6443/api/v1/namespaces/monitoring/pods?limit=1办法3: 证书要求应用apiserver的key文件和cert文件： curl -k --key /etc/kubernetes/pki/apiserver-kubelet-client.key --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt https://178.104.163.38:6443/api/v1/nodes参考1.Access Clusters Using the Kubernetes API

1. 装置要求在开始之前，部署Kubernetes集群机器须要满足以下几个条件： 虚构了3台机器，操作系统：Linux version 3.10.0-1127.el7.x86_64硬件配置：CPU(s)-2；3GB或更多RAM;硬盘20G左右；3台机器形成一个集群，机器之前网络互通；集群能够拜访外网，用于拉取镜像禁用swap分区2. 装置指标集群内所有机器装置Docker和Kubeadm部署Kubernetes Master节点部署容器网络插件部署Kubernetes Node节点，将节点退出Kubernetes集群中部署Dashboard Web页面，可视化查看Kubernetes资源3. 环境筹备master节点 ： 192.168.11.99node1节点 ：192.168.11.100node2节点 ：192.168.11.101## 1. 敞开防火墙$ systemctl stop firewalld### 防火墙敞开开启自启动$ systemctl disable firewalld## 2. 查看selinux状态$ sestatusSELinux status: disabled ### 2.1 永恒敞开selinux【重启失效】；$ vim /etc/sysconfig/selinux批改：SELINUX=disabled ### 2.2 长期敞开selinux$ setenforce 0## 3. 别离敞开swap$ free -g total used free shared buff/cache available Mem: 2 0 2 0 0 2 Swap: 1 0 1 ### 3.1 长期敞开$ swapoff -a ### 3.2 永恒敞开 【重启失效】；$ vi /etc/fstab 正文 swap## 4.别离设置设置主机名：$ hostnamectl set-hostname <hostname>#master节点:hostnamectl set-hostname k8s-master#node1节点：hostnamectl set-hostname k8s-node1#node2节点:hostnamectl set-hostname k8s-node2### 4.1 查看hostname[root@localhost vagrant]# hostname k8s-master ### 5.在master增加hosts【ip和name根据本人的虚机设置】：$ cat >> /etc/hosts << EOF192.168.11.99 k8s-master192.168.11.100 k8s-node1192.168.11.101 k8s-node2EOF## 6.配置master工夫同步：### 6.1装置chrony：$ yum install ntpdate -y$ ntpdate time.windows.com ### 6.2正文默认ntp服务器sed -i 's/^server/#&/' /etc/chrony.conf### 6.3指定上游公共 ntp 服务器，并容许其余节点同步工夫cat >> /etc/chrony.conf << EOFserver 0.asia.pool.ntp.org iburstserver 1.asia.pool.ntp.org iburstserver 2.asia.pool.ntp.org iburstserver 3.asia.pool.ntp.org iburstallow allEOF### 6.4重启chronyd服务并设为开机启动：systemctl enable chronyd && systemctl restart chronyd### 6.5开启网络工夫同步性能timedatectl set-ntp true## 7.配置node节点工夫同步### 7.1装置chrony：yum install -y chrony### 7.2正文默认服务器sed -i 's/^server/#&/' /etc/chrony.conf### 7.3指定内网 master节点为上游NTP服务器echo server 192.168.11.99 iburst >> /etc/chrony.conf### 7.4重启服务并设为开机启动：systemctl enable chronyd && systemctl restart chronyd### 7.5 查看配置--胜利同步master节点工夫[root@k8s-node2 vagrant]# chronyc sources 210 Number of sources = 1 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* k8s-master 3 6 36 170 +15us[ +85us] +/- 4405us ## 8.将桥接的IPv4流量传递到iptables（所有节点）$ cat > /etc/sysctl.d/k8s.conf << EOFnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1EOF$ sysctl --system # 失效## 9.加载ipvs相干模块注解：ipvs是虚构IP模块--ClusterIP：vip（虚构IP提供集群IP）因为ipvs曾经退出到了内核的骨干，所以为kube-proxy开启ipvs的前提须要加载以下的内核模块：在所有的Kubernetes节点执行以下脚本:### 9.1 配置cat > /etc/sysconfig/modules/ipvs.modules <<EOF#!/bin/bashmodprobe -- ip_vsmodprobe -- ip_vs_rrmodprobe -- ip_vs_wrrmodprobe -- ip_vs_shmodprobe -- nf_conntrack_ipv4EOF### 9.2执行脚本$ chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4下面脚本创立了/etc/sysconfig/modules/ipvs.modules文件，保障在节点重启后能主动加载所需模块。 应用lsmod | grep -e ip_vs -e nf_conntrack_ipv4命令查看是否曾经正确加载所需的内核模块。接下来还须要确保各个节点上曾经装置了ipset软件包。 为了便于查看ipvs的代理规定，最好装置一下管理工具ipvsadm。### 9.3装置管理工具$ yum install ipset ipvsadm -y4. 所有节点装置Docker / kubeadm-疏导集群的工具 / kubelet-容器治理Kubernetes默认CRI（容器运行时）为Docker，因而先装置Docker。4.1 Docker装置Kubernetes默认的容器运行时依然是Docker，应用的是kubelet中内置dockershim CRI实现。须要留神的是，Kubernetes 1.13最低反对的Docker版本是1.11.1，最高反对是18.06，而Docker最新版本曾经是18.09了，故咱们装置时须要指定版本为18.06.1-ce。$ wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo$ yum -y install docker-ce-18.06.1.ce-3.el7$ systemctl enable docker && systemctl start docker$ docker --version Docker version 18.06.1-ce, build e68fc7a批改镜像源： ...

背景：代码仓库gitlab,jenkins登程代码更新打包部署到kubernetes集群。jenkins构建频繁呈现：error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504仍然还是这个问题。jenkins中拉取能够减少--depth=1搞定了。然而小伙伴想保留切换分支， git log的信息啊......还是要加下ssh 记录一下： kubernetes搭建gitlab开启ssh前提：kubernetes集群搭建与腾讯云cvm上 应用了clb负载平衡。gitlab搭建形式见：https://www.yuque.com/duiniwukenaihe/ehb02i/begqgh#eOdFL gitlab svc开启nodeport首先 gitlab 的svc开启了nodeport,如下 clb代理ssh对应nodeportclb tcp的形式代理了gitlab ssh服务的nodeport端口 要应用ssh 的形式的服务器生成秘钥：ssh keygen -t rsa 上传id_rsa.pub到gitlab服务器登陆gitlab后盾Profile Settings-->SSH Keys--->Add SSH Key,上传id_rsa.pub中秘钥。确定 git clone 试一下：git clone ssh://git@xxx.xxxx.com/xxxx/xxxxx.git还是下了良久，下载实现后瞄了一眼我的项目下的.git目录objects就有700多m，代码也就800m：分支数量太多了。团队怎么能力正确应用git才是最重要的了…。反正当初一起工作的小伙伴让我很难过…

kubernetes 装置 Prometheus + Grafana kubernetes install Prometheus + Grafana 官网 Official website https://prometheus.io/GitHub GitHub https://github.com/coreos/kube-prometheus组件阐明 Component description MetricServer：是kubernetes集群资源应用状况的聚合器，收集数据给kubernetes集群内应用，如 kubectl,hpa,scheduler等。 PrometheusOperator：是一个零碎监测和警报工具箱，用来存储监控数据。 NodeExporter：用于各node的要害度量指标状态数据。 KubeStateMetrics：收集kubernetes集群内资源对象数 据，制订告警规定。 Prometheus：采纳pull形式收集apiserver，scheduler，controller-manager，kubelet组件数 据，通过http协定传输。 Grafana：是可视化数据统计和监控平台。 MetricServer: It is an aggregator of the resource usage of the kubernetes cluster, collecting data for use in the kubernetes cluster, such as kubectl, hpa, scheduler, etc. PrometheusOperator: is a system monitoring and alerting toolbox used to store monitoring data. NodeExporter: Used for the key metric status data of each node. ...

前言Volume 提供了十分好的数据长久化计划，不过在可管理性上还有有余。拿后面示例能够看出，要应用Volume，Pod 必须当时晓得如下信息： 以后 Volume 来自来哪里及具体位置 Local、网络。存储卷的类型,并晓得每种类型卷的配置应用办法,通过 kubectl explain pods.spec.volumes 能够看到kubernetes反对卷的类型十分的多Pod通常是由利用的开发人员保护，而 Volume 则通常是由存储系统的管理员保护。开发人员要取得下面的信息：要么询问管理员 要么本人就是管理员。这样就带来一个治理上的问题：利用开发人员和系统管理员的职责耦合在一起了。如果零碎规模较小或者对于开发环境这样的状况还能够承受。但当集群规模变大，特地是对于生成环境，思考到效率和安全性，这就成了必须要解决的问题。 Kubernetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。PersistentVolume (PV) 是内部存储系统中的一块存储空间，由管理员创立和保护。与 Volume 一样，PV 具备持久性，生命周期独立于 Pod。 PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创立和保护。须要为 Pod 调配存储资源时，用户能够创立一个 PVC，指明存储资源的容量大小和拜访模式（比方只读）等信息，Kubernetes 会查找并提供满足条件的 PV。 有了 PersistentVolumeClaim，用户只须要通知 Kubernetes 须要什么样的存储资源，而不用关怀真正的空间从哪里调配，如何拜访等底层细节信息。这些 Storage Provider 的底层信息交给管理员来解决，只有管理员才应该关怀创立 PersistentVolume 的细节信息。 PVC和PV简介是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是Volume 之类的卷插件，但具备独立于应用 PV 的 Pod 的生命周期。此 API 对象蕴含存储实现的细节，即NFS、iSCSI 或特定于云供应商的存储系统PV、PVC:将存储生产，存储创立的职能拆散开来，PV: Persistent Volume，长久卷，可被PVC绑定;而PV肯定要与某个真正的存储空间(个别是网络存储服务上的存储空间)对应起来，能力真正存储数据。由集群管理员负责管理。集群级别资源;将真正的存储设备上的一段存储空间形象成的k8s的对象PVC: Persistent Volume Claim 长久卷申请，简称PVC;k8s上规范的资源类型之一;名称空间级别;由用户定义出存储生产需要，而后依据需要条件与现有各PV进行匹配检测，找出一个最佳的应用。Pod应用这类存储的步骤: Admin: 创立好PV;User: 按需创立PVC，而后创立Pod，在Pod调用persistentVolumeClaim 类型的存储卷插件调用同一个名称空间的PVC资源;PV字段介绍:除了存储卷插件之外，PersistentVolume资源标准Spec字段次要反对嵌套以下几个通用字段，它们用于定义PV的容量、拜访模式和回收策略等属性 capacity <map[string]string>: 指定PV的容量;目前 Capacity仅反对存储容量设定，未来还应该能够指定IOPS和吞吐量(throughput) 。accessModes <[]string>: 指定以后PV反对拜访模式;存储系统反对存取能力大体可分为ReadWriteOnce(单路读写)、ReadOnlyWlany(多路只读)和ReadwriteMany(多路读写)三种类型,某个特定的存储系统可能会反对其中的局部或全副的能力。persistentVolumeReclaimPolicy <string> ∶PV空间被开释时的解决机制;可用类型仅为Retain(默认)、Recycle(已废除)或Delete(k8s主动发明默认抉择)。目前，仅nfs和hostPath反对Recycle策略，也仅有局部存储系统反对Delete策略。volumenode <string>:该PV的卷模型，用于指定此存储卷被格式化为文件系统应用还是间接应用裸格局的块设施;默认值为Filesystem，仅块设施接口的存储系统反对该性能。storageClassName <string>:以后PV所属的StorageClass资源的名称，指定的存储类须要当时存在;默认为空值，即不属于任何存储类。mountOptions <string>:挂载选项组成的列表，例如ro、soft和hard等。nodeAffinity <Object>:节点亲和性，用于限度可能拜访该PV的节点，进而会影响到应用与该PV关联的PVC的Pod的调度后果。PVC字段介绍:定义PVC时，用户可通过拜访模式(accessModes)、数据期(dataSource)、存储资源空间需要和限度(resources)、存储类、标签选择器、卷模型和卷名称等匹配规范来筛选集群上的PV资源，其中，resources和accessModes是最重的筛选规范。PVC的Spec字段的可嵌套字段有如下几个。 ...

前言:Kubernetes 中的卷有明确的寿命一一与封装它的 Pod 雷同。所以卷的生命比 Pod 中的所有容器都长，当这个容器重启时数据依然得以保留。当然，当 Pod 不再存在时，卷也将不复存在 为了保证数据的持久性，必须保证数据在内部存储,在docker容器中为了实现数据的持久性存储，在宿主机和容器内做映射，能够保障在容器的生命周期完结，数据仍旧能够实现持久性存储。然而在k8s中，因为pod散布在各个不同的节点之上，并不能实现不同节点之间持久性数据的共享，并且，在节点故障时，可能会导致数据的永久性失落。为此，k8s就引入了内部存储卷的性能。 Kubernetes 反对以下类型的卷: awsElasticBlockStore、azureDisk、azureFile、cephfs、csi、downwardAPI、emptyDirfc、flocker、gcePersistentDisk、gitRepo、glusterfs、hostPath、iscsi、local、nfspersistentVolumeClaim、projected、portworxVolume、quobyte、rbd、scaleIO、secretstorageos、vsphereVolume按存储类型分类: 长期存储:emptyDir :Pod删除，数据也会被革除，这种存储成为emptyDir，用于数据的长期存储。Host级别: hostPath,Local :数据不能跨节点网络级别: NFS、GlusterFS、rbd(块设施)、cephFS (文件系统) 具备长久能力的存储;CSI: Container Storage InterfaceLonghorn（容器存储接口）云存储（EBS，Azure Disk）依据共享式存储设备属性不同又分为: 多路并行读写多路只读单路读写几种罕用的卷类型 emptyDir、hostPath、NFS简介emptyDir当 Pod 被调配给节点时，首先创立 emptyDir 卷，并且只有该 Pod 在该节点上运行，该卷就会存在。正如卷的名字所述，它最后是空的。Pod 中的容器能够读取和写入 emptyDir 卷中的雷同文件，只管该卷能够挂载到每个容器中的雷同或不同门路上。当出于任何起因从节点中删除 Pod 时， emptyDir 中的数据将被永恒删除 emptyDir 的用法有：暂存空间，例如用于基于磁盘的合并排序用作长时间计算解体复原时的检查点Web服务器容器提供数据时，保留内容管理器容器提取的文件查看默认反对volumes 存储类型 [root@k8s-master ~]# kubectl explain pods.spec.volumes #查看默认反对volumes 存储类型KIND: PodVERSION: v1RESOURCE: volumes <[]Object>DESCRIPTION: List of volumes that can be mounted by containers belonging to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes Volume represents a named volume in a pod that may be accessed by any container in the pod.FIELDS: awsElasticBlockStore <Object> AWSElasticBlockStore represents an AWS Disk resource that is attached to a kubelet's host machine and then exposed to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore azureDisk <Object> AzureDisk represents an Azure Data Disk mount on the host and bind mount to the pod. azureFile <Object> AzureFile represents an Azure File Service mount on the host and bind mount to the pod. cephfs <Object> CephFS represents a Ceph FS mount on the host that shares a pod's lifetime...示例1：emptyDir Pod上间接挂载长期存储卷[root@k8s-master storage]# cat volumes-emptydir-demo.yaml apiVersion: v1kind: Podmetadata: name: volumes-emptydir-demo namespace: defaultspec: initContainers: - name: config-file-downloader image: ikubernetes/admin-box imagePullPolicy: IfNotPresent command: ["/bin/sh","-c","wget -O /data/envoy.yaml http://192.168.4.254/envoy.yaml"] #初始化容器 下载配置文件 volumeMounts: - name: config-file-store mountPath: /data #挂载目录 containers: - name: envoy image: envoyproxy/envoy-alpine:v1.13.1 command: ['/bin/sh','-c'] args: ['envoy -c /etc/envoy/envoy.yaml'] volumeMounts: - name: config-file-store mountPath: /etc/envoy #挂载目录 readOnly: true volumes: - name: config-file-store #被调用时的卷名称 emptyDir: #卷插件类型 临时文件 medium: Memory #应用内存 sizeLimit: 16Mi[root@k8s-master storage]# kubectl apply -f volumes-emptydir-demo.yaml pod/volumes-emptydir-demo created[root@k8s-master storage]# kubectl get podNAME READY STATUS RESTARTS AGEcentos-deployment-66d8cd5f8b-fkhft 1/1 Running 0 2mvolumes-emptydir-demo 1/1 Running 0 4s[root@k8s-master storage]# kubectl exec volumes-emptydir-demo volumes-emptydir-demo -it -- /bin/sh/ # cat /etc/envoy/envoy.yaml #查看挂载文件admin: access_log_path: /tmp/admin_access.log address: socket_address: { address: 127.0.0.1, port_value: 9999 }# 定义动态资源static_resources:...... clusters: - name: some_service connect_timeout: 0.25s type: STATIC lb_policy: ROUND_ROBIN # 配置后端挂载的IP地址 hosts: [{ socket_address: { address: 127.0.0.1, port_value: 8080 }}] / # netstat -tnlActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:9999 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTENhostPathhostPath 卷将主机节点的文件系统中的文件或目录挂载到集群中hostPath 的用处如下： ...

两种非凡类型的svcHeadless ServiceHeadless Service有时不须要或不想要负载平衡，以及独自的 Service IP 。遇到这种状况，能够通过指定 Cluster IP(spec.clusterIP) 的值为 “None” 来创立 Headless Service 。这类 Service 并不会调配 Cluster IP， kube-proxy 不会解决它们，而且平台也不会为它们进行负载平衡和路由每个个体都具备肯定水平的独特性，由其存储的状态决定;Headless Services是一种非凡的service，其spec:clusterIP示意为None，这样在理论运行时就不会被调配ClusterIP。也被称为无头服务。headless Service和一般Service的区别headless不调配clusterIPheadless service能够通过解析service的DNS，返回所有Pod的地址和DNS(statefulSet部署的Pod才有DNS) 一般的service，只能通过解析service的DNS返回service的ClusterIPstatefulSet和Deployment控制器的区别statefulSet下的Pod有DNS地址,通过解析Pod的DNS能够返回Pod的IPdeployment下的Pod没有DNS一般Service解析service的DNS后果headless Service 就是没头的Service,有什么应用场景呢?第一种: 自主选择权,有时候client想本人决定应用哪个Real Server,能够通过查问DNS来获取Real Server的信息第二种: headless service关联的每个endpoint(也就是Pod),都会有对应的DNS域名;这样Pod之间就能够相互拜访headless service个别和statefulSet联合应用为什么要用headless service+statefulSet部署有状态利用?headless service会为关联的Pod调配一个域<service name>.$<namespace name>.svc.cluster.localStatefulSet会为关联的Pod放弃一个不变的Pod Namestatefulset中Pod的hostname格局为$(StatefulSet name)-$(pod序号)StatefulSet会为关联的Pod调配一个dnsName$<Pod Name>.$<service name>.$<namespace name>.svc.cluster.local示例1.Headless Service无头服务解析[root@k8s-master svc]# cat demoapp-headless-svc.yamlapiVersion: v1kind: Servicemetadata: name: demoapp-headless-svcspec: clusterIP: None #必须为None selector: app: demoapp ports: - port: 80 targetPort: 80 name: http [root@k8s-master centos]# kubectl exec centos-deployment-66d8cd5f8b-nrfnv -it -- /bin/bashroot@centos-deployment-66d8cd5f8b-nrfnv /]# nslookup -query=A demoapp-headless-svc #解析到是后端pod IPServer: 10.96.0.10Address: 10.96.0.10#53Name: demoapp-headless-svc.default.svc.cluster.localAddress: 10.244.1.103Name: demoapp-headless-svc.default.svc.cluster.localAddress: 10.244.2.99Name: demoapp-headless-svc.default.svc.cluster.localAddress: 10.244.2.97Name: demoapp-headless-svc.default.svc.cluster.localAddress: 10.244.1.102[root@centos-deployment-66d8cd5f8b-nrfnv /]# nslookup -query=PTR 10.244.1.103 #对pod IP进行反解 失去所有绑定的SVCServer: 10.96.0.10Address: 10.96.0.10#53103.1.244.10.in-addr.arpa name = 10-244-1-103.demoapp-svc.default.svc.cluster.local.103.1.244.10.in-addr.arpa name = 10-244-1-103.demoapp-nodeport-svc.default.svc.cluster.local.103.1.244.10.in-addr.arpa name = 10-244-1-103.demoapp-loadbalancer-svc.default.svc.cluster.local.103.1.244.10.in-addr.arpa name = 10-244-1-103.demoapp-externalip-svc.default.svc.cluster.local.103.1.244.10.in-addr.arpa name = 10-244-1-103.demoapp-headless-svc.default.svc.cluster.local.[root@centos-deployment-66d8cd5f8b-nrfnv /]# curl 10.244.1.103iKubernetes demoapp v1.0 !! ClientIP: 10.244.1.104, ServerName: demoapp-66db74fcfc-2jf49, ServerIP: 10.244.1.103![root@centos-deployment-66d8cd5f8b-nrfnv /]# [root@centos-deployment-66d8cd5f8b-nrfnv /]# [root@centos-deployment-66d8cd5f8b-nrfnv /]# curl demoapp-headless-svc #须要留神的是Headless Service只有集群外部能拜访，宿主机上因为无奈解析到SVC IP是拜访的iKubernetes demoapp v1.0 !! ClientIP: 10.244.1.104, ServerName: demoapp-66db74fcfc-5dp5n, ServerIP: 10.244.1.102![root@centos-deployment-66d8cd5f8b-nrfnv /]# curl demoapp-headless-svciKubernetes demoapp v1.0 !! ClientIP: 10.244.1.104, ServerName: demoapp-66db74fcfc-z682r, ServerIP: 10.244.2.99![root@centos-deployment-66d8cd5f8b-nrfnv /]# curl demoapp-headless-svciKubernetes demoapp v1.0 !! ClientIP: 10.244.1.104, ServerName: demoapp-66db74fcfc-9wkgj, ServerIP: 10.244.2.97![root@centos-deployment-66d8cd5f8b-nrfnv /]# exit[root@k8s-master svc]# curl demoapp-headless-svc #无法访问curl: (6) Could not resolve host: demoapp-headless-svc; Unknown errorService类型中的第四种:ExternalNameexternalName Service是k8s中一个非凡的service类型，它不须要指定selector去抉择哪些pods实例提供服务，而是应用DNS CNAME机制把本人CNAME到你指定的另外一个域名上，你能够提供集群内的名字，比方mysql.db.svc这样的建设在db命名空间内的mysql服务，也能够指定http://mysql.example.com这样的内部实在域名。 ...

背景：早些时候kubernetes集群的cri还应用docker的时候经验过这样的情况： 集群运行很久后硬盘跑的快满了......,大文件次要集中在：/var/lib/docker/overlay2 下文件有快70G，/var/log/journal/日志也有4-5G。过后的操作是手工的在work节点进行了一下的操作： journalctl --vacuum-size=20M #设置journal 日志最大为20M不保留不必要日志。docker image prune -a --filter "until=24h" # 革除超过创立工夫超过24小时的镜像docker container prune --filter "until=24h" #革除掉所有停掉的容器，但24内创立的除外docker volume prune --filter "label!=keep" #除lable=keep外的volume外都清理掉(没有援用的volume)docker system prune #清理everything：images ，containers，networks一次性清理操作能够通过docker system prune来搞定注： 以上摘自集体博客2019年的一篇：https://duiniwukenaihe.github.io/2019/11/25/k8s-question2/。当然了相似的还有inotify watch 耗尽 cgroup 泄露。可参照：https://www.bookstack.cn/read/kubernetes-practice-guide/troubleshooting-problems-errors-no-space-left-on-device.md那么问题来了：我当初的集群是kubernetes1.21集群。cri是containerd 我改如何清理除了系统日志外的 对于cri的资源呢？失常的来说kubelet是有此性能的？反正我tke集群的work节点最近频繁收到了磁盘大于百分之九十的报警了......，强迫症犯了！ 对于Kubernetes image垃圾镜像容器的回收对于kubelet:节点治理节点通过设置kubelet的启动参数“--register-node”，来决定是否向API Server注册本人，默认为true.[kubelet --help] Pod治理kubelet通过API Server Client应用Watch/List的形式监听etcd中/registry/nodes/${以后节点名称}和/registry/pods的 目录，将获取的信息同步到本地缓存中。kubelet监听etcd，执行对Pod的操作，对容器的操作则是通过Docker Client 执行，常见的操作蕴含：增，删，该，查。 容器健康检查探针是kubelet对容器执行定期的诊断，次要通过调用容器配置的三类Handler实现，如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略的影响。 资源监控kubelet通过cAdvisor获取本节点信息及容器的数据。cAdvisor为谷歌开源的容器资源剖析工具，默认集成到 kubernetes中。 kubelet-garbage-collection注：以下内容来自：https://kubernetes.io/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/嗯多看下文档...... 垃圾回收是 kubelet 的一个有用性能，它将清理未应用的镜像和容器。Kubelet 将每分钟对容器执行一次垃圾回收， 每五分钟对镜像执行一次垃圾回收。 不倡议应用内部垃圾收集工具，因为这些工具可能会删除本来冀望存在的容器进而毁坏 kubelet 的行为。 镜像回收Kubernetes 借助于 cadvisor 通过 imageManager 来治理所有镜像的生命周期。 镜像垃圾回收策略只思考两个因素：HighThresholdPercent 和 LowThresholdPercent。 磁盘使用率超过下限 阈值（HighThresholdPercent）将触发垃圾回收。 垃圾回收将删除最近起码应用的镜像，直到磁盘使用率满足下 限阈值（LowThresholdPercent）。 ...

Kubernetes 是用于主动部署，扩大和治理容器化应用程序的开源零碎。本文将介绍如何疾速开始 K8s 的应用。 理解 K8sKubernetes / Overview搭建 K8s本地开发测试，须要搭建一个 K8s 轻量服务。理论部署时，能够用云厂商的 K8s 服务。 本文以 k3d 为例，于 macOS 搭建 K8s 服务。于 Ubuntu 则举荐 MicroK8s。其余可代替计划有： Kubernetes / Install Tools kind, minikube, kubeadmDocker Desktop / Deploy on Kubernetesk3dk3s 是 Rancher 推出的 K8s 轻量版。而 k3d 即 k3s in docker，以 docker 容器治理 k3s 集群。 以下搭建过程，是于 macOS 的笔记，供参考。其余平台，请按照官网文档进行。 # 装置 kubectl: 命令行工具brew install kubectl# 装置 kubecm: 配置管理工具brew install kubecm# 装置 k3dbrew install k3d❯ k3d versionk3d version v4.4.8k3s version latest (default)创立集群（1主2从）： ...

背景：团队成员都是老旧派，没有承受过容器思维。然而利用部署都在kubernetes集群下面了，而后他们认为利用的ip是不可变的。嗯，而后我就顺便看了一眼让容器放弃ip不变的材料。早些时候报名了罗伟老师的k8s网络训练营。因为工夫问题直播仅看了几次。然而受益匪浅。正好明天看群里小伙伴聊天探讨到了pod调配动态ip的计划就参考了一下：阿里云的-Terway：https://help.aliyun.com/document_detail/97467.html腾讯云的-VPC-CNIhttps://cloud.tencent.com/document/product/457/50355注：这都是云商的托管kubernetes集群中现有的计划。明天看文章貌似看到了jd也有相似的计划......集体的线上是基于tke1.20.6的集群还有一个搭建在腾讯云的1.21.2的kubeadm的高可用集群。具体的就是all in 腾讯云。tke不想用腾讯云的VPC-CNI。怎么说呢，感觉有点浪费资源.......明天正好群里探讨看到了小伙伴分享的openkruise还有腾讯开源的蓝鲸的容器平台(蓝鲸比拟早的时候就玩过17年的时候比拟重我还是不必了...)发现了神奇的宝藏kruise？试用一下注： 貌似是阿里云开源的，感激阿里云的开源，还有群内大佬的分享！ OpenKruise 是什么参照：http://openkruise.io/zh-cn/docs/what_is_openkruise.htmlOpenKruise 是 Kubernetes 的一个规范扩大，它能够配合原生 Kubernetes 应用，并为治理利用容器、sidecar、镜像散发等方面提供更加弱小和高效的能力。 外围性能原地降级原地降级是一种能够防止删除、新建 Pod 的降级镜像能力。它比原生 Deployment/StatefulSet 的重建 Pod 降级更快、更高效，并且防止对 Pod 中其余不须要更新的容器造成烦扰。Sidecar 治理反对在一个独自的 CR 中定义 sidecar 容器，OpenKruise 可能帮你把这些 Sidecar 容器注入到所有符合条件的 Pod 中。这个过程和 Istio 的注入很类似，然而你能够治理任意你关怀的 Sidecar。跨多可用区部署定义一个跨多个可用区的全局 workload，容器，OpenKruise 会帮你在每个可用区创立一个对应的上司 workload。你能够对立治理他们的正本数、版本、甚至针对不同可用区采纳不同的公布策略。镜像预热反对用户指定在任意范畴的节点上下载镜像。容器重建/重启反对用户重建/重启存量 Pod 中一个或多个容器。... Controllers 与 WebhooksCloneSet提供更加高效、确定可控的利用治理和部署能力，反对优雅原地降级、指定删除、公布程序可配置、并行/灰度公布等丰盛的策略，能够满足更多样化的利用场景。Advanced StatefulSet基于原生 StatefulSet 之上的加强版本，默认行为与原生完全一致，在此之外提供了原地降级、并行公布（最大不可用）、公布暂停等性能。SidecarSet对 sidecar 容器做对立治理，在满足 selector 条件的 Pod 中注入指定的 sidecar 容器。UnitedDeployment通过多个 subset workload 将利用部署到多个可用区。BroadcastJob配置一个 job，在集群中所有满足条件的 Node 上都跑一个 Pod 工作。Advanced DaemonSet基于原生 DaemonSet 之上的加强版本，默认行为与原生统一，在此之外提供了灰度分批、按 Node label 抉择、暂停、热降级等公布策略。AdvancedCronJob一个扩大的 CronJob 控制器，目前 template 模板反对配置应用 Job 或 BroadcastJob。ImagePullJob反对用户指定在任意范畴的节点上下载镜像。ContainerRecreateRequest为用户提供了重建/重启存量 Pod 中一个或多个容器的能力。Deletion Protection该性能提供了删除安全策略，用来在 Kubernetes 级联删除的机制下爱护用户的资源和利用可用性。PodUnavailableBudget比照Kubernetes PDB只提供针对Pod Eviction的防护，PUB可能防护Pod Deletion、Eviction、Update多种voluntary disruption场景。WorkloadSpread束缚无状态 workload 的区域散布，赋予繁多 workload 的多区域和弹性部署的能力。装置 OpenKruise参照：http://openkruise.io/zh-cn/docs/installation.html ...

依据 CNCF 最新调查结果，企业在生产环境中应用 Kubernetes 的比例从 78% 进步到了 83%，Kubernetes 作为云原生的外围平台，吸引了越来越多的开发者去理解、学习和把握。 在此基础之上，随同着云原生对业务翻新的影响力继续浮现，企业将容器利用于生产环境成为大势所趋，数据长久化存储问题始终以来都是容器技术的一大挑战。 为了解决上述问题，疾速帮忙开发者攻克 Kubernetes 技术难题，咱们和 ACK CNFS 及 NAS 的开发团队一起筹备了一场“硬核”训练营，为大家带来干货满满的直播课程，不仅提供技术难点的深度解读、最佳实践经验和胜利案例分享，同时实战环节将带你“沉迷式”上手体验，更有多重惊喜好礼等你来拿！ 9月22日「Kubernetes 难点攻破系列：容器长久化存储训练营」行将正式开营！ 01 训练营简介Kubernetes 难点攻破系列——容器长久化存储训练营，由阿里云容器服务团队与开发者社区独特打造，旨在帮忙更多开发者应答学习和应用 Kubernetes 的挑战。 9 月 22 日-9 月 24 日，3 天工夫，集中冲破。本次训练营你将理解为什么容器须要长久化存储、Kubernetes 容器服务编排的基本概念、长久化存储的架构和实现形式，并通过实战让你把握容器长久化存储的最佳实际。 02 流动福利实现容器长久化存储训练营的全副工作，即可依照以下规定支付流动奖品： 理解训练营玩法 + 课程打卡 + 实现通用型 NAS 文件系统创立（9 月 24 日 10：00 开启，次日 15:00 后查看打卡后果）+ 实现样板间试验+ 实现线上考试认证依照打卡工作实现程序支付奖品，1-10 名将获取奖品小米耳机，同时支付容器产品优惠券 （ACK Pro、ACREE），11-20 名将获取奖品阿里云定制T恤，21-60 名将获取奖品 ACK 定制小风扇03 实战课程（9 月 22-24 日，每天 17:00—18:00 开课） DAY1：何种数据存储能力助力容器计算主讲嘉宾：阿里云容器产品专家，张楠（朝昔）内容简介：本节课程将介绍容器计算中数据存储面临的挑战，分析以后存储状态在容器计算环境中应用的异同，以及阿里云在容器计算畛域对数据存储的洞察与翻新。 DAY2：容器网络文件系统 CNFS 在容器计算畛域的最佳实际主讲嘉宾：阿里云存储高级技术专家徐泰明、阿里云存储技术专家，孟威内容简介：介绍阿里云创新性的 CNFS 文件存储系统在各个场景的最佳实际和胜利案例。 DAY3：【实战体验】一步一步搭建容器弹性 Web 与内容管理系统主讲嘉宾：阿里云容器产品专家，阚俊宝内容简介：演示利用 ACK 和 CNFS 如何一步一步的疾速构建弹性 Web 与内容管理系统。同时，利用收费试验环境，您能够亲自体验平安易用、简略高效的阿里云 ACK 和 CNFS 文件系统 9 月 22 日-9 月 24 日，训练营课程会在钉钉群直播，老师将以实战与实践相结合的形式，带着你学习基础知识，并把握实战能力，同时也会在群内答疑。利用三天工夫，集中冲破！ 快扫描海报二维码或点击链接（https://developer.aliyun.com/learning/trainingcamp/kubernetes ）退出训练营开启 Kubernetes 难点攻破之旅吧！ ...

大家好，我是阿里云云原生利用平台的炎寻，很快乐能和大家一起在 Kubernetes 监控系列公开课上进行交换。本次公开课冀望可能给大家在 Kubernetes 容器化环境中疾速发现和定位问题带来新的解决思路。 为什么须要 Kubernetes 监控？很多同学对利用性能监控应该并不生疏，这类监控次要关注业务应用逻辑、利用框架和语言运行时，监控对象有线程池满，数据库连贯无奈获取，MySQL， 内存溢出，还有各种调用链异样栈等。随着 Kubernetes 容器化技术带来的云原生技术演进，下层利用的开发和运维变得更加简略，但复杂度是恒定的，下层的复杂度升高必然随同着底层的复杂度晋升。如下图所示，复杂度逐步转移到容器虚拟化层以及零碎调用内核层对各种虚拟化技术的反对。每一层都可能呈现问题，且这些问题会影响下层利用。比方容器虚拟化层的 Kubernetes 组件异样，如果调度器异样，Pod 将无奈调度影响利用；比方文件系统相干的零碎调用异样，下层利用无奈读取文件，造成利用问题；比方内核异样，利用过程无奈调度实现工作。利用想要衰弱稳固的运行，须要的是软件栈端到端的衰弱稳固，尽管当初很多运维团队都搭建了利用监控和系统监控体系，但没有一个监控可能自顶向下、端到端的串联起来各层软件的行为，导致辣手的问题产生时，无从下手解决。在应用层，一个网络申请超时，在客户端和服务端看起来仿佛都没有问题，但实际上是网络层包发送 RTT 过高，重传率过高，亦或是 DNS 解析慢，或者是 CNI 插件慢。如何在 Kubernetes 容器化环境下做到端到端的可观测性是Kubernetes 监控呈现的意义。Kubernetes 监控立足于利用监控之下的 Kubernetes 容器界面和底层操作系统。在容器虚拟化层，咱们通过以下五个数据源获取观测数据，通过 Kubernetes 管控组件 exporter 来获取 Kubernetes 管控组件的观测数据；通过 cAdvisor 获取容器的资源观测数据；通过 kube-state-metrics 获取 Kubernetes 资源的状态数据，还有事件和 Kubernetes 资源的状态以及条件数据。在零碎调用层，咱们通过 Kprobe/tracepoints 等 Linux tracing 技术获取观测数据；在内核层，咱们通过内核可观测模块获取观测数据，而后 Kubernetes 监控通过过程、容器、Kubernetes 资源和业务利用的关联关系向上关联买通利用性能监控，打造端到端的可观测性。所以 Kubernetes 监控是 Kubernetes 集群软件栈端到端可观测性的一体化解决方案，在 Kubernetes 监控中能够同时看到关联的所有层的观测数据。咱们心愿通过 Kubernetes 监控的一系列最佳实际，让大家可能应用 Kubernetes 监控解决 Kubernetes 环境下辣手的可观测问题。咱们也将从两个类型去解说，第一类是发现问题，次要蕴含五类问题的发现：利用架构问题、性能问题、资源问题、调度问题和网络问题。第二类是定位问题，次要蕴含对以上五类发现的问题进行根因定位，并且提供修复倡议。 摸索利用架构，发现预期外的流量Kubernetes 监控系列公开课第一节课的主题是“如何应用 Kubernetes 监控进行利用架构摸索，发现预期外的流量”，蕴含以下三点内容： 背景介绍：利用架构摸索的挑战；典型场景：在哪些场景下，咱们须要进行利用架构的摸索；最佳实际：介绍一种利用架构摸索的模式，高效的发现定位问题。一、利用架构摸索的挑战（1）混沌的微服务架构在 Kubernetes 容器化环境里，微服务架构是最广泛的架构模式。在这种架构下，随着业务倒退，肯定会有越来越多的微服务，他们之间的关系也会越来越简单。在复杂度一直增长的状况下，一些常见架构问题就变得艰难，比方利用以后运行架构是怎么的，利用上游依赖服务是否失常，利用上游客户端流量是否失常，利用 DNS 解析是否失常，两个利用之间的连通性是否有问题等。因而，咱们要进行利用架构摸索，往往变得十分困难。（2）多语言在微服务架构外面，各个微服务通常能够应用不同编程语言，只有暴露出规范的服务即可。那么不同语言如何进行监控，是否有雷同的埋点模式，是否对应语言有好用高效的埋点工具呢？代码侵入对性能有什么影响，是否埋点代码会影响业务运行呢？这是多语言场景下面临的观测难题。（3）多通信协议在微服务架构外面，各个微服务之间的通信能够应用不同通信协议，比方 HTTP、gRPC、Kafka、Dubbo 等，往往咱们须要辨认这些协定能力疾速发现对应依赖服务的问题，然而辨认协定意味着了解各个协定，在适合的中央须要进行埋点，不同通信协议如何对立埋点代码侵入，是否会影响业务性能，这是通信协议场景下面临的观测难题。 ...

Endpoint Controller简介后面有提到 治理后端端点与svc的绑定,依据标签选择器,筛选适配的pod,监控就绪的pod 并实现svc与pod的绑定理论利用中能够主动创立一个Endpoint Controller把内部的节点治理起来 相当于所内部的服务引入到外部 而后绑定到svc 集群外部就能够以拜访外部svc一样拜访到内部的服务资源标准apiVersion: v1kind: Endpointmetadata: # 对象元数据 name : namespace:subsets: #端点对象的列表- addresses: #处于“就绪”状态的端点地址对象列表 - hostname <string> #端点主机名 ip <string> #端点的IP地址，必选字段 hostname或IP给其中一个就行 nodeName <string> # 节点主机名 targetRef: #提供了该端点的对象援用 apiVersion <string> # 被援用对象所属的API群组及版本 kind <string> # 被援用对象的资源类型，多为Pod name <string> # 对象名称 namespace <string> # 对象所属的名称到底 fieldPath <string> #被援用的对象的字段，在未援用整个对象时应用，罕用于仅援用 # 指定Pod对象中的单容器，例如spec . containers[1] uid <string> #对象的标识符; notReadyAddresses: #处于“未就绪”状态的端点地址对象列表,格局与address雷同 ports: # 端口对象列表 - name <string> #端口名称; port <integer> # 端口号，必选字段; protocol <string> #协定类型，仅反对UDP、TCP和SCTP，默认为TCP; appProtocol <string> # 应用层协定;Endpoints详情[root@k8s-master svc]# kubectl get endpointsNAME ENDPOINTS AGEdemoapp-externalip-svc 10.244.1.102:80,10.244.1.103:80,10.244.2.97:80 + 1 more... 9m36sdemoapp-loadbalancer-svc 10.244.1.102:80,10.244.1.103:80,10.244.2.97:80 + 1 more... 3h15mdemoapp-nodeport-svc 10.244.1.102:80,10.244.1.103:80,10.244.2.97:80 + 1 more... 3h45mdemoapp-svc 10.244.1.102:80,10.244.1.103:80,10.244.2.97:80 + 1 more... 4h57m[root@k8s-master svc]# kubectl describe ep demoapp-svc Name: demoapp-svcNamespace: defaultLabels: <none>Annotations: endpoints.kubernetes.io/last-change-trigger-time: 2021-07-28T19:22:06ZSubsets: Addresses: 10.244.1.102,10.244.1.103,10.244.2.97,10.244.2.99 #绑定的后端Pod地址 NotReadyAddresses: <none> #所有归类到未就绪后端端点都不会承受流量 Ports: Name Port Protocol ---- ---- -------- http 80 TCP示例1: Endpoints引入内部服务1.通过Endpoints把192.168.4.100、192.168.4.254 http引入到k8s集权外部并绑定svc2.这里httpd服务为内部服务 无奈通过API service来检测就绪状态,须要手动配置 ...

Service简介Service:能够了解为pod的负债均衡器,规范资源类型,Service Controller 为动静的一组Pod提供一个固定的拜访入口， kubernetes实现SVC工作的是组件是kube-proxyEndpoint Controller:治理后端端点与svc的绑定,依据标签选择器,筛选适配的pod,监控就绪的pod 并实现svc与pod的绑定工作流程:Service Controller---->创立雷同标签选择器的 Endpoint Controller依据标签选择器去治理和监听后端Pod状态 实现Svc与Pod绑定Service可能提供负载平衡的能力，然而在应用上有以下限度:只提供4层负载平衡能力，而没有7层性能，但有时咱们可能须要更多的匹配规定来转发申请，这在4层负载平衡上是不反对的kube-proxy3种不同的数据调度模式1.UserspaceUserspace模型:Pod-->Service, iptables拦挡规定,但本人不做调度 工作流程: 用户空间-->ptables(内核)-->kube-proxy-->ptables(内核)-->再调度给用户空间 效率低iptables 用户空间-->ptables(内核 实现数据调度)-->调度给用户空间 效率高在iptables模型下kube-proxy的作用不在是数据调度转发,而是监听API server所有service中的定义转为本地的iptables规定毛病:iptables模式，一个service会生成大量的规定; 如果一个service有50条规定 那如果有一万个容器,内核的性能就会受到影响ipvs代理模式: 在继承iptables长处的状况下,同时改良了iptables产生大量规定的毛病,在大规模集群中serice多的状况下劣势更显著,Service的类型clusterIP:通过集群外部IP地址裸露服务，但该地址仅在集群外部可见、可达，它无奈被集群内部的客户端拜访;默认类型;倡议由K8S动静指定一个;也反对用户手动明确指定;NodePort: NodePort是ClusterIP的加强类型，它会于ClusterIP的性能之外，在每个节点上应用一个雷同的端口号将内部流量引入到该Service上来。LoadBalancer: 是NodePort的加强类型，为各节点上的NodePort提供一个内部负载均衡器;须要私有云反对ExternalName:内部流程引入到K8S外部,借助集群上KubeDNS来实现，服务的名称会被解析为一个CNAME记录，而CNAME名称会被DNS解析为集群内部的服务的TP地址,实现外部服务与内部服务的数据交互 ExternallP 能够与ClusterIP、NodePort一起应用 应用其中一个IP做进口IPServicePortService:被映射进Pod上的应用程序监听的端口; 而且如果后端Pod有多个端口，并且每个端口都想通过Service裸露的话，每个都要独自定义。 最终接管申请的是PodIP和ContainerPort; Service资源标准Service名称空间级别的资源不能跨名称空间 apiVersion: v1kind: Servicemetadata: name: .. namespace: ... labels: key1: value1 key2: value2spec: type <string> #Service类型，默认为ClusterIP selector <map[string]string> #等值类型的标签选择器，内含“与"逻辑 ports: # Service的端口对象列表 - name <string>#端口名称 protocol <string> #协定，目前仅反对TCP、UDP和SCTP，默认为TCP port <integer> # Service的端口号 targetPort <string> #后端指标过程的端口号或名称，名称需由Pod标准定义 nodePort <integer> # 节点端口号，仅实用于NodePort和LoadBalancer类型 clusterIP <string> # Service的集群IP，倡议由零碎主动调配 externalTrafficPolicy <string>#内部流量策略解决形式，Local示意由以后节点解决，#Cluster示意向集群范畴调度 loadBalancerIP <string> #内部负载均衡器应用的IP地址，仅实用于LoadBlancer externalName <string> # 内部服务名称，该名称将作为Service的DNS CNAME值示例1: ClusterIP 演示[root@k8s-master svc]# cat services-clusterip-demo.yaml apiVersion: v1kind: Servicemetadata: name: demoapp-svc namespace: defaultspec: clusterIP: 10.97.72.1 #正式部署不须要指定 会主动生成,手动指定还可能会导致抵触 selector: #定义过滤条件 app: demoapp ports: - name: http protocol: TCP port: 80 targetPort: 80 #后端pod端口[root@k8s-master svc]# kubectl apply -f services-clusterip-demo.yaml service/demoapp-svc created[root@k8s-master svc]# kubectl get svc -o wideNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTORdemoapp-svc ClusterIP 10.97.72.1 <none> 80/TCP 11s app=demoappkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 30d <none>my-grafana NodePort 10.96.4.185 <none> 80:30379/TCP 27d app.kubernetes.io/instance=my-grafana,app.kubernetes.io/name=grafanamyapp NodePort 10.106.116.205 <none> 80:31532/TCP 30d app=myapp,release=stabel[root@k8s-master svc]# curl 10.97.72.1 #通过拜访svc IP拜访到后端节点iKubernetes demoapp v1.0 !! ClientIP: 10.244.0.0, ServerName: demoapp-66db74fcfc-9wkgj, ServerIP: 10.244.2.97![root@k8s-master svc]# curl 10.97.72.1iKubernetes demoapp v1.0 !! ClientIP: 10.244.0.0, ServerName: demoapp-66db74fcfc-vzb4f, ServerIP: 10.244.1.98![root@k8s-master svc]# kubectl describe svc demoapp-svcName: demoapp-svcNamespace: defaultLabels: <none>Annotations: <none>Selector: app=demoappType: ClusterIPIP: 10.97.72.1Port: http 80/TCPTargetPort: 80/TCPEndpoints: 10.244.1.98:80,10.244.2.97:80 #后端节点Session Affinity: NoneEvents: <none>[root@k8s-master svc]# kubectl get pod -o wide --show-labels #匹配到前1、2个NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELSdemoapp-66db74fcfc-9wkgj 1/1 Running 0 39m 10.244.2.97 k8s-node2 <none> <none> app=demoapp,pod-template-hash=66db74fcfc,release=stabledemoapp-66db74fcfc-vzb4f 1/1 Running 0 39m 10.244.1.98 k8s-node1 <none> <none> app=demoapp,pod-template-hash=66db74fcfc,release=stable,track=dailyliveness-httpget-demo 1/1 Running 3 29m 10.244.1.99 k8s-node1 <none> <none> app=livenessliveness-tcpsocket-demo 1/1 Running 3 29m 10.244.1.100 k8s-node1 <none> <none> <none>my-grafana-7d788c5479-kpq9q 1/1 Running 4 27d 10.244.1.84 k8s-node1 <none> <none> app.kubernetes.io/instance=my-grafana,app.kubernetes.io/name=grafana,pod-template-hash=7d788c5479[root@k8s-master svc]# kubectl get ep #理论治理后端端点与svc的绑定是EndpointsNAME ENDPOINTS AGEdemoapp-svc 10.244.1.98:80,10.244.2.97:80 2m33skubernetes 192.168.4.170:6443 30dmy-grafana 10.244.1.84:3000 27dmyapp <none> 30d[root@k8s-master svc]# kubectl scale deployment demoapp --replicas=4 #批改deployment正本数为4deployment.apps/demoapp scaled[root@k8s-master svc]# kubectl get pod --show-labelsNAME READY STATUS RESTARTS AGE LABELSdemoapp-66db74fcfc-9jzs5 1/1 Running 0 18s app=demoapp,pod-template-hash=66db74fcfc,release=stabledemoapp-66db74fcfc-9wkgj 1/1 Running 0 100m app=demoapp,pod-template-hash=66db74fcfc,release=stabledemoapp-66db74fcfc-dw9w2 1/1 Running 0 18s app=demoapp,pod-template-hash=66db74fcfc,release=stabledemoapp-66db74fcfc-vzb4f 1/1 Running 0 100m app=demoapp,pod-template-hash=66db74fcfc,release=stable,track=dailyliveness-httpget-demo 1/1 Running 3 90m app=livenessliveness-tcpsocket-demo 1/1 Running 3 90m <none>my-grafana-7d788c5479-kpq9q 1/1 Running 4 27d app.kubernetes.io/instance=my-grafana,app.kubernetes.io/name=grafana,pod-template-hash=7d788c5479[root@k8s-master svc]# kubectl get ep #已实时增加到ep与svc绑定NAME ENDPOINTS AGEdemoapp-svc 10.244.1.101:80,10.244.1.98:80,10.244.2.97:80 + 1 more... 63mkubernetes 192.168.4.170:6443 30dmy-grafana 10.244.1.84:3000 27dmyapp <none> 30d示例2: NodePort 演示[root@k8s-master svc]# cat services-nodeport-demo.yaml apiVersion: v1kind: Servicemetadata: name: demoapp-nodeport-svc namespace: defaultspec: type: NodePort clusterIP: 10.97.56.1 #正式部署不须要指定 会主动生成手动指定还可能会导致抵触 selector: app: demoapp ports: - name: http protocol: TCP port: 80 targetPort: 80 #后端pod端口 nodePort: 31399 #正式部署不须要指定 会主动生成 默认生成端口在30000-32768之间[root@k8s-master svc]# kubectl apply -f services-nodeport-demo.yaml service/demoapp-nodeport-svc created[root@k8s-master svc]# kubectl get podNAME READY STATUS RESTARTS AGEdemoapp-66db74fcfc-9jzs5 1/1 Running 0 8m47sdemoapp-66db74fcfc-9wkgj 1/1 Running 0 109mdemoapp-66db74fcfc-dw9w2 1/1 Running 0 8m47sdemoapp-66db74fcfc-vzb4f 1/1 Running 0 109mliveness-httpget-demo 1/1 Running 3 98mliveness-tcpsocket-demo 1/1 Running 3 98mmy-grafana-7d788c5479-kpq9q 1/1 Running 4 27d[root@k8s-master svc]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdemoapp-nodeport-svc NodePort 10.97.56.1 <none> 80:31399/TCP 11s #能够看到两个prot 其中31399就是nodeport端口demoapp-svc ClusterIP 10.97.72.1 <none> 80/TCP 72m[root@k8s-master svc]# while true;do curl 192.168.4.171:31399;sleep 1;done #通过节点IP:prot拜访iKubernetes demoapp v1.0 !! ClientIP: 10.244.2.1, ServerName: demoapp-66db74fcfc-9wkgj, ServerIP: 10.244.2.97!iKubernetes demoapp v1.0 !! ClientIP: 10.244.2.0, ServerName: demoapp-66db74fcfc-dw9w2, ServerIP: 10.244.1.101!iKubernetes demoapp v1.0 !! ClientIP: 10.244.2.0, ServerName: demoapp-66db74fcfc-vzb4f, ServerIP: 10.244.1.98!iKubernetes demoapp v1.0 !! ClientIP: 10.244.2.1, ServerName: demoapp-66db74fcfc-9wkgj, ServerIP: 10.244.2.97!能够看到下面尽管是通过节点2拜访,但通过IP地址发现还是会轮询到节点1上的pod这时就要提到 'externalTrafficPolicy <string>' #内部流量策略解决形式，Local示意由以后节点解决Cluster示意向集群范畴调度[root@k8s-master ~]# kubectl edit svc demoapp-nodeport-svc...spec: clusterIP: 10.97.56.1 externalTrafficPolicy: Local #把默认的Cluster改成Local...[root@k8s-master svc]# kubectl scale deployment demoapp --replicas=1 #调整deployment正本数为1deployment.apps/demoapp scaled[root@k8s-master ~]# kubectl get pod -o wide #能够看到惟一的pod运行node2节点上NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESdemoapp-66db74fcfc-9wkgj 1/1 Running 0 123m 10.244.2.97 k8s-node2 <none> <none>liveness-httpget-demo 1/1 Running 3 112m 10.244.1.99 k8s-node1 <none> <none>[root@k8s-master ~]# curl 192.168.4.171:31399 #通过节点1 失败^C[root@k8s-master ~]# curl 192.168.4.172:31399 #通过节点2iKubernetes demoapp v1.0 !! ClientIP: 192.168.4.170, ServerName: demoapp-66db74fcfc-9wkgj, ServerIP: 10.244.2.97!示例3: LoadBalancer 演示[root@k8s-master svc]# cat services-loadbalancer-demo.yaml apiVersion: v1kind: Servicemetadata: name: demoapp-loadbalancer-svc namespace: defaultspec: type: LoadBalancer selector: app: demoapp ports: - name: http protocol: TCP port: 80 targetPort: 80 #后端pod端口# loadBalancerIP: 1.2.3.4 #这里应该不是在Iaas平台上,无奈创立ELB,所以无奈创立[root@k8s-master svc]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdemoapp-loadbalancer-svc LoadBalancer 10.110.155.70 <pending> 80:31619/TCP 31s #能够看到因为不是Iaas平台上 EXTERNAL-IP始终为pending状态,示意始终在申请资源而挂起,仍然能够通过NodePort的形式拜访demoapp-nodeport-svc NodePort 10.97.56.1 <none> 80:31399/TCP 30mdemoapp-svc ClusterIP 10.97.72.1 <none> 80/TCP 102m[root@k8s-master svc]# while true;do curl 192.168.4.171:31399;sleep 1;done #通过NodePort的形式拜访iKubernetes demoapp v1.0 !! ClientIP: 10.244.1.0, ServerName: demoapp-66db74fcfc-9wkgj, ServerIP: 10.244.2.97!iKubernetes demoapp v1.0 !! ClientIP: 10.244.1.1, ServerName: demoapp-66db74fcfc-2jf49, ServerIP: 10.244.1.103!iKubernetes demoapp v1.0 !! ClientIP: 10.244.1.0, ServerName: demoapp-66db74fcfc-9wkgj, ServerIP: 10.244.2.97!iKubernetes demoapp v1.0 !! ClientIP: 10.244.1.1, ServerName: demoapp-66db74fcfc-5dp5n, ServerIP: 10.244.1.102!示例4: externalIPs 演示NodePort 理论利用中还须要在后面加一层负载平衡，以起到对立入口和高可用，而且后端新增的节点也不会主动增加到负载上externalIPs 在只有1个或多个节点裸露IP的状况下，可通过虚构IP，实现高可用 ...

Pod生命周期容器初始化环境运行容器的pause根底容器init c容器初始化容器（init c能够有多个，串行运行）main c启动主容器（启动之初容许执行一个执行命令或一个脚本，在完结的时候容许执行一个命令）readless 就绪探测liveness 存活探测初始化容器初始化容器即 pod 内主容器启动之前要运行的容器，次要是做一些前置工作，初始化容器具备以下特色：初始化容器必须首先执行，若初始化容器运行失败，集群会始终重启初始化容器直至实现，留神，如果 pod 的重启策略为 Never，那初始化容器启动失败后就不会重启。初始化容器必须依照定义的程序执行，初始化容器能够通过 pod 的 spec.initContainers 进行定义。 lifecycle 申明周期钩子函数 创立资源对象时，能够应用lifecycle来治理容器在运行前和敞开前的一些动作。 lifecycle有两种回调函数︰PostStart:容器创立胜利后，运行前的工作，用于资源部署、环境筹备等PreStop:在容器被终止前的工作，用于优雅敞开应用程序、告诉其余零碎等等。备注：钩子程序的执行形式有“exec”和“HTTP”两种。Pod 状态Pod 的 status 定义在 PodStatus 对象中，其中有一个 phase 字段。它简略形容了 Pod 在其生命周期的阶段。相熟Pod的各种状态对咱们了解如何设置Pod的调度策略、重启策略是很有必要的。上面是 phase 可能的值： 阶段 形容Pending Pod 已被 Kubernetes 零碎承受，但有一个或者多个容器镜像尚未创立。等待时间包含调度 Pod 的工夫和通过网络下载镜像的工夫，这可能须要花点工夫。Running 该 Pod 曾经绑定到了一个节点上，Pod 中所有的容器都已被创立。至多有一个容器正在运行，或者正处于启动或重启状态。Succeeded Pod 中的所有容器都被胜利终止，并且不会再重启。Failed Pod 中的所有容器都已终止了，并且至多有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被零碎终止。Unknown 因为某些起因无奈获得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。Pod终止过程终止过程次要分为如下几个步骤： 用户收回删除 pod 命令Pod 对象随着工夫的推移更新，在宽限期（默认状况下30秒），pod 被视为“dead”状态将 pod 标记为“Terminating”状态第三步同时运行，监控到 pod 对象为“Terminating”状态的同时启动 pod 敞开过程 5.第三步同时进行，5. endpoints 控制器监控到 pod 对象敞开，将pod与service匹配的 endpoints 列表中删除如果 pod 中定义了 preStop 钩子处理程序，则 pod 被标记为“Terminating”状态时以同步的形式启动执行；若宽限期完结后，preStop 仍未执行完结，第二步会从新执行并额定取得一个2秒的小宽限期Pod 内对象的容器收到 TERM 信号宽限期完结之后，若存在任何一个运行的过程，pod 会收到 SIGKILL 信号Kubelet 申请 API Server 将此 Pod 资源宽限期设置为0从而实现删除操作探针容器探测 ...

kubernetes labels 标签简介标签中的键名称通常由"键前缀"和键名"“组成，其格局形如"KEY PREFIX/KEY_NAME"，键前缀为可选局部。键名至少能应用63个字符，反对字母、数字、连接号(-)、下划线(_)、点号(.)等字符，且只能以字母或数字结尾。而键前缀必须为DNS子域名格局。且不能超过253个字符。省路键前缀时，键将被视为用户的公有数据。那些由Kubernetes零碎组件或第三方组件主动为用户资源增加的键必须应用键前缀，kubernetes.io/和k8s.io/前缀预留给了kubernetes的外围组件应用，例如:Node对象上罕用的kubernetes.io/os、 kutbernetes.io/arch和kubernetes.io/hostname等。 标签的键值必须不能多于63个字符，它要么为空，要么是以字母或数字结尾及结尾，且两头仅应用了字母、数字、连接号(-)、下划线（_）或点号（.）等字符的数据。 标签选择器用于表白标签的查问条件或抉择规范，Kubernetes API目前反对两个选择器;基于等值关系(equality-based》的标签选项器以及基于汇合关系(set-bsel)的标签选择器。同时指定多个选择器时须要以逗号将其分隔，各选择器之间遵循“与"逻辑，即必须要满足所有条件，而且空值的选择器将不抉择任何对象。 基于等值关系的标签选择器的可用操作符有=、==和!= 三种，其中前两个意义雷同,都示意"等值"关系，最初一个示意"不等”。例如env=dev和env!=prod都是基于等值关系的选择器，而tier in (frontend,backend)则是基于汇合关系的选择器。 创立标签时:release=alpha,标签选择器应用:release==alpha 罕用标签: 版本标签: "release" : "stable","release" : "canary", "release" : "beta".环境标签: "environment" : "dev"， "environment" : "qa","environment" : "prod"利用标签: "app" : "ui"，"app" : "as"，"app" : "pc","app" : "sc"架构层级标签: "tier" : "frontend", "tier" : "backend" , "tier" : "cache"分区标签: "partition" : "customerA","partition" : "customerB"。品控级别标签:"track" : "daily"， "track" : "weekly"。匹配条件 KEY in (VALUE1,VALUE2,.….)∶指定的键名的值存在于给定的列表中即满足条件;KEY notin (VALUE1,VALUE2,.)︰指定的键名的值不存在于给定列表中即满足条件;KEY:所有存在此键名标签的资源;!KEY:所有不存在此键名标签的资源。示例1:手动增加标签 [root@k8s-master svc]# kubectl label --help[root@k8s-master svc]# kubectl get pod --show-labels #查看标签NAME READY STATUS RESTARTS AGE LABELSstress-pod 1/1 Running 1 25h <none>[root@k8s-master svc]# kubectl label pods stress-pod release=alpha #增加标签pod/stress-pod labeled[root@k8s-master svc]# kubectl get pod --show-labelsNAME READY STATUS RESTARTS AGE LABELSstress-pod 1/1 Running 1 25h release=alpha[root@k8s-master svc]# kubectl label pods stress-pod release- #删除标签pod/stress-pod labeled[root@k8s-master svc]# kubectl get pod --show-labelsNAME READY STATUS RESTARTS AGE LABELSstress-pod 1/1 Running 1 25h <none>标签匹配抉择 过滤[root@k8s-master svc]# kubectl get pod --show-labelsNAME READY STATUS RESTARTS AGE LABELSdemoapp-66db74fcfc-9wkgj 1/1 Running 0 11m app=demoapp,pod-template-hash=66db74fcfc,release=stabledemoapp-66db74fcfc-vzb4f 1/1 Running 0 11m app=demoapp,pod-template-hash=66db74fcfc,release=stableliveness-httpget-demo 0/1 ContainerCreating 0 25s <none>liveness-tcpsocket-demo 0/1 ContainerCreating 0 20s <none>my-grafana-7d788c5479-kpq9q 1/1 Running 4 27d app.kubernetes.io/instance=my-grafana,app.kubernetes.io/name=grafana,pod-template-hash=7d788c5479[root@k8s-master svc]# kubectl get pods -l app=demoapp --show-labels #过滤标签app=demoapp的podNAME READY STATUS RESTARTS AGE LABELSdemoapp-66db74fcfc-9wkgj 1/1 Running 0 12m app=demoapp,pod-template-hash=66db74fcfc,release=stabledemoapp-66db74fcfc-vzb4f 1/1 Running 0 12m app=demoapp,pod-template-hash=66db74fcfc,release=stable[root@k8s-master svc]# kubectl get pods -l app!=demoapp --show-labels #所有不匹配app=demoapp 的pod 蕴含没有app标签的pod NAME READY STATUS RESTARTS AGE LABELSliveness-httpget-demo 1/1 Running 2 3m28s <none>liveness-tcpsocket-demo 1/1 Running 2 3m23s <none>my-grafana-7d788c5479-kpq9q 1/1 Running 4 27d app.kubernetes.io/instance=my-grafana,app.kubernetes.io/name=grafana,pod-template-hash=7d788c5479stress-pod 1/1 Running 1 27h <none>[root@k8s-master svc]# kubectl get pods -l app --show-labels #过滤所有含app标签的容器NAME READY STATUS RESTARTS AGE LABELS demoapp-66db74fcfc-9wkgj 1/1 Running 0 16m app=demoapp,pod-template-hash=66db74fcfc,release=stabledemoapp-66db74fcfc-vzb4f 1/1 Running 0 16m app=demoapp,pod-template-hash=66db74fcfc,release=stable[root@k8s-master svc]# kubectl get pods -l '!app' --show-labels #过滤所有不含app标签的容器NAME READY STATUS RESTARTS AGE LABELSliveness-httpget-demo 1/1 Running 3 6m33s <none>liveness-tcpsocket-demo 1/1 Running 3 6m28s <none>my-grafana-7d788c5479-kpq9q 1/1 Running 4 27d app.kubernetes.io/instance=my-grafana,app.kubernetes.io/name=grafana,pod-template-hash=7d788c5479[root@k8s-master svc]# kubectl label pods liveness-httpget-demo app=liveness #增加app标签pod/liveness-httpget-demo labeled[root@k8s-master svc]# kubectl get pods -l 'app in (demoapp,liveness)' --show-labels #过滤app= demoapp或liveness的podNAME READY STATUS RESTARTS AGE LABELSdemoapp-66db74fcfc-9wkgj 1/1 Running 0 20m app=demoapp,pod-template-hash=66db74fcfc,release=stabledemoapp-66db74fcfc-vzb4f 1/1 Running 0 20m app=demoapp,pod-template-hash=66db74fcfc,release=stableliveness-httpget-demo 1/1 Running 3 9m45s app=liveness[root@k8s-master svc]# kubectl label pods demoapp-66db74fcfc-vzb4f track=daily #增加标签pod/demoapp-66db74fcfc-vzb4f labeled[root@k8s-master svc]# kubectl get pods -l 'app=demoapp,track=daily' --show-labels #过滤app=demoapp,track=daily同时满足条件的podNAME READY STATUS RESTARTS AGE LABELSdemoapp-66db74fcfc-vzb4f 1/1 Running 0 26m app=demoapp,pod-template-hash=66db74fcfc,release=stable,track=daily[root@k8s-master svc]# kubectl get deployment -l app=demoapp --show-labels #标签过滤同样对其实资源无效NAME READY UP-TO-DATE AVAILABLE AGE LABELSdemoapp 2/2 2 2 28m app=demoapp,release=stable

DaemonSet简介DaemonSet 确保全副（或者一些）Node 上运行一个 Pod 的正本。当有 Node 退出集群时，也会为他们新增一个Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创立的所有 Pod 应用 DaemonSet 的一些典型用法：运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、New Relic 代理，或 Ganglia gmond默认会在每个节点运行一个Pod (master节点除外)或依据标签匹配抉择运行的节点 DaemonSet 配置标准apiVersion: apps/v1 # API群组及版本kind: DaemonSet#资源类型特有标识metadata: name <string> #资源名称,在作用域中要惟一 namespace <string> #名称空间;DaemonSet资源附属名称空间级别spec: minReadySeconds <integer> # Pod就绪后多少秒内任一容器无crash方可视为“就绪” selector <object> #标签选择器，必须匹配template字段中Pod模板中的标签 template <object> #Pod模板对象; revisionHistoryLimit <integer> #滚动更新历史记录数量，默认为10; updateStrategy <0bject> #滚动更新策略 type <string> #滚动更新类型，可用值有OnDelete和Rollingupdate; rollingUpdate <Object> #滚动更新参数，专用于RollingUpdate类型 maxUnavailable <string> #更新期间可比冀望的Pod数量短少的数量或比例示例1: 新建DaemonSet控制器 部署node-exporter[root@k8s-master PodControl]# cat daemonset-demo.yaml apiVersion: apps/v1kind: DaemonSetmetadata: name: daemonset-demo namespace: default labels: app: prometheus component: node-exporterspec: selector: matchLabels: app: prometheus component: node-exporter template: metadata: name: prometheus-node-exporter labels: app: prometheus component: node-exporter spec: containers: - image: prom/node-exporter:v0.18.0 name: prometheus-node-exporter ports: - name: prom-node-exp containerPort: 9100 hostPort: 9100 livenessProbe: tcpSocket : port: prom-node-exp initialDelaySeconds: 3 readinessProbe: httpGet: path: '/metrics' port: prom-node-exp scheme: HTTP initialDelaySeconds: 5 hostNetwork: true hostPID: true[root@k8s-master PodControl]# kubectl apply -f daemonset-demo.yaml daemonset.apps/daemonset-demo created[root@k8s-master PodControl]# kubectl get podNAME READY STATUS RESTARTS AGEdeployment-demo-77d46c4794-fhz4l 1/1 Running 0 16hdeployment-demo-77d46c4794-kmrhn 1/1 Running 0 16hdeployment-demo-fb544c5d8-5f9lp 1/1 Running 0 17h[root@k8s-master PodControl]# cat daemonset-demo.yaml ... spec: containers: - image: prom/node-exporter:latest #更新为最新版...#默认为滚动更新[root@k8s-master PodControl]# kubectl apply -f daemonset-demo.yaml && kubectl rollout status daemonset/daemonset-demodaemonset.apps/daemonset-demo createdWaiting for daemon set "daemonset-demo" rollout to finish: 0 of 3 updated pods are available...Waiting for daemon set "daemonset-demo" rollout to finish: 1 of 3 updated pods are available...Waiting for daemon set "daemonset-demo" rollout to finish: 2 of 3 updated pods are available...daemon set "daemonset-demo" successfully rolled outJob的简介及 配置标准Job 负责批处理工作，即仅执行一次的工作，它保障批处理工作的一个或多个 Pod 胜利完结 ...

控制器简介Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来管制 Pod 的具体状态和行为 负责利用编排的控制器类型有如下几种:ReplicationController:最晚期的Pod控制器;RelicaSet: 正本集,负责管理一个利用(Pod）的多个正本;Deployment: 部署，它不间接治理Pod，而是借助于ReplicaSet来治理Pod;最罕用的无状态利用控制器;DaemonSet:守护过程集，用于确保在每个节点仅运行某个利用的一个Pod正本;StatefulSet:性能相似于Deployment，但StatefulSet专用于编排有状态利用;Job:有终止期限的一次性作业式工作，而非始终处于运行状态的服务过程;CronJob:有终止期限的周期性作业式工作;ReplicaSet 简介ReplicationController 和 ReplicaSetReplicationController（RC）用来确保容器利用的正本数始终保持在用户定义的正本数，即如果有容器异样退出，会主动创立新的 Pod 来代替；而如果异样多进去的容器也会主动回收；在新版本的 Kubernetes 中倡议应用 ReplicaSet 来取代 ReplicationController 。ReplicaSet 跟ReplicationController 没有实质的不同，只是名字不一样，并且 ReplicaSet 反对汇合式的 selector；Pod控制器定义因素:标签选择器;冀望的正本数;Pod模板;ReplicaSet的更新机制:删除式更新 比方:- set image:更新利用版本，但对于replicaset来说，仅能更新API Server中的定义 理论运行Pod只能删除后重新启动才失效Replicaset 字段阐明apiversion: apps/v1kind: Replicasetmetadata: name: ... namespace: …spec: minReadySeconds <integer> #Pod就绪后多少秒内任一容器无crash方可视为“就绪” replicas <integer> #冀望的Pod正本数,默认为1 selectorl: #标签选择器，必须匹配template字段中Pod模板中的标签; matchExpressions_<[ ]Object> #标签选择器表达式列表，多个列表项之间为“与"关系 matchLabels <map[string]string> #map格局的标签选择器;和之前SVC的标签选择器为selector:相似 template: #Pod模板对象 metadata: #Pod对象元数据 labels: #由模板创立出的Pod对象所领有的标签，必须要可能匹配后面定义的标签选择器 spec:# Pod标准,格局同自主式Pod ......示例1：创ReplicaSet控制器[root@k8s-master PodControl]# cat replicaset.demo.yaml apiVersion: apps/v1kind: ReplicaSetmetadata: name: replicaset-demospec: minReadySeconds: 3 replicas: 2 selector: matchLabels: app: demoapp release: stable version: v1.0 template: metadata: labels: #这里的标签要能覆盖住下面的标签,能够比下面多但不能比下面少,因为实践上控制器如果匹配不到Pod 控制器会有限创立Pod,理论是建创时会报错 app: demoapp release: stable version: v1.0 test: test22 spec: containers: - name: demoapp image: ikubernetes/demoapp:v1.0 ports: - name: http containerPort: 80 livenessProbe: httpGet: path: '/livez' port: 80 initialDelaySeconds : 10 readinessProbe: httpGet: path: '/readyz' port: 80 initialDelaySeconds: 15[root@k8s-master PodControl]# kubectl get replicaset -o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORreplicaset-demo 2 2 2 30m demoapp ikubernetes/demoapp:v1.0 app=demoapp,release=stable,version=v1.0[root@k8s-master PodControl]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESmy-grafana-7d788c5479-4ztb7 1/1 Running 0 44m 10.244.1.208 k8s-node1 <none> <none>replicaset-demo-b4hx9 1/1 Running 0 34m 10.244.1.210 k8s-node1 <none> <none>replicaset-demo-zb7m5 1/1 Running 1 34m 10.244.2.203 k8s-node2 <none> <none>#查看形容信息[root@k8s-master PodControl]# kubectl describe replicasets/replicaset-demoName: replicaset-demoNamespace: defaultSelector: app=demoapp,release=stable,version=v1.0Labels: <none>Annotations: <none>Replicas: 2 current / 2 desired #当初运行 / 冀望运行 Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed #Pod状态Pod Template: Labels: app=demoapp release=stable test=test22 version=v1.0 Containers: demoapp: Image: ikubernetes/demoapp:v1.0 Port: 80/TCP Host Port: 0/TCP Liveness: http-get http://:80/livez delay=10s timeout=1s period=10s #success=1 #failure=3 Readiness: http-get http://:80/readyz delay=15s timeout=1s period=10s #success=1 #failure=3 Environment: <none> Mounts: <none> Volumes: <none>Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 8m28s replicaset-controller Created pod: replicaset-demo-b4hx9 Normal SuccessfulCreate 8m28s replicaset-controller Created pod: replicaset-demo-zb7m5[root@k8s-master PodControl]# kubectl get pod replicaset-demo-zb7m5 -o yaml...ownerReferences: #查看Pod受哪个管理器治理 - apiVersion: apps/v1 blockOwnerDeletion: true controller: true kind: ReplicaSet name: replicaset-demo uid: d6525139-a5a5-4886-9c2b-d7cfe2db6d35 resourceVersion: "8790580" selfLink: /api/v1/namespaces/default/pods/replicaset-demo-zb7m5...ReplicaSet更新 可应用kubectl set命令更新[root@k8s-master PodControl]# kubectl set image --help #查看set更新的相干案例Update existing container image(s) of resources. Possible resources include (case insensitive): pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), replicaset (rs)Examples: # Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to'busybox'. kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1 # Update all deployments' and rc's nginx container's image to 'nginx:1.9.1' kubectl set image deployments,rc nginx=nginx:1.9.1 --all # Update image of all containers of daemonset abc to 'nginx:1.9.1' kubectl set image daemonset abc *=nginx:1.9.1 # Print result (in yaml format) of updating nginx container image from local file, without hittingthe server更新image镜像[root@k8s-master PodControl]# kubectl set image replicasets/replicaset-demo demoapp=ikubernetes/demoapp:v1.1 #更新replicasets中镜像版本为v1.1replicaset.apps/replicaset-demo image updat[root@k8s-master PodControl]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESmy-grafana-7d788c5479-4ztb7 1/1 Running 0 44m 10.244.1.208 k8s-node1 <none> <none>replicaset-demo-b4hx9 1/1 Running 0 34m 10.244.1.210 k8s-node1 <none> <none>replicaset-demo-zb7m5 1/1 Running 1 34m 10.244.2.203 k8s-node2 <none> <none>[root@k8s-master PodControl]# kubectl get replicaset/replicaset-demo -o yaml|grep image ... - image: ikubernetes/demoapp:v1.1 imagePullPolicy: IfNotPresent#能够看到replicaset中的镜像信息曾经更新胜利[root@k8s-master PodControl]# kubectl get pods replicaset-demo-zb7m5 -o yaml containerStatuses: - containerID: docker://4c4e576d7f5accb89c4f73a0aef18bd99cac37ee81b34a07a363d2afc35d5189 image: ikubernetes/demoapp:v1.0 imageID: docker-pullable://ikubernetes/demoapp@sha256:6698b205eb18fb0171398927f3a35fe27676c6bf5757ef57a35a4b055badf2c3#但Pod中的image并没有更新[root@k8s-master PodControl]# curl 10.244.1.210 iKubernetes demoapp v1.0 !! ClientIP: 10.244.0.0, ServerName: replicaset-demo-b4hx9, ServerIP: 10.244.1.210![root@k8s-master PodControl]# curl 10.244.1.210iKubernetes demoapp v1.0 !! ClientIP: 10.244.0.0, ServerName: replicaset-demo-b4hx9, ServerIP: 10.244.1.210!#理论拜访Pod 也并没有更新胜利 这是因为ReplicaSet为删除式更新 Pod删除重启后才会失效[root@k8s-master PodControl]# kubectl delete pod -l app=demoapp,release=stablepod "replicaset-demo-b4hx9" deletedpod "replicaset-demo-zb7m5" deleted[root@k8s-master PodControl]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESmy-grafana-7d788c5479-4ztb7 1/1 Running 0 57m 10.244.1.208 k8s-node1 <none> <none>replicaset-demo-686fl 0/1 Running 1 2m28s 10.244.1.212 k8s-node1 <none> <none>replicaset-demo-k4pq9 0/1 Running 0 2m28s 10.244.3.49 k8s-node3 <none> <none>[root@k8s-master PodControl]# curl 10.244.3.49 #更新胜利iKubernetes demoapp v1.1 !! ClientIP: 10.244.0.0, ServerName: replicaset-demo-k4pq9, ServerIP: 10.244.3.49![root@k8s-master PodControl]# curl 10.244.3.49 iKubernetes demoapp v1.1 !! ClientIP: 10.244.0.0, ServerName: replicaset-demo-k4pq9, ServerIP: 10.244.3.49服务部署 蓝绿公布、滚动更新Pod部署类型:蓝绿公布: 在旧版本的根底上 在新建一套新版本 ...

kubernetes资源援用格局<type>/<name>: pods/mypod,depolyment/demoapp #能够同时对不同的资源进行操作<type> <name>: pods mypod,deployment demoapp #只能对同一类型资源操作示例： [root@k8s-master ~]# kubectl delete pods/mypod depolyment/demoapp #胜利[root@k8s-master ~]# kubectl delete pods mypod mypod2 #胜利[root@k8s-master ~]# kubectl delete pods mypod depolyment demoapp #失败 会把pods前面的所以字段都当成pod kubectl 常用命令[root@k8s-master ~]# kubectl api-resources #查看资源类型与对象缩写[root@k8s-master ~]# kubectl get all #查看所有资源[root@k8s-master ~]# kubectl get pod # 可应用get查看pod、svc、ns、deployment简直所有资源状态[root@k8s-master ~]# kubectl describe pod <PodName> #可应用describe 查看pod、svc、ns、deployment简直所有资源状态更具体的形容信息，包含pod的错误信息等[root@k8s-master ~]# kubectl delete pod <PodName> #删除pod同样能够针对所有资源可用[root@k8s-master ~]# kubectl get pod --all-namespaces -o wide #所有名称空间下的pod <-o wide> 查看更详细描述 同样能够针对所有资源可用[root@k8s-master ~]# kubectl delete pod <PodName> #删除pod同样能够针对所有资源可用kubectl get pod --show-labels #查看标签[root@k8s-master ~]# kubectl get node --show-labels #查看节点标[root@k8s-master ~]# kubectl get cm -o yaml #以yaml格局输入[root@k8s-master ~]# kubectl create -f pop.yaml #命令式创建对象[root@k8s-master ~]# kubectl apply -f pod.yaml #申明式(幂等)创建对象[root@k8s-master ~]# kubectl edit pod myapp-pod #编辑pod[root@k8s-master ~]# kubectl logs myapp-pod -c test #查看pop的日志 -c 指定容器 如果只1个容器不须要指定[root@k8s-master ~]# kubectl exec readiness-httpget-pod -n xx -it -- /bin/sh #进入容器 如果多个容器 -c指定容[root@k8s-master ~]# kubectl exec liveness-httpget-pod -it -- rm -fr /usr/share/nginx/html/index.html #执行命令[root@k8s-master ~]# kubectl explain deployment #查看资源的文档 版本及定义的字段 其中<[]object> []KIND: DeploymentVERSION: apps/v1DESCRIPTION: Deployment enables declarative updates for Pods and ReplicaSets.FIELDS: apiVersion <string> #字段为字符 metadata <Object> #字身为对象 可通过kubectl explain deployment.metadata 可查看具体的阐明$ kubectl explain deployment.spec selector <Object> -required- #必须字段$ kubectl explain pod.spec containers<[]Object> -required- #在yaml中示意对象为列表 能够有多个对象kubernetes组件 ...