Showing posts with label kubernetes. Show all posts
Showing posts with label kubernetes. Show all posts

Saturday, April 17, 2021

What’s New In Kubernetes 1.21?

 

What's New In Kubernetes 1.21

In this world of technology, frameworks or development platforms are evolving to serve the best performance results to developers and users. And Kubernetes is not apart from this. It is a portable, extensible, open-source platform to manage containerized workloads and services, that facilitates declarative configuration and automation. It has large, rapidly growing ecosystem. Now, Kubernetes came with its new version Kubernetes 1.21 with some amazing features and improvements. But what are these new enhancements? Let’s dig in and find out.

New Features Of Kubernetes 1.21-

1. New Memory Manager-

Container deployments are dependent on memory. And those deployments must use memory wisely, otherwise they could wind up  by draining your cluster of precious resources. Memory manager is a new feature in the ecosystem which enables guaranteed memory allocation for pods in the Guaranteed QoS class. With this, you will be able to find two different allocation strategies:

  • Single: NUMA is for high-performance and performance-sensitive apps.
  • Multi-NUMA defeats situation that can’t be managed with single-NUMA strategy

Memory manager initializes a memory table collection for every NUMA node that results in memory map objects. Memory table and memory maps are constructed like-

type MemoryTable struct {
 
        TotalMemSize uint64 `json:"total"`
        SystemReserved uint64 `json:"systemReserved"`
        Allocatable uint64 `json:"allocatable"`
        Reserved uint64 `json:"reserved"`
        Free uint64 `json:"free"`
}
 
type NodeState struct {
       NumberOfAssignments int `json:"numberOfAssignments"`
       MemoryMap map[v1.ResourceName]*MemoryTable `json:"memoryMap"`
       Nodes []int `json:"nodes"`
}
 
type NodeMap map[int]*NodeState

2. Flexible Scheduler-

Every workload is not the same. With release of 1.21 the scheduler will receive two new features- Nominated nodes and Pod affinity. 

  • Nominated nodes allow cloud native developers to define preferred node, by using .status.nominatedNodeName filed in Pod. If scheduler fils to fit incoming pod into preferred node, it will preempt lower-priority pods to make room.
  • Pod affinity selector allows developers to define node affinity into deployment. It allows developer to constrain which nodes pods will be scheduled on.

3. Indexed Job-

Now, jobs associated with index so that job controller can check annotation while creating pods. This enhancement eases the deploying of highly parallelisable workloads into Kubernetes especially for HPC use cases. The job controller will create Pods for the lowest indexes that don’t already have active or succeeded pods. If there are multiple pod for an index, the controller will remove all but one. Active pods that do not have an index are removed and finished pods that don’t have an index won’t count towards failures or successes.

4. ReplicateSet Downscaling-

For anybody that deals with a Kubernetes deployments, you understand that autoscaling is one of the most significant highlights. One issue that has plagued Kubernetes autoscaling is downscaling after a load spike passes.  With Kubernetes 1.21, there are two new downscale strategies, means you will no longer need to manually check when it comes time to downscale a deployment. The strategies are-

  • ReplicaSet deletion cost makes it feasible for you to annotate Pods, using controller.kubernetes.io/pod-deletion-cost=X(here X is a number between 0 and 10). Pods with a lower deletion cost value will be removed first.
  • Random Pod selection on ReplicaSet downscale – that uses LogarithmicScaleDown to semi-randomly select pods to downscale.

5. Metric Cardinality Enforcement-

Previously, there have been occurrences of metrics causing memory leaks. In such cases, the issue couldn’t be solved until a new Kubernetes binary was released. 

To remove this issue, this enhancement introduces two new command line options in Kubernetes 1.21.

The –disabled-metrics flag will allow you to disable problematic metrics.

The –allow-label-value option allows you to define a list of accepted values for a metric.

6. Depreciation Of Pod Security Policy-

Pod security Policies restrict what can be done within the scope of deployment, like setting execution limits to a list of users or allowing resource access for things like network or volumes. PSP have been in beta for some time now, with no indication of effort made to take the feature stable state. Resulting in, PSP are being marked as deprecated in Kubernetes 1.21 and will be completely removed in Kubernetes 1.25. Users should consider Open Policy Gatekeeper (OPA) for policy enforcement. Canonical Kubernetes will support OPA in its distributions and is anticipating with users to ensure all their policy requirements can be met.

