DEV Community: Farshad Nickfetrat

Policy Management in Kubernetes with Kyverno

Farshad Nickfetrat — Sat, 08 Feb 2025 10:37:50 +0000

Policy management in Kubernetes means setting rules to control how resources are used, who can access them, and how workloads behave. This helps improve security, compliance, and stability in a cluster.
Why is Policy Management important?

Security: Prevents unauthorized access and enforces best practices.
Compliance: Ensures the system follows company and legal rules.
Stability: Avoids resource misuse and keeps the cluster healthy.

Tools like Kyverno and OPA Gatekeeper help enforce policies automatically.

Let’s Get started
What is the scenario ?

We want every Pod to have an app label. If not, Kyverno should block it.
1- First Step : Install Keyverno

You can install it via manifest or helm

helm installation :

helm repo add kyverno https://kyverno.github.io/kyverno/ helm repo update helm install kyverno kyverno/kyverno -n kyverno --create-namespace

Manifest installation :

kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.11.1/install.yaml

1–1 Install Keyverno CLI

Linux :

curl -LO https://github.com/kyverno/kyverno/releases/download/v1.12.0/kyverno-cli_v1.12.0_linux_x86_64.tar.gz
tar -xvf kyverno-cli_v1.12.0_linux_x86_64.tar.gz
sudo cp kyverno /usr/local/bin/

Mac :

brew install kyverno

arch Linux

yay -S kyverno-git

2- Define a Policy

The validationFailureAction field in Kyverno determines how the policy behaves when a resource violates the defined rules. There are two main modes:

We want every Pod to have an app label. If not, Kyverno should block it.

#policy.yml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-app-label
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-for-app-label
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "All Pods must have the 'app' label."
      pattern:
        metadata:
          labels:
            app: "?*"

kubectl apply -f policy.yml

validation Failure Action :

Audit (default): Testing new policies, monitoring violations, gradual enforcement.

Enforce : Strict security requirements, compliance enforcement, critical policies.
2- Create a pod without label

#pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: nginx
    image: nginx

kubectl apply -f pod.yml

the result would be something like that
3- Verifying Your Policy

we can test the policy by :

kyverno apply policy.yml --resource pod.yml

policy.yml → Your Kyverno policy (e.g., enforcing labels).
pod.yml → Your Kubernetes resource (e.g., a Pod you want to test).

OPA Gatekeeper is another policy management tool that I wrote an article about. You can access it through the link below:
Enforcing Kubernetes Policies with Gatekeeper: A Practical Scenario for Denying NodeName in Pods
Gatekeeper is a Kubernetes-native policy enforcement tool that integrates with the Open Policy Agent (OPA) to provide…

About Author :
Hi 👋, I’m Farshad Nick (Farshad nickfetrat)
A passionate Devops Engineer

📝 I regularly write articles on packops.dev and packops.ir
💬 Ask me about Devops , Cloud , Kubernetes , Linux
📫 How to reach me on my linkedin

Enhancing Kubernetes Networking: The Advantages of IPVS Over iptables

Farshad Nickfetrat — Sat, 02 Nov 2024 08:48:37 +0000

Hey there, If you’re diving into the world of container orchestration, you know that managing how your services talk to each other is crucial. Traditionally, Kubernetes has leaned on iptables for handling service load balancing. But guess what? There’s a cool kid in town: IPVS (IP Virtual Server). Let’s take a look at why you might want to consider IPVS over iptables for your Kubernetes setup.

Better Load Balancing

First off, IPVS is a superstar when it comes to distributing incoming traffic. It supports a bunch of scheduling options—like round-robin and least connections—so you can pick what works best for your app. Plus, it can keep sessions sticky, meaning users stick to the same backend server for their requests. This is super handy for apps that need to remember user state!
IPVS Supported Load balancing Algorithm

When you’re using IPVS for load balancing in Kubernetes, you have some cool options for how traffic gets distributed to your backend servers. Here’s a quick rundown of the main scheduling algorithms you might encounter:

