text:
Kyma allows you to connect applications and third-party services in a cloud-native environment. Use it to create extensions for the existing systems, regardless of the language they are written in. Customize extensions with minimum effort and time devoted to learning their configuration details.
With Kyma in hand, you can focus purely on coding since it ensures the following out-of-the-box functionalities:
- Service-to-service communication and proxying (Istio Service Mesh)
- In-built monitoring, tracing, and logging (Grafana, Prometheus, Jaeger, Loki)
- Secure authentication and authorization (Dex, Service Identity, TLS, Role Based Access Control)
- The catalog of services to choose from (Service Catalog, Service Brokers)
- The development platform to run lightweight functions in a cost-efficient and scalable way (Serverless, Kubeless)
- The endpoint to register Events and APIs of external applications (Application Connector)
- The messaging channel to receive Events, enrich them, and trigger business flows using lambdas or services (Event Bus, NATS)
- CLI supported by the intuitive UI (Console)
Major open-source and cloud-native projects, such as Istio, NATS, Kubeless, and Prometheus, constitute the cornerstone of Kyma. Its uniqueness, however, lies in the "glue" that holds these components together. Kyma collects those cutting-edge solutions in one place and combines them with the in-house developed features that allow you to connect and extend your enterprise applications easily and intuitively.
Kyma allows you to extend and customize the functionality of your products in a quick and modern way, using serverless computing or microservice architecture. The extensions and customizations you create are decoupled from the core applications, which means that:
- Deployments are quick.
- Scaling is independent from the core applications.
- The changes you make can be easily reverted without causing downtime of the production system.
Last but not least, Kyma is highly cost-efficient. All Kyma native components and the connected open-source tools are written in Go. It ensures low memory consumption and reduced maintenance costs compared to applications written in other programming languages such as Java.
The entire solution is containerized and runs on a Kubernetes cluster. Customers can access it easily using a single sign on solution based on the Dex identity provider integrated with any OpenID Connect-compliant identity provider or a SAML2-based enterprise authentication server.
The communication between services is handled by the Istio Service Mesh component which enables security, traffic management, routing, resilience (retry, circuit breaker, timeouts), monitoring, and tracing without the need to change the application code. Build your applications using services provisioned by one of the many Service Brokers compatible with the Open Service Broker API, and monitor the speed and efficiency of your solutions using Prometheus, which gives you the most accurate and up-to-date monitoring data.
Kyma is built of numerous components but these three drive it forward:
- Application Connector:
- Simplifies and secures the connection between external systems and Kyma
- Registers external Events and APIs in the Service Catalog and simplifies the API usage
- Provides asynchronous communication with services and lambdas deployed in Kyma through Events
- Manages secure access to external systems
- Provides monitoring and tracing capabilities to facilitate operational aspects
- Serverless:
- Ensures quick deployments following a lambda function approach
- Enables scaling independent of the core applications
- Gives a possibility to revert changes without causing production system downtime
- Supports the complete asynchronous programming model
- Offers loose coupling of Event providers and consumers
- Enables flexible application scalability and availability
Service Catalog:
- Connects services from external sources
- Unifies the consumption of internal and external services thanks to compliance with the Open Service Broker standard
- Provides a standardized approach to managing the API consumption and access
- Eases the development effort by providing a catalog of API and Event documentation to support automatic client code generation
This basic use case shows how the three components work together in Kyma:
Integration with Knative is a step towards Kyma modularization and the "slimming" approach which aims to extract some out-of-the-box components and provide you with a more flexible choice of tools to use in Kyma.
Both Kyma and Knative are Kubernetes and Istio-based systems that offer development and eventing platforms. The main difference, however, is their focus. While Knative concentrates more on providing the building blocks for running serverless workloads, Kyma focuses on integrating those blocks with external services and applications.
The diagram shows dependencies between the components:
Kyma and Knative cooperation focuses on replacing Kyma eventing with Knative eventing, and Kyma Serverless with Knative serving.
Minikube allows you to run Kyma locally, develop, and test your solutions on a small scale before you push them to a cluster. With the Installation and Getting Started guides at hand, you can start developing in a matter of minutes.
Read, learn, and try on your own to:
- Install Kyma locally
- Install Kyma on a cluster
- Deploy a sample service locally
- Deploy a service on a cluster
- Develop a service locally without using Docker
- Publish a service Docker image and deploy it to Kyma
- Configure the Installer with override values for Helm charts
- Register a Broker in Service Catalog
- Create a new Application
- Get the client certificate
- Register a service
- Bind an Application to a Namespace
- Trigger a lambda with events
- Call a registered external service from Kyma
- Expose custom metrics in Kyma
Kyma is built on the foundation of the best and most advanced open-source projects which make up the components readily available for customers to use. This section describes the Kyma components.
The Service Catalog lists all of the services available to Kyma users through the registered Service Brokers. Use the Service Catalog to provision new services in the Kyma Kubernetes cluster and create bindings between the provisioned service and an application.
The Service Mesh is an infrastructure layer that handles service-to-service communication, proxying, service discovery, traceability, and security independent of the code of the services. Kyma uses the Istio Service Mesh that is customized for the specific needs of the implementation.
Kyma security enforces RBAC (Role Based Access Control) in the cluster. Dex handles the identity management and identity provider integration. It allows you to integrate any OpenID Connect or SAML2-compliant identity provider with Kyma using connectors. Additionally, Dex provides a static user store which gives you more flexibility when managing access to your cluster.
The Helm Broker is a Service Broker which runs in the Kyma cluster and deploys Kubernetes native resources using Helm and Kyma bundles. A bundle is an abstraction layer over a Helm chart which allows you to represent it as a ClusterServiceClass in the Service Catalog. Use bundles to install the GCP Broker and the Azure Service Broker in Kyma.
The Application Connector is a proprietary Kyma solution. This endpoint is the Kyma side of the connection between Kyma and the external solutions. The Application Connector allows you to register the APIs and the Event Catalog, which lists all of the available events, of the connected solution. Additionally, the Application Connector proxies the calls from Kyma to external APIs in a secure way.
Kyma Event Bus receives Events from external solutions and triggers the business logic created with lambda functions and services in Kyma. The Event Bus is based on the NATS Streaming open source messaging system for cloud-native applications.
The Kyma Serverless component allows you to reduce the implementation and operation effort of an application to the absolute minimum. Kyma Serverless provides a platform to run lightweight functions in a cost-efficient and scalable way using JavaScript and Node.js. Kyma Serverless is built on the Kubeless framework, which allows you to deploy lambda functions, and uses the NATS messaging system that monitors business events and triggers functions accordingly.
Kyma comes bundled with tools that give you the most accurate and up-to-date monitoring data. Prometheus open source monitoring and alerting toolkit provides this data, which is consumed by different add-ons, including Grafana for analytics and monitoring, and Alertmanager for handling alerts.
The tracing in Kyma uses the Jaeger distributed tracing system. Use it to analyze performance by scrutinizing the path of the requests sent to and from your service. This information helps you optimize the latency and performance of your solution.
Logging in Kyma uses Loki, a Prometheus-like log management system.
A Namespace is a security and organizational unit which allows you to divide the cluster into smaller units to use for different purposes, such as development and testing.
Namespaces available for users are marked with the
env: "true" label. The Kyma UI only displays the Namespaces marked with the
env: "true" label.
Kyma comes configured with default Namespaces dedicated for system-related purposes. The user cannot modify or remove any of these Namespaces.
kyma-system- This Namespace contains all of the Kyma Core components.
kyma-integration- This Namespace contains all of the Application Connector components responsible for the integration of Kyma and external solutions.
kyma-installer- This Namespace contains all of the Kyma Installer components, objects, and Secrets.
istio-system- This Namespace contains all of the Istio-related components.
Kyma comes with three Namespaces ready for you to use.
Create a Namespace and mark it with the
env: "true" label to make it available for Kyma users. Use this command to do that in a single step:
cat <<EOF | kubectl create -f -apiVersion: v1kind: Namespacemetadata: name: my-namespace labels: env: "true"EOF
Initially, the system deploys two template roles:
kyma-reader-role and
kyma-admin-role. The controller finds the template roles by filtering the roles available in the
kyma-system Namespace by the label
env: "true". The controller copies these roles into the newly created Namespace.
For testing, the Kyma components use the Helm test concept. Place your test under the
templates directory as a Pod definition that specifies a container with a given command to run.
The system bases tests on the Helm broker concept with one modification: adding a Pod label. Before you create a test, see the official Chart Tests documentation. Then, add the
"helm-chart-test": "true" label to your Pod template.
See the following example of a test prepared for Dex:
# Chart treedex├── Chart.yaml├── README.md├── templates│ ├── tests│ │ └── test-dex-connection.yaml│ ├── dex-deployment.yaml│ ├── dex-ingress.yaml│ ├── dex-rbac-role.yaml│ ├── dex-service.yaml│ ├── pre-install-dex-account.yaml│ ├── pre-install-dex-config-map.yaml│ └── pre-install-dex-secrets.yaml└── values.yaml
The test adds a new test-dex-connection.yaml under the
templates/tests directory.
This simple test calls the
Dex endpoint with cURL, defined as follows:
apiVersion: v1kind: Podmetadata: name: "test-{{ template "fullname" . }}-connection-dex" annotations: "helm.sh/hook": test-success labels: "helm-chart-test": "true" # ! Our customizationspec: hostNetwork: true containers: - name: "test-{{ template "fullname" . }}-connection-dex" image: tutum/curl:alpine command: ["/usr/bin/curl"] args: [ "--fail", "http://dex-service.{{ .Release.Namespace }}.svc.cluster.local:5556/.well-known/openid-configuration" ] restartPolicy: Never
All tests created for charts under
/resources/core/ run automatically after starting Kyma.
If any of the tests fail, the system prints the Pod logs in the terminal, then deletes all the Pods.
NOTE: If you run Kyma locally, by default, the system does not take into account the test's exit code. As a result, the system does not terminate Kyma Docker container, and you can still access it. To force a termination in case of failing tests, use
--exit-on-test-failflag when executing
CI propagates the exit status of tests. If any test fails, the whole CI job fails as well.
Follow the same guidelines to add a test which is not a part of any
core component. However, for test execution, see the Run a test manually section in this document.
To run a test manually, use the
testing.sh script located in the
/installation/scripts/ directory which runs all tests defined for
core releases.
If any of the tests fail, the system prints the Pod logs in the terminal, then deletes all the Pods.
Another option is to run a Helm test directly on your release.
helm test {your_release_name}
You can also run your test on custom releases. If you do this, remember to always delete the Pods after a test ends.
Kyma uses Helm charts to deliver single components and extensions, as well as the core components. This document contains information about the chart-related technical concepts, dependency management to use with Helm charts, and chart examples.
The ADR 003: Init Containers for dependency management document declares the use of Init Containers as the primary dependency mechanism.
Init Containers present a set of distinctive behaviors:
- They always run to completion.
- They start sequentially, only after the preceding Init Container completes successfully.
If any of the Init Containers fails, the Pod restarts. This is always true, unless the
Readiness Probes ensure that the essential containers are ready to handle requests before you expose them. At a minimum, probes are defined for every container accessible from outside of the Pod. It is recommended to pair the Init Containers with readiness probes to provide a basic dependency management solution.
Here are some examples:
- Generic
apiVersion: apps/v1beta2kind: Deploymentmetadata: name: nginx-deploymentspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 30 timeoutSeconds: 1
apiVersion: v1kind: Podmetadata: name: myapp-podspec: initContainers: - name: init-myservice image: busybox command: ['sh', '-c', 'until nslookup nginx; do echo waiting for nginx; sleep 2; done;'] containers: - name: myapp-container image: busybox command: ['sh', '-c', 'echo The app is running! && sleep 3600']
- Kyma
apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: helm-broker labels: app: helm-brokerspec: replicas: 1 selector: matchLabels: app: helm-broker strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 template: metadata: labels: app: helm-broker spec: initContainers: - name: init-helm-broker image: eu.gcr.io/kyma-project/alpine-net:0.2.74 command: ['sh', '-c', 'until nc -zv service-catalog-controller-manager.kyma-system.svc.cluster.local 8080; do echo waiting for etcd service; sleep 2; done;'] containers: - name: helm-broker ports: - containerPort: 6699 readinessProbe: tcpSocket: port: 6699 failureThreshold: 3 initialDelaySeconds: 10 periodSeconds: 3 successThreshold: 1 timeoutSeconds: 2
High level Kyma components, such as core, come as Helm charts. These charts are installed as part of a single Helm release. To provide ordering for these core components, the Helm client runs with the
--wait flag. As a result, Tiller waits for the readiness of all of the components, and then evaluates the readiness.
Deployments, set the strategy to
RollingUpdate and set the
MaxUnavailable value to a number lower than the number of replicas. This setting is necessary, as readiness in Helm v2.10.0 is fulfilled if the number of replicas in ready state is not lower than the expected number of replicas:
ReadyReplicas >= TotalReplicas - MaxUnavailable
The Tiller server performs the chart installation process. This is the order of operations that happen during the chart installation:
- resolve values
- recursively gather all templates with the corresponding values
- sort all templates
- render all templates
- separate hooks and manifests from files into sorted lists
- aggregate all valid manifests from all sub-charts into a single manifest file
- execute PreInstall hooks
- create a release using the ReleaseModule API and, if requested, wait for the actual readiness of the resources
- execute PostInstall hooks
All notes are based on Helm v2.10.0 implementation and are subject to change in future releases.
Regardless of how complex a chart is, and regardless of the number of sub-charts it references or consists of, it's always evaluated as one. This means that each Helm release is compiled into a single Kubernetes manifest file when applied on API server.
Hooks are parsed in the same order as manifest files and returned as a single, global list for the entire chart. For each hook the weight is calculated as a part of this sort.
Manifests are sorted by
Kind. You can find the list and the order of the resources on the Kubernetes Tiller website.
- resource is any document in a chart recognized by Helm or Tiller. This includes manifests, hooks, and notes.
- template is a valid Go template. Many of the resources are also Go templates.
Docker is a free tool to deploy applications and servers. To run an application on Kyma, provide the application binary file as a Docker image located in a Docker registry. Use the
DockerHub public registry to upload your Docker images for free access to the public. Use a private Docker registry to ensure privacy, increased security, and better availability.
This document shows how to deploy a Docker image from your private Docker registry to the Kyma cluster.
The deployment to Kyma from a private registry differs from the deployment from a public registry. You must provide Secrets accessible in Kyma, and referenced in the
.yaml deployment file. This section describes how to deploy an image from a private Docker registry to Kyma. Follow the deployment steps:
- Create a Secret resource.
- Write your deployment file.
- Submit the file to the Kyma cluster.
A Secret resource passes your Docker registry credentials to the Kyma cluster in an encrypted form. For more information on Secrets, refer to the Kubernetes documentation.
To create a Secret resource for your Docker registry, run the following command:
kubectl create secret docker-registry {secret-name} --docker-server={registry FQN} --docker-username={user-name} --docker-password={password} --docker-email={registry-email} --namespace={namespace}
Refer to the following example:
kubectl create secret docker-registry docker-registry-secret --docker-server=myregistry:5000 --docker-username=root --docker-password=password --firstname.lastname@example.com --namespace=production
The Secret is associated with a specific Namespace. In the example, the Namespace is
production. However, you can modify the Secret to point to any desired Namespace.
Create the deployment file with the
.ymlextension and name it
Describe your deployment in the
.ymlfile. Refer to the following example:
apiVersion: apps/v1beta2kind: Deploymentmetadata: namespace: production # {production/stage/qa} name: my-deployment # Specify the deployment name. annotations: sidecar.istio.io/inject: truespec: replicas: 3 # Specify your replica - how many instances you want from that deployment. selector: matchLabels: app: app-name # Specify the app label. It is optional but it is a good practice. template: metadata: labels: app: app-name # Specify app label. It is optional but it is a good practice. version: v1 # Specify your version. spec: containers: - name: container-name # Specify a meaningful container name. image: myregistry:5000/user-name/image-name:latest # Specify your image {registry FQN/your-username/your-space/image-name:image-version}. ports: - containerPort: 80 # Specify the port to your image. imagePullSecrets: - name: docker-registry-secret # Specify the same Secret name you generated in the previous step for this Namespace. - name: example-secret-name # Specify your Namespace Secret, named `example-secret-name`.
- Submit you deployment file using this command:
kubectl apply -f deployment.yml
Your deployment is now running on the Kyma cluster.
Kyma is a complex tool which consists of many different components that provide various functionalities to extend your application. This entails high technical requirements that can influence your local development process. To meet the customer needs, we ensured Kyma modularity. This way you can decide not to include a given component in the Kyma installation, or install it after the Kyma installation process.
To make the local development process easier, we introduced the Kyma Lite concept in which case some components are not included in the local installation process by default. These are the Kyma and Kyma Lite components:
|Kyma Lite
Follow these installation guides to install Kyma locally or on a cluster:
Read rest of the installation documents to learn how to:
- Disable the selected components' installation or install them separately
- Update Kyma
- Reinstall Kyma
- Get in-depth knowledge about the installation scripts
NOTE: Make sure to check whether the version of the documentation in the left pane of the
kyma-project.iois compatible with your Kyma version.
This Installation guide shows developers how to quickly deploy Kyma locally on the MacOS and Linux platforms. Kyma is installed locally using a proprietary installer based on a Kubernetes operator. The document provides prerequisites, instructions on how to install Kyma locally and verify the deployment, as well as the troubleshooting tips.
To run Kyma locally, clone this Git repository to your machine and check out the latest release.
Additionally, download these tools:
- Hyperkit driver - Mac only
- VirtualBox - Linux only
NOTE: To work with Kyma, use only the provided scripts and commands. Kyma does not work on a basic Minikube cluster that you can start using the
minikube startcommand.
Kyma comes with a local wildcard self-signed
server.crt certificate that you can find under the
/installation/certs/workspace/raw/ directory of the
kyma repository. Trust it on the OS level for convenience.
Follow these steps to "always trust" the Kyma certificate on MacOS:
Change the working directory to
installation:Click to copycd installation
Run this command:Click to copysudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain certs/workspace/raw/server.crt
NOTE: "Always trusting" the certificate does not work with Mozilla Firefox.
To access the Application Connector and connect an external solution to the local deployment of Kyma, you must add the certificate to the trusted certificate storage of your programming environment. Read this document to learn more.
You can install Kyma either with all core subcomponents or only with the selected ones. This section describes how to install Kyma with all core subcomponents. Read this document to learn how to install only the selected subcomponents.
CAUTION: Running the installation script deletes any previously existing cluster from your Minikube.
NOTE: Logging and Monitoring subcomponents are not included by default when you install Kyma on Minikube. You can install them using the instructions provided here.
Follow these instructions to install Kyma from a release or from local sources:
- From a release
- From sources
Change the working directory to
installation:Click to copycd installation
Use the following command to run Kubernetes locally using Minikube:Click to copy./scripts/minikube.sh --domain "kyma.local" --vm-driver "hyperkit"
Wait until the
kube-dnsPod is ready. Run this script to setup Tiller:Click to copy./scripts/install-tiller.sh
Go to this page and choose the latest release.
Export the release version as an environment variable. Run:Click to copyexport LATEST={KYMA_RELEASE_VERSION}
Deploy the Kyma Installer in your cluster from the
$LATESTrelease:Click to copykubectl apply -f https://github.com/kyma-project/kyma/releases/download/$LATEST/kyma-installer-local.yaml
Configure the Kyma installation using the local configuration file from the
$LATESTrelease:Click to copywget -qO- https://github.com/kyma-project/kyma/releases/download/$LATEST/kyma-config-local.yaml | sed "s/minikubeIP: \"\"/minikubeIP: \"$(minikube ip)\"/g" | kubectl apply -f -
To trigger the installation process, label the
kyma-installationcustom resource:Click to copykubectl label installation/kyma-installation action=install
By default, the Kyma installation is a background process, which allows you to perform other tasks in the terminal window. Nevertheless, you can track the progress of the installation by running this script:Click to copy./scripts/is-installed.sh
Read this document to learn how to reinstall Kyma without deleting the cluster from Minikube. To learn how to test Kyma, see this document.
Follow the guidelines in the subsections to confirm that your Kubernetes API Server is up and running as expected.
is-installed.sh script is designed to give you clear information about the Kyma installation. Run it at any point to get the current installation status, or to find out whether the installation is successful.
If the script indicates that the installation failed, try to install Kyma again by re-running the
run.sh script.
If the installation fails in a reproducible manner, don't hesitate to create a GitHub issue in the project or reach out to the "installation" Slack channel to get direct support from the community.
Access your local Kyma instance through this link.
- Click Login with Email and sign in with the email@example.com email address. Use the password contained in the
admin-userSecret located in the
kyma-systemNamespace. To get the password, run:
kubectl get secret admin-user -n kyma-system -o jsonpath="{.data.password}" | base64 -D
- Click the Namespaces section and select a Namespace from the drop-down menu to explore Kyma further.
By default, the Horizontal Pod Autoscaler (HPA) is not enabled in your local Kyma installation, so you need to enable it manually.
Kyma uses the
autoscaling/v1 stable version, which supports only CPU autoscaling. Once enabled, HPA automatically scales the number of lambda function Pods based on the observed CPU utilization.
NOTE: The
autoscaling/v1version does not support custom metrics. To use such metrics, you need the
Follow these steps to enable HPA:
Enable the metrics server for resource metrics by running the following command:Click to copyminikube addons enable metrics-server
Verify if the metrics server is active by checking the list of addons:Click to copyminikube addons list
Use the
minikube.sh script to restart the Minikube cluster without reinstalling Kyma. Follow these steps to stop and restart your cluster:
- Stop the Minikube cluster with Kyma installed. Run:Click to copyminikube stop
- Restart the cluster without reinstalling Kyma. Run:Click to copy./scripts/minikube.sh --domain "kyma.local" --vm-driver "hyperkit"
The script discovers that a Minikube cluster is initialized and asks if you want to delete it. Answering
no causes the script to start the Minikube cluster and restarts all of the previously installed components. Even though this procedure takes some time, it is faster than a clean installation as you don't download all of the required Docker images.
To verify that the restart is successful, run this command and check if all Pods have the
RUNNING status:
kubectl get pods --all-namespaces
If the Installer does not respond as expected, check the installation status using the
is-installed.shscript with the
--verboseflag added. Run:Click to copyscripts/is-installed.sh --verbose
If the installation is successful but a component does not behave in an expected way, see if all deployed Pods are running. Run this command:Click to copykubectl get pods --all-namespaces
The command retrieves all Pods from all Namespaces, the status of the Pods, and their instance numbers. Check if the STATUS column shows Running for all Pods. If any of the Pods that you require do not start successfully, perform the installation again.
If the problem persists, don't hesitate to create a GitHub issue or reach out to the "installation" Slack channel to get direct support from the community.
If you put your local running cluster into hibernation or use
minikube stopand
minikube startthe date and time settings of Minikube get out of sync with the system date and time settings. As a result, the access token used to log in cannot be properly validated by Dex and you cannot log in to the console. To fix that, set the date and time used by your machine in Minikube. Run:Click to copyminikube ssh -- docker run -i --rm --privileged --pid=host debian nsenter -t 1 -m -u -n -i date -u $(date -u +%m%d%H%M%Y)
This Installation guide shows developers how to quickly deploy Kyma on a cluster. Kyma is installed on a cluster using a proprietary installer based on a Kubernetes operator. By default, Kyma is installed on a cluster with a wildcard DNS provided by xip.io. Alternatively, you can provide your own domain for the cluster.
Follow these installation guides to install Kyma on a cluster depending on the supported cloud providers:
This Installation guide shows developers how to quickly deploy Kyma on a Google Kubernetes Engine (GKE) cluster.
- Google Cloud Platform (GCP) project with Kubernetes Engine API enabled
- kubectl 1.12.0
- Docker
- Docker Hub account
- gcloud
- wget
- A domain for your GKE cluster (optional)
TIP: Get a free domain for your cluster using services like freenom.com or similar.
Select a name for your cluster. Set the cluster name and the name of your GCP project as environment variables. Run:Click to copyexport CLUSTER_NAME={CLUSTER_NAME_YOU_WANT}export PROJECT={YOUR_GCP_PROJECT}
Create a cluster in the
europe-west1region. Run:Click to copygcloud container --project "$PROJECT" clusters \create "$CLUSTER_NAME" --zone "europe-west1-b" \--cluster-version "1.12.5" --machine-type "n1-standard-4" \--addons HorizontalPodAutoscaling,HttpLoadBalancing,KubernetesDashboard
Install Tiller on your GKE cluster. Run:Click to copykubectl apply -f https://raw.githubusercontent.com/kyma-project/kyma/{RELEASE_TAG}/installation/resources/tiller.yaml
Add your account as the cluster administrator:Click to copykubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account)
NOTE: Execute instructions from this section only if you want to use your own domain. Otherwise, proceed to Prepare the installation configuration file section.
Follow these steps:
Export the domain name, project name, and DNS zone name as environment variables. Run the commands listed below:Click to copyexport DOMAIN={YOUR_SUBDOMAIN}export DNS_NAME={YOUR_DOMAIN}.export PROJECT={YOUR_GOOGLE_PROJECT_ID}export DNS_ZONE={YOUR_DNS_ZONE}
Example:Click to copyexport DOMAIN=my.kyma-demo.gaexport DNS_NAME=kyma-demo.ga.export PROJECT=kyma-demo-235208export DNS_ZONE=myzone
Create a DNS-managed zone in your Google project. Run:Click to copygcloud dns --project=$PROJECT managed-zones create $DNS_ZONE --description= --dns-name=$DNS_NAME
Alternatively, create it through the GCP UI. Navigate go to Network Services in the Network section, click Cloud DNS and select Create Zone.
Delegate your domain to Google name servers.
- Get the list of the name servers from the zone details. This is a sample list:Click to copyns-cloud-b1.googledomains.com.ns-cloud-b2.googledomains.com.ns-cloud-b3.googledomains.com.ns-cloud-b4.googledomains.com.
- Set up your domain to use these name servers.
- Get the list of the name servers from the zone details. This is a sample list:
Check if everything is set up correctly and your domain is managed by Google name servers. Run:Click to copyhost -t ns $DNS_NAME
A successful response returns the list of the name servers you fetched from GCP.
Create a folder for certificates. Run:Click to copymkdir letsencrypt
Create a new service account and assign it to the
dns.adminrole. Run these commands:Click to copygcloud iam service-accounts create dnsmanager --display-name "dnsmanager" --project "$PROJECT"Click to copygcloud projects add-iam-policy-binding $PROJECT \--member serviceAccount:dnsmanager@$PROJECT.iam.gserviceaccount.com --role roles/dns.admin
Generate an access key for this account in the
letsencryptfolder. Run:Click to copygcloud iam service-accounts keys create ./letsencrypt/key.json --iam-account dnsmanager@$PROJECT.iam.gserviceaccount.com
Run the Certbot Docker image with the
letsencryptfolder mounted. Certbot uses the key to apply DNS challenge for the certificate request and stores the TLS certificates in that folder. Run:Click to copydocker run -it --name certbot --rm \-v "$(pwd)/letsencrypt:/etc/letsencrypt" \certbot/dns-google \certonly \-m YOUR_EMAIL_HERE --agree-tos --no-eff-email \--dns-google \--dns-google-credentials /etc/letsencrypt/key.json \--server https://acme-v02.api.letsencrypt.org/directory \-d "*.$DOMAIN"
Export the certificate and key as environment variables. Run these commands:Click to copyexport TLS_CERT=$(cat ./letsencrypt/live/$DOMAIN/fullchain.pem | base64 | sed 's/ /\\ /g')export TLS_KEY=$(cat ./letsencrypt/live/$DOMAIN/privkey.pem | base64 | sed 's/ /\\ /g')
NOTE: You can use Kyma version 0.8 or higher.
- Go to this page and choose the latest release.
Export the release version as an environment variable. Run:Click to copyexport LATEST={KYMA_RELEASE_VERSION}
Download the
kyma-installer-cluster.yamlfiles from the latest release. Run:Click to copywget https://github.com/kyma-project/kyma/releases/download/$LATEST/kyma-config-cluster.yamlwget https://github.com/kyma-project/kyma/releases/download/$LATEST/kyma-installer-cluster.yaml
Prepare the deployment file.
Click to copycat kyma-installer-cluster.yaml <(echo -e "\n---") kyma-config-cluster.yaml | sed -e "s/__.*__//g" > my-kyma.yaml
- Run this command if you use the
xip.iodefault domain:
Click to copycat kyma-installer-cluster.yaml <(echo -e "\n---") kyma-config-cluster.yaml | sed -e "s/__DOMAIN__/$DOMAIN/g" | sed -e "s/__TLS_CERT__/$TLS_CERT/g" | sed -e "s/__TLS_KEY__/$TLS_KEY/g" | sed -e "s/__.*__//g" > my-kyma.yaml
- Run this command if you use your own domain:
- Run this command if you use the
The output of this operation is the
my_kyma.yamlfile. Use it to deploy Kyma on your GKE cluster.
- Checkout kyma-project and enter the root folder.
Build an image that is based on the current Installer image and includes the current installation and resources charts. Run:Click to copydocker build -t kyma-installer:latest -f tools/kyma-installer/kyma.Dockerfile .
Push the image to your Docker Hub:Click to copydocker tag kyma-installer:latest {YOUR_DOCKER_LOGIN}/kyma-installer:latestdocker push {YOUR_DOCKER_LOGIN}/kyma-installer:latest
Prepare the deployment file:
Click to copy(cat installation/resources/installer.yaml ; echo "---" ; cat installation/resources/installer-config-cluster.yaml.tpl ; echo "---" ; cat installation/resources/installer-cr-cluster.yaml.tpl) | sed -e "s/__.*__//g" > my-kyma.yaml
- Run this command if you use the
xip.iodefault domain:
Click to copy(cat installation/resources/installer.yaml ; echo "---" ; cat installation/resources/installer-config-cluster.yaml.tpl ; echo "---" ; cat installation/resources/installer-cr-cluster.yaml.tpl) | sed -e "s/__DOMAIN__/$DOMAIN/g" |sed -e "s/__TLS_CERT__/$TLS_CERT/g" | sed -e "s/__TLS_KEY__/$TLS_KEY/g" | sed -e "s/__.*__//g" > my-kyma.yaml
- Run this command if you use your own domain:
- Run this command if you use the
The output of this operation is the
my_kyma.yamlfile. Modify it to fetch the proper image with the changes you made (/kyma-installer:latest). Use the modified file to deploy Kyma on your GKE cluster.
Configure kubectl to use your new cluster. Run:Click to copygcloud container clusters get-credentials $CLUSTER_NAME --zone europe-west1-b --project $PROJECT
Deploy Kyma using the
my-kymacustom configuration file you created. Run:Click to copykubectl apply -f my-kyma.yaml
Check if the Pods of Tiller and the Kyma Installer are running:Click to copykubectl get pods --all-namespaces
Start Kyma installation:Click to copykubectl label installation/kyma-installation action=install
To watch the installation progress, run:Click to copywhile true; do \kubectl -n default get installation/kyma-installation -o jsonpath="{'Status: '}{.status.state}{', description: '}{.status.description}"; echo; \sleep 5; \done
After the installation process is finished, the
Status: Installed, description: Kyma installedmessage appears. In case of an error, you can fetch the logs from the Installer by running:Click to copykubectl -n kyma-installer logs -l 'name=kyma-installer'
NOTE: Skip this section if you use your own domain.
After the installation, add the custom Kyma
xip.io self-signed certificate to the trusted certificates of your OS. For MacOS, run:
tmpfile=$(mktemp /tmp/temp-cert.XXXXXX) \&& kubectl get configmap net-global-overrides -n kyma-installer -o jsonpath='{.data.global\.ingress\.tlsCrt}' | base64 --decode > $tmpfile \&& sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain $tmpfile \&& rm $tmpfile
NOTE: Execute instructions from this section only if you want to use your own domain.
Export the domain of your cluster and DNS zone as environment variables. Run:Click to copyexport DOMAIN=$(kubectl get cm net-global-overrides -n kyma-installer -o jsonpath='{.data.global\.ingress\.domainName}')export DNS_ZONE={YOUR_DNS_ZONE}
To add DNS entries, run these commands:Click to copyexport EXTERNAL_PUBLIC_IP=$(kubectl get service -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0].ip}")export APISERVER_PUBLIC_IP=$(kubectl get service -n kyma-system apiserver-proxy-ssl -o jsonpath="{.status.loadBalancer.ingress[0].ip}")export REMOTE_ENV_IP=$(kubectl get service -n kyma-system application-connector-ingress-nginx-ingress-controller -o jsonpath="{.status.loadBalancer.ingress[0].ip}")gcloud dns --project=$PROJECT record-sets transaction start --zone=$DNS_ZONEgcloud dns --project=$PROJECT record-sets transaction add $EXTERNAL_PUBLIC_IP --name=\*.$DOMAIN. --ttl=60 --type=A --zone=$DNS_ZONEgcloud dns --project=$PROJECT record-sets transaction add $REMOTE_ENV_IP --name=\gateway.$DOMAIN. --ttl=60 --type=A --zone=$DNS_ZONEgcloud dns --project=$PROJECT record-sets transaction add $APISERVER_PUBLIC_IP --name=\apiserver.$DOMAIN. --ttl=60 --type=A --zone=$DNS_ZONEgcloud dns --project=$PROJECT record-sets transaction execute --zone=$DNS_ZONE
If you need to use Helm, you must establish a secure connection with Tiller by saving the cluster's client certificate, key, and Certificate Authority (CA) to Helm Home.
Additionally, you must add the
--tls flag to every Helm command you run.
NOTE: Read this document to learn more about TLS in Tiller.
Run these commands to save the client certificate, key, and CA to Helm Home:
kubectl get -n kyma-installer secret helm-secret -o jsonpath="{.data['global\.helm\.ca\.crt']}" | base64 --decode > "$(helm home)/ca.pem";kubectl get -n kyma-installer secret helm-secret -o jsonpath="{.data['global\.helm\.tls\.crt']}" | base64 --decode > "$(helm home)/cert.pem";kubectl get -n kyma-installer secret helm-secret -o jsonpath="{.data['global\.helm\.tls\.key']}" | base64 --decode > "$(helm home)/key.pem";
- To get the address of the cluster's Console, check the name of the Console's virtual service. The name of this virtual service corresponds to the Console URL. To get the virtual service name, run:
kubectl get virtualservice core-console -n kyma-system
- Access your cluster under this address:
NOTE: To log in to your cluster, use the default
adminstatic user. To learn how to get the login details for this user, see this document.
Since Kyma is modular, you can remove some components so that they are not installed together with Kyma. You can also add some of them after the installation process. Read this document to learn how to do that.
NOTE: Not all components can be simply removed from the Kyma installation. In case of Istio and the Service Catalog, you must provide your own deployment of these components in the Kyma-supported version before you remove them from the installation process. See this file to check the currently supported version of Istio. See this file to check the currently supported version of the Service Catalog.
To disable a component from the list of components that you install with Kyma, remove this component's entries from the appropriate file. The file differs depending on whether you install Kyma from the release or from sources, and if you install Kyma locally or on a cluster. The version of your component's deployment must match the version that Kyma currently supports.
- Download the newest version of Kyma.
- Customize installation by removing a component from the list of components in the Installation resource. For example, to disable the Application Connector installation, remove this entry:Click to copyname: "application-connector"namespace: "kyma-system"
- from the
kyma-config-local.yamlfile for the local installation
- from the
kyma-config-cluster.yamlfile for the cluster installation
- Follow the installation steps described in the Install Kyma locally from the release document, or Install Kyma on a GKE cluster accordingly.
- Customize installation by removing a component from the list of components in the following Installation resource:
- installer-cr.yaml.tpl for the local installation
- installer-cr-cluster.yaml.tpl for the cluster installation
- Follow the installation steps described in the Install Kyma locally from sources document, or Install Kyma on a GKE cluster accordingly.
- Check if all Pods are running in the
kyma-systemNamespace:Click to copykubectl get pods -n kyma-system
- Sign in to the Kyma Console using the
email@example.com address as described in the Install Kyma locally from the release document.
NOTE: This section assumes that you already have your Kyma Lite local version installed successfully.
To install a component that is not installed with Kyma by default, modify the Installation custom resource and add the component that you want to install to the list of components :
- Edit the resource:Click to copykubectl edit installation kyma-installation
- Add the new component to the list of components, for example:Click to copy- name: "jaeger"namespace: "kyma-system"
- Trigger the installation:Click to copykubectl label installation/kyma-installation action=install
You can verify the installation status by calling
./installation/scripts/is-installed.sh in the terminal.
This guide describes how to update Kyma deployed locally or on a cluster.
- Docker
- Access to a Docker Registry - only for cluster installation
Kyma consists of multiple components, installed as Helm releases.
Update of an existing deployment can include:
- changes in charts
- changes in overrides
- adding new releases
The update procedure consists of three main steps:
- Prepare the update
- Update the Kyma Installer
- Trigger the update process
NOTE: In case of dependency conflicts or major changes between components versions, some updates may not be possible.
NOTE: Currently Kyma doesn't support removing components as a part of the update process.
If you update an existing component, make all required changes to the Helm charts of the component located in the
If you add a new component to your Kyma deployment, add a top-level Helm chart for that component. Additionally, run this command to edit the Installation custom resource and add the new component to the installed components list:Click to copykubectl edit installation kyma-installation
NOTE: Read this document to learn more about the Installation custom resource.
- If you introduced changes in overrides, update the existing ConfigMaps and Secrets. Add new ConfigMaps and Secrets if required. See this document for more information on overrides.
Build a new image for the Kyma Installer:Click to copy./installation/scripts/build-kyma-installer.sh
NOTE: If you started Kyma with the
run.shscript with a
--vm-driver {value}parameter, provide the same parameter to the
Restart the Kyma Installer Pod:Click to copykubectl delete pod -n kyma-installer {INSTALLER_POD_NAME}
Build a new image for the Kyma Installer:Click to copydocker build -t {IMAGE_NAME}:{IMAGE_TAG} -f tools/kyma-installer/kyma.Dockerfile .
Push the image to your Docker registry.
Redeploy the Kyma Installer Pod using the new image. Run this command to edit the Deployment configuration:Click to copykubectl edit deployment kyma-installer -n kyma-installer
Change the
imagePullPolicyattributes in this section:Click to copyspec:containers:- image: <your_image_name>:<your_tag>imagePullPolicy: Always
NOTE: If the desired image name and
imagePullPolicyis already set in the deployment configuration, restart the Pod by running
kubectl delete pod -n kyma-installer {INSTALLER_POD_NAME}
Execute the following command to trigger the update process:
kubectl label installation/kyma-installation action=install
The custom scripts allow you to remove Kyma from a Minikube cluster and reinstall Kyma without removing the cluster.
NOTE: These scripts do not delete the cluster from your Minikube. This allows you to quickly reinstall Kyma.
Use the
clean-up.shscript to uninstall Kyma from the cluster. Run:Click to copyscripts/clean-up.sh
Run this script to reinstall Kyma on an existing cluster:Click to copycmd/run.sh --skip-minikube-start
This document extends the Install Kyma locally from sources guide with a detailed breakdown of the alternative local installation method which is the
run.sh script.
The following snippet is the main element of the
run.sh script:
if [[ ! $SKIP_MINIKUBE_START ]]; then bash $SCRIPTS_DIR/minikube.sh --domain "$DOMAIN" --vm-driver "$VM_DRIVER" $MINIKUBE_EXTRA_ARGSfibash $SCRIPTS_DIR/build-kyma-installer.sh --vm-driver "$VM_DRIVER"if [ -z "$CR_PATH" ]; then TMPDIR=`mktemp -d "$CURRENT_DIR/../../temp-XXXXXXXXXX"` CR_PATH="$TMPDIR/installer-cr-local.yaml" bash $SCRIPTS_DIR/create-cr.sh --output "$CR_PATH" --domain "$DOMAIN"fibash $SCRIPTS_DIR/installer.sh --local --cr "$CR_PATH" --password "$ADMIN_PASSWORD"rm -rf $TMPDIR
Subsequent sections provide details of all involved subscripts, in the order in which the
run.sh script triggers them.
NOTE: To work with Kyma, use only the provided scripts and commands. Kyma does not work on a basic Minikube cluster that you can start using the
minikube startcommand.
The purpose of the
installation/scripts/minikube.sh script is to configure and start Minikube. The script also checks if your development environment is configured to handle the Kyma installation. This includes checking Minikube and kubectl versions.
If Minikube is already initialized, the system prompts you to agree to remove the previous Minikube cluster.
- If you plan to perform a clean installation, answer
- If you installed Kyma to your Minikube cluster and then stopped the cluster using the
minikube stopcommand, answer
no. This allows you to start the cluster again without reinstalling Kyma.
Minikube is configured to disable the default Nginx Ingress Controller.
NOTE: For the complete list of parameters passed to the
minikube startcommand, refer to the
Once Minikube is up and running, the script adds local installation entries to
The Kyma Installer is an application based on the Kubernetes operator. Its purpose is to install Helm charts defined in the Installation custom resource. The Kyma Installer is a Docker image that bundles the Installer binary with Kyma charts.
installation/scripts/build-kyma-installer.sh script extracts the Kyma-Installer image name from the
installer.yaml deployment file and uses it to build a Docker image inside Minikube. This image contains local Kyma sources from the
resources folder.
NOTE: For the Kyma Installer Docker image details, refer to the
installation/scripts/create-cr.sh script prepares the Installation custom resource from the
installation/resources/installer-cr.yaml.tpl template. The local installation scenario uses the default Installation custom resource. The Kyma Installer already contains local Kyma resources bundled, thus
url is ignored by the Installer component.
NOTE: Read this document to learn more about the Installation custom resource.
installation/scripts/installer.sh script creates the default RBAC role, installs Tiller, and deploys the Kyma Installer component.
NOTE: For the Kyma Installer deployment details, refer to the
The script applies the Installation custom resource and marks it with the
action=install label, which triggers the Kyma installation.
In the process of installing Tiller, a set of TLS certificates is created and saved to Helm Home to secure the connection between the client and the server.
NOTE: The Kyma installation runs in the background. Execute the
./installation/scripts/is-installed.shscript to follow the installation process.
installation/scripts/is-installed.sh script shows the status of Kyma installation in real time. The script checks the status of the Installation custom resource. When it detects that the status changed to
Installed, the script exits. If you define a timeout period and the status doesn't change to
Installed within that period, the script fetches the Installer logs. If you don't set a timeout period, the script waits for the change of the status until you terminate it.
installations.installer.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to control the Kyma Installer, a proprietary solution based on the
Kubernetes operator principles. To get the up-to-date CRD and show the output in the
yaml format, run this command:
kubectl get crd installations.installer.kyma-project.io -o yaml
This is a sample CR that controls the Kyma Installer. This example has the action label set to
install, which means that it triggers the installation of Kyma. The name and namespace fields in the
components array define which components you install and Namespaces in which you install them.
NOTE: See the
installer-cr.yaml.tplfile in the
/installation/resourcesdirectory for the complete list of Kyma components.
apiVersion: "installer.kyma-project.io/v1alpha1"kind: Installationmetadata: name: kyma-installation labels: action: install finalizers: - finalizer.installer.kyma-project.iospec: version: "1.0.0" url: "https://sample.url.com/kyma_release.tar.gz" components: - name: "cluster-essentials" namespace: "kyma-system" - name: "istio" namespace: "istio-system" - name: "prometheus-operator" namespace: "kyma-system" - name: "provision-bundles" - name: "dex" namespace: "kyma-system" - name: "core" namespace: "kyma-system"
This table lists all the possible parameters of a given resource together with their descriptions:
|Specifies the name of the CR.
|Defines the behavior of the Kyma Installer. Available options are
install and
|Protects the CR from deletion. Read this Kubernetes document to learn more about finalizers.
|When manually installing Kyma on a cluster, specify any valid SemVer notation string.
|Specifies the location of the Kyma sources
tar.gz package. For example, for the
master branch of Kyma, the address is
|Lists which components of Helm chart components to install or update.
|Specifies the name of the component which is the same as the name of the component subdirectory in the
resources directory.
|Defines the Namespace in which you want the Installer to install, or update the component.
|Provides the name of the Helm release. The default parameter is the component name.
The Kyma Installer adds the status section which describes the status of Kyma installation. This table lists the fields of the status section.
|Describes the installation state. Takes one of four values.
|Describes the installation step the installer performs at the moment.
|Lists all errors that happen during the installation.
|Specifies the name of the component that causes the error.
|Provides a description of the error.
|Specifies the number of subsequent occurrences of the error.
The status.state field uses one of the following four values to describe the installation state:
|Installation successful.
|Uninstallation successful.
|The Installer is still installing or uninstalling Kyma. No errors logged.
|The Installer encountered a problem but it continues to try to process the resource.
These components use this CR:
|The CR triggers the Installer to install, update or delete of the specified components.
This tutorial is intended for the developers who want to quickly learn how to deploy a sample service and test it with Kyma installed locally on Mac.
This tutorial uses a standalone sample service written in the Go language .
To use the Kyma cluster and install the example, download these tools:
Follow these steps:
Deploy the sample service to any of your Namespaces. Use the
stageNamespace for this guide:Click to copykubectl create -n stage -f https://raw.githubusercontent.com/kyma-project/examples/master/http-db-service/deployment/deployment.yaml
Create an unsecured API for your example service:Click to copykubectl apply -n stage -f https://raw.githubusercontent.com/kyma-project/examples/master/gateway/service/api-without-auth.yaml
Add the IP address of Minikube to the
hostsfile on your local machine for your APIs:Click to copyecho "$(minikube ip) http-db-service.kyma.local" | sudo tee -a /etc/hosts
Access the service using the following call:Click to copycurl -ik https://http-db-service.kyma.local/orders
The system returns a response similar to the following:Click to copyHTTP/2 200content-type: application/json;charset=UTF-8vary: Origindate: Mon, 01 Jun 2018 00:00:00 GMTcontent-length: 2x-envoy-upstream-service-time: 131server: envoy[]
Run the following command:
kubectl apply -n stage -f https://raw.githubusercontent.com/kyma-project/examples/master/gateway/service/api-with-auth.yaml
After you apply this update, you must include a valid bearer ID token in the Authorization header to access the service.
NOTE: The update might take some time.
This tutorial is intended for the developers who want to quickly learn how to deploy a sample service and test it with the Kyma cluster.
This tutorial uses a standalone sample service written in the Go language.
To use the Kyma cluster and install the example, download these tools:
Follow these steps to get the
kubeconfig file and configure the CLI to connect to the cluster:
- Access the Console UI of your Kyma cluster.
- Click Administration.
- Click the Download config button to download the
kubeconfigfile to a selected location on your machine.
- Open a terminal window.
Export the KUBECONFIG environment variable to point to the downloaded
kubeconfig. Run this command:Click to copyexport KUBECONFIG={KUBECONFIG_FILE_PATH}
NOTE: Drag and drop the
kubeconfigfile in the terminal to easily add the path of the file to the
export KUBECONFIGcommand you run.
kubectl cluster-infoto check if the CLI is connected to the correct cluster.
The commands in this guide use URLs in which you must provide the domain of the cluster that you use. Export the domain of your cluster as an environment variable. Run:
export yourClusterDomain='{YOUR_CLUSTER_DOMAIN}'
Follow these steps:
Deploy the sample service to any of your Namespaces. Use the
stageNamespace for this guide:Click to copykubectl create -n stage -f https://raw.githubusercontent.com/kyma-project/examples/master/http-db-service/deployment/deployment.yaml
Create an unsecured API for your service:Click to copycurl -k https://raw.githubusercontent.com/kyma-project/examples/master/gateway/service/api-without-auth.yaml | sed "s/.kyma.local/.$yourClusterDomain/" | kubectl apply -n stage -f -
Access the service using the following call:Click to copycurl -ik https://http-db-service.$yourClusterDomain/orders
The system returns a response similar to the following:Click to copyHTTP/2 200content-type: application/json;charset=UTF-8vary: Origindate: Mon, 01 Jun 2018 00:00:00 GMTcontent-length: 2x-envoy-upstream-service-time: 131server: envoy[]
Run the following command:
curl -k https://raw.githubusercontent.com/kyma-project/examples/master/gateway/service/api-with-auth.yaml | sed "s/.kyma.local/.$yourClusterDomain/" | kubectl apply -n stage -f -
After you apply this update, you must include a valid bearer ID token in the Authorization header to access the service.
NOTE: The update might take some time.
You can develop services in the local Kyma installation without extensive Docker knowledge or a need to build and publish a Docker image. The
minikube mount feature allows you to mount a directory from your local disk into the local Kubernetes cluster.
This tutorial shows how to use this feature, using the service example implemented in Golang.
Install Golang.
- Install the example:
go get -insecure github.com/kyma-project/examples/http-db-service
- Navigate to installed example and the
http-db-servicefolder inside it:
cd ~/go/src/github.com/kyma-project/examples/http-db-service
- Build the executable to run the application:
CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .
For this step, you need a running local Kyma instance. Read this document to learn how to install Kyma locally.
- Open the terminal window. Do not close it until the development finishes.
- Mount your local drive into Minikube:
# Use the following pattern:minikube mount {LOCAL_DIR_PATH}:{CLUSTER_DIR_PATH}`# To follow this guide, call:minikube mount ~/go/src/github.com/kyma-project/examples/http-db-service:/go/src/github.com/kyma-project/examples/http-db-service
See the example and expected result:
# Terminal 1minikube mount ~/go/src/github.com/kyma-project/examples/http-db-service:/go/src/github.com/kyma-project/examples/http-db-serviceMounting /Users/{USERNAME}/go/src/github.com/kyma-project/examples/http-db-service into /go/src/github.com/kyma-project/examples/http-db-service on the minikube VMThis daemon process must stay alive for the mount to still be accessible...ufs starting
- Create Pod that uses the base Golang image to run your executable located on your local machine:
# Terminal 2kubectl run mydevpod --image=golang:1.9.2-alpine --restart=Never -n stage --overrides='{ "spec":{ "containers":[ { "name":"mydevpod", "image":"golang:1.9.2-alpine", "command": ["./main"], "workingDir":"/go/src/github.com/kyma-project/examples/http-db-service", "volumeMounts":[ { "mountPath":"/go/src/github.com/kyma-project/examples/http-db-service", "name":"local-disk-mount" } ] } ], "volumes":[ { "name":"local-disk-mount", "hostPath":{ "path":"/go/src/github.com/kyma-project/examples/http-db-service" } } ] }}'
- Expose the Pod as a service from Minikube to verify it:
kubectl expose pod mydevpod --name=mypodservice --port=8017 --type=NodePort -n stage
- Check the Minikube IP address and Port, and use them to access your service.
# Get the IP address.minikube ip# See the example result: 192.168.64.44# Check the Port.kubectl get services -n stage# See the example result: mypodservice NodePort 10.104.164.115 <none> 8017:32226/TCP 5m
- Call the service from your terminal.
curl {minikube ip}:{port}/orders -v# See the example: curl http://192.168.64.44:32226/orders -v# The command returns an empty array.
- Edit the
main.gofile by adding a new
testendpoint to the
router.HandleFunc("/test", func (w http.ResponseWriter, r *http.Request) { w.Write([]byte("test"))})
- Build a new executable to run the application inside Minikube:
CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .
- Replace the existing Pod with the new version:
kubectl get pod mydevpod -n stage -o yaml | kubectl replace --force -f -
- Call the new
testendpoint of the service from your terminal. The command returns the
curl http://192.168.64.44:32226/test -v
Follow this tutorial to learn how to develop a service locally. You can immediately see all the changes made in a local Kyma installation based on Minikube, without building a Docker image and publishing it to a Docker registry, such as the Docker Hub.
Using the same example service, this tutorial explains how to build a Docker image for your service, publish it to the Docker registry, and deploy it to the local Kyma installation. The instructions base on Minikube, but you can also use the image that you create and the Kubernetes resource definitions that you use on the Kyma cluster.
NOTE: The deployment works both on local Kyma installation and on the Kyma cluster.
http-db-service example used in this guide provides you with the
Dockerfile necessary for building Docker images. Examine the
Dockerfile to learn how it looks and how it uses the Docker Multistaging feature, but do not use it one-to-one for production. There might be custom
LABEL attributes with values to override.
- In your terminal, go to the
examples/http-db-servicedirectory. If you did not follow the Sample service deployment on local guide and you do not have this directory locally, get the
http-db-serviceexample from the
- Run the build with
NOTE: Ensure that the new image builds and is available in your local Docker registry by calling
docker images. Find an image called
example-http-db-serviceand tagged as
This guide bases on Docker Hub. However, there are many other Docker registries available. You can use a private Docker registry, but it must be available in the Internet. For more details about using a private Docker registry, see the this document.
- Open the Docker Hub webpage.
- Provide all of the required details and sign up.
- Call
docker login.
- Provide the username and password, and select the
- Tag the local image with a proper name required in the registry:
docker tag example-http-db-service {USERNAME}/example-http-db-service:0.0.1.
- Push the image to the registry:
docker push {USERNAME}/example-http-db-service:0.0.1.
NOTE: To verify if the image is successfully published, check if it is available online at the following address:
http-db-service example contains sample Kubernetes resource definitions needed for the basic Kyma deployment. Find them in the
deployment folder. Perform the following modifications to use your newly-published image in the local Kyma installation:
- Go to the
- Edit the
deployment.yamlfile. Change the image attribute to
- Create the new resources in local Kyma using these commands:
kubectl create -f deployment.yaml -n stage && kubectl create -f ingress.yaml -n stage.
- Edit your
/etc/hoststo add the new
http-db-service.kyma.localhost to the list of hosts associated with your
minikube ip. Follow these steps:
- Open a terminal window and run:
sudo vim /etc/hosts
- Select the i key to insert a new line at the top of the file.
- Add this line:
{YOUR.MINIKUBE.IP} http-db-service.kyma.local
- Type
:wqand select the Enter key to save the changes.
- Open a terminal window and run:
- Run this command to check if you can access the service:
curl https://http-db-service.kyma.local/orders. The response should return an empty array.
Kyma packages its components into Helm charts that the Installer uses. This document describes how to configure the Installer with override values for Helm charts.
The Installer is a Kubernetes Operator that uses Helm to install Kyma components. Helm provides an overrides feature to customize the installation of charts, such as to configure environment-specific values. When using Installer for Kyma installation, users can't interact with Helm directly. The installation is not an interactive process.
To customize the Kyma installation, the Installer exposes a generic mechanism to configure Helm overrides called user-defined overrides.
The Installer finds user-defined overrides by reading the ConfigMaps and Secrets deployed in the
kyma-installer Namespace and marked with the
installer:overrides Label.
The Installer constructs a single override by inspecting the ConfigMap or Secret entry key name. The key name should be a dot-separated sequence of strings corresponding to the structure of keys in the chart's
values.yaml file or the entry in chart's template. See the examples below.
Installer merges all overrides recursively into a single YAML stream and passes it to Helm during the Kyma installation/upgrade operation.
The Installer looks for available overrides each time a component installation or update operation is due. Overrides for the component are composed from two sets: common overrides and component-specific overrides.
Kyma uses common overrides for the installation of all components. ConfigMaps and Secrets marked with the label
installer:overrides, contain the definition. They require no additional label.
Kyma uses component-specific overrides only for the installation of specific components. ConfigMaps and Secrets marked with both
installer:overrides and
component: <name> Labels, where
<name> is the component name, contain the definition. Component-specific overrides have precedence over Common ones in case of conflicting entries.
Overrides for top-level charts are straightforward. Just use the template value from the chart (without leading ".Values." prefix) as the entry key in the ConfigMap or Secret.
The Installer uses a
core top-level chart that contains a template with the following value reference:
memory: {{ .Values.test.acceptance.ui.requests.memory }}
The chart's default value
test.acceptance.ui.requests.memory in the
values.yaml file resolves the template.
The following fragment of
values.yaml shows this definition:
test: acceptance: ui: requests: memory: "1Gi"
To override this value, for example to "2Gi", proceed as follows:
- Create a ConfigMap in the
kyma-installerNamespace, labelled with:
installer:overrides(or reuse an existing one).
- Add an entry
test.acceptance.ui.requests.memory: 2Gito the map.
Once the installation starts, the Installer generates overrides based on the map entries. The system uses the value of "2Gi" instead of the default "1Gi" from the chart
values.yaml file.
For overrides that the system should keep in Secrets, just define a Secret object instead of a ConfigMap with the same key and a base64-encoded value. Be sure to label the Secret with
Overrides for sub-charts follow the same convention as top-level charts. However, overrides require additional information about sub-chart location.
When a sub-chart contains the
values.yaml file, the information about the chart location is not necessary because the chart and it's
values.yaml file are on the same level in the directory hierarchy.
The situation is different when the Installer installs a chart with sub-charts. All template values for a sub-chart must be prefixed with a sub-chart "path" that is relative to the top-level "parent" chart.
This is not an Installer-specific requirement. The same considerations apply when you provide overrides manually using the
helm command-line tool.
Here is an example.
There's a
core top-level chart, that the Installer installs.
There's an
application-connector sub-chart in
core with another nested sub-chart:
In one of its templates there's a following fragment (shortened):
spec: containers: - name: {{ .Chart.Name }} args: - "/connectorservice" - '--appName={{ .Chart.Name }}' - "--domainName={{ .Values.global.domainName }}" - "--tokenExpirationMinutes={{ .Values.deployment.args.tokenExpirationMinutes }}"
The following fragment of the
values.yaml file in
connector-service chart defines the default value for
deployment: args: tokenExpirationMinutes: 60
To override this value, such as to change "60 to "90", do the following:
- Create a ConfigMap in the
kyma-installerNamespace labeled with
installer:overridesor reuse existing one.
- Add an entry
application-connector.connector-service.deployment.args.tokenExpirationMinutes: 90to the map.
Notice that the user-provided override key now contains two parts:
- The chart "path" inside the top-level
- The original template value reference from the chart without the .Values. prefix:
Once the installation starts, the Installer generates overrides based on the map entries. The system uses the value of "90" instead of the default value of "60" from the
values.yaml chart file.
There are several important parameters usually shared across the charts.
Helm convention to provide these requires the use of the
global override key.
For example, to define the
global.domain override, just use "global.domain" as the name of the key in ConfigMap or Secret for the Installer.
Once the installation starts, the Installer merges all of the map entries and collects all of the global entries under the
global top-level key to use for installation.
Installer generally recognizes all override values as strings. It internally renders overrides to Helm as a YAML stream with only string values.
There is one exception to this rule with respect to handling booleans: The system converts "true" or "false" strings that it encounters to a corresponding boolean value (true/false).
When the Installer encounters two overrides with the same key prefix, it tries to merge them. If both of them represent a map (they have nested sub-keys), their nested keys are recursively merged. If at least one of keys points to a final value, the Installer performs the merge in a non-deterministic order, so either one of the overrides is rendered in the final YAML data.
It is important to avoid overrides having the same keys for final values.
Two overrides with a common key prefix ("a.b"):
"a.b.c": "first""a.b.d": "second"
The Installer yields correct output:
a: b: c: first d: second
Two overrides with the same key ("a.b"):
"a.b": "first""a.b": "second"
The Installer yields either:
a: b: "first"
Or (due to non-deterministic merge order):
a: b: "second"
The table contains a list of examples that demonstrate Kyma functionalities. You can run all of them locally or on a cluster. Examples are organized by a feature or concept they showcase. Each of them contains ready-to-use code snippets and the instructions in
README.md documents.
Follow the links to examples' code and content sources, and try them on your own.
|HTTP DB Service
|Test the service that exposes an HTTP API to access a database on the cluster.
|Go, MSSQL
|Event Service Subscription
|Test the example that demonstrates the
publish and
consume features of the Event Bus.
|Event Lambda Subscription
|Create functions, trigger them on Events, and bind them to services.
|Expose APIs for functions or services.
|Service Binding
|Bind a Redis service to a lambda function.
|Kubeless, Redis, NodeJS
|Call SAP Commerce
|Call SAP Commerce in the context of the end user.
|Kubeless, NodeJS
|Alert Rules
|Configure alert rules in Kyma.
|Custom Metrics in Kyma
|Expose custom metrics in Kyma.
|Go, Prometheus
|Event Email Service
|Send an automated email upon receiving an Event.
|Configure tracing for a service in Kyma.