7. Metrics Stability Enhancement-

This enhancement follows up on the recent efforts to better handle the deprecation of Kubernetes features. Now, the metrics come with two categories, either ALPHA or STABLE. Alpha metrics can be deleted any time, but stable metrics are guaranteed to not change. Hence deprecation life cycle has been put into a place to better handle deprecation of stable metrics. 

When stable metric is deprecated, it will be marked as deprecated. This will come in the form of a notice in the description text (Deprecated from x.y), and a warning log will be removed in metric registration.

After some releases, the metric will be hidden, not being registered by default. Sysadmins can enable those metrics back with the command line-

--show-hidden-metrics-for-version.

On the next release, the metric will be removed.

8. Service Internal Traffic Policy-

This enhancement is a step to build more efficient networking in Kubernetes. After ServiceTrafficPolicy feature gate is enabled, a new spec.trafficPolicy field will be available on Service objects. When,

  •  this field is set to Cluster, routing will behave as usual,
  • Set to Topology, it will use topology-aware routing. 
  • Set to PreferLocal, it will redirect traffic to services on the same node.
  • and Set to Local, it will only send traffic to services on the same node.

9. IngressClass namespaced params-

Due to this enhancement, you can specify parameters for an IngressClass with Namespace scope:

apiVersion: networking.k8s.io/v1
 kind: IngressClass
 metadata:
   name: external-lb
 spec:
   controller: example.com/ingress-controller
   parameters:
     apiGroup: k8s.example.com
     kind: IngressParameters
     name: external-lb
     namespace: external-configuration
     scope: Namespace

10. CRIContainerLogRotation-

It summarizes the work done to finally bring this feature up to Stable after being in beta since Kubernetes 1.11. For container runtimes that communicate with kubelet via the Container Runtime interface(CRI), the kubelet is the one in charge of handling the container runtime logs, and providing the log file path to the container runtime. While implementing log rotation, it was decided that kubelet took care of this too.

Here two command line options have been added to tweak log rotation behavior : –container-log-max-size and –container-log-max-files.


Friday, November 27, 2020

Top 11 Kubernetes Tools For 2021



For developers, writing applications for various operating environments is a major requirement. Kubernetes eliminates the restrictions and extends the capabilities of containers so got a high attention. There are some benefits like discoverability, observability, horizontal scaling and load balancing that Kubernetes offer through its collection of pods that can perform similar functions. You can use a deployment controller to achieve scalability, visibility, time savings and control over versions. Kubernetes tools extend the functionalities and eliminate the imposed restrictions for better performance. Here we’ll see top 11 Kubernetes tools that enhance your development work. 

Top 11 Kubernetes Tools –

1. cAdvisor-

cAdvisor is an open-source tool and maintained by Google.  It is used to monitor resource usage and performance. It natively supports Docker and is integrated with Kubelet. This tool can auto-detect all containers in a server, collects, processes and disseminates container information. But it has one weakness, it is limited to store metrics for long term monitoring. cAdvisor’s container abstraction is based on Imctfy, it inherits the nested hierarchical behavior.

2. Kubernetes Operational View (Kube-ops-view)-

It is an open-source tool and you can use it in all popular browsers like Chrome and Mozilla Firefox also. This tool provides a common operational structure for all Kubernetes clusters. Besides it can be considered as a read-only system dashboard for multiple Kubernetes platforms. This tool allows you to navigate between your cluster and monitor nodes seamlessly.

Creation and termination process of pod will be easier if you use this tool. Also it uses Heapster as a data source and render nodes to enable users to indicate overall status and remember that it is not an operational tool. Vertical bar for total memory can be rendered through this tool, while the rendering of individual pods has also been made possible by its developers.  Also you can group the system pods and get tooltip data for nodes and pods. But you can not consider it as a replacement for the kubernetes dashboard.

3. Minikube-

Know more at- https://solaceinfotech.com/blog/top-11-kubernetes-tools-for-2021/