rr: round-robin

lc: least connection

dh: destination hashing

sh: source hashing

sed: shortest expected delay

nq: never queue

Performance That Rocks

If you’re running a high-traffic application, IPVS is the way to go. It handles way more connections than iptables with lower latency, which means faster response times for your users. With its efficient connection management, IPVS keeps things running smoothly, even when the traffic spikes.

Health Checks Like a Pro

We all want our apps to be reliable, right? IPVS has built-in health checks that keep an eye on your backend pods. If one of them goes down, IPVS automatically takes it out of the rotation, so your users don’t hit a dead end. This helps keep everything up and running without a hitch!

Smart Resource Usage

By spreading the traffic around efficiently, IPVS helps make the most of your resources. This means your pods won’t get overloaded while others are sitting around doing nothing. It leads to a more stable and efficient setup overall.

Easier to Configure

Let’s face it—network configurations can get messy. IPVS makes it easier to set things up. You can define virtual servers and their backend services in a straightforward way, making it simpler to tweak things as your application needs change.

Smooth Integration with kube-proxy

Kubernetes has built-in support for IPVS as a mode for kube-proxy, so you can take advantage of all its features without overhauling your setup. It’s like getting a performance boost without the hassle!

Better Debugging and Monitoring

With IPVS, you get detailed metrics and stats about how your load balancing is performing. This means you can keep an eye on traffic patterns and server health, making it easier to spot issues before they become problems.

Wrapping It Up

While iptables has been a solid tool for networking in Kubernetes, IPVS brings a lot to the table that can seriously enhance your app’s performance and reliability. As you scale up your Kubernetes deployments, switching to IPVS for load balancing is a smart move that can lead to better resource management and happier users. So why not give it a shot? Your Kubernetes setup might just thank you!

I'm going to show you how IPVS works by walking through a comprehensive scenario in the next article.

Soooo, stay tuned!

Learn Kubernetes by Example

https://github.com/farshadnick/Mastering-Kubernetes/

Don’t Forget to Give me a Star :)

About Author :
Hi 👋, I’m Farshad Nick (Farshad nickfetrat)

📝 I regularly write articles on packops.dev and packops.ir

💬 Ask me about Devops , Cloud , Kubernetes , Linux

📫 How to reach me on my linkedin

Here is my Github repo

iptables vs nftables: What’s New in Linux Firewalling?

Farshad Nickfetrat — Wed, 09 Oct 2024 11:10:36 +0000

When it comes to managing firewall rules on Linux, iptables has been the go-to tool for years. But now, there’s a new sheriff in town: nftables. It’s more efficient, more flexible, and it’s slowly becoming the default for modern Linux distributions. If you're wondering what the fuss is all about, let's dive into the differences between these two and see how they compare in real-world scenarios.

A Quick Overview

iptables has been around since the early 2000s. It’s tried and true, but it’s also starting to show its age, especially when dealing with large, complex firewall configurations. Enter nftables, a more modern alternative introduced in 2014. nftables was designed to address many of the limitations of iptables, bringing better performance and more flexible rule management.

At a high level:

iptables: Solid, but separate tools for IPv4, IPv6, and ARP filtering, and it can get messy with large rule sets.

nftables: Unified syntax for all protocols (IPv4, IPv6, ARP, and more) and supports more efficient handling of complex rules.

Now let’s compare them in action!

Basic Syntax: Blocking Traffic on Port 22 (SSH)

Say you want to block incoming SSH connections on port 22. Here’s how you’d do it in each:

iptables:
```
iptables -A INPUT -p tcp --dport 22 -j DROP
```
Pretty straightforward! This command adds a rule to block incoming TCP traffic on port 22.
nftables:
```
nft add rule inet filter input tcp dport 22 drop
```
In nftables, it’s just as simple, but notice the keyword inet. It’s a unified table for both IPv4 and IPv6 traffic, so you don’t need separate rules like you would with iptables.