text:
Front Porch Forum is seeking an Intermediate or Senior-level Developer to join our team of 17 Vermont-based staff.
Category Archives: Social Media
FPF is hiring: Software Developer
Best of social media
VPR correspondent, Stephanie Green, shared her FPF experience on the radio this morning. Looking to her neighbors for recommendations on a good plumber, she was "astounded to get 13 useful replies in 24 hours…. I had no idea so many people read these posts so closely – or felt so passionately about their plumbers. And the re-connection to my neighbors was heartening. This, I think, is social media at its best, and it's a relief when we're daily buffeted by national headlines about social media at its very worst."
Read or listen to her commentary at http://digital.vpr.net/post/greene-best-social-media
FPF as a discussion tool
Varying opinions on a topic or issue can be difficult when not approached in a civic manner. Front Porch Forum members weigh in:
"Should we be discussing controversial issues on FPF? If not here, where? One of the problems with our pop culture these days is that we are constantly talking to those we agree with. Our social media echo chambers are really hurting our democracy. FPF is fundamentally different from Facebook. It is a platform where I can talk to my neighbors and they can talk to me. Facebook seems to be a self selecting group which will frequently share ones own views. How can we find common ground if we do not talk to one another? I think the discussion on guns in FPF has been respectful, diverse and informative." • Jeff in Richmond
Use Front Porch Forum to have civil discussions on tough topics and connect with your neighbors.
FPF Hiring Ruby on Rails Developer
Front Porch Forum is hiring! We are seeking a Ruby on Rails Developer to join our team. This position is full-time and based in Burlington, Vermont. Be part of a world-class team of software engineers, and help us fulfill our community-building mission. Check out the details and apply here.
Decline of open web in favor of social media… "grim consequences"
Iran's "Blogfather," Hossein Derakhshan, in a recent interview on the NiemanStoryboard…
"The decline of the web in favor of social media entails grim consequences. Hyperlinks were the founding principle of the web; it secured a diversity, nonlinearity, decentralization and interactivity, which made the web so powerful. But social media's very philosophy and monetization strategy, or the stream, cannot be friendly to hyperlinks, since they do not want their users to leave their space. This new environment, in addition to the currently dominant algorithms, which favors popularity and now-ness rather than diversity and quality, is worse than television in its potential damage to representative democratic societies, where majority is supposed to take informed decisions without jeopardizing minorities. The rise of identity politics and intolerance for diversity is directly linked to the current form of the internet. This is the deepest shock of this transition to me since my release. This shift from what I call books-internet to TV-internet."
Unlike some other social media platforms, Front Porch Forum doesn't aim to lure people in and hold their attention 24/7. FPF, for many Vermonters, is a 10-minute-a-day habit that leads to more face-to-face conversations with neighbors… and to friendlier, more informed, and more resilient local communities. Hyperlinks in FPF postings are an important part of that.
FPF Reaches Million-Posting Milestone
2017 marked the moment when Front Porch Forum saw its one-millionth posting! Celebrating 10 years helping neighbors connect and build community, FPF has experienced tremendous growth and accomplishments to serve every community in Vermont.
Take note of these FPF Milestones:
• More than 1 million postings made by our members
• 3.5 million e-newsletters sent every month
• More than 130,000 members…in a state with only 260,000 households
Co-Founder, Michael Wood-Lewis notes "we couldn't be happier about the impact FPF has had across Vermont. Once people have an easy and safe way to communicate with neighbors, they do! And that simple act adds up. The cumulative impact is huge… after months of FPF, people often report feeling more connected to neighbors, more tuned in to local goings on, and more a part of their community. And in many cases, people then become more active… organizing a group yard sale, mentoring a local kid, volunteering for a park clean-up, voting on election day, and, most recently, helping each other during Blizzard Stella. That's what FPF is all about!"
Our Northeast Kingdom neighbors sum it up nicely….
"FPF is the Closest Thing to My Favorite Past-Time: Drinking coffee on the front porch of the General Store." • Tim in Craftsbury
"FPF is the glue that keeps our rural conversations connected!" • Lian in Walden
"FPF keeps me informed of town and school issues thanks to posting by our town clerk and principal." • Rhonda in Morgan
Satisfied members tell their friends about Front Porch Forum… that's how the word gets out. Have a neighbor in the Northeast Kingdom looking to get connected? Invite them today!
FPF Hires, Achievements and Promotions: Sales Team Dedicated and Moving Forward!
As Front Porch Forum celebrates 10 years helping neighbors connect and build community, our team has grown and evolved. FPF serves every community in Vermont, and 130,000 members participate out of the 260,000 households that exist in the state. Our staff has grown and evolved to better serve our members and business community. Take a look at our dynamic sales team.
New Additions
Jodi Harrington is an 8th generation Manchester, Vermont gal and 5th generation graduate from Burr and Burton Academy. Previous owner/editor of the Winooski Eagle newspaper and marketing director for both Onion River Co-op and Opportunities Credit Union, Jodi's small business marketing skills are a great advantage to businesses utilizing FPF. She's a strong activist in her communities having served on both the Winooski School Board and City Council. She loves the mountains and can be often found on the slopes (she is a level 3 PSIA ski instructor who has taught at Bromley, Smuggs, Whiteface, Bolton, Stowe and Burke).
Wendy Wilson brings her 20 years of experience in marketing, public education and communications to Front Porch Forum. She's been actively involved in the fabric of Vermont through past work with Chittenden Solid Waste District, Vermont Commons School and Energy Action Network. In addition to her role at Front Porch Forum, Wendy also works part-time for VBSR. She has two teenage daughters and lives in Bristol where she enjoys cycling, traveling, cooking, reading and walking her dog Stella.
Celebrating Five Years
Suzie McCoy has helped local businesses connect with FPF members since 2012. She's seen FPF membership double in that time, and has a genuine enthusiasm for the important role that FPF plays in our communities. Fluent in French, Suzie earned a master's degree in education, and has taught at the high school and college levels. She's an active volunteer and cofounded the Vermont nonprofit Action Coalition for Media Education, and currently serves as school board vice chair. Mom to her 12-year old son, you can find her pursuing a number of outdoor activities year round.
Congratulations to Gisele Nelson, who after six years with FPF has been promoted to Sales Team Manager. Gisele started her tenure with FPF as an intern while she was a student at UVM. Her skills were quickly put to work as she took on a role in both Member Support and as an Online Content Manager. She built a strong rapport with many local businesses while in these roles which led her into the sales realm at FPF. Gisele's strength in balancing her work and understanding of needs from both members and local businesses, combined with her strong inter-office communication skills, led her into this newly developed role at FPF.
Front Porch Forum celebrates 10 years helping neighbors connect and build community. Using technology to bring neighbors closer together, members of a local forum submit their own messages, which FPF distributes to nearby residents as an online newsletter. Because the service is moderated and real names accompany postings, the discussions remain civil, engaging, and relevant. FPF is popular, because it works. Ask any of our sales team staff how they can help put your business in the forefront of neighborhood conversations with our active, engaged membership.
Vermonter loves hearing from her State Senator. How does your Representative keep in touch with you?
"Recently our State Senator posted on FPF about a Public Hearing. I am so thankful to have an easy and bipartisan way to hear about local government issues.
"This posting was a perfect use of Front Porch Forum. No matter your political opinion, it is important to understand what is going on in our local government.
"I encourage all of our elected leaders to use FPF to announce opportunities to effect change! Remember that they are working for us and we deserve democracy. Think global, act local!"
—Chloe, Williston FPF
Ask your legislators to use FPF to keep you tuned in about what's going on in the State house.
Watch your skis or snowboard… thieves strike slopes
"Just wanted to send out a quick PSA and let everyone know that there is apparently a ski/snowboard thief going around to most of the local resorts (Sugarbush, Smugg's, Bolton, Stowe). My skis and poles were stolen last night from Bolton and the desk employee informed me there have been about 5-10 other reports just in the last 2 days. Please be cautious and lock/watch your things!"
• Jenessa, Richmond Front Porch Forum
Has your gear been stolen this season? Pitch in by telling your neighbors on FPF.
About Blog
Ghost of Midnight is an online journal about fostering community within neighborhoods, with a special focus on Front Porch Forum (FPF). My wife, Valerie, and I founded FPF in 2006... read more
Monthly Archives
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- October 2018
- September 2018
- August 2018
- July 2018
- June 2018
- May 2018
- April 2018
- March 2018
- February 2018
- January 2018
- December 2017
- November 2017
- October 2017
- September 2017
- August 2017
- July 2017
- June 2017
- May 2017
- April 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- January 2016
- December 2015
- November 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
- January 2015
- December 2014
- November 2014
- October 2014
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
Post Categories
- Uncategorized
- Northeast Kingdom
- Peer Rental
- Wildlife
- Web Traffic
- Google AdSense
- berkmansunlight
- Maps
- Mobile
- Video
- Lost & Found
- Coupons
- Raffle
- Viral Marketing
- Donations
- How To Use FPF
- College Students
- Real Estate
- Social Responsibility
- Online Civility
- Orton Family Foundation
- Start ups
- Make It Your Own Awards
- Newspapers
- Clay Shirky
- Humor
- Online Classified Ads
- Peer Reviews
- Politics
- Community Management
- Economic Development
- Local Reviews
- Case Foundation
- Borrow and Lend
- Neighborhood Watch
- Good Government
- Small Business Advertising
- Citizen Journalism
- e-Vermont
- Democracy
- Local Search
- Knight Foundation
- Burlington
- MacArthur Fellows
- Civic Engagement
- Social Media
- social capital
- Social Networking
- Vermont
- Community Building
- Neighborhood
- Local Online
- Front Porch Forum