Monday, August 3, 2020

Kubernetes Security Best Practices That You Must Know

Kubernetes Security Best Practices That You Must Know

Kubernetes security best practices

Kubernetes is an open-source system for automating deployment, scaling  and management of containerized applications. But these new deployments can cause attacks and exploits from attackers and insiders as traditional environments which makes kubernetes security a prime concern for all deployments. 

Nearly, 94% of organizations have encountered a genuine security issue within a year in their container environment, 69% having detected misconfigurations, 27% experienced runtime security issues and also 24% found significant vulnerabilities to remediate. Each of these issues relates to a container lifecycle phase. You can differentiate these vulnerabilities during build/deploy phase, runtime phase etc.

Kubernetes Vulnerabilities And Attack Vectors-

Attacks on Kubernetes containers running in pods can come internally by insiders or externally through the network, that includes victims of phishing attacks whose system becomes a mediator for insider attacks. Some of the examples are as follows-

1. Unauthorized connections between pods- Compromised containers can try to connect with running pods to attack. Layer 3 network controls whitelisting pod IP addresses can offer protection but attacks over trusted IP addresses can only be detected with Layer 7 network filtering.

2. Container compromise- Application misconfiguration or vulnerability empowers the attacker to get into a container to start probing for weaknesses in the network, process controls or file system. 

3. Data exfiltration from a pod- Data stealing is generally carried out by combination of techniques, which can include a reverse shell in a pod connecting to a command/control server and network tunneling to hide confidential information.

Kubernetes Security Best Practices: Infrastructure Security-

Kubernetes Security Best Practices

1. Update your Kubernetes-

Only the last three versions of Kubernetes are supported, including security patches for new vulnerabilities. Hence if severe vulnerability is discovered, and you are four versions behind, then your version will not receive a patch.   

2. Securely configure the Kubernetes API server-

Ensure that you’re disabling unauthenticated/anonymous access and using TLS encryption for connections between the kubelets and the API server. 

Kubernetes Security Best Practices: Build Phase-

Securing containers and Kubernetes begins in the build phase with securing your container images. Any missed security best practices will be essentially more costly to fix down the line – consequently the expression “shift left” which means implementing security at prior stages as images are built. Scan and secure images are the main things to secure from any known vulnerabilities.

Recommendations-

1. Use an image scanner-

Image scanner can identify vulnerabilities in your images, including by layer and tell you whether they are fixable or not. It must scan for vulnerabilities in OS packages and also third-party runtime libraries for the languages being utilized in your containerized applications.

2. Label non-fixable vulnerabilities-

Some of the time there isn’t a fix for a known vulnerability, or the vulnerability is non-critical and hence doesn’t warrant a quick fix. At such time, include them to allow list or filter the scanner output so that you don’t intrude on the development team’s workflows over non-actionable alerts.

3. Don’t include unnecessary components-

Ensure that you’ve removed debugging tools from containers in production. Tools such as Curl should not be included in images.

4. Implement defense-in-depth-

When a security issue is discovered in a container image or a running deployment that utilizes that image, ensure you have policy checks and a remediation workflow set up to recognize and update those images.

Kubernetes Security Best Practices: Deploy Phase-

From a security point of view, you first need visibility into what you’re deploying – and how. At that point you can recognize and respond to security policy violations.

What is being deployed- including data about the image being used, like components or vulnerabilities and pods.

Where it is going to be deployed- namespaces, clusters and nodes.

How it is deployed- regardless of whether it runs privileged, what other deployments it can coordinate with, the pod security context that is applied, if any

What it can access- includes volumes, secrets and also other components like host or orchestrator API

Recommendations-

1. Isolate sensitive workloads by using namespaces-

Namespaces are a main isolation boundary for Kubernetes resources. It provides a reference for network policies, access control restrictions and also other important security controls. Separating workloads into namespaces can limit the impact of mistakes or destructive actions by authorize users.

2. Use Kubernetes network policies-

Kubernetes allows every pod to contact other pods. Network segmentation policies are the key security control that can prevent parallel movement across containers for the situation that an attacker breaks in.

Kubernetes Security Best Practices: Runtime Phase-