Merge with upstream master

.travis.yml

@@ -7,16 +7,16 @@ install:
 - export PATH=$GOPATH/bin:$PATH
 - mkdir -p $HOME/gopath/src/k8s.io
 - mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/website && cd $HOME/gopath/src/k8s.io/website
-# Fetch dependencies for us to run the tests in test/examples_test.go
-- go get -t -v k8s.io/website/test
+
 # Make sure we are testing against the correct branch
+- pushd $GOPATH/src/k8s.io && git clone https://github.com/kubernetes/kubernetes && popd
 - pushd $GOPATH/src/k8s.io/kubernetes && git checkout release-1.11 && popd
-
-# Simplified deduplication of dependencies.
 - cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
 - rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
 
+# Fetch additional dependencies to run the tests in examples/examples_test.go
+- go get -t -v k8s.io/website/content/en/examples
+
 script:
-# TODO(bep)
-- go test -v k8s.io/website/test #fixed by https://github.com/kubernetes/website/pull/8388
+- go test -v k8s.io/website/content/en/examples
 #- ./verify-docs-format.sh

OWNERS

@@ -1,19 +1,21 @@
 # Reviewers can /lgtm /approve but not sufficient for auto-merge without an
 # approver
 reviewers:
-- zhangxiaoyu-zidif
-- xiangpengzhao
+- Rajakavitha1
 - stewart-yu
-- Rajakavitha1 
+- xiangpengzhao
+- zhangxiaoyu-zidif
+
 # Approvers have all the ability of reviewers but their /approve makes
 # auto-merge happen if a /lgtm exists, or vice versa, or they can do both
 # No need for approvers to also be listed as reviewers
 approvers:
-- heckj
 - bradamant3
 - bradtopol
-- steveperry-53
-- zacharysarah
 - chenopis
+- kbarnard10
 - mistyhacks
+- steveperry-53
 - tengqm
+- zacharysarah
+- zparnold

content/en/_index.html

@@ -120,14 +120,14 @@ <h4><a href="/docs/concepts/workloads/controllers/jobs-run-to-completion/">Batch
     <main>
         <h3>Case Studies</h3>
         <div id="caseStudiesWrapper">
-          <div>
-              <p>Driving Banking Innovation with Cloud Native</p>
-              <a href="/case-studies/ing">Read more</a>
-          </div>
           <div>
               <p>Supporting Fast Decisioning Applications with Kubernetes</p>
               <a href="/case-studies/capital-one">Read more</a>
           </div>
+          <div>
+              <p>Driving Banking Innovation with Cloud Native</p>
+              <a href="/case-studies/ing">Read more</a>
+          </div>
           <div>
               <p>Cloud Native at Northwestern Mutual</p>
               <a href="/case-studies/northwestern-mutual/">Read more</a>

content/en/blog/_posts/2018-06-05-meet-our-contributors-youtube-mentoring-series.md

