https://helm.sh/docs/topics/charts/ Chart A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file. Directory structure wordpress/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.

As you edit your chart, you can validate that it is well-formed by running helm lint. When it’s time to package the chart up for distribution, you can run the helm package command: 1 2 $ helm package deis-workflow deis-workflow-0.1.0.tgz

Helm installs charts into Kubernetes, creating a new release for each installation. And to find new charts, you can search Helm chart repositories. Helm Chart Repository A Repository is the place where charts can be collected and shared. It’s like Perl’s CPAN archive or the Fedora Package Database, but for Kubernetes packages. 1 helm repo add bitnami https://charts.bitnami.com/bitnami $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.

Helm installs resources in the following order: Namespace NetworkPolicy ResourceQuota LimitRange PodSecurityPolicy PodDisruptionBudget ServiceAccount Secret SecretList ConfigMap StorageClass PersistentVolume PersistentVolumeClaim CustomResourceDefinition ClusterRole ClusterRoleList ClusterRoleBinding ClusterRoleBindingList Role RoleList RoleBinding RoleBindingList Service DaemonSet Pod ReplicationController ReplicaSet Deployment HorizontalPodAutoscaler StatefulSet Job CronJob Ingress APIService

https://helm.sh/docs/howto/charts_tips_and_tricks/ Helm uses Go templates for templating your resource files. While Go ships several built-in functions, we have added many others. First, we added all of the functions in the Sprig library, except env and expandenv, for security reasons. We also added two special template functions: include and required. The include function allows you to bring in another template, and then pass the results to other template functions. Using the ‘include’ Function For example, this template snippet includes a template called mytpl, then lowercases the result, then wraps that in double quotes.

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.