Allowing Traffic from a Specific IP Range

Next, let’s allow traffic from a certain subnet, like 192.168.1.0/24.

iptables:
```
iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT
```
Here, we append a rule to allow traffic from the subnet.
nftables:
```
nft add rule inet filter input ip saddr 192.168.1.0/24 accept
```
Notice that nftables uses ip saddr (source address), which is more descriptive and works for both IPv4 and IPv6.

Dealing with NAT (Network Address Translation)

If you’re setting up source NAT (SNAT) for outbound traffic, the commands look a bit different.

iptables:


iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 203.0.113.5

This is your classic iptables rule for source NAT on the eth0 interface.

nftables:
```
nft add rule ip nat postrouting oif "eth0" snat to 203.0.113.5
```
nftables syntax is cleaner here, using oif for the output interface and snat for source NAT. No need for -t nat because nftables handles everything within the same framework.

Handling Multiple IPs or Ports with Ease

Here’s where nftables really starts to shine. Let’s say you want to block traffic from multiple IP addresses.

iptables:
```
iptables -A INPUT -s 192.168.1.10 -j DROP

iptables -A INPUT -s 192.168.1.20 -j DROP
```
Each IP requires a separate rule in iptables. Imagine if you had 100 IPs to block. Your rule set would get really long!

nftables:


nft add set inet filter blocked_ips { type ipv4_addr\; }

nft add element inet filter blocked_ips { 192.168.1.10, 192.168.1.20 }

nft add rule inet filter input ip saddr @blocked_ips drop

nftables lets you create a set of blocked IPs and apply the rule to all of them in one go. Way more efficient, right?

Logging Packets for Debugging

When debugging network traffic, logging is super helpful. Here’s how you log traffic on port 80 (HTTP).

iptables:


iptables -A INPUT -p tcp --dport 80 -j LOG --log-prefix "HTTP Traffic: "

nftables:


nft add rule inet filter input tcp dport 80 log prefix "HTTP Traffic: "

nftables has the same functionality but with slightly cleaner syntax. Plus, nftables offers more advanced logging options, like counters and limits, making it easier to control log volume.

Efficiency & Performance

If you're dealing with a large number of firewall rules or complex traffic filtering, nftables blows iptables out of the water in terms of efficiency. nftables is designed to handle maps, sets, and stateful traffic with less CPU usage, so you’ll notice better performance, especially in high-traffic environments.

iptables processes rules in a linear fashion, so as your rule set grows, performance can drop.
nftables uses optimized data structures (like sets and maps) to handle rules more efficiently.

Atomic Rule Changes

One of nftables’ killer features is the ability to make atomic rule updates. This means you can load a whole new set of rules without any downtime or partial rule application.

With iptables, you have to update rules one by one, which could lead to mistakes or even security gaps if you’re not careful.

With nftables, you can write your rules into a file and apply them all at once:


nft -f /etc/nftables.conf

This way, your firewall rules are always consistent, and you avoid the risk of misconfigurations during updates.

Backward Compatibility

The good news is, nftables can support iptables rules through a compatibility layer. So, if you’ve been using iptables for years and don’t want to completely rewrite your firewall rules, you can transition to nftables gradually. Just keep in mind that as Linux continues to evolve, nftables will be the default, so it's worth learning it now.

Conclusion: Should You Switch to nftables?

If you’re managing a modern Linux system and want better performance, flexibility, and a cleaner syntax, nftables is definitely the way to go. It handles complex rule sets more efficiently, offers atomic rule updates, and provides a unified interface for IPv4, IPv6, and other protocols. Plus, it’s the future of Linux firewall management.

That said, iptables still works, and if you’ve got a simple setup or a legacy system, it’s perfectly fine to keep using it. But if you’re scaling up or managing complex environments, making the switch to nftables will save you a lot of time and headaches.

So, what do you think? Ready to give nftables a shot?

Why must a Kubernetes cluster have an odd number of nodes

