Our great sponsors
-
-
Universal-Kubernetes-Helm-Charts
Some universal helm charts used for deploying services onto Kubernetes. All-in-one best-practices
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Packer
Packer is a tool for creating identical machine images for multiple platforms from a single source configuration.
Also learn the "critical" services needed for Kubernetes to be HA/Fault-Tolerant. Services such as (if using AWS): aws-ebs-csi-driver, aws-efs-csi-driver, aws-load-balancer-controller metrics-server, cert-manager, cluster-autoscaler, nginx-ingress (or Traefik/Kong/Ambassador), oauth2-proxy (optional), openvpn (optional), elasticsearch-curator (automatically deletes old logs in Elasticsearch), prometheus, external-dns, fluentd-elasticsearch (cascades all logs into Elasticsearch), gitlab-runner (if using gitlab), github-actions-runner (if using Github Actions, grafana, volume-autoscaler (shamless plug I wrote this).
Start to think about and build "standards" at a company, because you, as a DevOps engineer, need these to succeed and not be the bottleneck for everything. You will engineer and support company-wide standards. With this in place, everyone from any team can easily move to another engineering team and still know how to setup, maintain, deploy, etc everything. For example, I setup and maintain some Gitlab CI Templates that every repo includes to do everything. Having an example repo or two of how to use your build and deploy system is also critical. I've also open sourced my Universal Helm Charts if you're into Kubernetes (you should be) which you can easily fork and set your own compant-wide standards and publish them to your own HTTP host. This sets the foundation and ease-of-adoption company-wide for deploying things. Other standards to try to align on is using the same Git and CI/CD provider (eg: Github / Gitlab), this is often a better experience than external CICD providers (Circle / Travis / Jenkins / etc).
Note: Some might argue that learning something like Puppet or Ansible is needed. However, the way the cloud works nowadays and with virtualization and orchestration (Kubernetes) both of these technologies (Puppet/Ansible) are losing their relevance/usage. Not to mention both of these are fairly convoluted tools with really pedantic naming and folder structures that over-complicates most processes needlessly. I would 100% recommend learning Terraform and something like Packer if you need to generate machine/VM images. You _could_ feed Ansible into packer if you so-desired, but I think this is silly when a simple shell script would do the trick. Ansible and Puppet are more-ideal for static infrastructure, not in a ephemeral world of Kubernetes.