In the realm of Kubernetes networking, selecting the appropriate networking solution is crucial for ensuring optimal performance, security, and scalability. Two prominent contenders in this space are Cilium and Calico. Both are open-source projects that enhance Kubernetes networking and security, but they differ in their underlying technologies and feature sets. This article delves into a detailed comparison of Cilium and Calico to aid in determining the best fit for your Kubernetes environment.

Overview of Cilium

Cilium is an open-source networking and security project that leverages the power of eBPF (extended Berkeley Packet Filter) within the Linux kernel. This approach allows Cilium to provide high-performance networking, advanced security policies, and deep observability for containerized environments like Kubernetes. By operating at the kernel level, Cilium can enforce fine-grained policies and offer insights into network traffic with minimal overhead.

Overview of Calico

Calico is another open-source networking and network security solution designed for Kubernetes and other container orchestrators. It employs a pure Layer 3 approach, utilizing the standard Linux networking stack to deliver high-performance data forwarding. Calico offers flexible networking options, including overlays and non-overlay modes, and provides robust network policy enforcement to secure workloads.

Key Differences Between Cilium and Calico

While both Cilium and Calico aim to enhance Kubernetes networking and security, they differ in several key aspects:

1. Underlying Technology

• Cilium: Built on eBPF, Cilium injects networking and security logic directly into the Linux kernel, enabling dynamic programmability and efficient packet processing.

• Calico: Utilizes the standard Linux networking stack and offers an eBPF data plane option. It provides multiple data plane choices, including iptables, eBPF, and Windows HNS, catering to diverse deployment needs.

2. Network Policy Enforcement

• Cilium: Supports Kubernetes NetworkPolicies and extends them with API-aware policies, allowing for enforcement based on application-layer protocols such as HTTP, gRPC, and Kafka.

• Calico: Offers a comprehensive policy engine compatible with Kubernetes NetworkPolicies and introduces additional features like DNS policies and global network policies. Calico’s policies can be applied to a wide range of endpoints, including pods, VMs, and host interfaces.

3. Observability and Monitoring

• Cilium: Provides Hubble, a native observability platform that offers real-time visibility into network traffic and security events, facilitating troubleshooting and compliance monitoring.

• Calico: Integrates seamlessly with popular observability tools such as Prometheus and Grafana, enabling users to monitor network traffic, security policies, and performance metrics effectively.

4. Load Balancing and Service Handling

• Cilium: Implements eBPF-based load balancing, which can replace kube-proxy for improved performance and reduced latency. This approach allows for direct routing and efficient handling of service-to-service communication.

• Calico: Relies on standard kube-proxy for service handling but enhances it with features like Egress Gateway, enabling controlled egress traffic and integration with existing firewall systems.

5. Encryption and Security Features

• Cilium: Supports encryption of network traffic using IPsec and WireGuard, providing data-in-transit security with minimal performance impact.

• Calico: Offers encryption capabilities using IPsec and WireGuard, ensuring secure communication between pods and services, and supports identity-aware microsegmentation for enhanced security posture.

Performance Considerations

Performance is a critical factor when choosing a networking solution for Kubernetes:

• Cilium: The use of eBPF allows Cilium to perform network processing within the kernel, reducing context switches and potentially lowering latency. Benchmarks have shown that Cilium’s eBPF-based data plane can offer superior performance compared to traditional iptables-based approaches. (cilium.io)

• Calico: With its eBPF data plane option, Calico can achieve performance improvements by bypassing iptables, similar to Cilium. However, the actual performance gains may vary based on specific use cases and configurations. (tigera.io)

Scalability and Deployment

• Cilium: Designed to handle large-scale deployments, Cilium supports cluster mesh capabilities, allowing up to 255 clusters in a single mesh. Deployment is facilitated through the Cilium CLI, which streamlines installation and configuration processes.

