Minor display docu updates

docs/addons/addons.md

@@ -81,6 +81,7 @@ cluster13 true v1.26.9+rke2r1 env=prod,sveltos-agent=present
 The third step is to create a ClusterProfile Kubernetes resource and apply it to the **management** cluster.
 
 ```yaml
+cat > clusterprofile_kyverno.yaml <<EOF
 apiVersion: config.projectsveltos.io/v1alpha1
 kind: ClusterProfile
 metadata:
@@ -96,10 +97,11 @@ spec:
  releaseName: kyverno-latest
  releaseNamespace: kyverno
  helmChartAction: Install
+EOF
 ```
 
 ```bash
-$ kubectl apply -f "kyverno_cluster_profile.yaml"
+$ kubectl apply -f "clusterprofile_kyverno.yaml"
 
 $ sveltosctl show addons
 

docs/addons/example_flux_sources.md

@@ -50,6 +50,7 @@ spec:
 Define a Sveltos ClusterProfile referencing the flux-system GitRepository and specify the _nginx-ingress_ directory as the source of the deployment.
 
 ```yaml
+cat > clusterprofile_nginx_ingress.yaml <<EOF
 apiVersion: config.projectsveltos.io/v1alpha1
 kind: ClusterProfile
 metadata:
@@ -61,6 +62,7 @@ spec:
  name: flux-system
  namespace: flux-system
  path: nginx-ingress
+EOF
 ```
 
 This ClusterProfile targets clusters with the __env=fv__ label and fetches relevant deployment information from the _nginx-ingress_ directory within the flux-system Git repository managed by Flux.
@@ -112,6 +114,7 @@ spec:
 Define a ClusterProfile to deploy the Kyverno helm chart.
 
 ```yaml
+cat > clusterprofile_kyverno.yaml <<EOF
 apiVersion: config.projectsveltos.io/v1alpha1
 kind: ClusterProfile
 metadata:
@@ -127,13 +130,15 @@ spec:
  releaseName: kyverno-latest
  releaseNamespace: kyverno
  helmChartAction: Install
+EOF
 ```
 
 Define a Sveltos ClusterProfile referencing the flux-system GitRepository and defining the _kyverno__ directory as the source of the deployment.
 
 This directory contains a list of Kyverno ClusterPolicies.
 
 ```yaml
+cat > clusterprofile_kyverno_policies.yaml <<EOF
 apiVersion: config.projectsveltos.io/v1alpha1
 kind: ClusterProfile
 metadata:
@@ -147,6 +152,7 @@ spec:
  path: kyverno
  dependsOn: 
  - deploy-kyverno
+EOF
 ```
 
 This ClusterProfile targets clusters with the __env=fv__ label and fetches relevant deployment information from the _kyverno__ directory within the flux-system Git repository managed by Flux.

docs/addons/raw_yaml.md

@@ -37,6 +37,7 @@ The commands will download the calico.yaml manifest file and afterwards create a
 The YAML definition below exemplifies a ConfigMap that holds multiple resources[^2]. When a ClusterProfile instance references the ConfigMap, a `Namespace` and a `Deployment` instance are automatically deployed in any managed cluster that adheres to the ClusterProfile *clusterSelector*.
 
 ```yaml
+cat > nginx_cm.yaml <<EOF
 apiVersion: v1
 kind: ConfigMap
 metadata:
@@ -69,11 +70,13 @@ data:
  image: nginx:latest # public image from Docker Hub
  ports:
  - containerPort: 80
+EOF
 ```
 
 Once the required Kubernetes resources are created/deployed, the below example represents a ClusterProfile resource that references the ConfigMap and the Secret created above.
 
 ```yaml
+cat > clusterprofile_deploy_nginx.yaml <<EOF
 apiVersion: config.projectsveltos.io/v1alpha1
 kind: ClusterProfile
 metadata:
@@ -87,10 +90,11 @@ spec:
  - name: calico
  namespace: default
  kind: Secret