Farshad Nickfetrat — Sun, 22 Sep 2024 10:41:27 +0000

If you’ve spent any time setting up or managing Kubernetes, you might have come across the recommendation that clusters should have an odd number of nodes. But why is that? Let's break it down in simple terms.
It's All About Leader Election

Kubernetes relies on ETCD and ETCD uses RAFT Algorithm that is a consensus algorithm (Paxos)
What is RAFT consensus

RAFT is a consensus algorithm used to ensure multiple computers (or nodes) agree on shared data, even if some nodes fail. It's designed to be easier to understand than other algorithms like Paxos.

RAFT ensures that distributed systems like etcd (used by Kubernetes) can agree on a single leader and maintain consistency, even when some nodes fail. Raft is designed to be understandable.

Imagine a group of people trying to agree on a decision (like which movie to watch). RAFT works by choosing one person as the leader, who suggests a movie (or decision). The others (followers) can agree with the leader or ask for changes. If the leader goes away (fails), the group elects a new leader. As long as a majority agree, the group can keep making decisions, even if some people (nodes) aren't available.

Take a look at these examples :

4-Node System

Total Nodes: 4Quorum Required: 3Allowed Failed Nodes: 1

Quorum Required: To maintain consensus in this 4-node system, a majority (3 nodes) must be operational.
Allowed Failed Nodes: This system can tolerate the failure of only 1 node. If 2 nodes go down, the system loses quorum and cannot make decisions.
Scenario: If 3 nodes are up and 1 is down, the system can still function. If 2 nodes go down, the system cannot process any new transactions until at least 3 nodes are up again.

9-Node System

Total Nodes: 9Quorum Required: 5Allowed Failed Nodes: 4

Quorum Required: In this 9-node system, at least 5 nodes (more than half) must be up and running to reach a consensus.

Allowed Failed Nodes: This system can tolerate up to 4 node failures while still maintaining quorum.
Scenario: If 4 nodes fail, the remaining 5 nodes can continue to operate and maintain consensus. However, if a 5th node fails, the system loses quorum and can no longer process updates or transactions.

10-Node System

Total Nodes: 10Quorum Required: 6Allowed Failed Nodes: 4

Quorum Required: In a 10-node system, at least 6 nodes must be operational to maintain consensus.
Allowed Failed Nodes: This system can tolerate the failure of up to 4 nodes. If 5 nodes go down, the system loses quorum.

Scenario: If 6 nodes are operational, the system can process transactions and make decisions. However, if 5 nodes are down, the system becomes inoperable because there are not enough nodes to reach quorum.

11-Node System

Total Nodes: 11Quorum Required: 6Allowed Failed Nodes: 5
Explanation:

Quorum Required: For an 11-node system, a minimum of 6 nodes need to be up to form a quorum.
Allowed Failed Nodes: This system can tolerate up to 5 node failures. If 6 nodes fail, quorum is lost.
Scenario: With 6 nodes operational, the system can still reach consensus and process transactions. However, if the 6th node fails, the system is effectively halted since it no longer has a quorum to make decisions.

Conclusion

By increasing the number of control plane nodes, you raise the failure tolerance of the cluster. However, it's crucial to have an odd number of nodes to simplify quorum (majority) calculations and avoid split-brain scenarios. This ensures the cluster can make decisions efficiently and remain stable even during failures.

About Author :
Hi 👋, I’m Farshad Nick (Farshad nickfetrat)

📝 I regularly write articles on packops.dev and packops.ir
💬 Ask me about Devops , Cloud , Kubernetes , Linux
📫 How to reach me on my linkedin
Here is my Github repo

Understanding Pod Topology Spread Constraints in Kubernetes

Farshad Nickfetrat — Thu, 19 Sep 2024 15:49:23 +0000

When you're running a Kubernetes cluster, it's critical to ensure your Pods are evenly distributed across different parts of your infrastructure, especially for high availability and fault tolerance. You don’t want all your Pods landing on a single node or in one availability zone. If that resource fails, your application could go down. This is where Pod Topology Spread Constraints come into play.