• Calico: Known for its scalability, Calico is widely adopted in production environments. It offers flexible deployment options, including the use of the Tigera operator for automated installation and management. Calico’s design supports seamless integration across various platforms and environments.

Conclusion

Both Cilium and Calico are robust solutions for enhancing Kubernetes networking and security. Cilium stands out with its eBPF-based architecture, offering advanced features and potentially lower latency. Calico, on the other hand, provides a mature and flexible platform with multiple data plane options and a strong focus on scalability and integration.

The choice between Cilium and Calico depends on specific requirements, including performance needs, security features, observability preferences, and existing infrastructure. Evaluating these factors in the context of your organization’s goals will guide you toward the most suitable networking solution for your Kubernetes environment.

In a major industry move, Cisco and Check Point have both announced strategic cloud security partnerships with Wiz, a rapidly growing player in the Cloud Native Application Protection Platform (CNAPP) market.

With Cisco-Wiz focusing on hybrid cloud security and Check Point-Wiz streamlining cloud workload protection, these partnerships could pose a direct threat to Palo Alto Networks (PANW) and its Prisma Cloud offering.

Why This Matters for Palo Alto Networks

1 Increased Competition in Cloud Security

Palo Alto Networks has been a dominant force in cloud security through its Prisma Cloud platform and Strata NGFW (Next-Gen Firewall). However:

• Cisco-Wiz: Combines Ciscos Hybrid Mesh Firewall with Wizs cloud risk visibility.
• Check Point-Wiz: Focuses on network security integration and customer migration to Wiz for CNAPP.

2 Wizs Growing CNAPP Market Share

Wiz is now positioned as the go-to CNAPP solution:

• Both Cisco and Check Point are endorsing Wiz over their own solutions.
• Prisma Cloud competes directly with Wiz in cloud-native security.
• Enterprises already using Cisco or Check Point might prefer Wiz over Prisma Cloud due to seamless integration.

3 Check Point’s CNAPP Exit Helps Wiz Overtake Prisma Cloud

Check Point is shutting down its CNAPP product and moving customers to Wiz. This directly reduces Palo Altos ability to win new CNAPP customers in a key growth market.

What Palo Alto Networks Needs to Do Next

To counteract this growing competition, PANW should:

• Enhance Prisma Cloud: Focus on AI-driven automation and runtime security.
• Strengthen Strategic Partnerships: Collaborate deeper with AWS, Azure, or Google Cloud.
• Differentiate with AI-powered attack path analysis: Cisco and Wiz are pushing AI-based threat detectionPANW must keep up.

Final Thoughts: Is Palo Alto Networks in Trouble?

While Palo Alto Networks remains a leader, the Cisco-Wiz and Check Point-Wiz partnerships create serious competition in cloud security.

PANW still has strong brand recognition, but with Wiz gaining major endorsements, it must innovate fast or risk losing market share in the CNAPP space.

Introduction

In todays fast-paced development environment, security can no longer be an afterthought. Traditional approaches to security, where vulnerabilities are identified and addressed late in the software development lifecycle (SDLC), are costly and inefficient. This is where Shift Left Security comes into play. By integrating security measures early in the development process, organizations can reduce risks, improve software quality, and accelerate delivery.

What is Shift Left Security?

Shift Left Security is a proactive approach that embeds security practices and tools into the early stages of software development. Rather than waiting until testing or deployment, security assessments, code analysis, and vulnerability detection are incorporated from the design phase onwards.

Key Principles of Shift Left Security

1. Security by Design Security considerations are embedded in architectural decisions and design principles.
2. Automation and Continuous Testing Implementing automated security scans and static/dynamic application security testing (SAST/DAST) ensures real-time vulnerability detection.
3. Developer Security Training Equipping developers with security best practices enables them to write secure code from the start.
4. Collaboration Between Teams Security, development, and operations teams work together to identify and remediate risks early.
5. Threat Modeling Early Identifying potential security threats at the planning stage to design mitigations proactively.

