Table of Contents. Section 1: Overview 3 NetScaler Summary 3 NetScaler CPX Overview 3

Transcription

1

2 Table of Contents Section 1: Overview 3 NetScaler Summary 3 NetScaler CPX Overview 3 Microservices Enabling cloud native applications: 4 Introduction to Microservices: 4 Container cluster management tools 4 Kubernetes: 5 Kubernetes Architecture: 5 Components of Kubernetes Master: 5 Components of Kubernetes Node: 5 Kubernetes Design: 6 Kubernetes Commands: 6 Ingress Controller Why it is required: 7 The ingress controller can be configured to give the following set of services: 7 Use Cases of NetScaler in Kubernetes: 7 Service Discovery: 7 Visibility: 7 NetScaler MAS as Kubernetes Ingress Controller: 8 Ingress Controller: 8 Ingress Device: 8 CPX Form Factor: 9 VPX/MPX/SDX: 10 Configuration of Kubernetes Cluster for NetScaler CPX 11 Extract fingerprint from NetScaler MAS 11 Diagram with VPX/MPX as Ingress controller: Configuration of NetScaler MAS for Container Management: 12 NetScaler CPX as Kube-proxy replacement: 12 Kube-proxy 12 Steps to register CPX with the MAS and act as kube-proxy for the node: Extract fingerprint from NetScaler MAS Create YAML File(s) Label the CPX Nodes Create the CPX instances 15 Daemonset: 16 Conclusion: 16 Reference Links: 17

3 Citrix NetScaler is an all-in-one application delivery controller that makes applications run up to five times better, reduces application ownership costs, optimizes the user experience and ensures that applications are always available by using: Advanced L4-7 load balancing and traffic management Proven application acceleration such as HTTP compression and caching An integrated application firewall for application security Server offloading to significantly reduce costs and consolidate servers As an undisputed leader of service and application delivery, Citrix NetScaler is deployed in thousands of networks around the world to optimize, secure and control the delivery of all enterprise and cloud services. Deployed directly in front of web and database servers, NetScaler combines high-speed load balancing and content switching, http compression, content caching, SSL acceleration, application flow visibility and a powerful application firewall into an integrated, easy-to-use platform. Meeting SLAs is greatly simplified with end-to-end monitoring that transforms network data into actionable business intelligence. NetScaler allows policies to be defined and managed using a simple declarative policy engine with no programming expertise required. Users and customers prefer their applications to be available from anywhere and on any device. As a result, enterprises are increasingly developing cloud native applications using microservice architecture. A microservice architecture provides benefits which makes it a perfect fit for cloud native applications: 1. Deploy applications in shorter period of time 2. Scale Up/Down in seamless fashion 3. Continuous delivery Push the new features/fix to production without impacting end user traffic 4. Allow each microservice to be under the control of a specific development team. 5. Ability to use the best programming language for a particular microservice. There are tools available to manage the microservices deployment, but still some challenges remain. They are as follows: 1. Lack of visibility into the North-South and inter services traffic (East West) which makes it hard to troubleshoot application performance issues 2. Lack of Security 3. Failure handling This document s focus is on how NetScaler solves these challenges and how NetScaler can be inserted into a miroservices architecture. This document includes: 1. Introduction to microservices architecture and management tools 2. Design/Deployment guidelines on using NetScaler in Kubernetes container cluster environment

4 Introduction to Microservices: Microservices refer to decomposing a monolithic application into a number of different small lightweight applications. Containers are light weight and fit perfectly for this type of requirement and is the predominant form factor in the microservices world Microservices architecture should provide the below set of services: 1. Ability to spin up new services 2. Ability to scale up/down the new services based on traffic 3. New services should be published so that it is discovered automatically Increasingly the above services are provided container cluster management tools. Some of the popular tools are: 1. Kubernetes 2. Apache Mesos and Marathon 3. Amazon Container service 4. Google Container Engine (GKE) 5. Azure Container Service 6. Docker Swarm and Datacenter Kubernetes and Apache Mesos can work in multi/hybrid cloud environment. Kubernetes is increasingly becoming a popular choice as container cluster management platform and this document focuses on NetScaler s integration with Kubernetes

