Virtual Thoughts

Virtualisation, Storage and various other ramblings.

Page 17 of 24

vSphere and Containers part 1 – VIC (VMware Integrated Containers)

In this multi-part series, we evaluate the options available to vSphere users/customers wishing to deploy a native container service into an existing vSphere environment.

Part 1 – VIC (VMware Integrated Containers).

Part 2 – PKS (Pivotal Container Service).

Why should we care about containers?

Containers change the way we fundamentally look at application deployment and development. There was a huge shift in the way we managed platforms when server virtualisation came around – all of a sudden we had greater levels of flexibility, elasticity and redundancy compared to physical implementations. Consequently, the way in which applications were developed and deployed changed. And here we are again, with the next step of innovation using technology that is making rifts in the industry, changing the way consume resources.

 

What is VIC?

VIC (or vSphere Integrated Containers) is a native extension to the vSphere platform that facilitates container technology, because of this tight integration we’re able to perform actions and activities using the vSphere client and integrate it with auxiliary services. VIC is developed in such a way so it presents a Docker Compatible API endpoint. Therefore Ops/Dev staff already familiar with Docker can leverage VIC using the same tools/commands that they’re already familiar with.

VIC is a culmination of three technologies:

 

The containers engine is the core runtime technology that facilitates containerised applications in a vSphere environment. As previously mentioned, this engine presents a Docker-compatible API for consumption. Tight integration between this and vSphere enables vSphere admins to manage container and VM workloads in a consistent way.

 

 

Harbour is an enterprise-level facilitator of Docker-based image retrieval and distribution. It’s considered an extension of the open source Docker Distribution by adding features and constructs that are beneficial to the enterprise including but not limited to : LDAP support, Role-based access control, GUI control and much more.

 

 

Admiral is a scalable and lightweight container management platform for managing containers and associated applications. Primary responsibilities are mainly around automated deployment and lifecycle management of containers.

How VIC works

The management plane of VIC is facilitated by a OVA appliance, rather than going through the installation steps here, I will simply point to the direction of the (excellent) documentation located at https://vmware.github.io/vic-product/#documentation. At the core though, we have the following constructs:

  • VIC Appliance – Management plane.
  • Virtual Container HostsInfrastructure resource with a docker endpoint.
  • Registry – Location for Docker-compatible images.

 

Which, from a logical view looks like this:

 

Key observations are:

  • The VCH (Virtual Container Host) isn’t a Virtual machine, it’s actually a resource pool. Therefore, I think the best way to describe a VCH is a logical representation of a pool of resources, including clustering, scheduling, vMotion, HA, and other features.
  • When a VCH is created, a VM is created that facilitates the Docker-compatible API endpoint.

 

Advantages of VIC

So why would any of us consider VIC instead of, for example, standard Docker hosts? Here are a few points I’ve come across:

  1. Native integration into vSphere.
  2. Administrators can secure  and manage VM and Container resources in the same way.
  3. Easy integration into other VMware products.
    1. NSX.
    2. VSAN.
    3. vRealize Network Insight.
    4. vRealize Orchestrator.
    5. vRealize Automation.
  4. Eases adoption.
  5. Eases security.
  6. Eases management.

Conclusion

VIC helps bridge the gap between Developers and Administrators when it comes to the world of containers. I would say VIC is still in its infancy in terms of development, but it’s being backed by a great team and I think it’s going to make a compelling option for vSphere customers/users looking to embrace the container world, whilst maintaining a predictable, consistent security and management model.

My Technology Hitlist for 2018

It’s time for me to set a few objectives with which technologies I want to learn more about in 2018. As a reminder for me and to try and not lose focus, I’ve compiled it into a blog post.

 

vRealize Automation / Orchestration

I’ve always dabbled in automation and orchestration but never really gone “full on”.  I used to write a lot of scripts for migrations and such “back in the day”, so I’ll be looking forward to getting my hands dirty again and messing around with automating and orchestrating….all the things.

 

Docker / Containers

My career pretty much started with mainstream x86 server virtualisation. P2V’s were rife and everyone was losing their minds with technologies such as vMotion. The industry has changed now, and I personally feel the next wave of change in the way we manage applications and the underlying operating system libraries is with containers. Docker is leading the charge and this ties nicely with Automation and Orchestration. VMware integrated containers intrigues me as well, as it bridges a gap between the ops teams that are used to, and familiar with vSphere but are experiencing even more demand to provision, manage, secure and automate containers.

Containers are nothing new and are currently loved by the likes of developers, but from what I’ve read/heard/seen, typical enterprises are approaching with caution.

Kubernetes

Pretty much a follow on from containers. This, in my opinion, is the key driver to take [insert container engine of choice] to prime time, typical enterprise consumption. We all know the likes of Netflix, Facebook, Google are already using containers en masse and with an eye-watering amount of orchestration behind it, but I personally think the uptake from typical enterprises is a lot slower, particularly outside of Dev/Test but we’re getting there.

 