Why Shift Left Security Matters

1. Reduces Costs Fixing security vulnerabilities in production is significantly more expensive than addressing them during development. The earlier an issue is found, the cheaper it is to resolve.
2. Improves Code Quality Secure coding practices lead to higher-quality software with fewer defects and vulnerabilities.
3. Accelerates Delivery Finding and fixing security issues early reduces last-minute delays and rework before deployment.
4. Enhances Compliance Many regulatory frameworks (e.g., GDPR, HIPAA, PCI-DSS) require secure coding practices and early security integration.
5. Strengthens Security Posture A proactive approach reduces the attack surface and improves overall cybersecurity resilience.

How to Implement Shift Left Security

1. Automate Security Testing

• Use Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools to scan code continuously.
• Integrate security testing into CI/CD pipelines to catch vulnerabilities early.

2. Embed Security in the DevSecOps Process

• Adopt a DevSecOps culture where security is an ongoing priority.
• Implement Infrastructure as Code (IaC) Security to enforce security policies in cloud-native environments.

3. Conduct Regular Code Reviews and Threat Modeling

• Perform peer reviews with a security focus to detect vulnerabilities before they reach production.
• Utilize threat modeling tools like Microsoft Threat Modeling Tool or OWASP Threat Dragon to anticipate risks.

4. Educate Developers on Secure Coding

• Train developers on secure coding best practices (e.g., OWASP Top 10, CWE/SANS Top 25).
• Provide security awareness programs to promote a security-first mindset.

5. Monitor and Improve Continuously

• Implement runtime security monitoring to detect threats in real-time.
• Use security metrics to track improvements and optimize security processes.

Conclusion

Shift Left Security is no longer optionalit is essential in modern software development. By embedding security early in the SDLC, organizations can reduce risks, improve efficiency, and build more secure applications. In a world where cyber threats are constantly evolving, embracing Shift Left Security is the key to staying ahead and protecting your applications from potential breaches.

If you havent already started shifting security left, now is the time to make it a core part of your development strategy.

Introduction

Kubernetes has revolutionized cloud-native application deployment, but managing ingress and traffic routing has always been a challenge. While the Ingress API has served well, it has limitations in extensibility and flexibility. The Gateway API is the next evolution in Kubernetes traffic management, providing a more structured, extensible, and role-oriented approach to managing network traffic.

What is Kubernetes Gateway API?

Gateway API is an open-source, Kubernetes-native API designed to standardize and enhance the way services handle external and internal traffic. It provides a more expressive, extensible, and role-based model for defining network traffic, replacing the traditional Ingress API.

It introduces Gateway, GatewayClass, Routes, and Backends as key resources, enabling better separation of concerns and interoperability across vendors.

Key Features of Gateway API

1. Multi-protocol Support Unlike Ingress, which is limited to HTTP/HTTPS, Gateway API supports TCP, UDP, gRPC, WebSockets, and more.
2. Improved Extensibility Uses Custom Resources (CRDs) for enhanced flexibility, allowing vendors to extend capabilities seamlessly.
3. Separation of Concerns Different personas (platform teams, developers, security engineers) can configure different parts of the networking stack independently.
4. Traffic Splitting & Advanced Routing Provides native support for traffic splitting, header-based routing, and weight-based distribution.
5. Multi-Tenancy Support Enables multiple teams to share networking infrastructure without interference.

Gateway API vs. Ingress API: Key Differences

Key Components of Gateway API

1. GatewayClass

   • Defines the type of Gateway infrastructure (e.g., managed by Istio, Traefik, or NGINX).
   • Similar to StorageClass in Kubernetes storage management.

2. Gateway

   • Represents an instance of a GatewayClass.
   • Defines listeners, protocols, and ports.

3. Routes (e.g., HTTPRoute, TCPRoute, GRPCRoute)

   • Defines traffic routing rules.
   • Attaches to a Gateway and directs traffic to Services or other Backends.