+EOF
 ```
 
 !!! note
- The `namespace` definition refers to the namespace where the ConfigMap, and the Secret were created in the management cluster. In our example, both resources created in the `default` namespace.
+  The `namespace` definition refers to the namespace where the ConfigMap, and the Secret were created in the management cluster. In our example, both resources created in the `default` namespace.
 
 When a ClusterProfile references a ConfigMap or a Secret, the **kind** and **name** fields are required, while the namespace field is optional. Specifying a namespace uniquely identifies the resource using the tuple namespace, name, and kind, and that resource will be used for all matching clusters.
 

docs/blogs.md

@@ -62,13 +62,11 @@ authors:
 
 ## Support us
 
-{==
+!!! tip ""
+ If you like the project, please <a href="https://github.com/projectsveltos/sveltos-manager" title="Manage Kubernetes add-ons" target="_blank">give us a</a> <a href="https://github.com/projectsveltos/sveltos-manager" title="Manage Kubernetes add-ons" target="_blank" class="heart">:octicons-star-fill-24:</a> if you haven't done so yet. Your support means a lot to us. **Thank you :pray:.**
 
-If you like the project, please [give us a](https://github.com/projectsveltos/sveltos-manager "Kubernetes add-on controller") [:octicons-star-fill-24:{ .heart }](https://github.com/projectsveltos/sveltos-manager "Kubernetes add-on controller") if you haven't done so yet. This will help other people find it and learn more about it.
 
-==}
-
-[:star: projectsveltos](https://github.com/projectsveltos/sveltos-manager "Kubernetes add-on controller"){ .md-button .md-button--primary }
+[:star: projectsveltos](https://github.com/projectsveltos/sveltos-manager "Manage Kubernetes add-ons"){:target="_blank" .md-button}
 
 [![Stargazers repo roster for @projectsveltos/addon-controller](http://reporoster.com/stars/projectsveltos/addon-controller)](https://github.com/projectsveltos/addon-controller/stargazers)
 

docs/deployment_order/depends_on.md

@@ -125,7 +125,8 @@ spec:
 !!! note
  Separate ClusterProfiles promote better organization and maintainability, especially when different teams or individuals manage different ClusterProfiles.
 
-[^1]: To create the ConfigMaps with Kyverno policies used in this example
+
+
 ```
 $ wget https://raw.githubusercontent.com/kyverno/policies/main/best-practices/disallow-latest-tag/disallow-latest-tag.yaml
 
@@ -135,3 +136,4 @@ $ wget https://raw.githubusercontent.com/kyverno/policies/main/other/res/restric
 
 $ kubectl create configmap restrict-wildcard-verbs --from-file restrict-wildcard-verbs.yaml
 ```
+[^1]: To create the ConfigMaps with Kyverno policies used in this example

docs/events/addon_event_deployment.md

@@ -396,7 +396,7 @@ The EventTrigger `OneForEvent` (false by default) field indicates whether to cre
 In the above example, if we create another Service in the managed cluster with the label set to *sveltos: fv*
 
 ```bash
-kubectl get services -A --selector=sveltos=fv 
+$ kubectl get services -A --selector=sveltos=fv 
 NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
 default another-service ClusterIP 10.225.134.41 <none> 443/TCP 24m
 default my-service ClusterIP 10.225.166.113 <none> 80/TCP 52m
@@ -405,7 +405,7 @@ default my-service ClusterIP 10.225.166.113 <none> 80/TCP
 two NetworkPolicies will be created, one per Service.
 
 ```bash
-kubectl get networkpolicy -A
+$ kubectl get networkpolicy -A
 NAMESPACE NAME POD-SELECTOR AGE
 default front-another-service app.kubernetes.io/name=MyApp-secure 8m40s
 default front-my-service app.kubernetes.io/name=MyApp 8m40s
@@ -443,13 +443,13 @@ For more examples, have a look [here](addon_event_deployment.md#yet-another-exam
  Based on the example above, if a Service is deleted, the NetworkPolicy is also removed automatically by Sveltos.
 
 ```bash