In this guide, we'll walk through what Pod Topology Spread Constraints are, how they work, and we'll explore a real-world example with a maxSkew of 2.
What Are Pod Topology Spread Constraints?

Pod Topology Spread Constraints allow you to control how Pods are distributed across various topology domains within your cluster. A topology domain could be anything from nodes to zones or regions, depending on your cluster setup. These constraints help ensure that Pods are not overly concentrated in a single domain, which would expose you to higher risk in case of a failure.

Essentially, it’s a way of telling Kubernetes: "Don't put all my Pods in one place. Spread them out!" By doing so, you improve the resiliency of your application.
Key Parameters Explained

topologyKey: This parameter defines what domain you want your Pods to be spread across. It could be zones (topology.kubernetes.io/zone), nodes, or even custom labels, depending on your infrastructure needs.

maxSkew: This parameter controls the allowed imbalance between topology domains. For instance, if you set maxSkew: 2, the difference in the number of Pods between any two domains should not be more than 2. It gives you some flexibility in distribution while still ensuring a reasonable balance.

whenUnsatisfiable: Defines what Kubernetes should do when it can’t satisfy the Pod distribution rules. There are two options:

labelSelector: Specifies which Pods the constraint applies to. Usually, you'll want this to match specific labels like app: my-app so that only a subset of Pods is affected.

Practical Example:

apiVersion: apps/v1 kind: Deployment metadata: name: web-app-deployment spec: replicas: 12 selector: matchLabels: app: web-app template: metadata: labels: app: web-app spec: containers: - name: web-app image: nginx:1.21.1 topologySpreadConstraints: - maxSkew: 2 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: web-app

What’s Going On Here?

maxSkew: 2: This ensures that the difference in the number of Pods between any two zones will be at most 2. For example, if there are 5 Pods in zone-a, the other zones can have anywhere from 3 to 5 Pods.

topology.kubernetes.io/zone: This tells Kubernetes to distribute the Pods across different availability zones (e.g., zone-a, zone-b, zone-c).

whenUnsatisfiable: DoNotSchedule: If Kubernetes can’t maintain the desired balance, it will stop scheduling Pods in the zones that would exceed the skew constraint. This prevents overloading any one zone at the expense of others.

How Kubernetes Distributes Pods

Let’s assume your cluster has three zones with enough capacity to run your Pods. Given 12 replicas and a maxSkew of 2, Kubernetes will attempt to distribute the Pods evenly. An ideal distribution would look something like:

zone-a: 4 Pods

zone-b: 4 Pods

zone-c: 4 Pods

and it also could be something like this :

zone-a: 6 Pods

zone-b: 4 Pods

zone-c: 2 Pods

This is a perfectly balanced scenario. But, with maxSkew: 2, Kubernetes has some leeway if things aren't perfect. For example:

zone-a: 5 Pods

zone-b: 4 Pods

zone-c: 3 Pods

Here, the difference between any two zones doesn’t exceed 2 Pods, so the constraint is still respected.
Handling Failures or Imbalances

Let’s say zone-a has no available capacity. In this case, Kubernetes will still try to adhere to the maxSkew: 2 constraint. If you have 12 Pods to distribute and zone-a is unavailable, Kubernetes might distribute them like this:

zone-a: 0 Pods

zone-b: 6 Pods

zone-c: 6 Pods

This scenario breaks the maxSkew: 2 rule because the difference between zone-a (0 Pods) and zone-b/zone-c (6 Pods) is 6, which exceeds the allowed imbalance. Since we set whenUnsatisfiable: DoNotSchedule, Kubernetes will refuse to schedule new Pods in zone-b or zone-c until capacity becomes available in zone-a. This way, the constraint is respected, and your application maintains resilience by avoiding overloading a single zone.
Why Use Pod Topology Spread Constraints?

Here are a few reasons you should consider using Pod Topology Spread Constraints:

Improved Availability: By spreading Pods across zones or nodes, you reduce the risk of downtime if one part of your infrastructure fails.

Fault Tolerance: Even in the event of a failure in one zone or node, your application can continue running in other zones.

Custom Control with maxSkew: You can fine-tune the balance between flexibility and strictness. A smaller maxSkew ensures tighter distribution control, while a larger value gives Kubernetes more room to optimize placement.

Conclusion

Pod Topology Spread Constraints are a powerful way to control how your Pods are distributed in a Kubernetes cluster. By spreading your Pods across zones or nodes and setting a reasonable maxSkew, you can ensure higher availability and fault tolerance.

In our example, a maxSkew of 2 allowed for a slight imbalance while still ensuring that no zone had an overloaded number of Pods. This approach ensures that your application stays resilient, even in less-than-perfect infrastructure conditions.

Improve Your Kubernetes Knowledge with my CKA Git repo :

Don't Forget to Give me a Star :)

https://github.com/farshadnick/Mastering-Kubernetes/

About Author :
Hi 👋, I’m Farshad Nick (Farshad nickfetrat)

📝 I regularly write articles on packops.dev and packops.ir

💬 Ask me about Devops , Cloud , Kubernetes , Linux

📫 How to reach me on my linkedin

Here is my Github repo

Kubescape : Comprehensive Kubernetes Security from Development to Runtime

Farshad Nickfetrat — Mon, 16 Sep 2024 10:48:35 +0000

Kubernetes is amazing for managing containers, but keeping it secure can be tricky. That's where Kubescape comes in—a super handy, open-source security tool for Kubernetes clusters. It helps you lock down your system from development all the way through runtime, making sure your cluster stays secure at every stage.

Here’s the quick rundown:

Cluster Hardening : Kubescape checks your cluster’s setup and flags potential vulnerabilities, following industry standards like the CIS benchmarks.

Posture Management : It continuously monitors your cluster’s security posture, letting you know if anything needs attention.

Runtime Security : Kubescape also keeps an eye on things when your system is live, catching any weird behavior or misconfigurations that could lead to security issues.

It’s perfect for developers and security teams who want to integrate security checks early in the development process and keep monitoring once the cluster is up and running. Plus, since it’s open-source, it’s flexible, accessible, and free!

In short, Kubescape is like having a security guard for your Kubernetes cluster, from start to finish. Easy to use, reliable, and it makes sure your cluster stays safe.
Installation

curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

Take look at some example:

Scan a running Kubernetes cluster:
kubescape scan

Scan NSA framework

Scan a running Kubernetes cluster with the NSA framework:

kubescape scan framework nsa

Scan MITRE framework

Scan a running Kubernetes cluster with the MITRE ATT&CK® framework:

kubescape scan framework mitre

Scan specific namespaces:

kubescape scan --include-namespaces development,staging,production

Scan local YAML files

kubescape scan /path/to/directory-or-directory

Take a look at the example.
Scan git repository

Scan Kubernetes manifest files from a Git repository:

kubescape scan https://github.com/kubescape/kubescape

Conclusion

Kubescape offers a powerful and user-friendly way to safeguard your Kubernetes clusters from development to runtime. With features like compliance auditing, hardening recommendations, and continuous monitoring, it fills a crucial need in Kubernetes security. For teams looking to integrate security seamlessly across their workflows, Kubescape is an essential tool in their DevSecOps pipeline.

About Author :
Hi 👋, I’m Farshad Nick (Farshad nickfetrat)

📝 I regularly write articles on packops.dev and packops.ir
💬 Ask me about Devops , Cloud , Kubernetes , Linux
📫 How to reach me on my linkedin
Here is my Github repo

Cleaning Up Kubernetes: A Guide to Finding Unused Resources with Kor

Farshad Nickfetrat — Tue, 10 Sep 2024 12:16:07 +0000