4. Backends

   • Can be Kubernetes Services, external endpoints, or other APIs.

Use Cases for Gateway API

1. Multi-Tenant Kubernetes Clusters

   • Enables shared infrastructure across multiple teams with strict isolation.

2. Advanced Traffic Routing

   • Supports path-based, header-based, and weighted traffic routing, without requiring a service mesh.

3. Hybrid and Multi-Cloud Deployments

   • Works across different cloud providers and on-premises environments using vendor-neutral API definitions.

4. Security and Policy Enforcement

   • Fine-grained security policies with mTLS, authorization, and rate-limiting built into the API.

Getting Started with Gateway API

1. Install Gateway API CRDs

1

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml

2. Create a GatewayClass

1
2
3
4
5
6

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: my-gateway-class
spec:
  controllerName: example.com/gateway-controller

3. Deploy a Gateway

1
2
3
4
5
6
7
8
9

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - protocol: HTTP
    port: 80

4. Define an HTTP Route

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - path:
        type: Prefix
        value: /app
    backendRefs:
    - name: my-service
      port: 80

Conclusion

Gateway API represents a significant leap forward in Kubernetes traffic management. By offering multi-protocol support, enhanced extensibility, and better separation of concerns, it is poised to replace the traditional Ingress API. Organizations looking for more flexibility, security, and scalability in their Kubernetes networking should start exploring Gateway API today.

With its growing adoption and vendor support (Istio, Contour, GKE, etc.), Gateway API is the future of cloud-native networking.

Introduction

AWS Lambda is a powerful serverless compute service, but it comes with some constraints, including a 6MB payload limit for synchronous invocations. If your application needs to handle larger payloads, you might wonder how to address this limitation effectively. In this post, we’ll explore various strategies to overcome the 6MB limit and keep your architecture scalable and efficient.

1. Use S3 for Large Payloads

Offload large files or data to Amazon S3 and pass the S3 object key as an input to your Lambda function. This approach keeps the payload small and makes it easier to manage large datasets.

Workflow Example:

1. Upload the large payload to an S3 bucket.
2. Trigger the Lambda function with the S3 object key as input.
3. Fetch and process the object inside the Lambda function.

2. API Gateway Service Proxy

API Gateway can act as a service proxy to directly integrate with AWS services like S3. This approach avoids Lambda altogether and leverages API Gateway’s 10MB payload limit.

Benefits:

• Offloads processing from Lambda.
• Simplifies architecture by directly interacting with S3 or other AWS services.

3. Use Presigned S3 URLs

Generate presigned URLs to allow clients to upload large files directly to S3. This eliminates the need to send large payloads to Lambda or API Gateway.

Steps:

1. Generate a presigned URL from your backend application.
2. Share the URL with the client.
3. The client uploads the file directly to S3.

4. Lambda@Edge for Forwarding

Use Lambda@Edge with a CloudFront distribution to handle authentication and route requests directly to S3. This method provides a simple HTTP endpoint for clients but adds some operational complexity.

Use Case:

• Ideal for applications requiring secure, low-latency access to large files.

5. Presigned POST

Similar to presigned URLs, this method uses a POST policy to restrict file content type, size, and metadata. Clients upload files to S3 via HTTP POST, adhering to the provided restrictions.

Key Features:

• Greater control over uploads.
• Enables additional constraints like allowed file types.

Choosing the Right Approach

Each solution has trade-offs in complexity, scalability, and client-side implementation. Heres how to choose:

• Use S3 and presigned URLs for simplicity and scalability.
• Use API Gateway service proxy for integrating directly with AWS services.
• Use Lambda@Edge for applications requiring low latency or custom logic at the edge.

Conclusion

While the 6MB payload limit can be a constraint, AWS provides several tools and services to work around it effectively. By leveraging S3, presigned URLs, or API Gateway, you can handle large payloads without compromising scalability or performance.

