Voice of the DBA

Tag: career

  • Learning Kubernetes Security Concepts

    This post continues looking at my process of learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Here I continue on with a few videos on secrets, configuration management and RBAC.

    Secrets

    I am glad that the idea of storing data securely has come to so many applications. Authentication, authorization, privileges, and more are complex and hard to get right. We continually see problems with passwords, certificates, and the link not being managed well.

    Kubernetes has the concept of secrets, which can be values or file contents (like a certificates). These can then be sent or mounted to containers for use.

    One problem, these are stored in the Kubernetes etcd (keyvalue store) in an unencrypted format. Kubernetes has new concepts to integrate into key management areas, like Azure Key Vault, to protect secrets, though Kubernetes privilege controls are still needed.

    A gross simplification, but I learned a little more about what secrets are.

    Configuration Management

    This is interesting to me, because I like abstracting things away. In Kubernetes, we abstract a configuration object as a separate entity, which can then be applied to a container/pod later. This also works through deployments, allowing configurations to be part of the rolling deployment, which can prevent issues.

    If you have good testing/evaluation of what is healthy. This is likely easier than comprehensive unit testing, but still.

    A good idea, just not sure if this is too much.

    RBAC

    I always think of this as row-based, but it’s really role-based, so maybe that should be the way I translate RBAC in my head.

    Like most systems that use RBAC, there is, of course, a role. The video wanders a bit in the explanation, but I’ll try to summarize what I learned. There are two facets to roles. First, these are verb/noun pairs that determine what permission is available for what resource. Like get/list for the verb, and pod, volume, service, etc. for the noun. These are setting up the permission side.

    However, there is another facet. These roles can be set as cluster roles, similar to server roles for SQL Server, or at the namespace level, more like a database role. In either case, you are scoping permissions. Obviously, be careful with cluster roles.

    The other side of this is the user. We can have users or groups used for these roles, similar to what is in SQL Server.

    A simple explanation, but at least I have some idea of the concept.

  • More Kubernetes Concepts

    This post continues looking at my process of learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Now that I had a break from some travel, I went through a few videos in a short period of days. This post combines a few looks at Scenarios, storage, and stateful sets

    Scenarios

    This was a good look at how one of the founders see the Kubernetes being used. The initial idea was microservices, where many services each live in a container and communicate. Managing lots of containers, and lots of instances of each, is where Kubernetes excels.

    The second scenario is the diurnal or cyclical scenario where a load goes up and down each day/night, week/weekend, etc. Having Kubernetes manage the increase and decrease of workload is valuable, and if you’re in the cloud, then you’re not investing heavily in hardware that is unused.

    The third is with complex workflows, where one thing, then another, then another happens. I’m less sold here, but I do see that spin up/spin down, and having these workloads/processes in containers rather than on certain machines makes sense.

    Lastly, AI/ML places where all parts of your flow can access the Kubernetes API and spin things up and down or move workloads to better hardware, like GPU/FPU concentrated systems, that can help keep things moving.

    Good to see the different ways that this might be useful, though I was wondering if I’d see anything database related. I didn’t.

    Volumes and Storage

    The important thing for database workloads is storage. This is a constant question when I talk containers. What about the disks and storage and how does this work.

    This is a basic video, just noting that volumes are objects in K8s. They are attached to pods, but can be mounted (or not) inside containers in the pod. There is temp storage (/emptydir, need to look this one up), but we can also abstract away other storage with Persistent Volume Claims. These are the aspirational storage requirements that the container/pod needs.

    I’m not completely clear on these, and the explanation is a little light, so I’ll have to learn more later.

    Stateful Applications

    The last set of learning for this post. More relevant because SQL is a stateful application. Or so I thought.

    This really looks at stateful sets in Kubernetes, which are the ways in which we want orderly copies in a replica set. This means hostnames and DNS entries in stateful sets are ordered, and 0 based indexed. If I have a host of SalesSQL with 3 sets, I’ll get

    • SalesSQL-0
    • SalesSQL-1
    • SalesSQL-2

    Likewise, I may have salessql.mydomain.com, but I’ll also have the –0, –1, –2 DNS entries as well. The Kubernetes platform also will scale up and down from the end, adding or removing the next ordered element container.

    There can also be volumes associated here, or not, as your stateful application may have the need to use the same volume (like a clustered SQL Server) or separate volumes, like AGs. In any case, it’s a light explanation that I need to know more of.

    One thing I didn’t really like is that the data stores were associated as “cloud native storage applications”, not data stored or data platforms. Application developers I think sometimes forget there’s more to data than storage.

  • Redis University

    As if I don’t have enough to do, I started a data structures class at Redis University. Someone recommended this to me as another way a company has structured learning, so I decided to give it a try. There were some things they liked that we might use as Redgate University.

    I decided to start with the 101 course, since I have a rough idea of what Redis is, but now how it works. The class has a number of videos, with transcripts alongside that teach various concepts. One thing I like is that if I get lost, I can glance at the transcript, click it, and the video jumps back to that point. That’s handy, as life sometimes distracts me.

    The quizzes every video or two are nice, but I wish there was a bit more chance to practice things in the middle. I could certainly grab a Redis VM or container, but I have no real idea of how to access it, and I’d have another project. I would actually suggest some “launch lab” points after each set of videos with some practice tutorials or exercises.

    The class has two weeks, with a few chapters, each of which is about 6-7 videos. I don’t know about you, but that’s a lot in a week. If I could abandon some other things for an hour a night, maybe, but that can be tough to do consecutively. I’d really rather this was a 4 week class, with each of the items listed as a set of learning and practice for one week.

    Overall I learned some interesting things about how Redis works. With the power and speed of this memory based key-value system, I can see why some of our customers are using it. If you are thinking about it, or your app uses it and you want to know more, maybe check out their university.

  • Kubernetes Pipelines

    This post continues looking at some of the Kubernetes concepts I’ve been learning with the 50 days of Kubernetes (K8s). Specifically in this post, I’m writing and thinking about the flow of containers from code to a Kubernetes cluster.

    The video talks about pipelines, which is the way in which you get code running in a Kubernetes cluster. The start looks at the idea that we don’t want arbitrary containers running in the cluster, so we limit access to the cluster to somewhere like a container registry, like Azure Container Registry. This ensures that only those containers loaded into your space get onto the cluster. No pulling from Docker Hub or some arbitrary location.

    However, then we worry about developers loading containers into the registry that haven’t been checked. So, we don’t give them permission, we give it to some CI/CD pipeline, which means any code written by a developer that builds a container has to be checked in.

    Now, we have a pipeline flow that we can control. As Brendon mentioned, this isn’t simple, and really, I think you have a lot of work here before you want to trust things running on a production Kubernetes cluster. Really now you need these in your CI pipeline:

    • Unit tests
    • Vulnerability scanning
    • credential scanning ( I see this from MS for Github repos)
    • every other type of scanning you can do

    In this way, you ensure some quality level in your containers as far as security goes and code working. The big win here, at least for me, is that you can continue to raise the bar by adding more tests and scans, something that’s hard to do for developers without automation.

    Not a lot new here, but certainly the idea of putting access and control into the CI/CD flow makes sense.