5 Kubernetes Architecture: Kubernetes manages a cluster of nodes. One of the nodes will be the master and the rest of the nodes will host the applications. 1. Etcd - A persistent lightweight distributed key-value data store that stores the state of the cluster and it nodes. 2. API server Clients can use the API server to access the etcd key-value store and it enables clients to configure new services in the cluster 3. Scheduler Selects the nodes on which a new pod/application should be launched based on the current CPU/ Memory/Disk Usage 4. Controller manager It is responsible for updating the API server on new nodes and service endpoints created 1. Kubelet It is responsible for starting the services on a particular node based on the requests from API server 2. Kube-proxy Responsible for routing traffic to the appropriate container based on IP address and port number and provides basic load balancing capability using round robin load balancing algorithim 3. cadvisor Gathers CPU, memory usage and passes the data to the Kubernetes Master

6 Kubernetes provides a set of blocks which can be used to deploy and scale applications. The basic scheduling unit is called a pod. A pod consists of one or more container applications that are guaranteed to be co-located on the same node. Each pod is assigned a unique IP address. A service is a set of pods that work together. A set of pods that constitute a service are defined by label selector and have reachable IP address called endpoints. Below is sample output of kubectl commands which lists the services and pods: root@ubuntu# kubectl get services NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend /TCP 13d kubernetes <none> 443/TCP 33d redis-master <none> 6379/TCP 13d redis-slave <none> 6379/TCP 13d root@ubuntu# kubectl get pods NAME READY STATUS RESTARTS AGE cpx-1 1/1 Running 0 11d cpx-3 1/1 Running 0 11d cpx-4 1/1 Running 0 11d

7 kubectl get pods - CONT'D frontend qdv6 1/1 Running 0 13d frontend fjx61 1/1 Running 0 13d frontend j1prp 1/1 Running 0 13d redis-master tw 1/1 Running 0 13d redis-slave b8l3 1/1 Running 0 13d redis-slave n80fb 1/1 Running 0 13d root@cpxkube-4:~# Usually services and pods have IP address which are routable only inside the cluster network An ingress controller is collection of rules which allow the end client/user connections to reach respective application/service hosted in the kubernetes cluster. 1. Publish externally reachable url for applications hosted on kubernetes 2. Load balance traffic 3. SSL offload The use cases are: 1. NetScaler acting as ingress-controller for North-South and East-West traffi c for front end apps 2. NetScaler as replacement for kube-proxy for East-West traffic within Kuberntes For both the above use cases NetScaler MAS is integral part of the deployment and it provides the following functionalities: Listens to the kube-api server and based on events makes the necessary configuration changes in the NetScaler using Stylebook/NITRO API s Provides application performance analytics and it helps the administrator in the below areas using Applica tion performance analytics and app scoring. a. Whether the new changes to application has the desired effect b. Blue/Green Deployments c. Troubleshoot application performance issue.

8 Ingress Traffic Management consists of two parts: Ingress controller listes to kube-api for ingress related updates and makes necessary configurations changes to make it effective on the Ingress device Ingress device handles the incoming traffic and routes the traffic to the appropriate service based on the ingress rules configured and provides reverse proxy functionality. Since Ingress controller acts as entry point and it is in the path of N-S traffic, providing the below set of capabilities will add great value 1. Rewrite 2. SSL Offload 3. L4/L7 Rate Limit 4. L4/L7 DDoS Protection 5. Application performance and troubleshooting NetScaler + NetScaler MAS provides the above set of capabilities. NetScaler MAS using application health score can enable administrators to troubleshoot the issues NetScaler MAS + NetScaler acts as the Ingress controller. NetScaler MAS listens to the kube-api server and using stylebooks configures the NetScaler which does the actual routing. Background of Stylebooks: Stylebook is a feature in NetScaler MAS and it is template that can be used to create and manage complex NetScaler configurations. In this case, customer has an option to provide the LB methods, persistency etc. in the stylebook and the stylebook using REST API s will configure the NetScaler. Below are the benefits of using NetScaler as Ingress controller 1. Security (Ratelimit,DDoS Protection) 2. Analytics (Application performance troubleshooting) 3. Service discovery and automatic configuration using NetScaler MAS + Stylebooks