subset: commoncrawl


text:
B. JohansenHas no ancestors and no descendants in this family tree.
Set As Default Person
Gender Male Person ID I2076 Devantier Tree | Danish - Fredericia Branch Last Modified 10 Mar 2017
Family K.E. Tychsen Last Modified 19 Feb 2012 Family ID F713 Group Sheet | Family Chart
Notes At least one living or private individual is linked to this note - Details withheld.


text:
Worldwide Golf Shops serves as the parent company to some of the most well-known and established golf retail stores in the United States. Founded more than 50 years ago, Worldwide Golf Shops operates over 80 golf specialty stores across the country under established brand names that golfers recognize and trust, such as Roger Dunn Golf Shops, The Golf Mart, Vans Golf Shops, Golfers' Warehouse, Edwin Watts Golf, and Uinta Golf. Our fully trained and highly knowledgeable retail and customer service associates are second to none in service and expertise, and we are at your disposal to help provide the information, guidance, and support services you are looking for to help you enjoy the game more, and play better golf. Our worldwidegolfshops.com website serves as the online portal for all of our retail store brands and offers our customers an easy and convenient way to find what you are looking for, even if you aren't exactly sure what that may be. The products we carry and sell both online and in stores are from the very best manufacturers and brands in all of golf. We are also proud to say that we are golfers, active golfers who play the game, watch the game, live the game, and love the game just like you or someone you know. We're very glad you're here, so please don't ever hesitate to let us know what we can do to assist you with your golf needs.
Whether you're looking to upgrade your set or help an amateur get introduced to the game, our selection of discount golf clubs is a great place to start your search for new equipment. We carry a variety of equipment at hard-to-beat prices and guarantee that our selection will help you get outfitted and back onto the green in no time at all. Read More +
Thanks for swingin' by! Looking for some great deals on golf equipment? Well then you've come to the right place my friend. We have the Guaranteed Lowest Prices on golf clubs, apparel, balls, bags & MORE! There are hundreds of ways to save when you're at Rock Bottom. Whether you're shopping in the 50% Off Clearance Cave, Trading In your used clubs for some cold, hard cash or even saving money when booking your next Tee Time, we have you covered on EVERYTHING golf. And don't forget to check out our Free Same Day Shipping policy. Because saving money is great, and so is getting your new gear FAST!