Introduction

Effective tagging in AWS is essential for managing cloud resources efficiently. Proper tagging helps in cost tracking, access control, automation, and compliance. In this post, we will explore AWS tagging best practices and how they can benefit your organization.

Why Use AWS Tags?

AWS tags consist of key-value pairs that can be assigned to AWS resources. These tags help with:

• Cost Allocation: Track spending by project, team, or environment.
• Resource Organization: Easily group and identify resources.
• Access Control: Implement IAM policies based on tags.
• Automation: Enable automated processes based on tags.
• Security & Compliance: Improve visibility and apply security controls.

Best Practices for AWS Tagging

1. Define a Standardized Tagging Policy

Establish a consistent tagging strategy to ensure uniformity across teams. Example key categories include:

• Environment: env=production, env=staging, env=dev
• Project: project=customer-portal
• Owner: owner=john.doe
• Cost Center: cost-center=12345
• Compliance: compliance=PCI-DSS

2. Use a Tagging Enforcement Mechanism

Leverage AWS Organizations Service Control Policies (SCPs), AWS Config, or AWS Lambda functions to enforce tagging policies across your organization.

3. Keep Tags Simple and Consistent

Use clear and concise tag names with standardized capitalization and spacing conventions. Avoid redundant information in tags.

4. Leverage AWS Cost Allocation Tags

Enable cost allocation tags in AWS Billing and Cost Management to gain insights into cost distribution across projects and teams.

5. Implement Automation for Tagging

Use AWS Lambda, AWS Config rules, or Infrastructure as Code (IaC) tools like Terraform and CloudFormation to enforce and validate tags automatically.

6. Restrict Tag Modifications for Critical Resources

Use AWS IAM policies to restrict who can modify tags on critical resources, ensuring consistency and compliance.

7. Regularly Audit Tags

Perform regular audits using AWS Config, AWS Resource Groups, or custom scripts to ensure adherence to the tagging policy.

8. Document and Educate Teams

Create and maintain a tagging policy document and educate teams on its importance. Use AWS Tag Editor to manage and update tags efficiently.

Conclusion

Tagging is a crucial aspect of AWS resource management. A well-defined tagging strategy helps in cost optimization, security, and automation. By following these best practices, you can improve your cloud governance and streamline operations.

Introduction

Avaya, once a dominant player in the enterprise communication space, has twice filed for Chapter 11 bankruptcy, most recently in 2023. Despite its legacy and strong brand presence, the company faced financial struggles that ultimately led to widespread global layoffs. This serves as a cautionary tale for businesses, highlighting the dangers of poor financial management, failure to adapt to technological shifts, and lack of strategic vision.

The First Chapter 11 Bankruptcy (2017)

Avayas troubles began long before its first Chapter 11 filing in 2017. The company was spun off from Lucent Technologies in 2000 and later taken private by private equity firms Silver Lake and TPG Capital in 2007. While the move provided capital, it also burdened the company with significant debt.

By the time Avaya filed for Chapter 11 in January 2017, it was struggling with nearly $6 billion in debt. Despite being a leader in the Unified Communications (UC) and Contact Center (CC) markets, Avaya failed to transition effectively to cloud-based solutions, losing ground to competitors like Cisco, Microsoft, and emerging cloud-native providers such as RingCentral and Zoom. The restructuring process helped Avaya shed $3 billion in debt, allowing it to emerge from bankruptcy later that year.

The Second Chapter 11 Bankruptcy (2023)

Despite emerging from its first bankruptcy with a leaner balance sheet, Avaya continued to struggle with declining revenue and increasing competition. The company’s attempt to pivot to a subscription-based model was slow and poorly executed. Furthermore, mismanagement, leadership changes, and uncompetitive cloud offerings eroded customer confidence.

