In elastic (cloud or on self hosted in AKS) we can take snapshots of our indices. If we want to restore evrything we can do a full restore for a recovery. However, in a situation where we need to restore a single index into a diffrent name to prevent touching existing live index, but we need to recover some index documents previously was there in a given index (which are deleted as of now), we have the option of restoring a given index by a diffren t name.
Below is an example
We have discussed how to setup Nginx-Gateway instead of Nginx ingress controller in AKS in previous posts listed in the bottom of this post. We have also looked at "Setup Managed Prometheus for AKS via Terraform" and "Deploying Azure Managed Grafana with Terraform" . For Nginx-Gateway deployed in AKS, we need to enable datascraping so that we can start monitring nginx metrices from managed grafana. Let's look at the steps required.
The expectation is getting metrices ti managed grafana as shown below.
We might have to sometimes use native assembiles such Aspose.Slides.NET6.CrossPlatform as for specific needs.
However, when there is a native exception which is not propagating the exceptions to .NET app, but fails due to native errors and restart cotianers with exit code 139.
Exit code 139 in a Linux container means the process was terminated due to a Segmentation Fault (SIGSEGV). The operating system killed the container because it attempted to access a memory location it wasn't allowed to touch.
SIGSEGV is signal 11, the result is: (128+11=139)
Valkey is the open source redis alternative. We have discussed getting AKS instance ready for Valkey in the post "Create AKS Cluster to Setup Valkey Cluster (Open Source Redis)". Let's look at the prerequisites for setting up Valkey.
First step is setting up a namespace for valkey in the AKS cluster.
We sometimes come across issues such as shown below while trying to deploy AKS clusters. It could be due to diffrent reasons. One such case is the below one where there is no availability for the VM size in zone 2 in the region but it has availability in other two regions.
performing CreateOrUpdate: unexpected status 400 (400 Bad Request) with response: {
│ "code": "AvailabilityZoneNotSupported",
│ "details": null,
│ "message": "The zone(s) '2' for resource 'vkdefault' is not supported. The supported zones for location 'eastus2' are '1,3'",
│ "subcode": "",
│ "target": "agentPoolProfile.availabilityZone"
│ }
It would be usefull to figure out how many pods running in a given AKS cluster sometimes for various diagnostic needs. In this post let's see how we can use kubectl command to get pod count in diffrent combinations.
Below are some examples.
Since bitnami redis images have gone commercial now the best open source redis cluster setup option is to use Valkey, which is guranteed to be open source forever. The source code repos for Valkey is here. We have discussed deploying redis cluster on AKS with bitnami in "Setup Redis Cluster with JSON and Search Modules on AKS with Binami Redis Using Custom Image" However, if we want to deploy Valkey/Redis in cluster in AKS and want to access the Valkey/Redis from outside the AKS cluster, we have to setup AKS networking in a way that each pod is allocated with an IP from the Azure virtual network subnet. In this post let's explore how to setup such an AKS cluster correctly.
Why we need pods in AKS to have IPs from virtual network subnet to deploy Valkey?
When we connect to a Valkey/Redis cluster it always provide diffrent IPs of master nodes to client. Therefore, clients need to acess to IPs of Valkey node pods.
We cannot use Azure CNI overlay for this AKS cluster as it would setup internal network CIDR for pod IPs. Such IPs are not visible outside of AKS. Therefore it is not possible use Azure CNI overlay for AKS clsuter, if we are to deploy Valkey clsuter that should be allowed to access outside of AKS.
We can Azure node subnet mode. But this is not ideal as we have to have a large subnet planned to support boith the node needs as well as pods IP requirement.
The best option is to use Azure CNI Pod Subnet, which would be really useful for this need.
In AKS processing files on AKS node disk by application pod is not a recommended approach. It could lead to issues in stability of the AKS node itself. Therefore, we have two options. Either mount an Azure fileshare to the pod as described in "Mount Azure Storage Fileshare Created with Terraform on AKS". The other option is to setup a per pod disk, specially when the need is to process larger files. This option is really useful when we have pods running a single job and when it lives for the lifetime of the job. Example case is use of KEDA scale object with per single message processing from rabbitmq as described in "RabbitMQ KEDA Trigger for AKS Deployed Apps to Scale Out the Apps Accurately".
Expentation is to get a per pod disk attached as shown below.
