mdrakiburrahman

# Here is a sample set of roles we'd want our SA/User account to have, this can be anything and the kubeconfig will inherit it
kubectl apply -f https://gist.githubusercontent.com/mdrakiburrahman/d94613872601c397f3a052492f168827/raw/a7909c131beb02f45970f2b605178859c6882555/tina-onboarder-rbac.yaml

# = = = = = = = = =
# Create a kubeconfig from this that overwrites our Cluster Admin that we get when we install a new K8s cluster
# = = = = = = = = =

# Service Account is in default but because of ClusterRoleBinding it has Cluster scope
namespace=default
serviceAccount=arc-data-deployer

mdrakiburrahman

apiVersion: v1
data:
  password: YWNudG9yUFJFU1RPIQ==
  username: Ym9vcg==
kind: Secret
metadata:
  name: sql-bc-1-login-secret
  namespace: arc-primary
type: Opaque
---

mdrakiburrahman

# = = = = = = = = = = = = = = = = = = = =
# Verbosity wrapper
# = = = = = = = = = = = = = = = = = = = =
# On
export VERBOSE=1
# Off
unset VERBOSE

# = = = = = = = = = = = = = = = = = = = =
#                                       #

mdrakiburrahman

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-conf
  namespace: azure-arc-data
  labels:
    app: opentelemetry
    component: otel-collector-conf
data:
  otel-collector-config: |

mdrakiburrahman

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-conf
  namespace: azure-arc-data
  labels:
    app: opentelemetry
    component: otel-collector-conf
data:
  otel-collector-config: |

mdrakiburrahman

mdrakiburrahman

mdrakiburrahman

#!/bin/bash -e
################################################################################
##  File:  install.sh
##  Desc:  Helper functions for installing tools
################################################################################

download_with_retries() {
# Due to restrictions of bash functions, positional arguments are used here.
# In case if you using latest argument NAME, you should also set value to all previous parameters.
# Example: download_with_retries $ANDROID_SDK_URL "." "android_sdk.zip"

mdrakiburrahman

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "-1"
  name: single-job-hook-no
---
apiVersion: v1
data:
  password: aGVsbG8K

mdrakiburrahman

The key capability a GitOps tool can provide to declaratively deploy each of our CRDs is health checks. Most Production Grade Gitops tools have the logic necessary to monitor K8s native resources (Pod, Service etc), but also the flexibility to extend to any Custom Resource.

Both Flux V1 and V2 has good support for K8s native resources, which makes it a great tool for the average Arc-enabled Kubernetes Customers deploying K8s components that aren't Customer Resources.

For custom resources, Flux V2 has limited literature, as it offloads that responsibility to kstatus, which makes rigid assumptions about the fields a CR should emit to be considered healthy - a boolean called Ready. Due to there being no standardized pattern for this, many open source