By 2023, Avaya faced another financial crisis, ultimately filing for Chapter 11 bankruptcy again in February. The restructuring plan wiped out previous shareholders, significantly reduced debt, and brought in new financing. However, the damage to Avaya’s reputation and customer trust was severe.

Global Layoffs and Market Impact

The financial instability led to massive global layoffs, affecting thousands of employees. Many skilled professionals found themselves jobless, and customers started looking for more stable alternatives. The layoffs were not just numbers on a balance sheet; they represented the loss of institutional knowledge, disrupted projects, and declining customer support quality.

Key Lessons from Avayas Fall

Avayas downfall provides critical lessons for businesses and technology firms:

1. Debt Can Be a Double-Edged Sword Leveraged buyouts can provide short-term capital but create long-term financial instability.
2. Adapt or Perish Failure to transition to cloud-based solutions and SaaS models cost Avaya its competitive edge.
3. Leadership and Strategy Matter Poor strategic decisions and leadership instability eroded customer and investor confidence.
4. Customer Trust is Fragile Losing customer trust due to poor service and financial instability can accelerate a companys decline.
5. Technology Evolves Rapidly Businesses must stay ahead of industry trends to remain relevant.

Conclusion

Avaya’s repeated Chapter 11 filings and global layoffs serve as a stark warning for technology companies and businesses in general. A strong brand and market presence do not guarantee success if a company fails to adapt, mismanages finances, and loses customer trust. As industries continue to evolve, businesses must remain agile, financially responsible, and strategically forward-thinking to avoid a similar fate.

Both n8n and Make.com (formerly Integromat) are powerful workflow automation tools, but they cater to different users and use cases. This guide compares features, flexibility, pricing, and ease of use to help you decide which one fits your needs.

Feature Comparison

Key Differences

1 Hosting Model:

• n8n Self-hosted or Cloud
• Make.com Cloud-only (No self-hosted option)

Who Wins? n8n (if you want full control & self-hosting)

2 Flexibility & Customization:

• n8n Allows JavaScript in function nodes, lets you create custom nodes, and provides low-level API access.
• Make.com More user-friendly, but less flexible (limited to built-in integrations).

Who Wins? n8n (if you need customization), Make.com (if you prefer a no-code approach)

3 Ease of Use:

• n8n More technical (requires basic programming knowledge for advanced use)
• Make.com Easier for beginners (drag-and-drop UI, prebuilt integrations)

Who Wins? Make.com (if you want an easy-to-use tool)

4 Pricing:

Who Wins? n8n (better for unlimited, self-hosted users), Make.com (cheaper for cloud users)

When to Choose n8n

You need a self-hosted solution for privacy or compliance
You want custom scripts & nodes for advanced automation
You prefer an open-source tool with no vendor lock-in
You work with APIs, databases, and webhooks frequently

When to Choose Make.com

You want an easy-to-use, drag-and-drop tool
You dont want to manage your own server
You need prebuilt integrations for common tools
You prefer low-code/no-code over scripting

Final Verdict

• For developers & self-hosting n8n
• For non-tech users & quick automation Make.com

If you’re technical and need control & flexibility, go with n8n.
If you want a simple, cloud-based automation tool, choose Make.com.

Introduction

Before Kubernetes 1.30, a Kubernetes Service guaranteed only a list of endpoints for routing traffic. However, there was no intelligent routing within that groupall traffic was randomly distributed across available endpoints. This default behavior worked well for most workloads but introduced inefficiencies when running clusters across multiple availability zones (AZs).

The iptables-based CNI would round-robin traffic, which could result in costly and unnecessary cross-zone data transfers. This inefficiency increases latency and networking costs in cloud environments.

Kubernetes 1.30+: Introducing trafficDistribution: PreferClose

Kubernetes 1.30 introduced the trafficDistribution: PreferClose feature, allowing preferential traffic routing to the closest available node. This feature significantly reduces cross-zone network overhead and improves performance by directing traffic to the nearest node with available endpoints.