If you’ve been running Kubernetes for a while, you probably know how messy things can get. When applications come and go, they often leave behind unused or forgotten resources. These “orphans” don’t serve any purpose but still sit there, wasting space and potentially even costing you money. That’s where Kor - Kubernetes Orphaned Resources Finder comes in!

What Exactly Is Kor?

Kor is a tool designed to help you find and clean up those orphaned resources in your Kubernetes cluster. Think of it like a janitor that keeps your Kubernetes environment tidy by identifying and removing stuff you no longer need — like old PVCs (Persistent Volume Claims), ConfigMaps, Secrets, or even abandoned Services.

If you're running a busy Kubernetes cluster with tons of deployments, chances are you've got a bunch of orphaned resources sitting around. And here’s the kicker: they can actually slow down your cluster or eat up valuable resources. Kor solves that problem by tracking down those leftovers and helping you decide what to keep or toss.
Why You Need Kor

Managing Kubernetes resources can get tricky, especially when things aren’t cleaned up properly. Here’s why Kor can make your life easier:

Efficient Resource Management: Orphaned resources can clog up your cluster. Kor helps you find and get rid of them, freeing up space and resources for the stuff that actually matters.

Cost Savings: Depending on your cloud provider, orphaned resources can cost you. Things like unused volumes or IP addresses can add up in cost over time. Kor can help you avoid these hidden charges by cleaning up the mess.

Cluster Hygiene: Keeping a cluster clean and organized is key to maintaining performance. With Kor, you reduce the chances of having an overly cluttered cluster that’s harder to manage and debug.

How Kor Works

Kor operates by scanning your Kubernetes cluster and identifying any resources that no longer have any dependent objects. For example, if a PVC is sitting there without a Pod or Deployment using it, Kor will flag it as orphaned. Similarly, ConfigMaps or Secrets that no longer have references can be identified.

Kor provides a report of these resources and gives you options to remove them. It’s simple, lightweight, and efficient!
What Resources Can Kor Find?

Kor is designed to find a variety of orphaned resources, including:

Persistent Volume Claims (PVCs): Old storage volumes that are no longer being used.

ConfigMaps: Configuration files that are no longer tied to active services.

Secrets: Credentials and keys left behind after services or pods are deleted.

Services: Networking endpoints that aren’t in use anymore.

How to Get Started with Kor

Kor is easy to set up and integrate with your Kubernetes environment. Once you’ve installed it, you can run it as a CronJob or a one-time scan, depending on how frequently you want to clean up.

You’ll get a detailed list of orphaned resources, and you can either manually review them or set up automated cleanups to make sure your cluster stays neat and tidy.

*Installation : *

For macOS users :

brew install kor

Install the binary to your $GOBIN or $GOPATH/bin:

go install github.com/yonahd/kor@latest

Kubectl plugin

kubectl krew install kor

Kor provides various subcommands to identify and list unused resources. The available commands are:

all - Gets all unused resources for the specified namespace or all namespaces.

configmap - Gets unused ConfigMaps for the specified namespace or all namespaces.

secret - Gets unused Secrets for the specified namespace or all namespaces.

service - Gets unused Services for the specified namespace or all namespaces.

serviceaccount - Gets unused ServiceAccounts for the specified namespace or all namespaces.

deployment - Gets unused Deployments for the specified namespace or all namespaces.

statefulset - Gets unused StatefulSets for the specified namespace or all namespaces.

role - Gets unused Roles for the specified namespace or all namespaces.

clusterrole - Gets unused ClusterRoles for the specified namespace or all namespaces (namespace refers to RoleBinding).

hpa - Gets unused HPAs for the specified namespace or all namespaces.

pod - Gets unused Pods for the specified namespace or all namespaces.

pvc - Gets unused PVCs for the specified namespace or all namespaces.

pv - Gets unused PVs in the cluster (non namespaced resource).

storageclass - Gets unused StorageClasses in the cluster (non namespaced resource).

ingress - Gets unused Ingresses for the specified namespace or all namespaces.

pdb - Gets unused PDBs for the specified namespace or all namespaces.