@@ -0,0 +1,24 @@
+---
+layout: blog
+title: Meet Our Contributors - Monthly Streaming YouTube Mentoring Series
+date: 2018-07-10
+---
+
+**Author**: Paris Pittman (Google)
+
+![meet_our_contributors](/images/blog/2018-06-05-meet-our-contributors-youtube-mentoring-series/meet-our-contributors.png)
+
+July 11th at 2:30pm and 8pm UTC kicks off our next installment of Meet Our Contributors YouTube series. This month is special: members of the steering committee will be on to answer any and all questions from the community on the first 30 minutes of the 8pm UTC session. More on submitting questions below.
+
+[Meet Our Contributors](https://github.com/kubernetes/community/blob/master/mentoring/meet-our-contributors.md) was created to give an opportunity to new and current contributors alike to get time in front of our upstream community to ask questions that you would typically ask a mentor. We have 3-6 contributors on each session (an AM and PM session depending on where you are in the world!) answer questions [live on a YouTube stream](https://www.youtube.com/c/KubernetesCommunity/live). If you miss it, don’t stress, the recording is up after it’s over. Check out a past episode [here](https://www.youtube.com/watch?v=EVsXi3Zhlo0&list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F).
+
+As you can imagine, the questions span broadly from introductory - “what’s a SIG?” to more advanced - “why’s my test flaking?” You’ll also hear growth related advice questions such as “what’s my best path to becoming an approver?” We’re happy to do a live code/docs review or explain part of the codebase as long as we have a few days notice.
+
+We answer at least 10 questions per session and have helped 500+ people to date. This is a scalable mentoring initiative that makes it easy for all parties to share information, get advice, and get going with what they are trying to accomplish. We encourage you to submit questions for our next session:
+
+- Join the Kubernetes Slack channel - #meet-our-contributors - to ask your question or for more detailed information. DM paris@ if you would like to remain anonymous.
+- Twitter works, too, with the hashtag #k8smoc
+
+If you are contributor reading this that has wanted to mentor but just can’t find the time - this is for you! [Reach out to us](https://goo.gl/forms/ZcnFiqNR5EQH03zm2).
+
+You can join us live on June 6th at 2:30pm and 8pm UTC, and every first Wednesday of the month, on the [Kubernetes Community live stream](https://www.youtube.com/c/KubernetesCommunity/live). We look forward to seeing you there!

content/en/blog/_posts/2018-07-10-coredns-ga.md

@@ -0,0 +1,180 @@
+---
+layout: blog
+title: "CoreDNS GA for Kubernetes Cluster DNS"
+date: 2018-07-10
+---
+
+**Author**: John Belamaric (Infoblox)
+
+**Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/) on what’s new in Kubernetes 1.11**
+
+## Introduction
+
+In Kubernetes 1.11, [CoreDNS](https://coredns.io) has reached General Availability (GA) for DNS-based service discovery, as an alternative to the kube-dns addon. This means that CoreDNS will be offered as an option in upcoming versions of the various installation tools. In fact, the kubeadm team chose to make it the default option starting with Kubernetes 1.11.
+
+DNS-based service discovery has been part of Kubernetes for a long time with the kube-dns cluster addon. This has generally worked pretty well, but there have been some concerns around the reliability, flexibility and security of the implementation.
+
+CoreDNS is a general-purpose, authoritative DNS server that provides a backwards-compatible, but extensible, integration with Kubernetes. It resolves the issues seen with kube-dns, and offers a number of unique features that solve a wider variety of use cases.
+
+In this article, you will learn about the differences in the implementations of kube-dns and CoreDNS, and some of the helpful extensions offered by CoreDNS.
+
+## Implemenation differences
+
+In kube-dns, several containers are used within a single pod: `kubedns`, `dnsmasq`, and `sidecar`. The `kubedns`
+container watches the Kubernetes API and serves DNS records based on the [Kubernetes DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md), `dnsmasq` provides caching and stub domain support, and `sidecar` provides metrics and health checks.
+
+This setup leads to a few issues that have been seen over time. For one, security vulnerabilities in `dnsmasq` have led to the need
+for a security-patch release of Kubernetes in the past. Additionally, because `dnsmasq` handles the stub domains,
+but `kubedns` handles the External Services, you cannot use a stub domain in an external service, which is very
+limiting to that functionality (see [dns#131](https://github.com/kubernetes/dns/issues/131)).
+
+All of these functions are done in a single container in CoreDNS, which is running a process written in Go. The
+different plugins that are enabled replicate (and enhance) the functionality found in kube-dns.
+
+## Configuring CoreDNS
+
+In kube-dns, you can [modify a ConfigMap](https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/) to change the behavior of your service discovery. This allows the addition of
+features such as serving stub domains, modifying upstream nameservers, and enabling federation.
+
+In CoreDNS, you similarly can modify the ConfigMap for the CoreDNS [Corefile](https://coredns.io/2017/07/23/corefile-explained/) to change how service discovery
+works. This Corefile configuration offers many more options than you will find in kube-dns, since it is the
+primary configuration file that CoreDNS uses for configuration of all of its features, even those that are not
+Kubernetes related.
+
+When upgrading from kube-dns to CoreDNS using `kubeadm`, your existing ConfigMap will be used to generate the
+customized Corefile for you, including all of the configuration for stub domains, federation, and upstream nameservers. See [Using CoreDNS for Service Discovery](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) for more details.
+
+
+## Bug fixes and enhancements
+
+There are several open issues with kube-dns that are resolved in CoreDNS, either in default configuration or with some customized configurations.
+
+  * [dns#55 - Custom DNS entries for kube-dns](https://github.com/kubernetes/dns/issues/55) may be handled using the "fallthrough" mechanism in the [kubernetes plugin](https://coredns.io/plugins/kubernetes), using the [rewrite plugin](https://coredns.io/plugins/rewrite), or simply serving a subzone with a different plugin such as the [file plugin](https://coredns.io/plugins/file).
+
+  * [dns#116 - Only one A record set for headless service with pods having single hostname](https://github.com/kubernetes/dns/issues/116). This issue is fixed without any additional configuration.
+  * [dns#131 - externalName not using stubDomains settings](https://github.com/kubernetes/dns/issues/131). This issue is fixed without any additional configuration.
+  * [dns#167 - enable skyDNS round robin A/AAAA records](https://github.com/kubernetes/dns/issues/167). The equivalent functionality can be configured using the [load balance plugin](https://coredns.io/plugins/loadbalance).
+  * [dns#190 - kube-dns cannot run as non-root user](https://github.com/kubernetes/dns/issues/190). This issue is solved today by using a non-default image, but it will be made the default CoreDNS behavior in a future release.
+  * [dns#232 - fix pod hostname to be podname for dns srv records](https://github.com/kubernetes/dns/issues/232) is an enhancement that is supported through the "endpoint_pod_names" feature described below.
+
+
+## Metrics
+
+The functional behavior of the default CoreDNS configuration is the same as kube-dns. However,
+one difference you need to be aware of is that the published metrics are not the same. In kube-dns,
+you get separate metrics for `dnsmasq` and `kubedns` (skydns). In CoreDNS there is a completely
+different set of metrics, since it is all a single process. You can find more details on these
+metrics on the CoreDNS [Prometheus plugin](https://coredns.io/plugins/metrics/) page.
+
+## Some special features
+
+The standard CoreDNS Kubernetes configuration is designed to be backwards compatible with the prior
+kube-dns behavior. But with some configuration changes, CoreDNS can allow you to modify how the
+DNS service discovery works in your cluster. A number of these features are intended to still be
+compliant with the [Kubernetes DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md);
+they enhance functionality but remain backward compatible. Since CoreDNS is not
+*only* made for Kubernetes, but is instead a general-purpose DNS server, there are many things you
+can do beyond that specification.
+
+### Pods verified mode
+
+In kube-dns, pod name records are "fake". That is, any "a-b-c-d.namespace.pod.cluster.local" query will
+return the IP address "a.b.c.d". In some cases, this can weaken the identity guarantees offered by TLS. So,
+CoreDNS offers a "pods verified" mode, which will only return the IP address if there is a pod in the
+specified namespace with that IP address.
+
+### Endpoint names based on pod names
+
+In kube-dns, when using a headless service, you can use an SRV request to get a list of
+all endpoints for the service:
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 10 33 0 6234396237313665.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 10 33 0 6662363165353239.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 10 33 0 6338633437303230.headless.default.svc.cluster.local.
+dnstools#
+```
+
+However, the endpoint DNS names are (for practical purposes) random. In CoreDNS, by default, you get endpoint
+DNS names based upon the endpoint IP address:
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-14.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-18.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-4.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-9.headless.default.svc.cluster.local.
+```
+
+For some applications, it is desirable to have the pod name for this, rather than the pod IP
+address (see for example [kubernetes#47992](https://github.com/kubernetes/kubernetes/issues/47992) and [coredns#1190](https://github.com/coredns/coredns/pull/1190)). To enable this in CoreDNS, you specify the "endpoint_pod_names" option in your Corefile, which results in this:
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-qv84p.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-zc8lx.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-q7lf2.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-566rt.headless.default.svc.cluster.local.
+```
+
+### Autopath
+
+CoreDNS also has a special feature to improve latency in DNS requests for external names. In Kubernetes, the
+DNS search path for pods specifies a long list of suffixes. This enables the use of short names when requesting
+services in the cluster - for example, "headless" above, rather than "headless.default.svc.cluster.local". However,
+when requesting an external name  - "infoblox.com", for example - several invalid DNS queries are made by the client,
+requiring a roundtrip from the client to kube-dns each time (actually to `dnsmasq` and then to `kubedns`, since [negative caching is disabled](https://github.com/kubernetes/dns/issues/121)):
+
+  * infoblox.com.default.svc.cluster.local -> NXDOMAIN
+  * infoblox.com.svc.cluster.local -> NXDOMAIN
+  * infoblox.com.cluster.local -> NXDOMAIN
+  * infoblox.com.your-internal-domain.com -> NXDOMAIN
+  * infoblox.com -> returns a valid record
+
+In CoreDNS, an optional feature called [autopath](https://coredns.io/plugins/autopath) can be enabled that will cause this search path to be followed
+*in the server*. That is, CoreDNS will figure out from the source IP address which namespace the client pod is in,
+and it will walk this search list until it gets a valid answer. Since the first 3 of these are resolved internally
+within CoreDNS itself, it cuts out all of the back and forth between the client and server, reducing latency.
+
+### A few other Kubernetes specific features
+
+In CoreDNS, you can use standard DNS zone transfer to export the entire DNS record set. This is useful for
+debugging your services as well as importing the cluster zone into other DNS servers.
+
+You can also filter by namespaces or a label selector. This can allow you to run specific CoreDNS instances that will only server records that match the filters, exposing only a limited set of your services via DNS.
+
+## Extensibility
+
+In addition to the features described above, CoreDNS is easily extended. It is possible to build custom versions
+of CoreDNS that include your own features. For example, this ability has been used to extend CoreDNS to do recursive resolution
+with the [unbound plugin](https://https://coredns.io/explugins/unbound), to server records directly from a database with the [pdsql plugin](https://coredns.io/explugins/pdsql), and to allow multiple CoreDNS instances to share a common level 2 cache with the [redisc plugin](https://coredns.io/explugins/redisc).
+
+Many other interesting extensions have been added, which you will find on the [External Plugins](https://coredns.io/explugins/) page of the CoreDNS site. One that is really interesting for Kubernetes and Istio users is the [kubernetai plugin](https://coredns.io/explugins/kubernetai), which allows a single CoreDNS instance to connect to multiple Kubernetes clusters and provide service discovery across all of them.
+
+## What's Next?
+
+CoreDNS is an independent project, and as such is developing many features that are not directly
+related to Kubernetes. However, a number of these will have applications within Kubernetes. For example,
+the upcoming integration with policy engines will allow CoreDNS to make intelligent choices about which endpoint
+to return when a headless service is requested. This could be used to route traffic to a local pod, or
+to a more responsive pod. Many other features are in development, and of course as an open source project, we welcome you to suggest and contribute your own features!
+
+The features and differences described above are a few examples. There is much more you can do with CoreDNS.
+You can find out more on the [CoreDNS Blog](https://coredns.io/blog).
+
+### Get involved with CoreDNS
+
+CoreDNS is an incubated [CNCF](https:://cncf.io) project.
+
+We're most active on Slack (and Github):
+
+- Slack: #coredns on <https://slack.cncf.io>
+- Github: <https://github.com/coredns/coredns>
+
+More resources can be found:
+
+- Website: <https://coredns.io>
+- Blog: <https://blog.coredns.io>
+- Twitter: [@corednsio](https://twitter.com/corednsio)
+- Mailing list/group: <coredns-discuss@googlegroups.com>