9 Flow diagram with NetScaler as ingress controller Customer can choose either CPX or VPX/MPX/SDX as the ingress controller. For many customers, the use hardware-based approach with MPX or SDX versus a software based approach with VPX and CPX depends on how far they have move towards a microservices architecture. Customers who have started the journey may leverage an available MPX or SDX in front of Kubernetes, especially if they need to go into production for large clusters. For smaller clusters, the CPX would be suitable. There are pros and cons for each of the form factor: Pros: 1. No additional integration required for participating in the overlay network 2. CPX can be spun up or down through Kubernetes automatically. 3. Kubernetes replication controller can be used for maintaining HA Cons: 1. Limited throughput to < 10 Gbps 2. Web Applifcation Firewall is not supported in CPX

10 Pros: 1. All NetScaler features are available 2. High scale throughput and SSL performance 3. Availability of clustering Cons: 1. Need additional integration in participating in the overlay network Customer s choice on VPX/MPX vs CPX depends on the performance requirement and the features required. CPX with multi core can scale upto 7000 SSL TPS and 10Gbps of throughput. But if the customer's requirement is beyond the above numbers then VPX/MPX should be choosen as Ingress device

11 Below is the command to add the CPX as Ingress controller docker run -dt --privileged=true -p 5080:80 -p 5443:443 -p 80:5080 -e NS_HTTP_PORT=5080 -p 443:5443 -e NS_HTTPS_PORT=5443 -e EULA=yes -e NS_MGMT_SERVER=<MAS-IP> -e NS_MGMT_FINGER_PRINT="9C:2C:E7:64:38:C9:97:F1:0A:55:47:16:70:07:5B:70:B- B:25:32:A3" -e NS_ROUTABLE=FALSE -e NS_LB_ROLE=SERVER -e HOST=$HOSTNAME :5000/cpx:latest Run the above command on the Kubernetes Master for registering CPX to the NetScaler MAS and act as ingress controller Get the fingerprint from the MAS using the below steps bash-2.05b# more fingerprint.sh #!/bin/sh CHOST=${1:-localhost} echo openssl s_client -connect $CHOST:443 openssl x509 -fingerprint -noout cut -d'=' - f2 bash-2.05b# pwd /root bash-2.05b# ls.bash_history.ssh bash-2.05b# sh fingerprint.sh depth=0 C = US, ST = California, L = San Jose, O = Citrix NetScaler, OU = Internal, CN = Test Only Cert verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = California, L = San Jose, O = Citrix NetScaler, OU = Internal, CN = Test Only Cert verify return:1 DONE 5F:97:C3:14:72:66:5E:C4:EB:E2:5B:9E:FA:D2:74:7F:AC:9D:59:F8 bash-2.05b#

12 Go to Menu -> Orchestration -> Container Orchestration Provide the kube-api url and the certificate/key for authentication purpose. Below is the NetScaler MAS snapshot. The cert/ key data is available in Kubernetes master node in the file /etc/kubernetes/admin.conf and the same should be used while adding the kube-api server url in the NetScaler MAS. Kube-proxy listens to the kube-api server and adds/removes iptables rules based on the addition/removal of services, so that the new services are accessible by the clients. CPX can replace kube-proxy and provides the below benefits: 1. Application health score: a. CPX is integrated with NetScaler MAS. CPX provides the telemetry data to the MAS and In NetScaler MAS applications can be defined and application performance analytics can be done on the microservices. Some of the use cases are listed below 2. SSL Offload 3. Rate Limit i. Health of the backend services can be monitored ii. Administrator can isolate the issue to particular node using the data from NetScaler MAS

