diff --git a/case-studies/index.html b/case-studies/index.html index c2a2deeab6..4bbfc62a7a 100644 --- a/case-studies/index.html +++ b/case-studies/index.html @@ -16,10 +16,28 @@ cid: caseStudies
"In the 15 months that we’ve been using Kubernetes, it has been amazing for us. It enabled us to iterate quickly, increase development speed, and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."
Read about Crowdfire +||||||| merged common ancestors +
+ "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery."
+ + Read about BlackRock +======= +
+ "Over the next couple of years, people won’t even think that much about it when they want to run containers. Kubernetes is going to be the go-to solution."
+ + Read about Haufe Group +
+ "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery."
+ + Read about BlackRock +>>>>>>> 1.10 update (#7151)
"Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes."
@@ -43,6 +62,15 @@ cid: caseStudies
+ "It’s amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better."
+ + Read about Buffer +
+<<<<<<< HEAD
+||||||| merged common ancestors
+=======
+
+>>>>>>> 1.10 update (#7151)
diff --git a/docs/concepts/cluster-administration/device-plugins.md b/docs/concepts/cluster-administration/device-plugins.md
index c8e9993e7c..8bd3249167 100644
--- a/docs/concepts/cluster-administration/device-plugins.md
+++ b/docs/concepts/cluster-administration/device-plugins.md
@@ -62,8 +62,17 @@ metadata:
name: demo-pod
spec:
containers:
+<<<<<<< HEAD
- name: demo-container-1
image: k8s.gcr.io/pause:2.0
+||||||| merged common ancestors
+ -
+ name: demo-container-1
+ image: gcr.io/google_containers/pause:2.0
+=======
+ - name: demo-container-1
+ image: gcr.io/google_containers/pause:2.0
+>>>>>>> 1.10 update (#7151)
resources:
limits:
vendor-domain/resource: 2 # requesting 2 vendor-domain/resource
diff --git a/docs/concepts/configuration/pod-priority-preemption.md b/docs/concepts/configuration/pod-priority-preemption.md
index dc482b11e1..54b0fe06a8 100644
--- a/docs/concepts/configuration/pod-priority-preemption.md
+++ b/docs/concepts/configuration/pod-priority-preemption.md
@@ -220,11 +220,23 @@ can be scheduled on N. P might become feasible on N only if a Pod on another
Node is preempted. Here's an example:
* Pod P is being considered for Node N.
+<<<<<<< HEAD
* Pod Q is running on another Node in the same Zone as Node N.
* Pod P has Zone-wide anti-affinity with Pod Q
(`topologyKey: failure-domain.beta.kubernetes.io/zone`).
* There are no other cases of anti-affinity between Pod P and other Pods in the Zone.
* In order to schedule Pod P on Node N, Pod Q can be preempted, but scheduler
+||||||| merged common ancestors
+* Pod Q is running on another Node in the same zone as Node N.
+* Pod P has anit-affinity with Pod Q.
+* There are no other cases of anti-affinity between Pod P and other Pods in the zone.
+* In order to schedule Pod P on Node N, Pod Q should be preempted, but scheduler
+=======
+* Pod Q is running on another Node in the same zone as Node N.
+* Pod P has anti-affinity with Pod Q.
+* There are no other cases of anti-affinity between Pod P and other Pods in the zone.
+* In order to schedule Pod P on Node N, Pod Q should be preempted, but scheduler
+>>>>>>> 1.10 update (#7151)
does not perform cross-node preemption. So, Pod P will be deemed unschedulable
on Node N.