Kubernetes namespaces - they’re an essential feature for building modern cloud architectures. Namespaces let you split up a single cluster into multiple “virtual clusters”. Resources like pods, replicasets, and deployments all live in namespaces. You can think of a namespace as being a resource’s last name - it specifies which family the resource is part of - and normal resources can have one and only one namespace (There are exceptions like the Node resource which is cluster-wide and doesn’t belong to any namespace). If you don’t think you’re using namespaces on your cluster then you’re wrong. You’re actually just putting everything into the default namespace.
Applications and workloads running on Kubernetes environment, just like any application, requires secrets to gain access to data stored in the database, 1st / 3rd party services or APIs.
Secrets, however, are only effective if they actually remain secret. When secrets leak, attackers will be able to gain access to sensitive data, services or APIs and can potentially put your entire environment and business at risk.
Everyone is talking about Kubernetes these days, and it’s no secret that Kubernetes has emerged as the leading container orchestration tool. There are a variety of reasons for that, ranging from Kubernetes’s open source, community-based development model to helpful technical features like pod security policies and automatic load balancing.
If you work with Kubernetes, you’re probably already familiar with basic Kubernetes best practices guides and patterns. But the recent release of Kubernetes v1.14 has introduced some new features, which in turn necessitate new best practices. Most of them center on security and automation, which are top of the list for operations staff, management, and development alike. But there are some others that factor in as well.
If you believe all the marketing hype, then Kubernetes is the silver bullet to make containers so routine that they’re boring, and your infrastructure will have better harmony than any boy band in history. If only this were true.
Main highlights include:
- Support for Windows nodes (graduating from Beta to Stable)
- Several kubectl improvements (updated plugin mechanism, kustomize Integration, new documentation website)
- Persistent Local Volumes, which makes locally attached (non-network attached) storage available as a persistent volume source (graduating to GA)