text:
- Sightseeing
- Beaches
- Meals
- Accommodation/Hotel
Our representatives are ready to plan your holidays.
On arrival at Cochin airport after you have cleared your immigration and customs formalities, our representative will meet you and you are driven to Munnar. Enroute visit the beautiful Cheeyapara & Valara waterfalls. Enjoy the breathtaking and glorious waterfall cascade down the seven steps. Arrive at Munnar and check in to the resort. Munnar - Situated at the confluence of three mountain streams - Mudrapuzha, Nallathanni and Kundale, Munnar is situated 1600 Meter above sea level. Once the summer resort of erstwhile British Government in South India and the best hill station with sprawling tea plantations in the state. Blessed with a rich variety of flora and fauna with the most well- known Neelakurinji (botanical name: Strobilanthus) flowering once in 12 years. Balance of the day you are at leisure to enjoy on your own. Overnight stay at Munnar.
After breakfast proceed to Rajamala. Visit the Eravikulam National Park, the 97 sq km park with its irresistible grace and beauty is home to the endangered Mountain goats. Enjoy a guided short trek in the beautiful hill station. Afternoon - Visit the Mattupetty Dam built in the mountains. Later visit Echo point, a very popular place for the natural phenomenon. The echo that reverberates after hitting the distant hills is fascinating. Overnight stay at Munnar.
Check out from the resort and drive to Alleppey. Arrive at Alleppey and board the houseboat at noon for a backwater cruise and for an overnight stay. While cruising in these floating luxury-villas, let your eyes settle for the rare and the unusual - skim past Chinese fishing nets, bowed-down paddy fields, and local inhabitants engaged in making coir products, rustic homes, and ancient temples and swaying coconut groves. Overnight stay in houseboat.
Disembark from the houseboat at 0900hrs after a refreshing breakfast on board and drive to Kovalam, one of the most popular beach destinations in Kerala. Enroute visit Thiruvananthapuram literally means 'the abode of Anantha', the snake God. The main attraction of the city is the Sri Padmanabhaswamy Temple dedicated to Vishnu (also known as Padmanabha) reclining on the snake Anantha. The imposing gopuram (gateway tower) and intricate sculptures of the temple make it a very popular tourist attraction. Later visit Napier Museum, an art and natural history museum which houses a collection of archaeological and historic artifacts, bronze idols, ancient ornaments, a temple chariot and ivory carvings. Sri Chitra Art Gallery (Closed on Mondays & Wednesday forenoons) displays the original paintings of Raja Ravi Varma which houses a collection of paintings from the Rajput, Mughal and Thanjore schools. The collection also includes unique copies of Indian mural paintings from pre-historic times down to the 18th century. Overnight stay at Kovalam.
Morning proceed for an excursion to Kanyakumari, literally means the virgin, the cape owes its Indian name to Hindu mythology. Enroute visit Padmanabhapuram Palace, once the capital of Thiruvananthapuram during 1600 to 1790. Constructed with wood and stone in Kerala's indigenous style of architecture this palace is surrounded by 4km stone fort. Contained within the complex is a collection of 14 palaces and 127 beautiful royal rooms, many of which feature ornate wood carvings. The carved ceilings of the palace depict 90 varieties of flowers. Paintings, hundreds of years old and stone statues, some over 1000 years old, are on display on the palace grounds. Arrive at Kanyakumari and proceed for a sightseeing tour. At the Cape Comorin - the southernmost tip in the sub-continent, the three mighty oceans viz. the Bay of Bengal, the Indian Ocean and the Arabian Sea meet. Significant landmarks include the Kumari Amman Temple dedicated to the Goddess Parvati, the Gandhi Memorial where an urn containing the Mahatma's ashes are kept, the Vivekananda Memorial - built in memory of Swami Vivekananda exuding a calm and peace rarely found elsewhere and the Church of our Lady Ransom starkly etched against the beautiful shoreline. Drive back to Kovalam after the tour. Overnight stay at Kovalam.
Check out from the resort and drive to Trivandrum airport. Board the flight to your onward destination feeling contented about a wonderful holiday you spent in the "God's Own Country". Our services end after dropping you at Trivandrum airport.
Good afternoon Praveen and indeed the whole of the intersight team who have made our short stay here in India so magical. We have just finished our last guided tour with your team and again it was magnificent.
Won the "Best Tour Operator of South India" Award in South Asian Travel Awards (SATA) 2017.
Best Domestic Tour Operator' in India from Central Minister
Nehru Peace Foundation award for Excellence in Tourism and CRS Activities