How PreferClose Works

With trafficDistribution: PreferClose, Kubernetes prioritizes routing traffic to the topologically closest node based on cluster-level metrics. The system considers factors like:

• Same node (if an endpoint is available)
• Same availability zone (AZ)
• Same region (if no closer endpoint exists)

By favoring proximity-based routing, workloads experience lower latency and optimized network efficiency.

Enabling PreferClose in Kubernetes 1.30+

Starting with Kubernetes 1.31, the feature is enabled by default through the ServiceTrafficDistribution feature gate:

1
2
3
4
5

# API Server
--feature-gates="ServiceTrafficDistribution=true"

# kube-proxy
--feature-gates="ServiceTrafficDistribution=true"

In Kubernetes 1.30, you need to enable this manually.

Configuring a Kubernetes Service with PreferClose

To use PreferClose, update your Service manifest:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    service.kubernetes.io/topology-mode: auto  # Enable Topology Aware Routing
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  trafficDistribution: PreferClose

Key Components Explained

• service.kubernetes.io/topology-mode: auto Enables Topology Aware Routing.
• trafficDistribution: PreferClose Ensures traffic prioritization to nearest available endpoints.

Benefits of PreferClose

• Reduced Cross-Zone Costs: Avoid unnecessary data transfer charges between AZs.
• Lower Latency: Traffic stays within the nearest node or AZ.
• Improved Network Efficiency: Optimizes Kubernetes networking by reducing bottlenecks.

Considerations & Limitations

• Availability of Endpoints: If no endpoints exist in the preferred zone, Kubernetes will fallback to other available zones.
• Load Balancer Behavior: Some cloud providers might have additional routing constraints beyond Kubernetes.
• Works Best with Multi-AZ Deployments: Ideal for large-scale clusters spanning multiple zones or regions.

Final Thoughts

With Kubernetes 1.30+, the introduction of PreferClose for trafficDistribution revolutionizes how Services handle traffic routing. By reducing cross-zone latency and costs, Kubernetes clusters can run more efficiently while ensuring optimal performance for workloads.

If you’re running Kubernetes in a multi-AZ setup, upgrading to Kubernetes 1.30+ and enabling PreferClose can significantly enhance your networking strategy.

Install Ollama

Ollama is a lightweight environment for running LLMs locally. Download and install it from the official website.

Windows users: After installation, log out and log back in to apply system variables correctly.

Run DeepSeek 14B

Ollama will automatically download the model upon first execution.

• Run DeepSeek 7B (default model):

  1	ollama run deepseek-r1

• Run DeepSeek 14B (requires 16GB VRAM):

  1	ollama run deepseek-r1:14b

Configure Environment Variables (Optional)

To enable external access, set the following environment variables:

• Windows:

  1 2	setx OLLAMA_HOST "0.0.0.0:11434" setx OLLAMA_MODELS "%USERPROFILE%\.ollama\models"

• Linux/macOS:

  1 2	export OLLAMA_HOST="0.0.0.0:11434" export OLLAMA_MODELS="$HOME/.ollama/models"

Start Ollama Server

To run Ollama as a background service and allow remote access:

1

ollama serve

Ollama will now listen on port 11434, making it accessible locally and remotely.

Test Your Deployment

After launching, run:

1

ollama run deepseek-r1:14b

Alternatively, use Ollama API:

1
2
3
4
5

curl http://localhost:11434/api/generate -d '{
    "model": "deepseek-r1:14b",
    "prompt": "Hello, introduce the features of DeepSeek 14B",
    "stream": false
}'

Exit Ollama

To stop Ollama, you can simply close the terminal or type:

1

/bye

Summary

Ollama provides a lightweight local environment for running LLMs
DeepSeek 14B requires 16GB+ VRAM
Set OLLAMA_HOST to enable remote access
Run ollama serve to start the API server