-kubectl get services -A --selector=sveltos=fv 
+$ kubectl get services -A --selector=sveltos=fv 
 NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
 default my-service ClusterIP 10.225.166.113 <none> 80/TCP 54m
 ```
 
 ```bash
-kubectl get networkpolicy -A
+$ kubectl get networkpolicy -A
 NAMESPACE NAME POD-SELECTOR AGE
 default front-my-service app.kubernetes.io/name=MyApp 10m40s
 ```

docs/events/example_service_event_trigger.md

@@ -107,7 +107,7 @@ data:
 If we have two Service instance in the managed cluster in the namespace `eng`
 
 ```bash
-kubectl get service -n eng
+$ kubectl get service -n eng
 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
 my-service ClusterIP 10.225.83.46 <none> 80/TCP,443/TCP 15m
 my-service-2 ClusterIP 10.225.108.8 <none> 80/TCP,8443/TCP 14m

docs/features/rolling_upgrade.md

@@ -42,7 +42,7 @@ The __nginx__ ConfigMap contains a Deployment mounting a ConfigMap[^1].
 The above ClusterProfile is responsible for deploying both a ConfigMap instance and a Deployment instance, with the latter mounting a ConfigMap.
 
 ```bash
-& sveltosctl show addons 
+$ sveltosctl show addons 
 +-----------------------------+---------------------------------+-----------+---------------------+---------+-------------------------------+------------------------------+
 | CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | CLUSTER PROFILES |
 +-----------------------------+---------------------------------+-----------+---------------------+---------+-------------------------------+------------------------------+

docs/features/set.md

@@ -43,7 +43,7 @@ This scenario demonstrates active/passive failover with a ClusterSet.
 We have two Civo clusters registered with Sveltos, all labeled `env:prod`.
 
 ```
-kubectl get sveltoscluster -A --show-labels
+$ kubectl get sveltoscluster -A --show-labels
 NAMESPACE NAME READY VERSION LABELS
 civo cluster1 true v1.29.2+k3s1 env=prod
 civo cluster2 true v1.28.7+k3s1 env=prod
@@ -141,7 +141,7 @@ status:
 ```
 
 ```
-sveltosctl show addons 
+$ sveltosctl show addons 
 +---------------+---------------+-----------+----------------+---------+-------------------------------+------------------------+
 | CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | PROFILES |
 +---------------+---------------+-----------+----------------+---------+-------------------------------+------------------------+
@@ -158,7 +158,7 @@ In this example, __cluster2__ was deleted.
 Sveltos detected that and marked the cluster as not ready
 
 ```
-kubectl get sveltoscluster -A
+$ kubectl get sveltoscluster -A
 NAMESPACE NAME READY VERSION
 civo cluster1 true v1.29.2+k3s1
 civo cluster2 v1.28.7+k3s1
@@ -218,7 +218,7 @@ status:
 ```
 
 ```
-sveltosctl show addons 
+$ sveltosctl show addons 
 +---------------+---------------+-----------+----------------+---------+-------------------------------+------------------------+
 | CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | PROFILES |
 +---------------+---------------+-----------+----------------+---------+-------------------------------+------------------------+

docs/getting_started/install/quick_start.md

@@ -34,6 +34,7 @@ To deploy the Kyverno Helm chart in any Kubernetes cluster with labels _env: fv_
 
 !!! example "Example - Helm Chart"
  ```yaml
+ cat > clusterprofile_kyverno.yaml <<EOF
  apiVersion: config.projectsveltos.io/v1alpha1
  kind: ClusterProfile
  metadata:
@@ -49,6 +50,7 @@ To deploy the Kyverno Helm chart in any Kubernetes cluster with labels _env: fv_
  releaseName: kyverno-latest
  releaseNamespace: kyverno
  helmChartAction: Install
+ EOF
  ```
 
 ## Deploy Raw YAMl/JSON
@@ -79,6 +81,7 @@ To deploy all these resources in any cluster with labels *env: fv*, create a Clu
 
 !!! example "Example - Raw Yaml/Json"
  ```yaml
+ cat > clusterprofile_gateway.yaml <<EOF
  apiVersion: config.projectsveltos.io/v1alpha1
  kind: ClusterProfile
  metadata:
@@ -90,6 +93,7 @@ To deploy all these resources in any cluster with labels *env: fv*, create a Clu
  - name: contour-gateway-provisioner-secret
  namespace: default
  kind: Secret
+ EOF
  ```
 
 ## Deploy Resources Assembled with Kustomize
@@ -98,6 +102,7 @@ Sveltos can work along with Flux to deploy content of Kustomize directories.
 
 !!! example "Example - Kustomize"
  ```yaml
+ cat > clusterprofile_flux.yaml <<EOF
  apiVersion: config.projectsveltos.io/v1alpha1
  kind: ClusterProfile
  metadata:
@@ -111,6 +116,7 @@ Sveltos can work along with Flux to deploy content of Kustomize directories.
  kind: GitRepository
  path: ./helloWorld/
  targetNamespace: eng
+ EOF
  ```
 
 Full examples can be found [here](../../addons/kustomize.md).

docs/getting_started/sveltosctl/techsupport.md

@@ -30,6 +30,7 @@ Techsupport CRD is used to configure Sveltos to periodically collect tech suppor
 
 !!! example "Example 1"
  ```yaml
+ cat > techsupport.yaml <<EOF
  apiVersion: utils.projectsveltos.io/v1alpha1
  kind: Techsupport
  metadata:
@@ -48,6 +49,7 @@ Techsupport CRD is used to configure Sveltos to periodically collect tech suppor
  - group: ""
  version: v1
  kind: Secret
+ EOF
  ```
 
 The above YAML Techsupport definition instructs Sveltos to:
@@ -60,6 +62,7 @@ The __Techsupport__ CRD allows filtering pods and resources using the label and
 
 !!! example "Example 2"
  ```yaml
+ cat > techsupport_advanced.yaml <<EOF
  apiVersion: utils.projectsveltos.io/v1alpha1
  kind: Techsupport
  metadata:
@@ -101,6 +104,7 @@ The __Techsupport__ CRD allows filtering pods and resources using the label and
  operation: Different
  value: eng
  namespace: default
+ EOF
  ```
 
 - *schedule* field specifies when a tech-support needs to be collected. It is [Cron format](https://en.wikipedia.org/wiki/Cron).

docs/help_and_tutorials/troubleshooting.md

@@ -195,11 +195,11 @@ $ kubectl get clustersummary,clusterprofile -A
 Even if the Kubernetes add-ons are not deployed, both resources will be available to the management cluster.
 
 ```bash
-$ k get clusterprofile <clusterprofile name> -n <clusterprofile namespace> -o jsonpath='{.status}'
+$ kubectl get clusterprofile <clusterprofile name> -n <clusterprofile namespace> -o jsonpath='{.status}'
 ```
 
 ```bash
-$ k get clustersummary <clustersummary name> -n <clustersummary namespace> -o jsonpath='{.status}'
+$ kubectl get clustersummary <clustersummary name> -n <clustersummary namespace> -o jsonpath='{.status}'
 ```
 
 We are here to help! Whether you have questions, or issues or need assistance, our Slack channel is the perfect place for you. Click [here](https://app.slack.com/client/T0471SNT5CZ/C06UZCXQLGP) to join us.

docs/observability/display_resources.md

@@ -392,6 +392,7 @@ To deploy Kyverno and a ClusterPolicy in each managed cluster matching the label
 - The ConfigMap contains [this](https://kyverno.io/policies/best-practices/disallow-latest-tag/disallow-latest-tag/) Kyverno ClusterPolicy.
 
  ```bash
- $ wget https://github.com/kyverno/policies/raw/main//best-practices/disallow-latest-tag/disallow-latest-tag.yaml
- $ kubectl create configmap kyverno-latest --from-file disallow-latest-tag.yaml
+ wget https://github.com/kyverno/policies/raw/main//best-practices/disallow-latest-tag/disallow-latest-tag.yaml
+
+ kubectl create configmap kyverno-latest --from-file disallow-latest-tag.yaml
  ```