Deploying Azure Functions in Containers to Azure Container Apps - like a boss!!!
Introduction
In today's cloud-native world, containerization has become a fundamental approach for deploying applications. Azure Functions can be containerized and deployed to a docker container which means we can deploy them on kubernetes. One compelling option is Azure Container Apps (ACA), which provides a fully managed Kubernetes-based environment with powerful features specifically designed for microservices and containerized applications.
Azure Container Apps is powered by Kubernetes and open-source technologies like Dapr, KEDA, and Envoy. It supports Kubernetes-style apps and microservices with features like service discovery and traffic splitting while enabling event-driven application architectures. This makes it an excellent choice for deploying containerized Azure Functions.
This blog post explores how to deploy Azure Functions in containers to Azure Container Apps, with special focus on the benefits of Envoy for traffic management, revision handling, and logging capabilities for troubleshooting.
Video Demo:
Why Deploy Azure Functions to Container Apps?
Container Apps hosting lets you run your functions in a fully managed, Kubernetes-based environment with built-in support for open-source monitoring, mTLS, Dapr, and Kubernetes Event-driven Autoscaling (KEDA). You can write your function code in any language stack supported by Functions and use the same Functions triggers and bindings with event-driven scaling.
Key advantages include:
- Containerization flexibility: Package your functions with custom dependencies and runtime environments for Dev, QA, STG and PROD
- Kubernetes-based infrastructure: Get the benefits of Kubernetes without managing the complexity
- Microservices architecture support: Deploy functions as part of a larger microservices ecosystem
- Advanced networking: Take advantage of virtual network integration and service discovery
Benefits of Envoy in Azure Container Apps
Azure Container Apps includes a built-in Ingress controller running Envoy. You can use this to expose your application to the outside world and automatically get a URL and an SSL certificate. Envoy brings several significant benefits to your containerized Azure Functions:
1. Advanced Traffic Management
Envoy serves as the backbone of ACA's traffic management capabilities, allowing for:
- Intelligent routing: Route traffic based on paths, headers, and other request attributes
- Load balancing: Distribute traffic efficiently across multiple instances
- Protocol support: Downstream connections support HTTP1.1 and HTTP2, and Envoy automatically detects and upgrades connections if the client connection requires an upgrade.
2. Built-in Security
- TLS termination: Automatic handling of HTTPS traffic with Azure managed certificates
- mTLS support: Azure Container Apps supports peer-to-peer TLS encryption within the environment. Enabling this feature encrypts all network traffic within the environment with a private certificate that is valid within the Azure Container Apps environment scope. Azure Container Apps automatically manage these certificates.
3. Observability
- Detailed metrics and logs for traffic patterns
- Request tracing capabilities
- Performance insights for troubleshooting
Traffic Management for Revisions
One of the most powerful features of Azure Container Apps is its handling of revisions and traffic management between them.
Understanding Revisions
Revisions are immutable snapshots of your container application at a point in time. When you upgrade your container app to a new version, you create a new revision. This allows you to have the old and new versions running simultaneously and use the traffic management functionality to direct traffic to old or new versions of the application.
Traffic Splitting Between Revisions
Traffic split is a mechanism that routes configurable percentages of incoming requests (traffic) to various downstream services. With Azure Container Apps, we can weight traffic between multiple downstream revisions.
This capability enables several powerful deployment strategies:
Blue/Green Deployments
Deploy a new version alongside the existing one, and gradually shift traffic:
- Deploy revision 2 (green) alongside revision 1 (blue)
- Initially direct a small percentage (e.g., 10%) of traffic to revision 2
- Monitor performance and errors
- Gradually increase traffic to revision 2 as confidence grows
- Eventually direct 100% traffic to revision 2
- Retire revision 1 when no longer needed
A/B Testing
Test different implementations with real users:
Traffic splitting is useful for testing updates to your container app. You can use traffic splitting to gradually phase in a new revision in blue-green deployments or in A/B testing. Traffic splitting is based on the weight (percentage) of traffic that is routed to each revision.
Implementation
To implement traffic splitting in Azure Container Apps:
By default, when ingress is enabled, all traffic is routed to the latest deployed revision. When you enable multiple revision mode in your container app, you can split incoming traffic between active revisions.
Here's how to configure it:
- Enable multiple revision mode:
- In the Azure portal, go to your container app
- Select "Revision management"
- Set the mode to "Multiple: Several revisions active simultaneously"
- Apply changes
- Configure traffic weights:
- For each active revision, specify the percentage of traffic it should receive
- Ensure the combined percentage equals 100%
Logging and Troubleshooting
Effective logging is crucial for monitoring and troubleshooting containerized applications. Azure Container Apps provides comprehensive logging capabilities integrated with Azure Monitor.
Centralized Logging Infrastructure
Azure Container Apps environments provide centralized logging capabilities through integration with Azure Monitor and Application Insights. By default, all container apps within an environment send logs to a common Log Analytics workspace, making it easier to query and analyze logs across multiple apps.
Key Logging Benefits
- Unified logging experience: All container apps in an environment send logs to the same workspace
- Detailed container insights: Access container-specific metrics and logs
- Function-specific logging: You can monitor your containerized function app hosted in Container Apps using Azure Monitor Application Insights in the same way you do with apps hosted by Azure Functions.
- Scale event logging: For bindings that support event-driven scaling, scale events are logged as FunctionsScalerInfo and FunctionsScalerError events in your Log Analytics workspace.
Troubleshooting Best Practices
When troubleshooting issues in containerized Azure Functions running on ACA:
- Check application logs: Review function execution logs for errors or exceptions
- Monitor scale events: Identify issues with auto-scaling behavior
- Examine container health: Check for container startup failures or crashes
- Review ingress traffic: Analyze traffic patterns and routing decisions
- Inspect revisions: Verify that traffic is being distributed as expected between revisions
Implementation Steps
Here's the full playlist we did in youtube to follow along: https://www.youtube.com/playlist?list=PLKwr1he0x0Dl2glbE8oHeTgdY-_wZkrhi
In Summary:
- Containerize your Azure Functions app:
- Create a Dockerfile based on the Azure Functions base images
- Build and test your container locally
- Video demo:
- Push your container to a registry:
- Push to Azure Container Registry or another compatible registry
- Create a Container Apps environment:
- Set up the environment with appropriate virtual network and logging settings
- Deploy your function container:
- Use Azure CLI, ARM templates, or the Azure Portal to deploy
- Configure scaling rules, ingress settings, and revision strategy
- Set up traffic management:
- Enable multiple revision mode if desired
- Configure traffic splitting rules for testing or gradual rollout
Conclusion
Deploying Azure Functions in containers to Azure Container Apps combines the best of serverless computing with the flexibility of containers and the rich features of a managed Kubernetes environment. The built-in Envoy proxy provides powerful traffic management capabilities, especially for handling multiple revisions of your application. Meanwhile, the integrated logging infrastructure simplifies monitoring and troubleshooting across all your containerized functions.
This approach is particularly valuable for teams looking to:
- Deploy Azure Functions with custom dependencies
- Integrate functions into a microservices architecture
- Implement sophisticated deployment strategies like blue/green or A/B testing
- Maintain a consistent container-based deployment strategy across all application components
By leveraging these capabilities, you can create more robust, scalable, and manageable serverless applications while maintaining the development simplicity that makes Azure Functions so powerful.
Azure Container Apps: Simplifying Container Deployment with Enterprise-Grade Features
In the ever-evolving landscape of cloud computing, organizations are constantly seeking solutions that balance simplicity with enterprise-grade capabilities. Azure Container Apps emerges as a compelling answer to this challenge, offering a powerful abstraction layer over container orchestration while providing the robustness needed for production workloads.
What Makes Azure Container Apps Special?
Azure Container Apps represents Microsoft’s vision for serverless container deployment. While Kubernetes has become the de facto standard for container orchestration, its complexity can be overwhelming for teams that simply want to deploy and scale their containerized applications. Container Apps provides a higher-level abstraction that handles many infrastructure concerns automatically, allowing developers to focus on their applications.
Key Benefits of the Platform
Built-in Load Balancing with Envoy
One of the standout features of Azure Container Apps is its integration with Envoy as a load balancer. This isn’t just any load balancer – Envoy is the same battle-tested proxy used by major cloud-native platforms. It provides:
- Automatic HTTP/2 and gRPC support
- Advanced traffic splitting capabilities for A/B testing
- Built-in circuit breaking and retry logic
- Detailed metrics and tracing
The best part? You don’t need to configure or maintain Envoy yourself. It’s managed entirely by the platform, giving you enterprise-grade load balancing capabilities without the operational overhead.
Integrated Observability with Azure Application Insights
Understanding what’s happening in your containerized applications is crucial for maintaining reliability. Container Apps integrates seamlessly with Azure Application Insights, providing:
- Distributed tracing across your microservices
- Detailed performance metrics and request logging
- Custom metric collection
- Real-time application map visualization
The platform automatically injects the necessary instrumentation, ensuring you have visibility into your applications from day one.
Cost Considerations and Optimization
While Azure Container Apps offers a serverless pricing model that can be cost-effective, it’s important to understand the pricing structure to avoid surprises:
Cost Components
- Compute Usage: Charged per vCPU-second and GB-second of memory used
- Baseline: ~$0.000012/vCPU-second
- Memory: ~$0.000002/GB-second
- Request Processing:
- First 2 million requests/month included
- ~$0.40 per additional million requests
- Storage and Networking:
- Ingress: Free
- Egress: Standard Azure bandwidth rates apply
Cost Optimization Tips
To keep your Azure Container Apps costs under control:
- Right-size your containers by carefully setting resource limits and requests
- Utilize scale-to-zero for non-critical workloads
- Configure appropriate minimum and maximum replica counts
- Monitor and adjust based on actual usage patterns
Advanced Features Worth Exploring
Revision Management
Container Apps introduces a powerful revision management system that allows you to:
- Maintain multiple versions of your application
- Implement blue-green deployments
- Roll back to previous versions if needed
DAPR Integration
For microservices architectures, the built-in DAPR (Distributed Application Runtime) support provides:
- Service-to-service invocation
- State management
- Pub/sub messaging
- Input and output bindings
Conclusion
Azure Container Apps strikes an impressive balance between simplicity and capability. It removes much of the complexity associated with container orchestration while providing the features needed for production-grade applications. Whether you’re building microservices, web applications, or background processing jobs, Container Apps offers a compelling platform that can grow with your needs.
By understanding the pricing model and following best practices for cost optimization, you can leverage this powerful platform while keeping expenses under control. The integration with Azure’s broader ecosystem, particularly Application Insights and Container Registry, creates a seamless experience for developing, deploying, and monitoring containerized applications.
Remember to adjust resource allocations and scaling rules based on your specific workload patterns to optimize both performance and cost. Monitor your application’s metrics through Application Insights to make informed decisions about resource utilization and scaling policies.
Understanding Container Network Interfaces (CNI): A Practical Guide for Troubleshooting
As an administrator managing containerized environments, understanding Container Network Interfaces (CNI) is crucial for effective troubleshooting. This guide will help you understand CNI basics and common troubleshooting scenarios for Kubernetes clusters using routes and tunnels as Calico CNI does.
Key Components You Need to Grok
What is CNI?
We all know the NIC acronym which stands for Network Interface Card, similarly Container Network Interface (CNI) is like a universal plug adapter for container networking. It’s a standard way to configure network interfaces for Linux containers, regardless of the container runtime (Docker, containerd, etc.) or the network plugin (Calico, Flannel, Weave, etc.) you’re using.
1. CNI Bridge
- Think of it as a virtual switch on your host
- Usually named
cni0or similar - Connects all pods on a node
2. Pod Network Namespace
- Each pod gets its own isolated network space
- Contains its own network interface (usually
eth0) - Has its own IP address and routing table
3. Virtual Ethernet Pairs (veth)
- Work like a virtual network cable
- One end connects to the pod
- Other end connects to the CNI bridge
Common Troubleshooting Scenarios
Scenario 1: Pod Can’t Reach Other Pods
Check these first:
# Check pod's network interface
kubectl exec -- ip addr
# Check pod’s routing table
kubectl exec — ip route
# Verify CNI bridge exists
ip link show cni0
Common causes:
- CNI plugin misconfiguration
- Network policy blocking traffic
- Corrupted CNI configuration
Scenario 2: Pod Can’t Reach External Services
Troubleshooting steps:
# Check node's DNS resolution
kubectl exec <pod-name> -- nslookup kubernetes.default
# Verify outbound connectivity
kubectl exec <pod-name> — ping 8.8.8.8
# Check pod’s DNS configuration
kubectl exec <pod-name> — cat /etc/resolv.conf
Scenario 3: Pod Stuck in “ContainerCreating” State
Investigation path:
# Check CNI logs
journalctl -u kubelet | grep cni
# Verify CNI configuration
ls /etc/cni/net.d/
# Check kubelet logs
journalctl -u kubelet
Good-to-have Troubleshooting Commands
1. Network Connectivity Checks
# Check pod networking details
kubectl get pod <pod-name> -o wide
# Test network connectivity between pods
kubectl exec <pod-name> — curl <other-pod-ip>
# View CNI configuration
cat /etc/cni/net.d/10-*.conf
2. Network Plugin Status
# Check CNI pods status (for Kubernetes)
kubectl get pods -n kube-system | grep cni
# Verify CNI binaries
ls /opt/cni/bin/
3. Node Network Status
# Check node interfaces
ip addr show
# View routing table
ip route
# Check iptables rules (if using iptables mode)
iptables-save | grep KUBE
Best Practices
- Regular Health Checks
- Monitor CNI plugin pods
- Check network latency between pods
- Verify DNS resolution regularly
- Documentation
- Keep network diagrams updated
- Document IP ranges and network policies
- Maintain troubleshooting runbooks
- Backup and Recovery
- Backup CNI configurations
- Keep known-good configurations ready
- Document recovery procedures
Azure Functions on your local Kubernetes Cluster: A Dev Powerhouse
In today’s fast-paced development landscape, the traditional Dev, QA, STG (Staging), PROD pipeline has become a standard practice. However, the increasing adoption of cloud-based environments has introduced new challenges, particularly in terms of cost and deployment speed. To address these issues, many organizations are exploring strategies to optimize their development and deployment processes. In this article we are exploring the use of our local Kubernetes cluster since Azure Functions can run on containers, this can improve your deployments and cost savings.
KEDA (Kubernetes Event-Driven Autoscaler)
KEDA is a tool that helps manage the scaling of your applications based on the workload they’re handling. Imagine having a website that experiences a sudden surge in traffic. KEDA can automatically increase the number of servers running your website to handle the increased load. Once the traffic subsides, it can also scale down all the way to zero PODS to reduce costs.
What is Scale to Zero? It’s a feature that allows applications to automatically scale down to zero instances when there’s no incoming traffic or activity. This means that the application is essentially turned off to save costs. However, as soon as activity resumes, the application can quickly scale back up to handle the load.
Caveat: Your app needs to be packaged in a way that it can start up fast and not have a high warm-up period.
How Does it Work? KEDA monitors application metrics and automatically scales the number of instances up or down based on predefined rules. KEDA supports a wide range of application metrics that can be used to trigger scaling actions. Here are some examples and the most commonly used ones:
- HTTP Metrics:
- HTTP requests: The number of HTTP requests received by an application.
- HTTP status codes: The frequency of different HTTP status codes returned by an application (e.g., 200, 404, 500).
- Queue Lengths:
- Message queue length: The number of messages waiting to be processed in a message queue.
- Job queue length: The number of jobs waiting to be executed in a job queue.
- Custom Metrics:
- Application-specific metrics: Any custom metrics that can be exposed by your application (e.g., database connection pool size, cache hit rate).
Choosing the right metrics depends on your specific application and scaling needs. For example, if your application relies heavily on message queues, monitoring queue lengths might be the most relevant metric. If your application is CPU-intensive, monitoring CPU utilization could be a good indicator for scaling.
KEDA also supports metric aggregators like Prometheus and StatsD, which can be used to collect and aggregate metrics from various sources and provide a unified view of your application’s performance.
Azure Container Registry
Azure Container Registry (ACR) and Docker Hub are both popular platforms for storing and managing container images. While both offer essential features, Azure Container Registry provides several distinct advantages that make it a compelling choice for many developers and organizations.
Key Benefits of Azure Container Registry
-
Integration with Azure Ecosystem:
- Seamless integration: ACR is deeply integrated with other Azure services, such as Azure Kubernetes Service (AKS), Azure App Service, and Azure Functions. This integration simplifies deployment and management workflows.
- Centralized management: You can manage container images, deployments, and other related resources from a single Azure portal.
-
Enhanced Security and Compliance:
- Private repositories: ACR allows you to create private repositories, ensuring that your container images are not publicly accessible.
- Role-based access control (RBAC): Implement fine-grained access control to manage who can view, create, and modify container images.
- Compliance: ACR meets various industry compliance standards, making it suitable for organizations with strict security requirements.
-
Performance and Scalability:
- Regional proximity: ACR offers multiple regions worldwide, allowing you to store and retrieve images from a location that is geographically closer to your users, improving performance.
- Scalability: ACR can automatically scale to handle increased demand for container images.
-
Advanced Features:
- Webhooks: Trigger custom actions (e.g., build pipelines, notifications) based on events in your registry, such as image pushes or deletes.
- Geo-replication: Replicate your images across multiple regions for improved availability and disaster recovery.
- Integrated vulnerability scanning: Automatically scan your images for known vulnerabilities and receive alerts.
-
Cost-Effective:
- Azure pricing: ACR is part of the Azure ecosystem, allowing you to leverage Azure’s flexible pricing models and potential cost savings through various discounts and promotions.
In summary, while Docker Hub is a valuable platform for sharing container images publicly, Azure Container Registry offers a more comprehensive solution tailored to the needs of organizations that require enhanced security, integration with Azure services, and performance optimization.
ACR and Kubernetes Integration
To pull container images from Azure Container Registry (ACR) in a Kubernetes manifest, you’ll need to add an imagePullSecret attribute to the relevant deployment or pod specification. This secret stores the credentials required to authenticate with ACR and pull the images.
Here’s a step-by-step guide on how to achieve this:
1. Create a Kubernetes Secret:
- Use the
kubectl create secret docker-registrycommand to create a secret that holds your ACR credentials. Replace<your-acr-name>with the actual name of your ACR instance and<your-acr-password>with your ACR password:
kubectl create secret docker-registry <your-acr-name> --username=<your-acr-username> --password=<your-acr-password>
2. Reference the Secret in Your Manifest:
- In your Kubernetes manifest (e.g., deployment.yaml, pod.yaml), add the
imagePullSecretsattribute to thespecsection of the deployment or pod. Reference the name of the secret you created in the previous step:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: <your-acr-name>.azurecr.io/<your-image-name>:<your-tag>
imagePullPolicy: Always
imagePullSecrets:
- name: <your-secret-name>
Key Points:
- Replace
<your-acr-name>,<your-image-name>,<your-tag>, and<your-secret-name>with the appropriate values for your specific ACR instance, image, and secret. - The
imagePullPolicyis set toAlwaysto ensure that the image is always pulled from the registry, even if it’s already present on the node. You can adjust this policy based on your requirements.
Additional Considerations:
- For more complex scenarios, you might consider using service accounts and role-based access control (RBAC) to manage permissions for accessing ACR.
- If you’re using Azure Kubernetes Service (AKS), you can leverage Azure Active Directory (Azure AD) integration for authentication and authorization, simplifying the management of ACR credentials.
By following these steps, you can successfully configure your Kubernetes deployment or pod to pull container images from Azure Container Registry using the imagePullSecret attribute.
Deploy Azure Container Apps with the native AzureRM Terraform provider, no more AzAPI!
Azure has given us great platforms to run containers. Starting with Azure Container Instance where you can run a small container group just like a docker server and also Azure Kubernetes Service where you can run and manage Kubernetes clusters and containers at scale. Now, the latest Kubernetes abstraction from Azure is called Container Apps!
When a service comes out in a cloud provider their tools are updated right away so when Contrainer Apps came out you could deploy it with ARM or Bicep. You could still deploy it with Terraform by using the AzAPI provider which interacts directly with Azures API but as of a few weeks back (from the publish date of this article) you can use the native AzureRM provider to deploy it.
Code Snippet
resource "azurerm_container_app_environment" "example" {
name = "Example-Environment"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
log_analytics_workspace_id = azurerm_log_analytics_workspace.example.id
}
resource "azurerm_container_app" "example" {
name = "example-app"
container_app_environment_id = azurerm_container_app_environment.example.id
resource_group_name = azurerm_resource_group.example.name
revision_mode = "Single"
template {
container {
name = "examplecontainerapp"
image = "mcr.microsoft.com/azuredocs/containerapps-helloworld:latest"
cpu = 0.25
memory = "0.5Gi"
}
}
}
Sources
Kubernetes Secret for Fleet Elasticsearch Agents
If you are having issues with your Elasticsearch Agents not getting the correct Fleet server enrollment token then this fix is for you. Elasticsearch support docs recommend adding the token as clear text in the Elastic agent daemonset manifest but here I show how to add it in the daemonset but as a kubernetes secret!Read more
The NodeSelector Is My Mixed-CPU-Architecture Kubernetes Cluster's Best Friend!
I have an always growing Kubernetes cluster. I currently have a cluster made of 2 Raspberry Pis and 1 PC but HOW, isn't that frowned upon? Well, you can use the NodeSelector attribute to make the containers stick to specific nodes. The specifics we are covering in this article are the CPU architectures of the nodes since the Raspberry Pis run ARM and my PCs run AMD64.
Don't be a part of the naughty list of the internet exposed Kubernetes clusters!
A finding by the Shadow Foundation uncovered close to half a million k8s endpoints on the internet which can be targets to exploits. One factor is that by default these clusters are built with public IPs since cloud providers are outside your network and not all companies can have ExpressRoutes or dedicated point to point connectivity. To increase the security and have easier routing of your kubernetes cluster you can create a private cluster. In Azure Kubernetes Service the private cluster assigns an internal IP to your k8s API but NGINX defaults to external IP so in this article I walk through configuring NGINX to have internal IPs as well to keep it all inside the network.
Scale Down a specific node in Azure Kubernetes Service
In the past I've scaled up a cluster to test a new deployment or to provide extra compute during an upgrade but when it comes to scaling down AKS won't pick the node with less resources or even the drained one so I've seen it briefly disrupt a deployment.
To have more control on what AKS scales down you can use virtual machine scale set protection policies to specify which node to remove. Here's how to do so...
Avoid Self-Monitoring on your PROD ElasticSearch Cluster! Ship logs to a separate deployment.
It is highly recommended to disable self-monitoring on your production Elasticsearch deployment for performance and built-in support in Elastic Cloud on Kubernetes. In this article we go over configuring the monitoring cluster.