text:
Are you looking for a cannabis dispensary that delivers the highest quality flowers and edibles? Finding a good place to buy weed Canada online is pretty easy. When you know where to shop, buying from a place that sells great products and accessories can also be a lot of fun.
You need to register to place your first order and this requires submitting your ID. Once you have your account set up, you can sit back, relax and order whatever you like.
The cannabis choices include excellent, fragrant blends of Indica-dominant and Sativa-dominant strains. These are delivered right to your door and come to you securely packed. Everything is fresh, and you will be enticed to enjoy your buds from the second you open your package until you need to place another order.
There is also a wide selection of concentrates, shatters, and resins to select. Read the product descriptions online to see which one is right for you. If you are new to cannabis and cannabis-related products, you will want to select products that have the right balance of lower THC and higher CBD in them.
Some people enjoy the THC and the pain relief when it is accompanied by an Indica-strained sleepiness. Others want Sativa to stay inspired and creative while some people want to explore the pain relief that comes from CBD oils and creams. These do not produce the high that THC-rich products do. Just visit the West Coast 420 Express website to start shopping now.
You will love the edibles which come from such quality companies as Herbivores. Choose THC or CBD infused gummies to get the perfect dose for your needs. These taste just like the real thing, but if you want something even more indulgent, there is a selection of caramel melts which contain a low amount of THC to allow for discreet dosing anytime.
There is also a wide selection of fruit flavored high-dose THC lollipops together with marshmallow treats and quality teas. Of course, you can also buy glass accessories and pipes.
To get started, you simply fill out and submit the registration form. You will need to send your photo ID and your age along with your Canadian address. Once the account is approved, this information is deleted for your protection.
Shopping is easy with your registered account. Just browse the items you want to from the online catalog and then add them to your cart. Check out your items using the checkout button and your order will be placed. After the order is placed you get emailed instructions to do an Email Money Transfer. As soon as your payment is received your order will be shipped out to you.
There are more options than ever to buy weed Canada online. Trust the selection of marijuana products available from West Coast 420 Express. There are always special offers available that let you buy the items you want for special, discounted prices. Register for your account today so you can start ordering weed online.