NSX-T

Fitting in with VMware’s ethos of any cloud, any device, anywhere, NSX-T sits as the hyperivsor-agnostic SDN solution. Having already dabbled quite a lot in NSX-V, I’d like to know more about NSX-T and the auxiliary technologies.

 

Google Cloud

Although some would consider late to the game, I think Google Cloud has potential. I’m already familiar with AWS and I think it’s a good idea to learn another cloud technology, so GCP it is.

Why not Azure? – I’m just not a Microsoft person anymore. Years ago (before Azure was even a thing) I used to be all over Windows Server, AD, Exchange, Group Policies, IIS, DHCP, WSUS etc, took the exams etc. After years of managing this ecosystem, I lost my enthusiasm for it. Bodged windows updates, Windows Server “quirks” and the like – couldn’t deal with it. Therefore I stay away.

“%20” free space on my NIC card? Good job, Windows.

Heck, if work would permit it, I’d run Linux on my company laptop.

Certifications?

Ideally this year I’d like to get:

  • VCIX-NV
  • Docker Certified Associate
  • Certified Kubernetes Administrator
  • VCP7-CMA

 

Understanding Data Center traffic flow using NSX-V capabilities

The defining characteristic of the Software Defined Data Center (SDDC), as the name implies, is to bring the intelligence and operations of various datacenter functions into software. This type of integration provides us with the ability to gain insights and analytics in a much more controlled, tightly integrated fashion.

VMware NSX is the market leader in network virtualisation. In this post, we have a look at a selection of tools which come with NSX, enabling a greater understanding of exactly what is transpiring in our NSX environment.

 

What we do now

Before diving into NSX-V traffic flow capabilities, let’s take a step back into how some organisations may approach identifying traffic flows currently by taking a simple example issue:

“Server A can’t talk to Server B on port 8443”

In this example, we assume that Server B is listening on port 8443.

Here are a few tools/methods that can be used to help identify the root cause

 

What these tools/methods have in common are:

 

  • Disjointed – Treated as separate, discrete exercises.
  • Isolated – Requires specific tools/skillsets.
  • Decentralised – Analysis requires output to be crossed referenced and analysed manually.

 

How NSX-V native tools can help

NSX-V provides us with a number tools to help us gain a deeper understanding of our network environment as well as provide accelerated troubleshooting and root cause analysis. These can be found via the vCenter client:

 

Flow Monitoring

Flow Monitoring is one of the traffic analysis tools that provide a detailed view of the traffic originating and terminating at virtual machines. One example use case of this is to determine in real time the traffic flows originating from a virtual machine – the below example demonstrating this. No agent or VM configuration is needed, unlike with Wireshark – NSX does this all natively without any modifications to the VM:

 

The VM in the example above has an IP of 172.16.201.10. We can see that itself is making DNS calls out to 8.8.8.8 as well as communicating with another machine with an IP of 172.16.200.10 over port 8443.

Endpoint Monitoring

 

Endpoint Monitoring enables us to map specific processes inside a guest operating system to network connections that are facilitating this traffic. This is helpful for gaining insight into application-layer details. The examples shown below demonstrate NSX’s ability to identify:

  • The source of the flow (process or application)
  • The source VM
  • The destination (can be any destination)
  • Traffic Type

 

 

 

Traceflow

Traceflow acts as a very useful diagnostic tool. Compared to flow monitoring, which takes a real-time view of network traffic, traceflow allows us to simulate traffic by synthetically “injecting” this traffic into our environment and monitoring the data path. In this example a test was executed for connectivity from a web server to an App server over port 8443:

 

NSX has informed us that this packet was dropped due a firewall rule – it also gives us the Rule ID in question. We can click on this link to get more information about this rule:

 

Once this rule was modified we can re-run the test, which shows this traffic has been successfully delivered to the target VM.

Traceflow also gives us an idea as to the journey our packet has travelled. From the above output we can see that this packet has traversed two logical switches, two ESXi hosts, one distributed logical router, and has forwarded through the distributed firewall running on the vNIC’s of two VM’s:

 

 

Packet Capture

The Packet Capture feature in NSX-V enables us to generate packet traces from physical ESXi hosts should we wish to perform any troubleshooting at that level.

These captures are done on a per-host level and we can specify to gather packet captures from one of the following interface types:

  • Physical NIC
  • VMKernel Interface
  • vNIC
  • vDR Port

Or from one of the respective filter types. Once started NSX will start gathering packet logs. Once the session has stopped these can be downloaded as .PCAP files which can be opened with a tool such as Wireshark

 

Conclusion

As organisations are adopting software-defined technologies, the tools and processes we use must also change. Thankfully, NSX-V has a plethora of native capabilities to observe, identify and troubleshoot software-defined networks.

« Older posts Newer posts »

© 2025 Virtual Thoughts

Theme by Anders NorenUp ↑

Social media & sharing icons powered by UltimatelySocial
RSS
Twitter
Visit Us
Follow Me