Values https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing To see what options are configurable on a chart, use helm show values: $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.

k8s headless svc k8s headless and dns https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ A/AAAA records “Normal” (not headless) Services are assigned a DNS A or AAAA record, depending on the IP family of the service, for a name of the form my-svc.my-namespace.svc.cluster-domain.example. This resolves to the cluster IP of the Service. “Headless” (without a cluster IP) Services are also assigned a DNS A or AAAA record, depending on the IP family of the service, for a name of the form my-svc.

https://banzaicloud.com/blog/istio-mixerless-telemetry/ Because Istio Telemetry V2 lacks a central component (Mixer) with access to K8s metadata, the proxies themselves require the metadata necessary to provide rich metrics. Additionally, features provided by Mixer had to be added to the Envoy proxies to replace the Mixer-based telemetry. Istio Telemetry V2 uses two custom Envoy plugins to achieve just that. In-proxy service-level metrics in Telemetry V2 are provided by two custom plugins, metadata-exchange and stats.

https://istio.io/latest/docs/tasks/observability/metrics/tcp-metrics/ Understanding TCP telemetry collection In this task, you used Istio configuration to automatically generate and report metrics for all traffic to a TCP service within the mesh. TCP Metrics for all active connections are recorded every 15s by default and this timer is configurable via tcpReportingDuration. Metrics for a connection are also recorded at the end of the connection. TCP attributes Several TCP-specific attributes enable TCP policy and control within Istio.

https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/ from worknode no cert check TLS 1 2 3 4 5 6 export DOMAIN=fortio-server.idm-mark.svc.cluster.local export INGRESS_IP=10.97.117.127 export SECURE_INGRESS_PORT=8080 curl -v -HHost:$DOMAIN --resolve "$DOMAIN:$SECURE_INGRESS_PORT:$INGRESS_IP" \ -k "https://$DOMAIN:$SECURE_INGRESS_PORT/fortio/" simple TLS 1 2 curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \ --cacert example.com.crt "https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418" through gateway no cert check TLS 1 2 3 4 5 6 export DOMAIN=fortio-server.idm-mark.svc.cluster.local export INGRESS_IP=10.100.122.140 export SECURE_INGRESS_PORT=80 curl -v -HHost:$DOMAIN --resolve "$DOMAIN:$SECURE_INGRESS_PORT:$INGRESS_IP" \ -k "https://$DOMAIN:$SECURE_INGRESS_PORT/fortio/" no cert check TLS 1 2 3 4 5 6 export DOMAIN=fortio-server.

https://istio.io/latest/docs/ops/configuration/traffic-management/tls-configuration/ Sidecars Sidecar traffic has a variety of associated connections. Let’s break them down one at a time. Sidecar proxy network connections External inbound traffic This is traffic coming from an outside client that is captured by the sidecar. If the client is inside the mesh, this traffic may be encrypted with Istio mutual TLS. By default, the sidecar will be configured to accept both mTLS and non-mTLS traffic, known as PERMISSIVE mode.

https://istio.io/v1.4/docs/tasks/security/authentication/mtls-migration/ Ensure that your cluster is in PERMISSIVE mode before migrating to mutual TLS. Run the following command to check: 1 2 3 4 5 6 $ kubectl get meshpolicy default -o yaml ... spec: peers: - mtls: mode: PERMISSIVE In PERMISSIVE mode, the Envoy sidecar relies on the ALPN value istio to decide whether to terminate the mutual TLS traffic. If your workloads (without Envoy sidecar) have enabled mutual TLS directly to the services with Envoy sidecars, enabling PERMISSIVE mode may cause these connections to fail.

SPIFFE https://spiffe.io/docs/latest/spiffe-about/overview/ https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/ old school Official SPIFFE method: https://blog.envoyproxy.io/securing-the-service-mesh-with-spire-0-3-abb45cd79810 Workload A workload is a single piece of software, deployed with a particular configuration for a single purpose; it may comprise multiple running instances of software, all of which perform the same task. The term “workload” may encompass a range of different definitions of a software system, including: A web server running a Python web application, running on a cluster of virtual machines with a load-balancer in front of it.

x-forwarded-client-cert https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-client-cert x-forwarded-client-cert (XFCC) is a proxy header which indicates certificate information of part or all of the clients or proxies that a request has flowed through, on its way from the client to the server. A proxy may choose to sanitize/append/forward the XFCC header before proxying the request. The XFCC header value is a comma (",") separated string. Each substring is an XFCC element, which holds information added by a single proxy.

https://istio.io/latest/docs/ops/common-problems/network-issues/#double-tls Double TLS (TLS origination for a TLS request) When configuring Istio to perform TLS origination, you need to make sure that the application sends plaintext requests to the sidecar, which will then originate the TLS. TLS Origination TLS origination occurs when an Istio proxy (sidecar or egress gateway) is configured to accept unencrypted internal HTTP connections, encrypt the requests, and then forward them to HTTPS servers that are secured using simple or mutual TLS.

How Does the CPU Manager Work? When CPU manager is enabled with the “static” policy, it manages a shared pool of CPUs. Initially this shared pool contains all the CPUs in the compute node. When a container with integer CPU request in a Guaranteed pod is created by the Kubelet, CPUs for that container are removed from the shared pool and assigned exclusively for the lifetime of the container. Other containers are migrated off these exclusively allocated CPUs.

注意：kubelet修改cpu_manager策略配置，一定要停掉kubelet服务，并删除/var/lib/kubelet/cpu_manager_state 文件，再重启kubelet，否则会导致kubelet服务重启失败。 kubelet的快照文件: cpu_manager_state：CPU管理器快照文件，包含cpu分配策略和已分配pod的cpuset信息 device-plugins/kubelet_internal_checkpoint：deviceplugin的快照信息，这里关注测试numa亲和性分配相关的TOPO分配信息 Ref. http://bingerambo.com/posts/2020/12/k8s%E5%9F%BA%E4%BA%8Enuma%E4%BA%B2%E5%92%8C%E6%80%A7%E7%9A%84%E8%B5%84%E6%BA%90%E5%88%86%E9%85%8D%E7%89%B9%E6%80%A7%E6%B5%8B%E8%AF%95/