13 Get the fingerprint from the MAS using the below steps bash-2.05b# more fingerprint.sh #!/bin/sh CHOST=${1:-localhost} echo openssl s_client -connect $CHOST:443 openssl x509 -fingerprint -noout cut -d'=' -f2 bash-2.05b# pwd /root bash-2.05b# ls.bash_history.ssh bash-2.05b# sh fingerprint.sh fingerprint.sh depth=0 C = US, ST = California, L = San Jose, O = Citrix NetScaler, OU = Internal, CN = Test Only Cert verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = California, L = San Jose, O = Citrix NetScaler, OU = Internal, CN = Test Only Cert verify return:1 DONE 5F:97:C3:14:72:66:5E:C4:EB:E2:5B:9E:FA:D2:74:7F:AC:9D:59:F8 bash-2.05b# Last line in the above output (5F:97:C3:14:72:66:5E:C4:EB:E2:5B:9E:FA:D2:74:7F:AC:9D:59:F8) is the fingerprint and this value should be used by the CPX in registering with the NetScaler MAS.

14 Sample YAML file format:

15 The table below defines values for some of the most commom key fields in the yaml file: Field ImagePullPolicy This field indicates whether the docker image should be downloaded from the docker repository everytime the cpx is started. nodeselector: Kube_no The label on which the cpx should be started. Label and kubernetes node are key value pairs and created using the command kubectl label nodes cpxkube-1 Kube_no=minion_ NS_MGMT_SERVER NS_MGMT_FINGER NetScaler MAS IP Finger print of MAS and used in registration Label the nodes using the below command. In the below command cpxkube-1 is one of the nodes in kuber netes cluster. kubectl label nodes cpxkube-1 Kube_no=minion_1 Start using kubectl f create cpx_1.yaml The last step of kubectl f create needs to be repeated for each of the nodes in the cluster. After the cpx is launched the CPX will get register itself with NetScaler MAS. NetScaler MAS using Stylebook/NITRO APIs will configure the CPX based on the events received from kube-api. da

16 Another approach to launch CPX as kube-proxy on the all nodes would be daemonset. A key advatnage of using daemonset is that the administrator need not launc cpx from each master node because daemonset configuration will take care of launching CPX on all the cluster nodes. Below is the yamlfile with daemonset configuration: NetScaler along with NetScaler MAS solves the below challenges faced in deploying microservice environment 1. Reliable/secure delivery of requests 2. Failure handling of services 3. Visibility into application traffi c and ability to troubleshoot application performance issues using applica tion health score

17 NetScaler CPX Datasheet: Cluster Management Tools: Kubernetes reference Material: Lyft Engineering Reference:

18 About Citrix Citrix (NASDAQ:CTXS) is a leader in mobile workspaces, providing virtualization, mobility management, networking and cloud services to enable new ways to work better. Citrix solutions power business mobility through secure, personal workspaces that provide people with instant access to apps, desktops, data and communications on any device, over any network and cloud. This year Citrix is celebrating 25 years of innovation, making IT simpler and people more productive. With annual revenue in 2013 of $2.9 billion, Citrix solutions are in use at more than 330,000 organizations and by over 100 million users globally. Learn more at Copyright 2014 Citrix Systems, Inc. All rights reserved. Citrix, NetScaler MPX, NetScaler SDX, NetScaler, CloudBridge and AppFlow are trademarks of Citrix Systems, Inc. and/or one of its subsidiaries, and may be registered in the U.S. and other countries. Other product and company names mentioned herein may be trademarks of their respective companies.