crd - Gets unused CRDs in the cluster (non namespaced resource).

job - Gets unused jobs for the specified namespace or all namespaces.

replicaset - Gets unused replicaSets for the specified namespace or all namespaces.

daemonset- Gets unused DaemonSets for the specified namespace or all namespaces.

finalizer - Gets unused pending deletion resources for the specified namespace or all namespaces.

networkpolicy - Gets unused NetworkPolicies for the specified namespace or all namespaces.

exporter - Export Prometheus metrics.

version - Print kor version information.

in this scenario i want to list all unused resources in default namespace

kor all -n default --show-reason

And here is the result

About Author :
Hi 👋, I’m Farshad Nick (Farshad nickfetrat)

📝 I regularly write articles on packops.dev and packops.ir

💬 Ask me about Devops , Cloud , Kubernetes , Linux

📫 How to reach me on my linkedin

Here is my Github repo

Centralized Package Caching for Linux: Mastering Apt-Cacher for Faster Updates

Farshad Nickfetrat — Sun, 08 Sep 2024 08:51:22 +0000

Introduction

APT-Cache-ng is a Life Saver for Situation which you do not want to Give Internet to Your Ubuntu Servers for Updating Packages

apt cacher is a caching proxy for Debian based distributions that creates a local cache of Debian-based mirrors as well as other Linux distributions. This means that whenever a package is pulled from the official repositories, an APT cache server caches them such that if any other local machine would want to install the same package, it just pulls it from the local caching server. This helps eliminates the bottlenecks of slow internet connections.

Apt-Cacher NG has been designed from scratch as a replacement for apt-cacher, but with a focus on maximizing throughput with low system resource requirements. It can also be used as replacement for apt-proxy and approx with no need to modify clients’ sources.list files.

In This Article we want to implement APT-Cacher NG
Configuration

Install with Package

1- Easily you can install APT-Cacher-ng by run Following Command :

apt-get install apt-cacher-ng

2- Enable APT cacher in Startup by doing :

systemctl enable apt-cacher-ng

Install with Docker

1- Update apt repository and install APT-Transport which allows us to add new repository easily

sudo apt-get update sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg \ lsb-release
2- Add Official Docker ‘s GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

3- Add Docker Repository

echo \ "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

4- Install Docker-Ce

sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io

5- Install Docker-compose for Bringing Apt-cacher-ng Container up

sudo chmod +x /usr/local/bin/docker-compose

6- Make a docker-compose.yml and Paste following Parameter :

--- version: '3' services: apt-cacher-ng: image: sameersbn/apt-cacher-ng container_name: apt-cacher-ng ports: - "3142:3142" volumes: - apt-cacher-ng:/var/cache/apt-cacher-ng restart: always volumes: apt-cacher-ng:

7- Bring up your Docker-cmpose by doing :

docker-compose up -d

8- You can Get access to APT cacher by entering your http://Machine IP:3172 (192.168.110.200:3172)

8–1 As you can see we can get access to Statistics (how much package cached) by clicking on Statistics and report and Configuration Page

Client Side Config
We have 2 option for configuring Client To Give Packages From APT-Cacher-NG

1- Send All APT Repository Requests to the Proxy Section By Creating /etc/apt/apt.conf.d/02proxy File and Put Following Section To IT :

`Acquire::http { Proxy "http://192.168.110.200:3142"; };

192.168.110.200 is our apt-cacher-ng ip

`
OR

2- Appending your APT Cacher URL:PORT to Your APT Repository Like:

deb http://192.168.110.200:3142/ftp.debian.org/debian stable main contrib non-free deb-src http://192.168.110.200:3142/ftp.debian.org/debian stable mrnickfetratmain contrib non-free deb http://192.168.110..200:3142/HTTPS///get.docker.com/ubuntu docker main

Conclusion

You Can Cache Packages , Speed UP Downloading Packages and Also Not Accessing Your Servers To the Internet By Simply Using APT Cacher-NG