# Release 0.50

:material-calendar: 2024-01-29 · :material-list-status: [Full Changelog](https://github.com/srl-labs/containerlab/releases)

## k8s-kind

Containerlab now natively supports [kind](https://kind.sigs.k8s.io/) clusters as part of its topology by introducing a new kind [`k8s-kind`](../manual/kinds/k8s-kind.md).

Since more and more applications (including network management systems and network functions) are being deployed in the k8s clusters, it is important to be able to test the network connectivity between the k8s workloads and the underlay network.

[Kind](https://kind.sigs.k8s.io/) is a tool for running local Kubernetes clusters using Docker container “nodes”. By integrating kind clusters via a new kind `k8s-kind` with containerlab, it is possible to spin-up kind clusters as part of the containerlab topology.

This deployment model unlocks the possibility to integrate network underlay created by containerlab with the workloads running in the kind clusters in a single YAML file. The integration between kind clusters and containerlab topology makes it easy to deploy and interconnect k8s clusters and the underlay network.

## Ansible inventory improvements

We've shipped containerlab with the automatic Ansible inventory generation for quite a while now. It is a very convenient way to get the inventory file for the Ansible playbooks that can be used to configure the nodes in the topology.

Now we've improved the inventory generation by adding some additional Ansible variables for a few node kinds. If you use `nokia_srlinux` or `nokia_sros` kinds you will find the following variables in the inventory file:

* `ansible_user` - set to the default username of the node
* `ansible_password` - set to the default password of the node
* `ansible_connection` - set to `network_cli` for the SR OS nodes and to `httpapi` for the SR Linux nodes
* `ansible_network_os` - set to `nokia.sros.sros` for the SR OS nodes and to `nokia.srlinux.srlinux` for the SR Linux nodes

With these variables set you can start using Ansible right away without setting these variables elsewhere.

If you need the same functionality for other node kinds, please raise a PR or an issue.

## Using nftables API

With #1362 containerlab now starts using nftables API backend when installing iptables rules to allow external access for the nodes.

NFtables API is a new way to manage nftables/iptables rules and has been part of the kernel for quite a while. Still, some old kernels known to be used in Centos/RHEL distros up to and including version 7 might not have the nftables API available.

In that case, containerlab will fail to setup external access rules and users would have to do it manually.

## SANs move to Certificate level

///warning
This is a non backwards compatible change!
///

We offered the users to set additional Subject Alternative Names (SANs) for the generated certificates via the `.san` node property. But then we introduced the `.certificate` node property to tune certificate parameters for a given node or a kind.

Now we are moving the SANs to the [certificate level](../manual/nodes.md#subject-alternative-names-san) to keep things under one roof.

## Miscellaneous

* TLS certificates that containerlab provides for the nodes now also include `KeyEncipherment` usage role #1822
* xrv9k default mem and cpu values have been increased to 16 GB and 2 vCPUs respectively #1806
* SR Linux `admin` user's rc files are now owned by `admin` user #1832
* Updated wireshark docs #1842
* Config apply timeout for the SR OS nodes has been increased to 15 minutes #1835