text:
Could Comprehensive, Accurate Sex Education Curtail the War on Women?
It wasn't long ago that I was prepping for a lesson I would be teaching to a group of middle school girls in the Bronx on female reproductive anatomy. It was a lot of information so I was nervous and enlisted my roommate to run through my workshop. As I was going through my explanation I was pleasantly surprised with how engaged she was and how many questions she had. I had thought she was just playing along to help better prep me, but it turned out that my 25-year-old guinea pig actually didn't know much about her own anatomy and reproductive system.
As the years have gone by, I've realized that she's not alone and that men are just as ignorant of female anatomy.
Enter a recent social experiment conducted by the millennial media outlet Mic where men were asked to draw a vagina. Among a sea of nervous laughter and hesitations to get started, the men do their best to draw the "crotch area," "vaginal lips," "bottom," "pee hole," "baby hole," and even "belly button" as they put it. While there were also some accurate terms used, like uterus, cervix and, most impressive in my book, the labia majora, the pictures were laughably inaccurate.
You can watch the video yourself here:
While the video really is very funny, it makes the serious point of how problematic it is for the overwhelming majority of elected officials to be men who know so little about women's bodies. As the mastermind behind the video, Mic's Senior Editor Elizabeth Plank, puts it, "America's male elected officials continue to aggressively legislate women's bodies in the year 2014, even though they often seem not to know basic facts about women." From birth control to abortion to sexual assault, it is these men who are pushing through laws that impact women's bodies. In fact, in 2014 alone approximately 75 percent of anti-choice bills were sponsored by, you guessed it, men.
Should men really be in charge of legally regulating women's bodies if they can't name the parts that make them up?
As a former sexual educator myself, this video also really spoke to the importance of comprehensive sexual education across the country. Unfortunately, while there has been increasing support for such programs over the last 20 years with 80-85 percent of parents indicating they want their children to receive comprehensive, medically accurate, age-appropriate sexual education, there are countless programs that are discriminatory, biased and judgmental, or use shame and fear to scare young people about sexuality.
What we need is not only for schools to accurately educate students, but for the conversations to continue at home from a young age through adulthood. Yes we all know that having "the talk" can be tricky and embarrassing, but if we want men and women to grow up and actually be able to name and identify their own body parts, we need to start young. This new project from The Cut about parents having the birds and the bees talk with their kids demonstrates just that:
Beginning to have conversations like these at home from a young age is incredibly important, especially for the impact it can have later in life. For example, in California college students are demanding schools teach prospective students about sexual consent in kindergarten through twelfth grade. The hope is that teaching students about consent before they get to college will prevent sexual assault and rape once they are there.
Meghan Warner, one of the students behind the initiative and the director of the Associated Students of the University of California Sexual Assault Commission, says: "Sex ed in California — and everywhere else — is really bad. If we can't even get basic, accurate sex ed in schools, I'm assuming getting consent education won't be easy. But that doesn't mean we're not going to fight for it."
This is a fight I hope these students win. Learning about the birds and the bees is certainly about much more than learning where babies come from. Empowering students with this knowledge can mean more understanding around sexual assault, rape, birth control and abortion.
What would the world be like if we all received comprehensive, accurate sex education from kindergarten through twelfth grade? Would there still be a war on women or a rape epidemic on college campuses? At the very least, would the men of Mic have been better prepared to draw a vagina? I certainly think so.
Photo Credit: Mic